[cairo] Spot colors (and CMYK)

[Francois Robert]

-----Original Message-----
ecir hana wrote:
> On every device which does not have the desired colorant 
> you would want to simulate it by mixing some of the available 
> colorants. 
PDF and Postscript won't let you use a spot to approximate a spot (see below).

> [...]
>> why couldn't this fallback be specified as RGB?

> Exactly. This is an interesting question. My reasoning was that
> since you use spot colors you probably intent to print on subtractive
> device. If that device does not have "gold" it still most probably 
> has CMYK.
In Postscript (and PDF) *which* fallback to use (the so called 'alternate colorspace') is part of the /DeviceN or /Separation colorspace definition itself. PDF and PS impose additional constraints on the alternate colorspace. In particular they cannot be /Separation or /DeviceN (nor /Indexed or /Pattern but that's non-sensical anyway). In other words, spot ink approximation can only be done using process inks, not other spots. But the alternate colorspace can be CIE-based (*AND* substractive at the same time, possibly...). Photoshop does emit such PS code for duotone images.

Regarding 'substractive devices' : Even though the notion is self-evident when you know the physical process used for rendering, it is unfortunately not so clear-cut when considering only the software side of things. Consider this: In PS L3, one can access [1] the device type in the page device dictionnary:
- On black & white printers, you may likely get /DeviceGray, which is ... additive.
- On some color printers, (some Lexmark spring to mind) you may get ... /DeviceRGB (!)

[...]
> To convert from CMYK to RGB I thought one could use the formula 
> from the above spec [...]
This does not generally gives visually satisfactory results (hence the invention of color management, which I will not get into). Moreover, in PS, the aforementionned formulas are used only if the /UseCIEColor flag is cleared in the device page dictionary. If the flag is set, then some heavy machinery gets involved which basically performs /Device* -> XYZ -> 'tints of physical colorants' behinds the scenes. Elsewhere in this thread, the word 'implicit conversion' was used to characterize this logic. It is merely automatic: A PS program can indeed modify certain aspects of this conversion, even multiple times in the same page. And even in the 'simple' case where the above formula are used, transfer functions, halftoning and undercolor removal and black generation are applied anyway.
Now, I am not advocating for or against the use of CMS. Just enumerating the CMS features available to a PS program(mer) and the transformations a basic monocolor drawing will go through on a RIP.
I would suspect that some (host) CMS machinery may be unavoidable _somewhere_ for satisfying use cases that involve 'soft proofing' (on-screen rendering that aim to 'match' a print output). But that kind of use cases may be out of Cairo's scope anyway ?

François

[1]: To dump the process color model on a L3 device, just feed it this PS program:
%!PS
/Helvetica findfont 30 scalefont setfont 100 100 moveto
currentpagedevice /ProcessColorModel get 
dup type /stringtype ne
{ 100 string cvs 
} if
show showpage

On L2 device, things are more complicated.