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 _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
