[cairo] Creating CMYK and spot colors using Postscript backend

[Behdad Esfahbod]

On Fri, 2007-05-11 at 22:06 +0200, Markus Meyer wrote:
> Behdad Esfahbod schrieb:
> > On Fri, 2007-05-11 at 18:13 +0200, Markus Meyer wrote:
> >   
> >> I'd like to have two functions like this:
> >>
> >> cairo_set_source_cmyk(cairo_t *cr, double c, double m, double y, double k);
> >> cairo_set_source_spot(cairo_t *cr, const char* name, double c, double m,
> >> double y, double k);
> >>     
> > This is actually pretty good already.
> >   
> Thanks :-)
> 
> > Instead of erring if CMYK/spot are not supported by a backend I suggest
> > cairo automatically converts to RGB.  Also, how do they play with alpha?
> > Should they both accept an alpha too?
> >   
> It would just be consistent if they did, but I want to set the bar for
> implementing this low (don't want to over-engineer this so it is too
> much work and/or it doesn't get implemented at all). At the moment I'm
> only interested in solid colors, especially as alpha transparency is of
> more use on screens than it is on paper.

To me alpha with spot colors makes a lot of sense.  That's your only way
to create new colors after all  (which will result in halftones in
print).


> Regarding conversion to RGB: problem is, conversion from CMYK to RGB is
> not unambiguous. In a real world environment, it depends e.g. on the
> color profile used for the given screen, the output device (say, the
> type of paper and ink) and the actual conversion method used. It could
> be argued that someone who uses CMYK probably knows what he's doing and
> will probably not use any simple conversion method anyway. OTOH, I
> wouldn't mind if Cairo would implement a simple default conversion
> method and direct the user to direct set_rgb/set_cmyk calls for the
> cases when he wants to have more control.

We probably want cairo to convert to RGB, optimized for screen display.
You don't want to have cairo code that doesn't render to display.


> > Also, instead of adding cairo_set_source_*, we probably want to add
> > cairo_pattern_create_* instead.  Probably need
> > cairo_pattern_add_color_stop_cmyk/etc too.  Maybe if going that far we
> > should export a cairo_color_t type to reduce the number of new API
> > needed.
> >   
> A cairo_color_t type makes sense to me, especially as it would reduce
> the number of API functions in the long run. Of course,
> cairo_set_color_rgb[a] must still be maintained for backward
> compatibility and ease of use.

That's fine.  We have a bunch of convenience API like this in cairo.
cairo_set_source_rgb is already convenience for
cairo_set_source(cairo_pattern_create_rgb()).


> So where to go from here? Are you a Cairo developer? Any directions on
> how this could be implemented? I can provide the needed output templates
> for Postscript (and probably PDF) output to write CMYK and Spot color
> information, if this is of any use.

I am a cairo developer (and maintainer), yes.
Please provide that information, we will see who implements it first!

As for implementation, we will expose an opaque cairo_color_t which
simply maps to the internal cairo_color_t that we have already.  It
needs an enum member to identify the type of the color (rgb/cmyk/etc),
have a global alpha parameter, the 'short' rgb for display use, and a
union of per rgb/cmyk/spot/... data.  The cairo_color_type_t enum needs
to be public too.

> Markus


-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759