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

[Kai-Uwe Behrmann]

Am 10.02.11, 15:19 +1100 schrieb Graeme Gill:
> Hal V. Engel wrote:
>> 1.  If an app turns this switch on and then sends a PDF with only DeviceXXX
>> objects and with no OutputIntent then this is an app that is explicity
>> requesting that the output go unaltered to the printer.   There is 
>> absolutely
>> no ambiguity.
>
> What if a DeviceXXX inappropriate for the device is used ? How are device 
> independent
> colorspace definitions handled ? (ie. should it error ?)

That indicates to me that a PDF without OutputIntent for the 
purpose of calibration is not rebust enough to pass as spool file.

In the above case I could imagine someone to simply put a smart pdftopdf 
filter in the chain to catch such wrong PDFs and "fix" them.

> [One of the issues we saw in the PS world was PS files that were in just
> a single device space DeviceRGB or DeviceCMYK _except_ that they had
> the odd bits of DeviceGray for lettering, lines etc. It shouldn't happen,
> but it did.]
>
>> 3. Like #2 except the app sets an OutputIntent and it is over riding the
>> system default profile.  The profile setup in OutputIntent will always be 
>> used.
>
> What about 3a, where you want to proof ? (ie. the file gets rendered to the
> OutputIntent, and then re-rendered to the actual output device).

A application, which can opt-out in colour management is free to render to 
whatever colours before sending the file to the print system. The linux 
print system should IMO not support such valuable, but clearly exotic 
features like proofing in its code. It should rather allow such 
features elsewere in the chain, e.g. before PDF creation.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org