[cairo] cmyk support in Inkscape/Cairo

[Thomas Stover]

Ok I don't know the first thing about CMYK, but this has made me 
curious. I understand the concept that the 4 different dots in spot 
color are not in the same location on the paper, and so therefor you 
want some logic almost like sub pixel antialiasing. If you just wanted 
to convert a drawing routing to produce CMYK how much more would you 
really need in cairo than what is already there? For instance, why 
couldn't I just...

1) create an image surface with enough pixels to represent each spot 
color dot as a pixel, or if the dot pattern is not "grid aligned" just 
increase the resolution until you could represented the true positions 
of the dots

2) render in a meaningful user space scale

3) then ignore any extra pixels involved in the non-grid aligned dot 
work around above if need be, followed by a switch case for each dot 
picking an appropriate formula similar to:
C = 1.0 - (R * A)
M = 1.0 - (G * A)
Y =  1.0 - (B * A)
K = 1.0 - (R + G + B / 3.0) * A)
*I just made these up, probably all wrong.
 
4) if you had spot dots that overlapped, use an increased resolution and 
take the mean value from a sample of pixels in the right area.

5) it looks like going from CMYK to RGB is harder than the other way 
around, no?

I know, I have no idea what I'm talking about. Just inquisitive.
Also what is PMS spot?



Date: Sat, 27 Sep 2008 09:54:55 -0400
From: Aron Rubin <aron.rubin at lmco.com>
Subject: Re: [cairo] cmyk support in Inkscape/Cairo
To: Ralph Giles <giles at ghostscript.com>
Cc: cairo <cairo at cairographics.org>
Message-ID: <48DE3B2F.8040702 at atl.lmco.com>
Content-Type: text/plain; charset=ISO-8859-1

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