[cairo] Spot colors (and CMYK)

[Bill Spitzak]

I absolutely agree with this!

If sRGB is unclamped floating point, it can fully specify any point in 
any 3-Dimensional color space, including XYZ or any Lab space and any 
other triplet of color primaries and any 3-primary ICC profile.

By the "keep it simple" principle this means there is no reason to have 
more than 1 3D color space to specify colors, since the application can 
convert any other color to it. By the obvious and OVERWHELMING 
requirement to specify colors in sRGB it means that sRGB must be this 
single space.

There also seems to be lots of indications from the color management 
experts that all 4 and above dimensional spaces, including CMYK, are 
highly device specific, and that all useable methods of converting them 
to standard colors involve reducing that space to a 3D intermediate 
space. Therefore I cannot see any possible reason to not have the 
application do this and use the Cairo sRGB api.

MAYBE there needs to be a channel to communicate that a specific device 
color is needed. This includes the CMYK inks. I think the best way to do 
this is to examine exactly what PDF users need and add an api 
specifically for that, just like there are many other PDF-specific apis 
already in there. Most likely a "the current color is actually this spot 
color" api that is ignored or unimplemented by other back ends. This is 
just another channel composited just like RGB, Cairo does NOT calculate 
ink mixtures, and compositing white atop it will just cause less of it 
to be printed.

Also for a basic point about "color management": If your program takes a 
screen shot and puts it back on the screen, or displays an 8-bit image 
produced by another piece of software on that screen, and it looks 
different, IT IS BROKEN. I don't care if some color management expert 
says that somehow it is correct, I can tell it is broken and it makes 
the software either unusable or very unappealing. This is something 
Microsoft understands but it seems Apple and a lot of Linux folk do not.

The practical result is that buffers either must have much more than 8 
bits or they must store sRGB values. If they are 8 bits then either raw 
sRGB values must be sent to the display, or color management must be 
done by hardware between the buffer and the display. If you do actually 
store non-sRGB values the color space must be significantly close to 
sRGB so that composite mixtures do not vary too much in color, in 
particular on my work with Nuke I have learned that linear space is too 
far away for users and they will complain.

Carl Worth wrote:

> I'm much more interested in optimizing the API than optimizing the
> implementation.
> 
> So if floating-point RGB allows a user to specify exactly what the user
> could specify with LAB or XYZ, then I'm delighted to offer only the RGB
> API in cairo and have the application convert to that.