[Openicc] CUPS Color Management under Linux... (what is to do ?)

[Chris Murphy]

On Feb 10, 2011, at 2:50 PM, Kai-Uwe Behrmann wrote:
>> 
>> If those source objects are not set correctly by the CPD, we have a problem.
> 
> It is more a convention, of course following the PDF spec. A calibration application can send even a ready PDF and is done. CPD is then not at all needed.

OK.

> 
>> For this to be really consistent, you'd have to have the CPD *strip* ICC profile metadata if the application submits tagged objects for printing.
> 
> This puts the responsibility into CPD and as well much work. But why? Documenting that DeviceXXX + OutputIntent fitting to the device behavior as a precondition for calibration is enough. Developers can debug their own stuff.

OK, but the consequence of CPD being unable to strip means if the user chooses "no color management" in the CPD, they will get different results application to application.


> 
>> If those objects are ICCBased, and the user chooses in the CPD a "no color management" option, are we really going to have the CPD responsible for changing ICCBased objects to /DeviceXXXX? Or is it easier to pass a "color management OFF" flag as metadata, and then for something downstream to know to ignore all ICC profiles in the PDF print spool file?
> 
> Its not easily on the agenda now. Maybe for a future version.

I don't think any of this is probably easy.



> 
>>> 
>>> The model of DeviceXXX and no OutputIntent appears to me as fragile. What if some filter assumes this PDF as coming from a CM unaware source and tries to fix that, e.g. remote?
>> 
>> Well if the CPD is 100% reliable in setting an OutputIntent no matter what, EXCEPT when "no color management" is chosen by the user, then that means the absence of OutputIntent is the same as "no color management" and should be reliable.
> 
> Why should CPD do that? It set a local configured ICC profile as OutpuIntent. If there is none then there is none and done. A obligation for CPD to must set the OutpuIntent can become a burden.

I'm not saying it should, I'm saying if, based on Hal's suggestion the CPD do this. If not the CPD, then what puts the OutputIntent into every PDF print spool file? If it's up to the application, that means opt-in color management. I thought the context of the discussion was applications had to opt-out if they DON'T want color management, otherwise you only end up with a few apps that opt-in that print correctly.


>> 
>> CONCLUSION:
>> As I think about it, the most reliable "no color management" tag is a message directly to the thing that does the conversions. And that's the CMM. So the message would be a particular kind of ICC profile.
> 
> As a additional hint it might be fine.
> 
> 
> A small comparision for "colour management off" methods in printing:
> 
> CPD controls everything
> * UI options can be exposed for "no colour management" or "switch off"
> * more UI options mean, users can fail etc.
> * many new(?) strip and convert capabilities to be implemented in
>  poppler/GS
> * alternative paths are not likely, e.g. direct CUPS user, command
>  line
> 
> DeviceXXX + OutputIntent
> * no UI option needed in CPD, its a application option
> * flexible to be used on the command line, etc.
> * useful for opt-out in apps, e.g. proofing
> * conforms to PDF/X (A,E) spec
> 
> DeviceXXX - OutputIntent
> * no UI option needed in CPD, its a application thing
> * flexible to be used on the command line, etc.
> * useful for opt-out, e.g. proofing
> * cupsICC might jump in
> * not well defined by the PDF spec(?) and spool files might get "fixed"
>  elsewhere


OK wait. CPD is not mutually exclusive from setting an OutputIntent. It very well may be the mechanism by which an OutputIntent is reliably set for every PDF print spool file.

If you don't have something ensuring an OutputIntent is set in every PDF: application, and/or CPD, and/or pdftopdf and/or pdftoraster & OTHER (using *cupsICCProfile), then you will have different behavior among applications. There's got to be a sequence of stop gaps, we can't just depend on applications writing PDF correctly.

Chris Murphy