[cairo] Spot colors (and CMYK)

[Kai-Uwe Behrmann]

Am 19.02.10, 18:04 +0100 schrieb ecir hana:
> On Thu, Feb 18, 2010 at 6:51 AM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> Am 17.02.10, 21:55 +0100 schrieb ecir hana:
>>>
>>> Ok, so but why do I need to allocate each new color? Just set the
>>> working space and call:
>>>
>>> cairo_set_source_native_channels(cairo_t *cr, double *native_channels);
>>
>> Well I have decided in Oyranos to reference all colour data with a profile.
>> This makes communication very explicite. The overhead is minimal as profiles
>> are typically referenced not copied.
>> A profile should not change during building cairos drawing graph. Following
>> this a backend A would imediately draw with the colour and forget
>> cairo_color_t. Backend B had to copy the structure for remembering. The
>> overhead for backend B would be the cairo_color_t + the channels doubles and
>> a call to reference cairo_profile_t.
>> (The cairo_color_t * argument is owned by the caller and can be changed on
>> user side at any time.)
>>
>> /* a small sequence */
>> cairo_color_t * colour = cairo_color_create( /**/ );
>> cairo_source_color_set( cr, color );
>> cairo_rectangle( cr, /**/ );
>> cairo_color_set_native_channels( color, 0.2, 0.2, 0.2, 1.0 );
>> cairo_set_source_color( cr, color );
>> cairo_rectangle( cr, /**/ );
>> cairo_color_set_native_channels( color, 0.5, 0.5, 0.5, 1.0 );
>> cairo_set_source_color( cr, color );
>> cairo_rectangle( cr, /**/ );
>>
>>
>> With your model backend B had to track colour space changes itself. It would
>> end in eigther do the same as I outlined above behind the scenes. Or cairo
>> had to maintain a internal table for storing each colour value plus the
>> according cairo_profile_t reference. So eigther way some overhead would
>> remain.
>
> I'm not sure I understood. You don't have to store every color +
> profile. Just use the latest set profile. Think of it as path building
> works. Cairo maintains the last x, y position as well and every new
> position is calculated from there. If I rewrite your sequence above:
>
> cairo_profile_t * profile = cairo_profile_create( /**/ );
> cairo_set_profile(cr, profile)
> cairo_rectangle(cr, /**/); // default stroke and fill?
> cairo_set_source_tints(0.2, 0.2, 0.2, 1.0);
> cairo_rectangle(cr, /**/);
> cairo_set_source_tints(0.2, 0.2, 0.2, 1.0);
> cairo_rectangle(cr, /**/);

That looks short for that purpose. My point was that using a cairo_color_t 
is quite more flexible and will cover many cases without extending the 
API. However a cairo_set_profile(cr, profile) would at least integrate 
with the current API at the cost to need later more API expansion for 
CmykA, named colours and so on. cairo_color_t would cover these cases more 
immediately.

> And setting another profile once more would either cause everything
> already drawn to convert to new space (pixel surfaces) or just change
> the current color space (PDF "cs" and "CS" operator)

I think it s backend specific and the cairo API can not make assumptions,
in which order things are to be drawn. Still the passed colour objects can 
be immediately be forgoten inside cairo if no longer needed or copied 
otherwise. The PDF case would be a draw and forget case.

>> Hooks would be part of cairos API. The CMS would be on the user side. In
>> comparision Pango is the same way independent.
>
> Yes but even without Pango you are able to write some basic text.

Same for colours without CMS. The current cairo colour toy API can 
still process colours. This is similiar to the font toy API.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org