Dear Sylvain,

> Which svg renderer will be used? Which XML parser will be used? Because, that
> could add heavy SDK deps to freetype.

Very very good point, I sympathize you strongly.

At present, I don't suggest to link SVG renderer to libfreetype directly.
For sbix color font support, libpng is directly linked to libfreetype,
but I suggest to make libfreetype + SVG renderer collaborate by a callback
system.

If the users of SVG-OT want to use SVG-OT with the application
which already have their own SVG renderer (aslike web browsers or
other application using WebKit as layout engine), I hope if they
can use existing SVG renderers by a callback system.

> libxml2 is massive and heavy, and we can start to feel the weight of
> expat.

Indeed. I don't suggest to link libxml2 to libfreetype directly,
because it's huge as you say. In my understanding, expat can parse
XML, but the clients have to many things by themselves. I don't
suggest to invent yet another XML parser for FreeType and maintain
as a part of FreeType.

Regards,
mpsuzuki

sylvain.bertr...@gmail.com wrote:
> On Tue, May 07, 2019 at 06:24:41AM +0200, Werner LEMBERG wrote:
>>   (3) Moazin Khatti: Adding support for OpenType SVG Colored Fonts to
>>                      FreeType
> 
> Hi,
> 
> Which svg renderer will be used? Which XML parser will be used? Because, that
> could add heavy SDK deps to freetype.
> librsvg is re-implemented in rust, and the only reasonable alternative I know
> is the small and incomplete svg renderer from netsurf browser.
> 
> libxml2 is massive and heavy, and we can start to feel the weight of
> expat.
> 
> Or will be there a font taylored svg renderer? (I guess that would add a dep 
> on
> cairo FT own vector rendering code).
> 
> regards,
> 

_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Reply via email to