[Openicc] Gutenprint team requests CM-off for a print queue be provided as a maintained engineering facility.

[Chris Murphy]

Michael,


On May 11, 2012, at 11:13 AM, Michael Sweet wrote:
> 
> It's not that /DeviceRGB is banned, it is that /DeviceRGB is interpreted as sRGB by CoreGraphics and you need to use OutputIntents to effectively turn it off (to say that it isn't sRGB but the device RGB colorspace reported by your driver or registered by the user).  I think everyone in our team thinks this is less than optimal but is a "necessary evil" until we figure out something better to deal with the multitude of PDF files that use DeviceRGB but really mean sRGB (or some display RGB).

There is no multitude of PDFs that are: PDF/X-3 + contain RGB output intent + contain /DeviceRGB objects. That's a very unique PDF, and I'd argue only occurs in a case where /DeviceRGB is "prematched" or otherwise intended to be left alone, as-is.

For PDF's that do not contain an OutputIntent, are not PDF/X-3 compliant, fine. Second guess away, and treat /DeviceRGB with a substitute.

The Quartz PDF Context is certainly banning /DeviceRGB because to my knowledge it never causes such objects to be written into a PDF print spool file. All intercepts I've done where the application did not tag RGB content, at the time the PDF was written, /DeviceRGB was not employed, sRGB or GenericRGB was immediately substituted. Now, I'll buy off on this for applications that don't use KPMApplicationColorMatching, but apps that do should follow a rather well tested workflow in PDF/X-3 and use both an OutputIntent and /DeviceRGB as the explicit off switch, rather than depending on matching source-destination.

In scenarios where KPMApplicationColorMatching doesn't work, I see in the PDF, ICCBased objects that don't match the OutputIntent. This should be disallowed. As in fail to write out the PDF, or ignore ICCBased tags, and make objects /DeviceRGB (or /DeviceCMYK) when the SPI is used.



> 
>> 2. The SPI for applications to achieve this null transform (hopefully) is private. It's not a public API.
> 
> Correct, but it is provided by the developer relations folks to any app developer that needs it (profiling tools, professional graphics tools with built-in color management, etc.)

That's a recent development. And it's logically problematic for a developer to ask for something that they have no way of knowing exists in the first place.


> Another problem with the current implementation is that ICC profiles are not tied to the options used to print the target and generate the profile.  Users will turn every knob trying to get "right color" and end up never producing consistent results.

I understand that neither magic nor mindreaders can be shipped with the product, yet.


>> I see no risk of 1, or 2 occurring in any Linux distribution.
>> 
>> I think the OpenICC's position should mere be that: there must be a clearly, and publicly defined mechanism for disabling system level color management. 
> 
> I think that is a misnomer - color management is always there.

A fair criticism, as I castigate its use regularly myself, and then turn around and use it. I do mean disabling transforms at a system level, at a minimum. Better would be a message/tag that means the same thing to multiple levels: system level "no transform", application level "no transform, and print driver "ICC based compatible mode + calibration applied".


> I can't say that the way we do it on OS X is optimal since, well, it isn't, but it does clearly define which device/output colorspace is intended.

It misses the objects themselves. If they were ensured to be only /DeviceRGB, in the case of the highly problematic raster drivers, even bugs in the print drivers would have been vastly undercut. They could have returned, "DestroyAllLifeRGB.icc" back to the OS, which would have been embedded as OutputIntent, and we'd still have a no-op for printing prematched images, or targets.

But from day 1, now almost 10 years ago, this argument was made by me and two other people, was ignored. Here we are. This is not a new criticism. It's truly mystifying to me why things are the way they still are.

And all the more reason why I don't think the concerns in this list about Mac OS behaviors being repeated elsewhere are with much merit. It's a unique case, not easily repeated.


Chris Murphy