[cairo] Spot colors (and CMYK)

[Kai-Uwe Behrmann]

Am 17.02.10, 21:55 +0100 schrieb ecir hana:
> On Wed, Feb 17, 2010 at 9:31 PM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>>
>> I would think of working space and blending space as synonym. It is changed
>> only if the blending/editing/working space is different from that specified
>> in the CMS or say sRGB. So it can be specified but might not be specified
>> and all works nevertheless.
>
> 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.

Maybe I am a bit object oriented from my style of programming. And it is 
about personal taste, explicite code versus shorter arguments.

> or even better:
>
> cairo_set_source_native_channels(cairo_t *cr, ...);
> 
> No?
>
>> Cairo definately not alone. lcms or ColorSync or WCS, each qualifies.
>
> I personally think, *if* there has to be CMS then lcms is the only
> option because, contrary to what others have said above, it seems to
> me rather difficult to get CMS working across platforms.. But I might
> be wrong....

The ICC spec is designed to work crossplatform. So a wrapper can be made 
to allow for accessing a local CMS of choice. Its would be in analogy of 
the font engine selection.

> But still, what exactly do you propose? How would the relationship to
> lcms look like? How to maintain a fork of it especially for Cairo?

My preference would be CMS hooks in cairo. This makes colour in cairo very 
flexible.

A fork of lcms is undesireable. Distributors prefere libraries not static 
linking. Maintainance would be easier.

> What about releases? Because that's the problem of every Linux distro,
> which, if not CMS itself, is completely out of Cairo's scope, I would
> say.

Hooks would be part of cairos API. The CMS would be on the user side. In 
comparision Pango is the same way independent.

If a linking to lcms is prefered by cairo maintainers, then I would say 
the lcms maintainer has provided a very stable API. Its a solid choice.

>> "display" would be a colour conversion?
>
> Yes.
>
>> Then at least the backend should know how to convert.
>
> But it could be application responsibility, not beckend's.

How can a app hook into backends? Personally I considerd their output as 
pretty final.


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