[Openicc] Re: Hello *and* (was): LINUX, Gutenprint / CUPS / Color policies

Chris Murphy lists at colorremedies.com
Fri May 13 02:52:34 EST 2005


On May 11, 2005, at 11:43 PM, Graeme Gill wrote:

> It's a matter of semantics. By some views, the driver is "part of  
> the OS".

It's a 3rd party "part of the OS" then.

> In the tagged view of color, every element that handles color data
> has some mechanism available to convert from the colorspace the data
> is in, to the colorspace that processing element needs it in to do  
> its job.
> This conversion could be handled almost transparently by other
> OS elements, or might be quite explicit within the print driver.
> A printer driver (in the broad sense) has a primary job of seeing
> that the graphic information it is given, is transformed into a
> form suitable for the printing device. Making sure (by whatever
> underlying mechanism) that the color space is correct for the
> printer is fundamental.

A driver ensuring conversion from pixels to commands to produce  
droplets in a reasonably consistent, predictable and logical manner  
is fundamental. Colorimetric accuracy is not.

No print drivers from the major manufacturers perform color  
management with a particular print job containing multiple source  
profiles. On both platforms, this is deferred to the operating system  
to manage with input from the printer driver based on print dialog  
settings. In-driver color management is limited to black box color  
management with an assumed source space and destination space of some  
kind, along with the various ink limiting and black generation they  
choose to use for each paper type. I  haven't heard a compelling  
argument for making printer drivers more sophisticated in this  
regard. More complexity means more points for failure, and  
differences in behavior from printer to printer, and that doesn't  
help anyone. They are already complicated enough, and lacking  
sufficient documentation on Mac OS X, at least, that the CMS isn't  
getting correct information from the driver and thus the whole  
shebang is busted. Putting more dependency on successful outcomes on  
driver developers, I think, will only make the problem worse.


Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
-------------------------------------------------------------
Co-author "Real World Color Management, 2nd Edition"
Published by PeachPit Press (ISBN 0-321-26722-2)




More information about the openicc mailing list