[Openicc] Linux printing

[Chris Murphy]

On Feb 27, 2012, at 10:52 PM, Michael Vrhel wrote:

> It is not true that Ghostscript will assume DeviceRGB is sRGB.  Ghostscript can be specified to use specific ICC profiles for DeviceGray, DeviceRGB and DeviceCMYK.  In fact, Ghostscript can have different source ICC profiles specified for different graphic types (e.g. text, graphics and images in DeviceRGB and DeviceCMYK color spaces).   These can even override ICC profiles that are internally specified within the document.    Object dependent ICC profiles can also be specified for the output device ICC profile and DeviceN source color spaces can be specified with external ICC profiles.

For what it's worth, the idea of overriding embedded profiles in a document is a big problem. If the wrong source profile is embedded, the PDF needs to print like crap, and the offending user or application that produced the PDF needs to fix their error.

Hacks that ignore embedded profiles is what destroyed the original PNG based color management implementation. Apps wrote out PNGs with bogus color information, and when honored by viewing applications the images looked whacky. So PNG viewer application developers started to ignore the color/gamma metadata in PNG, rendering that whole paradigm entirely useless.

Second guessing embedded metadata is just like second guessing actual data. Apps, RIPs, printers themselves are not ignoring RGB 232, 50, 100 in favor of some other values. They should not be ignoring embedded profiles in favor of some other values either.

The mere option of overriding embedded profiles is like handing developers and users razor blades and telling them to go play out on the freeway. It will regress the consistency of color management, by making it even less consistent than it already is.


Chris Murphy