[Openicc] colord Printing Plans

[Chris Murphy]

On Feb 24, 2011, at 6:11 PM, Graeme Gill wrote:

> Chris Murphy wrote:
>> I admit this is unique on Linux. On Mac OS and Windows, the legacy RGB path is not
>> PostScript but QuickDraw and GDI, and for Mac OS today now that QuickDraw is deprecated
>> it is Quartz which can do either RGB or CMYK.
> 
> This may be so for color unsophisticated applications, but anything sophisticated
> has used "PostScript Bypass" to inject its own PS into the print job on MSWin and Mac.

Those sophisticated applications are producing CMYK PostScript streams. And on Mac OS and Windows, those are pass through. They are always untouched for the very reason they have unique PostScript.


>> it in the first place. If the application is seriously producing untagged data across
>> the board including saving out its own document format, then neither that developer nor
>> its users really care one bit about color. I am not opposed to the idea of building
> 
> This isn't strictly true. They expect DeviceXXX to be a "reasonable" color space,
> not the actual device colorspace. For RGB that means something that compares
> to what they see on their display. For CMYK, that means something that compares
> to a standard printing press or the Pantone CMYK swatches. Any system that is to be
> regarded as having satisfactory color, meets these expectations. (Take that as a
> lesson from spending 10 years developing PS RIPS).


If only the manufacturers cared to properly document these behaviors in their manuals, and the PPDs, and ensured the simulations actually correlated to something other than dog crap. Then maybe there'd be a chance. But historically, they are pretty poorly behaved devices, that behave very inconsistently hour to hour, and lack transparency in their behavior.


Chris Murphy