[cairo] Spot colors (and CMYK)
spitzak at gmail.com
Tue Feb 23 11:16:33 PST 2010
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.
More information about the cairo