[cairo] cmyk support in Inkscape/Cairo

[Aron Rubin]

Ralph Giles wrote:
> On Fri, Sep 26, 2008 at 1:54 PM, Ian Britten <britten at caris.com> wrote:
> 
>> In some workflows, my users will *define* their colours in CMYK (ie In
>> their own palette).  When they produce PS, they want those *exact*
>> colours written out, not the result of a CMYK -> RGB -> CMYK conversion.
>> As such, we maintain an abstract 'colour' class, with derived 'rgb',
>> 'cmyk', etc, variants, which maintain the defined colours as they were
>> originally specified.
> 
> If I understand correctly, this is what we call "device-dependent
> colours", and it's not just avoiding CMYK->RGB->CMYK but CMYK->CMYK.
> They're really a special case of named or 'spot' colours, and indeed
> SVG Print defines them as such.
> 
> One way to handle this is to have clean pass-through, and assume the
> application knows what it's doing for a particular device. That's a
> bit old-fashioned, but is one way to structure the API. Another
> approach is to always attach an ICC profile describing whatever space
> (including non-CMYK, non-RGB named colours) the application is feeding
> cairo, and then ensuring that colour conversion is a no-op if the
> eventual output device uses the same profile. In the meantime, output
> on other devices (e.g. for proofing) can be calibrated.
> 
> The latter is the more general API, but people used to pass through
> may complain and wonder what to specify as an input colour space.

The kind of stuff being talked about here is not for the faint of heart
or the uncommitted. I dabble in pre-press graphic design and often
administer an art computer network for many years noe. One thing is just
supporting CMYK for simple 4 color process images. The issues there are
really in terms of dynamic range and output diligence. HDR RGB should
map to and from CYMK without significant loss. If someone asks for a pdf
in CMYK you would need to ensure that ALL embedded objects are in that
color space or plate makers and digital presses react poorly.
	Spot color however is very complicated software wise. Spot color does
not have a 1 to 1 mapping from color to pallete. For example [4 color]
process black is not to be mixed up with PMS spot black. A more
complicated issue is how software should handle blending between
different spot colors and even 4 color process areas. Blending would
either need to produce multi-tone screens (aka dithering) or convert to
process color equivalents. That should only happen in the areas that are
blended.
	The software implementing all this would also want to report what is
going on to the user too.

Aron