[Openicc] colord 0.1.0 released!

[Hal V. Engel]

On Monday, January 17, 2011 04:41:26 pm Graeme Gill wrote:
> Alastair M. Robinson wrote:
> > In that case the rendering pipeline needs to detect when source and
> > destination profiles are identical, and bypass the transform completely.
> > Allowing the CM engine to transform the data between two CMYK profiles
> > would be disastrous for profiling - even if they're identical - because
> > it would mess up the GCR.
> 
> But this is exactly the root cause of the Apple profiling problems !
> 
> They treat matching profiles as a null transform, and as a side
> effect use it to pass unmodified numbers to the device.
> 
> Relying on such a match is fragile, and is not a direct way
> to signal the actual intention. Don't follow Apple down
> into this mess! If you want to disable certain transforms,
> be explicit about it, that way the intention signalling
> is robust.

I agree with this.  The UI design related to CM for the CPD allows for this to 
be directly over ridden (IE. there is a "no color management" option that is 
part of the UI design).   This is not something that is on by default and it 
does require drilling down into the settings in the CPD to do this.   Of 
course at this point this is all "on paper" only since nothing related to CM 
has been implemented in the current CPD code. The problem is that we still 
don't have a well defined printing CM architecture that this can be built on 
top of.  How does this flag get passed into CUPS so that it can turn off CM in 
the *toraster filters?

Also as a side note I see that there is a pdftoraster.c file that is part of GS 
9.  Is this a CM enabled replacement for the pdftoraster CUPS filter?  Or is 
this something else?  Has anyone had a chance to look at GS 9 yet to see if it 
has what is needed to be a basis for a CM enabled CUPS PDF based work flow?

Hal