[cairo] [RFC] Color space API (partial proposal)

[Jon Cruz]

On Feb 25, 2010, at 11:18 AM, Chris Murphy wrote:

> 
> The Hexachrome workflow, with six primaries, is challenging even with existing professional applications so I'd get the CMYK + spot stuff working before even considering 5+ channel color separations with DeviceN output profiles.

As a minor note, my general preference would be to start by defining an API that could support CMYK *and* CMYKOG or CcMmYK, both with additional spot ink/emboss/etc channels.

From a software engineering standpoint that would help removed the hardcoded assumption of "cmyk*" in the names and in the implementation (I'm wondering if "process plus spot" would make a better description than "cmyk plus spot". etc). It seems clear by this point that color channels will fall into either one of two groups: the process set and individual spots. *If* it were easy to craft a solution without the process==4 hardcoded assumption, that would be nice.

However, I do agree that it were to be too much work, then deferring that 'till later is entirely reasonable.

Looking at Adrian's suggestion:

/* Create a color in the same CMYK color space as the page
* and draw a rectangle.
*/

double cmyk[4] = { 0.1, 0.2, 0.3, 0.4 };
c = cairo_color_create (dest_col_space, &cmyk);
cairo_set_source_color (cr, c);
cairo_rectangle (cr, 10, 10, 20, 20);
cairo_fill (cr);

it seems to me that one could easily just tweak the variable names to achieve that:

/* Create a color in the same hexachrome color space as the page
* and draw a rectangle.
*/

double process[6] = { 0.1, 0.2, 0.3, 0.4, 0.1, 0.2 };
c = cairo_color_create (dest_col_space, &process);
cairo_set_source_color (cr, c);
cairo_rectangle (cr, 10, 10, 20, 20);
cairo_fill (cr);

Or one could drop it down a step and target CMY printers in a similar way (I've worked with some fun little dye sub printers in the past).