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

[Chris Murphy]

After reading all of the emails in this thread, I'm not really understanding precisely what the request is, nor am I distinctly hearing a denial of that request (whatever it is).

I don't get the impression that an explicit off switch is being denied. I think there is a question on the presentation of that off switch in terms of UI.

/DeviceRGB and /DeviceCMYK are kinds of explicit off switches, in that they don't require interpretation/analysis downstream. The default condition, in particular a PDF/X-3(4,5) context is to leave the data alone so long as the mode of the destination device supports the mode of such objects.

The problems on Mac OS are very specific:

1.  /DeviceRGB is banned and ipso facto this demands the insertion of bogus tags in order to achieve the equivalent of "off" which is the null transform: an interpretive off switch, not an explicit one.

2. The SPI for applications to achieve this null transform (hopefully) is private. It's not a public API.

3. An overly complicated imaging and printing pipeline, in particular as it relates to color, without commensurate documentation with detailed explanations and examples.

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 this should be in the form of an an API. I don't think it should be presented in the GUI.[1]

I don't think it's reasonable at all to consider random applications suitable for printing profiling targets. That has never been the case on Mac OS or Windows, best practices *required* that such combinations be tested against a reference. It was never something that could be assumed because of the existence of an apparent "off switch". To make it reliable would require qualification testing of every possible combination. And I think that's a huge waste of resources.

So I personally think there are two things that are needed:

1. An API, so that any application that implements its own internal color management, or needs to print profile/calibration targets, can effectively disable system level color management on a print job basis.

2. A CLI tool, that allows me to disable system color management at a device (minimum). A queue level switch would be better, that way I can have an "off" queue and an "auto" queue for the same printer. This I can use to test #1, and indirectly achieve the means to do my own qualification of apps that don't use the API.

But a GUI switch? No thank you.

[1] However, if such a GUI instance is going to appear, for sure the terminology of "No Color Management" or "Color Management Off" or whatever, should be stricken from the GUI lexicon. This is hideously misleading. In that sense, I prefer Max's terms. For an app that implements color management internally, "Normal Printing" would use the API to disable system level color management, and "Printer Profiling" would disable both system and application level color management.