Re: [ft-devel] libsvgtiny (Re: [ft] Three GSoC projects for FreeType)

[sylvain . bertrand]

On Wed, May 08, 2019 at 03:34:22PM -0400, Alexei Podtelezhnikov wrote:
> > That said, I am wondering if the expressive power of freetype internal
> > vector
> > code could satisfy the requirements of the font svg rendering. Because that
> > would reduce the external dependency to some xml parser, then some internal
> > freetype code would "translate" this font svg directly into internal
> > freetype
> > vector code.
> 
> 
> FreeType historically was a colorless rasterizer and only returned a pixel
> coverage map, which could then be colored and blended by a client
> application. As of the last version, FreeType can now add color according
> to CPAL/COLR tables, where each layer is blended with a monocolor. To
> support SVG, tt is a matter of implementing color gradients, which is not
> that hard. Some work needs to be done to implement data structures for
> complex colors and properly isolate the blending code into a dedicated
> blender-rasterizer.

Then, if the font svg gradient rendering is juke/ignored, current freetype
vector renderer will be enough. In a second phase, freetype vector code could
be re-arranged, to support the fancy extra font svg features, if actually
really needed.
If I understand where this project was going, freetype would receive some code
for an optional "pluggable" xml parser. Didn't really see how freetype vector
renderer code would be used, if ever.

-- 
Sylvain