[cairo] [RFC] Color space API (partial proposal)

[Francois Robert]

Bill Spitzak wrote: 

> Since zero tint is (I think) the same as not drawing in the spot 
> color at all, I don't see how this can work.
Not necessarily in PDF or Postscript.
Generally, a zero tint is drawing opaque white. But it becomes more complicated when you consider overprint flags (setoverprint and setoverprintmode in PS).

When setoverprint flag is set, only the colorants on which the current colorspace relies on are affected. Say your colorspace is set for duotone (black with a bump plate, aka /DeviceN [/Black /Spot] and your RIP does have a /Spot colorant declared, so the alternative colorspace is not being used). Then drawing with color (0.5 ,0) leaves gray marks in the /Black and white marks in the /Spot separation, but leaves NO MARK (eg. is fully transparent) in the C,M, and Y separations (and other spots).
Same happens with /DeviceCMYK and a (0, 0, 0, 0.5) (any spot plates are left undisturbed but C,M,Y are marked with white. K is marked with gray).

HOWEVER...

The above mentionned behavior is significantly different from the historical practice, which was to use nul tint as transparent, and which seems to be the behavior you mentionned. Hence the introduction of the "compatibility flag" setoverprintmode, which causes nul tints to be transparent ONLY when the /DeviceCMYK is the current colorspace. So when both flags are set, (0, 0, 0, 0.5) will mark with gray only the K plate and leave C,M,Y and spots undisturbed.  

The above explanation is valid if you ignore possible PDF 1.4 transparency. When adding transparency to the mix, things are getting even more convoluted...

François