[Openicc] Creating CMYK and spot colors using Postscript backend

[Craig Ringer]

Leonard Rosenthol wrote:

>> Is that correct as far as you folks on OpenICC can see? Could Cairo get
>> away with working in an expanded floating-point RGB space and still
>> produce good results on CMYK output targets with CMYK inputs - presuming
>> decent colour profiles are available?
>>
> 
>     If you ask a color expert - the answer is always "NO!".   There is
> too much additional color science involved in the process of color
> conversion (rendering intent, black point compensation, etc.) - all of
> which are handled by ICC profiles - that to do algorithmic conversion
> (such as described in the classic Postscript "Red Book") just doesn't
> cut it.
> 
>     In addition, there are specific concerns for things such as black
> text becoming "not so black"...

I was assuming a colour managed environment for all colour space/format
conversions. I'm well aware of the extensive problems with simple
algorithmic conversions. I probably wasn't as clear about this as I
could have been.

>> Now one more wrinkle pops up: spot colours. (OpenICC folks: yell at me
>> if any of this isn't 100% accurate in nitpicking detail please). Spot
>> colours are NOT just named CMYK values. A spot colour is a specific
>> colour *in* *the* *real* *world*. Your named colour is a placeholder for
>> that, and the output device is responsible for reproducing the desired
>> colour. This "colour" need not even be a conventional colour - it could
>> be gold ink, or a varnish layer. An intensity value makes sense for a
>> spot colour in most outputs (corresponding to things like halftoning),
>> but blending it with other colours generally does not.
>>
> 
>     That is 100% correct.   In fact, when working with spot colours in
> PDF you get an associated "Alternate Color", which is the color to
> render when the output device doesn't know the name (eg the screen).  
> The alternate can be ANY colorspace - though the normal cases are
> DeviceCMYK, ICCBased and LAB.

OK, that's a good point. So a spot colour in Cairo could be represented
by a cairo_color_t containing a spot colour name and another nested
cairo_color_t for the alternate colour, thus permitting spots to have
alternate colours in any supported format.

>> However, I'd agree with Behded Esfahbod, who said that:
>>> To me alpha with spot colors makes a lot of sense.  That's your only way
>>> to create new colors after all  (which will result in halftones in
>>> print).
>>
> 
>     Alpha blending/transparency with spot colors only makes sense on a
> composite (probably digital) based output device.
> 
>     As Craig pointed out, the normal use of spot colors is for a
> separated workflow where each color is printed to a separate "plate" and
> then the plates are later "combined".  Transparency/alpha does NOT work
> in this world (for obvious reasons).

My impression was that alpha would translate fairly sanely to a halftone
screen density in that sort of environment. I know that the staff work
with part-intensity spots in practice at work.

I guess alpha and a halftone screen density are really two very
different things, and it's probably not useful to try to cheat by
treating one as the other in any situation, even if it would seem to
initially simplify matters.

>     That said, you can certainly have a transparent spot color in PDF -
> and the PDF Reference goes into VERY GORY detail about how to handle
> such things including the fact that you MUST have a predefined "blending
> colorspace" through which all rendering will take place.  This is true
> for all mixed colorspace rendering, but it's required for spot.

To do this, it'd presumably have to either use the spot's alternative
colour, or would have to do the blending in a device-specific RIP that
could convert the spot to appropriate device-specific colour values.

>> My personal interest is in CMYK and spot colour in PDF, rather than
>> PostScript. PDF uses /DeviceRGB (conventional RGB colour), /DeviceCMYK
>> (simple CMYK colour), /DeviceGray (pure K) and /DeviceN (spot colour).
> 
>     Minor clarification - PDF uses /Separation as the colorspace for
> spot colors.  /DeviceN is a special space that enables multiple colors
> (inks) to be specified for a single object.  Although those colors can
> be anything, they are usually spots or named process colors.

Thanks. That's a misunderstanding I managed to hang on to for a fair
while, so it's good to have it put right.

>> PDF supports mixed colour spaces. This means that except where Cairo
>> supports blend operations that PDF does not (so Cairo must render them
>> internally to a bitmap) it could output tagged mixed colour space data
>> directly.
> 
>     I'd be curious to know what blend operations are supported by Cairo
> that PDF does not....

Honestly, I'm not even sure there are any. However, the possibility
exists in the future, and it's also possible that Cairo may want to
internally render things that can be supported in PDF, but either only
in very new versions, or are only implemented in practice by Adobe
Reader and professional RIPs.

--
Craig Ringer