[Openicc] colord Printing Plans, CPD and Gutenprint role of PPD

Chris Murphy lists at colorremedies.com
Tue Mar 1 14:11:31 PST 2011


> 
> 
>> Cloud printing is another area of exploration of the issues, and might go in a v1.0 or maybe v1.5. How must it differ from local printing? Or maybe how doesn't it differ at all? And what do the cloud printing
> 
> From a architectural and interoperational point of view, it makes sense to put all required informations inside the PDF in a standard way. Thus any remote side is free to support these features.


The "off flag" token is a particular challenge. It's so rare, but so important that it be honored, that we do need a clever way to deal with this. Rewriting every single PDF and PS file, to stamp out /DeviceRGB or /DeviceCMYK (let alone conditionally) is complicated. And yet, doing nothing means applications that don't tag their print spools do not get any kind of color management while others do, and that means inconsistency.

On Mac OS, either Preview.app or Acrobat are used for viewing and printing PDFs. /DeviceRGB is never honored to RGB displays, for example. By default in both apps now, it's assumed to be sRGB. And then when printing, again assumed by the print driver in a proprietary non-ICC context to be sRGB. So we get something coherent both on display and print. But certainly we do *NOT* get a /DeviceRGB result on either display or print.

On Windows, Acrobat is of course common so it behaves the same way. I do not know what the common alternatives to Acrobat are on Windows, or how they behave. I suspect they behave this way for print, but perhaps the display compensation component is missing.

So this little nugget really requires some consideration and resolution because from it a *TON* of other assumptions and coding have dependencies on it.


Chris Murphy


More information about the openicc mailing list