[Openicc] Printing Plans GhostScript

[Chris Murphy]

On Mar 1, 2011, at 3:52 PM, Gerhard Fuernkranz wrote:

> Am 01.03.2011 22:14, schrieb Kai-Uwe Behrmann:
>> Retargeting is a special feature. It makes sense to retarget
>> automatical if the DeviceXXX color space does not match. For instance
>> a DeviceCMYK PDF sent to a DeviceRGB device should be converted using
>> the OutputIntent. The same for displaying DeviceCMYK on the screen.
>> This was mentioned previously here on list. That seems easy to agree
>> about.
>> 
>> A DeviceRGB sent to a RGB device should not be changed automatical IMO.
> 
> Well, I'm not sure whether users would understand why their untagged
> sRGB documents are printed nicely on a CMYK printer, while the same
> documents are printed with wrong colors on a printer which happens to
> have a RGB ProcessColorModel, although they have profiled the RGB
> printer as well.
> 
> The issue of interest is actually how the DeviceXXX colors _in the
> document_ should be interpreted, and I do not see why this
> interpretation should depend on the ProcessColorModel the printer
> happens to have. I don't think that users would like to see a different
> behavior when they submit the same print job a) to a CMYK printer and b)
> to an RGB printer - for them both are just printers.

Color managing device colors means redefining the present concept of device color. I think this is a small problem, in that Adobe already does this for PDF, and so does Apple. And perhaps others too on Windows.

Not color managing device colors means exactly what you say. And that too is a problem.

Someone with Windows 7 can double check for me, but I'm pretty sure it does not produce a display profile based on EDID still. And instead assumes the display profile is sRGB. It's a complete crock, ten years after Mac OS has been doing this. So that would mean fairly 90% of the computer market (Windows) does, in fact, have /DeviceRGB to the display* and then assumed sRGB for the printer, in a PDF context.

In Microsoft's imagination, displays bearing the Windows logo are supposed to conform to sRGB out of the box. But what a colossally ridiculous position to continue to take today, rather than requiring that EDID data be correct, and then building a display profile on the fly? 8-\


* Since /DeviceRGB is redefined by Acrobat to be sRGB by default, and the OS assumes sRGB as the display profile, and Acrobat gets the display profile from the OS, there is a null transform in Acrobat. UNLIKE on Mac OS, where display compensation is the default behavior.


Chris Murphy