[cairo] Spot colors (and CMYK)

[Carl Worth]

On Sat, 16 Jan 2010 19:42:22 +0100, ecir hana <ecir.hana at gmail.com> wrote:
> On Tue, Jan 12, 2010 at 9:16 PM, Carl Worth <cworth at cworth.org> wrote:
> >
> >  * Concrete use case to describe what is missing at the
> >    application<->cairo boundary.
> 
> A graphic editor exporting print-ready PDFs.

Thanks. I really appreciate a lot of aspects of this post.

> After reading the posts above a few times I think there was a bit of
> confusion - I was specifically talking about subtractive color spaces,
> i.e. no sRGB, no BGRA, no CIE. In my opinion, converting between
> various color spaces and color management is just too complex and
> perhaps should be left out to the application or another library.

This is very encouraging to me. I know that often when the topic of
color management comes up, the conversation spins out of control to some
extent. I know that's because there are a lot of complex issues here,
and a *lot* of potential for for functionality that's not available yet,
(perhaps implying the need for entirely new color management frameworks
etc.).

But I've long had the impression that there are people with specific
needs that could likely be met with a small amount of additional API and
implementation in cairo, without requiring a large, color-management
framework etc. So I'm glad to see you agreeing there.

I'm hoping we can make small steps, always improving, and never adding
functionality for its own sake, but keeping things grounded in the
actual use cases.

> By "subtractive color" I actually mean just one very board thing -
> "DeviceN". Think of it as one or more spot colors. In turn, a spot
> color is just a name (as in "const char *name"), perhaps with
> associated intensity value called "tint".

Perfect. Nice, clean definitions. And I think I'm following you up to
this point.

> It is almost certain that in the process of getting the print out it
> will go through several devices which wont have the right spot colors.
> This includes screen previews and proof-readings on a printer. So if I
> say "gold" color, I think it is perfectly ok to display it on screen
> as yellow, to print it on a printer as yellow, as long as it comes out
> from the final output device (press) as golden. Now, the question is
> whether do this automatically (implicitly) or explicitly specify what
> to do. I must admit this is rather ultra-opinion on my side, but I
> think that the first option, i.e. to work just in RGB (or some generic
> united color space) simply does not work. Therefore one needs to be
> able to specify how to convert a color from one space to another.

I'm not sure I understood every nuance in the above
paragraph. Specifically, I'm not sure what you meant by "implicit" and
"explicit" nor precisely what "work just in RGB" means (or why it
wouldn't work).

Finally, "specify how to convert a color from one space to another"
starts to sound like opening the whole color-management can of worms
again, and we agreed above we don't want to go there. So there might be
something else I'm missing here as well.

It's clear to me that starting with a named spot color (or N named spot
colors as in DeviceN) that cairo will need *some* information about how
to render that color for "preview" purposes on devices without the
desired spot colorant. Since this preview color need not be particularly
precise, (by definition it cannot accurately capture the presentation of
the final device), why couldn't this fallback be specified as RGB?

I think the process of answering that question might help cover some of
the misunderstandings and broken assumptions I have.

> - To actually paint with a color one would need to specify two things:
> first the color space (instance of some concrete DeviceN or RGB),
> second the tints (intensity values for each colorant in color space,
> be it RGB(A) or DeviceN)
> 
> - There would be convenience functions for RGB and CMYK painting which
> set both the color space and tints, say:
> cairo_set_source_cmyk(double cyan, double magenta, double yellow, double black)
> 
> - While generating PS or PDF the surface could detect if the colorants
> of DeviceN surface are Cyan, Magenta, Yellow, Black and if so use
> DeviceCMYK color space, instead of DeviceN color space.

Are you to a point where you could start capturing the above as
concretely as an API proposal for cairo? That also might help me
understand better what I'm missing.

> I apologize, this grew to a rather long post. To summarize: CMYK is
> just a special case of DeviceN. Spot color is just a special case of
> DeviceN with just one colorant.

That much is very clear to me now. And I appreciate that.

Thanks again for the enlightening post, and I'll look forward to future
contributions from you.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20100116/52272921/attachment.pgp