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

[Kai-Uwe Behrmann]

Am 09.02.11, 11:26 -0700 schrieb Chris Murphy:
> On Feb 9, 2011, at 9:46 AM, Jan-Peter Homann wrote:
>>
>> PDFtoRaster
>> It is important to define, how the current valid cupsICC profile is 
>> merged into the print workflow:
>> - placed as PDF Output Intent in the print spool PDF (this needs a e.g. 
>> specialized CUPS filter to do this), before it is send to PDFtoRaster. 
>> In this case PDFtoRaster don`t needs any configuration for the cupsICC 
>> profile.
>
> I think the most appropriate place is right at PDF print spool 
> generation time. Obviously the ideal is for every PDF print spool file 
> to perfectly state its case in all respects, including color intent and 
> how it is to be converted for printing. But I'm not familiar enough with 
> what actually produces the PDF print spool file to know how reliably it 
> will tag objects correctly, including the setting of (at least) a 
> default OutputIntent.

Where should the OutputIntent come from? From application, if not from 
CPD, if not fall back to cupsICC?

> If the generation of the PDF print spool file is centralized, and can be 
> made consistent, great. Then pdftoraster, pdftops, pdftotiff, pdftoOTHER 
> all just need to share some code to properly interpret these PDFs with 
> the help of Ghostscript, to produce consistent results as raster, 
> postscript, tiff, and OTHER file formats that represent the intent of 
> the PDF. Also, if this is always reliable, then we can enable our 
> explicit color management off switch for calibration and profiling 
> devices very literally as well (i.e. no ICCBased objects, no 
> OutputIntent, and that's the off switch). So is there some single 
> library or process that all applications can use to produce a PDF print 
> spool file? I suspect not, but have to ask.

A convention to opt-out of colour management could as well be
DeviceXXX + OutputIntent. Thus its clear the PDF/A/E/X comes from a CM 
aware side and its intention is no to override the embedded destination 
profile.

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?


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