[cairo] Spot colors (and CMYK)

[Bill Spitzak]

Chris Murphy wrote:
> On Feb 22, 2010, at 10:53 PM, Bill Spitzak wrote:
> 
>> Jon Cruz wrote:
>>
>>> Cairo needs to emit proper CMYK+spot details to the PDF.
>>> Cairo *should* at the same time be able to 'preview' to an RGB display.
>>> If that preview does not have ANYTHING to do with the spot color specified, then most even semi-profesionals will laugh their heads off at Open Source and dismiss such software as mere toys.
>> This sounds completely impossible. It sounds like you want composites in Cairo where some of the input is a spot color to exactly reproduce whatever effects the overprinting and mixing of the ink does on the printer.
> 
> A DeviceN (multichannel) profile with a CMS will do this for you. I don't know if lcms supports 5+ channel profiles, I presume it does but don't know what the upper limit is.
> 
> For solid spots, non-interactive (not part of color separations) they don't need a profile, just an XYZ or LAB value to define their color.

Are you saying that when I overprint a spot color over some RGB, Cairo 
and CMS knows exactly how the chemicals in the inks will mix and 
interact and exactly how the spot patterns overprint each other and how 
it effects ink spread?

I think you are saying that somehow by magically working in LAB or XYZ 
or CMYK rather than RGB, that somehow Cairo will produce "correct" 
mixtures. That is false. If this was acceptable then we would not need 
color management at all because sRGB would be acceptably close too.

> I don't know any product that behaves this way. Display anti-aliasing is done either by the viewing application (e.g. Acrobat) or as an OS service (e.g. OS X  provides this capability to Preview), and in any case it's done in RGB. If the spot alternate definition is LAB, it's converted to RGB for antialiasing. It's a question whether this is done in some intermediate RGB space, or in DisplayRGB.

Every screen I have seen acts exactly this way. The XYZ/LAB/whatever 
equivalent is mixed in a lossy manner with the other colors, and you 
cannot retrieve from that result the desired spot colors, since the 
result has fewer dimensions.

If I print a spot color with 50% opacity over an existing device-space 
rgb, the result will be (r+R)/2, (g+G)/2, and (b+B)/2, where rgb are the 
existing device-space color there, and RGB is the (correct) translation 
of that spot color to device space.

Now the backend can reproduce this on the output, but it is unlikely to 
magically produce 50% of that spot color as part of it. This is because 
the exact same result can be arrived at by mixing normal colors and the 
user certainly does not intend for the spot color to be used then!

If you can explain how this works I would appreciate it, but it appears 
mathematically impossible unless a channel is allocated for each spot color.