[Openicc] colord 0.1.0 released!

[Chris Murphy]

On Jan 17, 2011, at 7:46 PM, Leonard Rosenthol wrote:

> On Mon, Jan 17, 2011 at 8:32 PM, Hal V. Engel <hvengel at gmail.com> wrote:
> 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).  
> 
> EXCEPT that in the case of PDF processing, there is NO SUCH THING as "no color management".  The standard itself goes into detail about how (ICC-based) color management is used as part of the rendering pipeline.  For PDF/X (and PDF/A), this is even more significant.

OK so I want to better understand this before inevitable suggestions of an explicit "off" flag in PDF for the purposes of supporting a PDF based print spool file format, and printing profile targets comes up.

My understanding is that in PDF/X-3 (and 4 and 5), that /DeviceRGB =! ICCBased and is effectively "no color management" in the context of outputting to the OutputIntent device. If there is a mismatch, a redirection for example, of that PDF to some other output device: a proofing device, or a display, then the context is different and it means all /DeviceRGB objects have an implicit source profile = OutputIntent and thus are treated as ICCBased. So there is the possibility of "no color management" but it is conditional.

Is this a fair way of describing it?

Is there a need for an immutable "off" flag for ensuring objects aren't color managed no matter what? I'm not sure that there is, and that any desire to create one is probably just a knee jerk reaction from what Apple has subjected professionals to. If they're going to ignore /DeviceRGB because untagged RGB data is evil, they will ignore an immutable off flag too, because untagged RGB data is evil.

Chris Murphy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110119/9e4328c4/attachment.htm>