Hello Jan,
>> The next FreeType release will introduce FT_Color, [...] Currently
>> it represents color as common 32-bit RGBA structure. What is your
>> opinion about SVG color gradients? Do we need to consider a more
>> complex color structure with full description of color gradients?
>> Or, alternatively, should we reference color gradients by an index
>> within FT_Color?
>
> I think this feature was added to support COLR/CPAL fonts, which
> only have flat colors; the only use for gradients would thus be
> proper SVG. Given the complexity of SVG I don't think it's a good
> idea to attempt to decompose it into a set of shape layers with
> gradient descriptions. I think applications would rather consume
> the SVG directly.
thanks for your comment.
I've just done another look at OpenType's `SVG' description, and I
agree. The `FT_Color' structure will exclusively be used for getting
and setting CPAL data (also for SVG glyphs), as far as I can see, and
an SVG gradient is not something a user should ever manipulate
according to the OpenType specification.
It *might* be possible to add a means to manipulate gradients.
However, if this ever be desired, it must happen on the SVG side, this
is, outside of FreeType's direct control.
Note that we do not plan to decompose SVG at all. Decomposition into
layers is a `COLR' feature and thus not related to `SVG'. The idea is
rather to parse the `SVG' table and feed all SVG data directly to an
SVG rendering library, which returns a bitmap (or pixmap) to FreeType.
To summarize: The current definition of `FT_Color' should be just
fine.
Werner
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
