[cairo] Spot colors (and CMYK)

[James Cloos]

>>>>> "Bill" == Bill Spitzak <spitzak at gmail.com> writes:

Bill> What would be sent to cairo is "This is the spot color id, and here
Bill> is an sRGB approximation". This sRGB value would be the Pantone CMYK
Bill> converted using the DeviceCMYK to sRGB, although not be clamped to
Bill> the 0-1 range (so outside-sRGB-gamut inks can be approximated).

For the specific case of dealing with spot colours, I agree that the above
proposal probably would be sufficient.

The only issues are that:

    Every app needs to know how to convert whatever the user or existing
    docuement specifies as its fallback into unclamped sRGB.

    It often will be useful or even necessary for the pdf and ps backends
    to specify the fallback in terms of CMYK rather than in terms of RGB.

And the related point that:

    One of the reasons for using cairo to generate pdf/ps is that it can
    also be used to generate the on-screen editing and proofing displays;
    apps which know colour need to be able to specify the that the output
    pdf/ps will request colours in pretty much any of the spaces those
    formats permit.  That can only work if cairo supports specifying
    colours in any of those spaces, and supports passing them on through
    to the output documents.

Obviously, colour aware apps will want to link to a cms, such as lcms.
It is reasonable, then, to presume that they can convert between any
of the ABC spaces, including to sRGB.  (At least if lcms can do such
conversions w/o clamping.  I don't know whether it supports that.)

But cairo would still need an API to specify inks to cover the needs
of all apps which may want to use it for display and print generation.

Thinking about it a bit further, though, your suggested api can cover
that; such users would just need to specify the four spot colours:
"Cyan", "Magenta", "Yellow" and "Key", which the pdf/ps backend could
recognize and from which generate setcmykcolor calls.

Even hexachrome and similar could be so handled.

Blending fo the colourants should work, too, using cairo's existing OPs
and treating each separation as an alpha map.

Documenting it in a way which app devs would understand well enough to
avoid asking lots a FAQs *might* be a hurdle.  Or perhaps a separate
lib sitting on top of cairo could provide a higher-level, more intuitive
(or should I write "more typical"?), colour-aware api for apps which
need to get the details of printing right.

But it could work.

Intriguing.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6