[Openicc] Creating CMYK and spot colors using Postscript backend

[Leonard Rosenthol]

On May 14, 2007, at 12:53 PM, Craig Ringer wrote:
> MIXED COLOUR SPACES
> ===================
>
> You could simplify this by converting to a single internal working
> colour space, like L*A*B (white-point corrected XYZ). That's expensive
> for rgb->rgb though, and that's currently the only use Cairo sees.
>

	It doesn't necessarily have to a LAB for the single space - it can  
be any space that makes sense for the user.   For example, when  
working in applications like Adobe InDesign, even though you can have  
objects of varying colorspaces - the actual rendering of those colors  
to screen will go through a single colorspace (potentially multiple  
ones, if transparency is involved - more on this later).


> Carl Worth mentioned that the Cairo devs are already considering  
> using a
> wide-gamut RGB  space as the sole internal colour representation.

	Certainly a good idea - though I am not sure how you'd do this in a  
non-color-managed environment since the definition for all of the  
industry standard wide-gamut RGB's are based on ICC profiles.


> 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"...


> 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.



> 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).

	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.

	The idea is simple - in order to properly alpha blend you have to  
have all of your values in a single colorspace.  So, all colors  
involved in the blending are converted (using ICC profiles) to the  
blending space and then blending takes place.  If the output device  
is different than the blending space (eg. rgb screen but CMYK blend)  
then things get converted to the output space - as expected.


> 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.

	
> It also has built-in support for tagging image data and I think solid
> colours too with ICC profile information, so conversions can be  
> deferred
> to the RIP.
>

	/ICCBased is just another colorspace to PDF.  Any object can use it  
- just like RGB or CMYK.


> 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....


Leonard