[cairo] [RFC] Color space API (partial proposal)
ajohnson at redneon.com
Sun Feb 28 00:31:15 PST 2010
James Cloos wrote:
>>>>>> "Adrian" == Adrian Johnson <ajohnson at redneon.com> writes:
> Adrian> The tint transform will map tint values between 0 and 1 to the
> Adrian> linear interpolation between first_color and second_color.
> The more general solution would be to specify the tint transform as a
> gradient. The tint transform functions and gradient functions are at
> least essentially the same—perhaps even exactly the same—concept.
I like the idea of using a gradient. So then the API becomes:
cairo_color_space_create_spot (const char *name,
where pattern must be a linear gradient with at least one stop. The
alternate color space will be the color space of the gradient. The tint
transform will map tint values between 0 and 1 to the colors between
offset 0 and 1 on the gradient.
> And a type7 gradient can make for a reasonably convincing alternate for
> things like metalic, opalescent, iridescent spots or glossy overcoats.
> (Not exact, of course, but not unreasonable either.)
How would the tint transform be derived from a type 7 gradient?
> Which begs the question of when the type6/7 gradient code will be added. ☺
Good question. My last update to the API and implementation is at .
The only feedback I got on the list was Behdad preferred some of the
API functions to be renamed .
> But anyway.
> Since it takes several API calls to build up a gradient, I suspect that
> cairo should demand that the colour stops in a given gradient all be in
> the same colour space, thus the API for specifying the alternate colour
> should not need to specify the alternate's space explicitly.
I agree that gradient color stops should all be in the same color
space. I don't see any benefit in allowing mixed color spaces for
gradient stops. PDF requires all stops to be in the same color space.
More information about the cairo