Re: [Openicc] colord 0.1.0 released!

[Robert Krawitz <rlk alum mit edu>]

On Mon, 17 Jan 2011 09:00:52 -0500, Leonard Rosenthol wrote:
> On Mon, Jan 17, 2011 at 8:49 AM, edmund ronald <edmundronald gmail com>wrote:
>
>> My feeling is that it is very important not only to be able to turn
>> all CMS off for a printer,
>
> Just to be pedantic, since it's VERY important here, what you really mean is
> turn off DRIVER color management.  There are no provisions at the
> CUPS/GutenPrint level to turn off APPLICATION CM _NOR_ to turn off HARDWARE
> CM...and both of those can (of course) play a part in the whole pipeline....

To be even more precise, what we really mean is to turn off all color
management at the system software level.

Anything at the device level -- whether implemented in hardware or
firmware -- is simply part of the device response, which of course we
have no control over.  That's part of what's getting profiled.  And
people (hopefully) won't create profiles with software that's already
playing games behind the user's back.

For that matter, the printer driver (e. g. Gutenprint) itself can be
considered to be part of the device, since it's represented by the PPD
file.

The real issue here is making sure that CUPS and its filter chain
don't modify color data on the way down unless they're told to, and
when they do so, it must be predictable.  That's the problem on OS X:
there doesn't seem to be any way to ensure that data from the
application reaches the printer (or driver) unmodified.  In other
words, if we send an RGB tuple (97, 38, 108) from an application, we
have no way to guarantee that Gutenprint sees that same RGB value.