[cups.development] Color management in a cups raster driver

[Michael Sweet]

On Sep 16, 2009, at 11:35 AM, Laser, Curtis wrote:
> I am working on a CUPS driver for a color printer. The driver accepts
> cupsRaster data (as created by cgpdfToRaster on Mac OS X). I have been
> pouring over the CUPS documentation and have been left with some
> questions.
>
> There are two cups custom ppd keywords  to help with ICC profiles. The
> first is cupsColorProfile which is deprecated. The other is
> cupsICCProfile.

There is also a third way via the custom color matching keywords;  
information on this is provided right after the section on ICC  
profiles. See:

     http://www.cups.org/documentation.php/spec-ppd.html#APCustom

Basically this path tells the printing system you use one of a few  
standard colorspaces in your driver.

> These options provide for a single ICC profile to take
> the color from source space to device space. Traditionally we have
> used two tables, one goes from RGB to a device independent colorspace
> and the second goes from that space to CMYK. I can combine these
> profiles I suppose but it increases the number of profiles I must ship
> with the driver due to the number of combinations. Is there any way to
> specify a chain of profiles?

OK, so we aren't looking for a profile that converts from a specific  
source space to device. Rather, the profiles are selected using one or  
more PPD options (such as ColorModel, MediaType, and Resolution) so  
that CoreGraphics and ColorSync can generate the right device color  
for your driver. The PCS for these profiles needs to be CIE XYZ or CIE  
Lab, per the ICC spec. We'll hook up the source (document) color  
profiles to your device profile to convert to device color.

> However, all of this may be moot because there is a note in the spec
> that says none of the raster filters currently support ICC profiles.
> Is this still true today, even with the filters in Mac OS X 10.6?

Per the CUPS documentation, Mac OS X has supported ICC color profiles  
since 10.3. The note is for the open source CUPS filters  
(Ghostscript's pstoraster and the imagetops, and imagetoraster filters  
from the CUPS sources) which still do not support them. Perhaps we can  
make this more clear, but basically Linux (in particular) does not yet  
have a system-wide color management system in place - the best we can  
do is use LCMS (or some other open source ICC library) to do the color  
conversions, and make lots of assumptions when working with untagged  
color values.

> Are any specific actions taken by the printing system based on the
> value of pseudo-setpagedevice key OutputType (other than setting it in
> the raster header), or is that defined simply so the driver can use  
> it?

That's just there for the driver.

> Are any specific actions taken by the printing system based on the
> value of pseudo-setpagedevice key cupsRenderingIntent (other than
> setting it in the raster header), or is that defined simply so the
> driver can use it?

Currently just for the driver; conceptually it might also be used by  
the RIP filters when generating device color data, but that doesn't  
currently happen - on Mac OS X we put the rendering intent in the PDF  
print file where it could potentially be applied differently for  
different parts of the page...

> And though it has nothing to do with color, I would also like to know
> if any actions are taken by the print system based on the value of the
> pseudo-setpagedevice key OutputFaceUp (other than setting it in the
> raster header), and more generally what its purpose is.

We don't use it directly; it is there for the driver to use, and  
generally should control whether the output is face up or face down.   
For example, some printers can do this independent of the output bin  
while others would use this to select between bins.

___________________________________________________
Michael Sweet, Senior Printing System Engineer