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

[James Cloos]

>>>>> "Adrian" == Adrian Johnson <ajohnson at redneon.com> writes:

>> The more general solution would be to specify the tint transform as a
>> 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.)

Adrian> How would the tint transform be derived from a type 7 gradient?

I must have forgotten that separation and devicen do not allow pattern
spaces as alternates.  [SIGH]

A linear gradient will translate well to a linear type0 function or a
stitching of them.  But cubic type0 and type2 (exponential) functions
are also useful.

I suppose were cairo to have support for cubic-interprolated shadings,
it could use them for specifying cubic type0 tint transform functions;
when they are used as shadings it should be possible to geneate a mesh
from them by making several of the control points co-incident.

As for type4 functions, an api to support them either would be
excessively verbose or likely would need to consume cairoscript syntax.
PDF Type1 shadings are a good match, though, so were cairo to support
type1 shadings that could be used for type4 tint transform functions.

>> Which begs the question of when the type6/7 gradient code will be added. ☺

Adrian> Good question. My last update to the API and implementation is at
Adrian> [1]. The only feedback I got on the list was Behdad preferred some of
Adrian> the API functions to be renamed [2].

Adrian> [1]http://lists.cairographics.org/archives/cairo/2009-September/018095.html
Adrian> [2]http://lists.cairographics.org/archives/cairo/2009-September/018098.html

Some thoughts:

That renaming looks like a reasonable thing to do.

Ghostscript cannot render mesh-gradient-overlap-transp.pdf or
mesh-gradient.pdf (I tried 8.71 and the icc_work branch).  It would be
interesting to see what it could do with level3 ps of those, presuming
that using level3 could avoid the fallback images.

(btrfs makes for *slow* git pulls and branch switching.)

in commit 0946988c580b059be9477f27616905a7db227a0e,
   s/ie if not control points/ie if no control points/

Otherwise, the api and codebase look ready to me for master, after a
read through »git log -p --reverse 9b932d7cd.. « on that branch.


I also like the direction your cms branch is headed.

In that branch, the doc for cairo_render_intent_t repeats the
default line cap style rather than specifying the default render
intent.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6