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