[Openicc] colord 0.1.0 released!

[Chris Murphy]

On Jan 18, 2011, at 1:38 AM, Kai-Uwe Behrmann wrote:
> 
> We seem to stuck to eigther work on the PDF spec, which is not a trivial task and then just for generating pass through target files.
> 
> Or we define a way to bypass PDF. This will be most likely some raster like Tiff with the appropriate "no color management" flag.
> 
> Till,
> can you highlight where a "no color management" flag would best fit into the pipeline from CPD to get seen by all intermediate stages until the print driver. Could that be the image file itself or a job ticket file?
> The goal is to send unaltered device values to a given printer for profiling.

Funny enough, PDF print spool files written out by Apple's Quartz PDFContext upon the application calling for the SPI that should cause colorsync to be disabled, contain the following XML:

<key>AP_ColorMatchingMode</key>  <string>AP_ApplicationColorMatching</string>

So there is already a sort of flag in the f'n PDF that clearly describes the intent: NO COLOR MANAGEMENT. Well, Apple's cgpdftoraster filter ignores it and color manages the file anyway. It's so completely frustratingly stupid.

The point is, you can still have some downstream component that does things the wrong way, because the conclusion by the designers is woven into their premises. I think PDF/X-4 (and even PDF/X-3) has a way to do exactly what we want with respect to reliably printing profile targets, it simply requires that all components follow the specification, which would have to be the case anyway.

So until convinced otherwise, I'm going to stick to my guns that we just follow the specs. And if there is some problem that prevents us from doing what we want, change the spec rather than creating yet another sub-species of PDF with an obscure custom flag for a singular purpose that could still be ignored.


Chris Murphy