[cairo] Spot colors (and CMYK)

[ecir hana]

On Sat, Jan 16, 2010 at 11:01 PM, Carl Worth <cworth at cworth.org> wrote:
>
> Thanks. I really appreciate a lot of aspects of this post.

Thanks!

>> 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).

On every device which does not have the desired colorant you would
want to simulate it by mixing some of the available colorants. You can
either try to build a clever conversion process build around ICC,
materials, dyes, coatings which would simulate the missing spot color
automatically - in this case the conversion would be transparent to
the user, i.e. implicit. Or you could leave that to the user to
manually specify what colors to use in case of falling back, i.e. a
user explicitly defines the "tintTransform".

By saying "using just RGB wont work" I just meant to give a nod
approval to the post above by Francois Robert, where he says "In
theory, color management should make it possible to use full RGB or
even L*a*b* workflows in the printing industry and not care about the
inks details. In practice, however, this is still not very common and
many shops are still using CMYK". In other words, I heard a few times
that all you need is sRGB and some ICC profiles and everything else
will be taken care of by.....? I mean, even CMYK alone has incredible
potential.

> 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.

Quite the opposide - if you explicitly specify a mapping of how 0% -
100% "gold" translates to CMYK values, there would be no need of CMS.

An example of how to define such mapping:
http://www.adobe.com/devnet/acrobat/pdfs/pdf_reference_1-7.pdf
3.9.1 Type 0 (Sampled) Functions, p. 169

> 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?

Exactly. This is an interesting question. My reasoning was that since
you use spot colors you probably intent to print on subtractive
device. If that device does not have "gold" it still most probably has
CMYK. If you specified RGB fallback you would then also need to
convert this RGB to CMYK. Another way of looking at this is, for spot
colors, favoring print intent over screen display. Of course, most
precise way of doing this would be to specify RGB fallback for screen
and CMYK fallback for print but I thought that might be an overkill
for the user.

To convert from CMYK to RGB I thought one could use the formula from
the above spec, 6.2.4 Conversion from DeviceCMYK to DeviceRGB, p. 484:
  red = 1.0 - min(1.0, cyan + black)
green = 1.0 - min(1.0, magenta + black)
 blue = 1.0 - min(1.0, yellow + black)

> 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.

You have to believe me it's not that I'm lazy or something and Cairo
is very nicely written it's just I don't really know Cairo and I'm not
a good programmer. But give me a week, I'll try and see where it goes,
ok?