[cairo] cmyk support in Inkscape/Cairo

[Aron Rubin]

Thomas Stover wrote:
> 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.

No that is the opposite of spot color. That is dithering. Spot color
means the color of a dot/spot on the printed work. This is a component
of dithered/multitone dot. The gimp has a nice plugin for what your
talking about that replicates dithering pattern. You can look at what I
did on this website for more info:
http://fairmountprinters.com

> 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
> 
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo


-- 

ssh aron at rubinium.org cat /dev/brain | grep ^work:

Aron Rubin                       Senior Member, Engineering Staff
Lockheed Martin                  E-Mail: arubin at atl.lmco.com
Advanced Technology Laboratories Phone:  856.792.9865
3 Executive Campus               Fax:    856.792.9930
Cherry Hill, NJ USA 08002        Web:    http://www.atl.lmco.com