[cairo] Subtractive API, part 0

[Jon Cruz]

On Jan 31, 2010, at 9:46 AM, ecir hana wrote:

> I'm afraid you misunderstood what I wrote. What I said was that the
> numbers should be arbitrary from the Cairo's point of view. Your
> application could supply any RGB for displaying you want, be it
> managed or not. What I said was, that it should be the application who
> keeps track of all the properties to make CMS work. The application
> would do the color conversion (possible with the use of other library)
> and supply the calibrated values straight to Cairo. I fail to see how
> this prevent a color to show up on screen in the way you want..?

No, I understood what you said. You, though, seem to be misunderstanding me.

The KEY point is that there is no "arbitrary" way to manipulate color. If Cairo needs to do a blend, it needs to know *how* to do the math to do that.

So either Cairo must keep things intact, or it must convert in a known manner to known values. If rgb is being used, then things are simpler. However if CMYK is involved, Cairo can not really do *any* math in the abstract with arbitrary values.

That's really the crux of the problem with CMYK, hexachrome, or any non-sRGB solution. With a color-managed workflow cairo can manipulate things, but without one it can not. Of course, one *could* implement such a workflow by leveraging callback functions for Cairo to invoke at each pass, but often such approaches lead to reductions in performance.

a few factors:

* to perform operations, Cairo *needs* to know how the supplied numbers relate to real colors.

* there is no "CMYK color space".

* each specific "CMYK color space" applies to a specific combination of exact printer, paper, inks, etc. For precise control these can and do change even from day to day.

* there are a few "generic CMYK colorspaces" defined... but those vary by region, media type and other factors.

* artists, designers, and graphics professionals have concrete need to control separate channels to deal with overprint, trapping, bleed, registration, "blacker than black blacks" and other such issues. (these key issues prevent a simple "just convert all input to Lab" approach)

* artists, etc, can be used to keeping spot colors separated, but expect CMYK values to be mixed, blended, and properly represented. (it seems to me that such workflow expectations can be leveraged to the benefit of the API)

* display preview and "soft proofing" can be simpler one-way lossy paths, but PDF output and such need to keep full fidelity end-to-end.