[cairo] Subtractive API, part 0

[ecir hana]

(Look, at least on my part, this discussion is rather interesting so
thanks for your patience.)

I repeatedly said this proposal is not about displaying colors and yet
you always talk about color management. The proposal does not care
whether cmyk(0, 1, 2, 3) is rgb(4, 5, 6) or rgb(7, 8, 9). It is about
saying "cmyk", about the ability to define any cmyk(w, x, y, z) in
Cairo.

Apparently, you have two problems with the above: how do you display
untagged cmyk and how do you print untagged cmyk. As I said, those are
questions not central to my proposal but I will address them anyway,
for the sake of discussion. For display, use that simple formula I
wrote above. Is it perfect? Hardly and I never claimed that. For my
needs, it is sufficient as I understand that what's on the screen is
wrong anyway. If you need more precise way of converting to RGB you
are very welcomed to come up with a more suitable fallback. Again, I
don't care whether you use ICC or CIE LAB or sRGB - my question is,
certainly there is some kind of fallback which would make you happy,
but how to tell Cairo about it? If you were in need of defining cmyk
in Cairo how would you write it down? Would "set-cmyk-for-this-icc" do
it? What about:

void cairo_set_source_cmyk_icc(cairo_t *cr, double cyan, double
magenta, double yellow, double black, cairo_icc_t *profile);

Or perhaps, even if IMHO it's of no use, you could define rgb
f_allback for a cmyk color, how about that? You could supply any
values you want, like:

void cairo_set_source_cmyk_rgb(cairo_t *cr, cyan, magenta, yellow,
black, f_red, green, f_blue);

For printing, even with untagged cmyk, nothing stops the application
or CMS to supply correct cmyk values to Cairo. Those values would get
baked-in into the pdf, making them possibly unusable on another device
- so what? Do you print a poster on two different printers? The point
is, currently you could not even export cmyk. If there was the ability
to define cmyk, you could enter any values, be it from CMS or
experience. If you still insist that the PDF must have embedded ICC,
is it really such a problem to provide it as an additional argument of
the function from the very above? Btw, decoupling CMS from Cairo has
several advantages.

Then there is my favorite topic, spot colors. Saying there is no
magenta is just utterly wrong. You can buy magenta here:
http://www.printinginksupplies.com/NOVASET-PROCESS-MAGENTA_p_76.html

I claim that if you need to print a certain color the best possible
way is to use a spot color. I hope we agree that if the color is
present on the output device, there is no problem whatsoever and we
both get the same result if we use the same spot color, right? Now,
what happens if the device does not support the spot? Again, I don't
really care. There is no substitute for metallic color or matte
varnish, anyway. Take gold, for example. To supply some random yellow
in CMYK for the fallback is perfectly ok, because metallic colors look
differently at different view angles. You certainly don't need CIE to
get higher precision because it is totally wrong anyway. But if you
insist, your application could ask you what kind of paper, printer,
... you use and supply these CMYK fallback values to Cairo. I'm
interested in how the API function should be written, what kind of
data structures are there needed and what does it mean for the current
Cairo surfaces.

In other words, say you want to print "ultramarine" color. How do you
tell Cairo? How do you supply its tints values?

On Fri, Jan 29, 2010 at 6:42 PM, Chris Murphy <lists at colorremedies.com> wrote:
>
> CMYK is completely useless on everything except for the CMYK output device those
> values were intended for.

Right. This is all I was talking about.

> And worse, you will be creating files that contain undefined CMYK values.
> ...
> They do not actually communicate a repurposeable intent.

Good point. I agree.

>> Interesting. Do you believe there is "full magenta"?
>
> No.
>
> When referring to "magenta" in a printing context, this is a color that runs from light pink to
> red in hue, low chroma (high gray component possibly due to media) to high chrome, and
> variable lightness as well. Magenta is not a color. It's a huge range of colors.

See above.

> Same problem, except worse. A spot color in printing context is a control signal. It's not a
> color. To display it, or print it where that spot color is unavailable, requires reference to a
> CIE space as well. However, we tend to specify the spot color CIE value in relation to a
> reference medium, not actual printing medium. The effect of how it will print isn't known
> until it's on that media.

"To display it, or print it where that spot color is unavailable" -
the primary question of this proposal is - "to print it where that
spot color is available".

> If you start interacting this spot color with other spot colors, it's even more complex still,
> because you have all kinds of opacity problems that need to be considered (and ink
> opacity is rarely a published value, you have to measure it), and print sequence makes a
> huge difference as well.
>
> Insofar as I'm aware, there's only one product on the market that handles spot colors
> correctly in all their complexity: the color of the spot ink, the color of the media, the effect
> of the media color on the spot color, ink behavior on the media in terms of dot gain, ink
> opacity behavior in relation to other inks, print sequence, ink trapping, etc. All play major
> roles in the color you'll actually end up with.
>
> Adobe InDesign optionally will use Lab values for spots, and thus show them correctly
> on-screen at 100% when printed on media white only. When you start to print tints, or
> interact the inks, all bets are off. Neither Adobe nor Pantone supply ink opacity, and even
> if it were supplied there isn't an algorithm to effectively use this to improve on-screen
> display or printed simulations. So the net result of this is that you have to outsource these
> kinds of proofs, and typically you get overlays, and spend a lot of money on experienced
> prepress handling in order to get things to print correctly.

Exactly! Exactly!!!

This is single most important point I try to make from the beginning.
"all bets are off" - this whole CMS is just so complex that no one
gets it right. Thus I proposed to use functions with user-definable
fallbacks so that CMS is left out from Cairo and give you the full
control and hope you know what you are doing.

> But if you're talking about spot colors such as Pantone solids, you might like to look at a
> gamut plot showing how much of those colors are outside of sRGB.

It doesn't matter whether Pantone is or is not outside of sRGB -
Pantone is not for screens.