(Cross-posted to freetype-devel)
It seems that skia itself has all the rsvg equivalent to implement the ot-svg renderer callback hooks in freetype, but skia-python is missing the python equivalent of SKSVGDOM::renderNode() . This means that if I re-write the rsvg-based python svgrender hooks with skia-python, it would only work with Adobe/Mozilla OT-SVG fonts, but not Google OT-SVG fonts (until skia-python improves).
I think I'll give it a go and try to put an example out under freetype-py/examples (probably will call it "ot-svg-example-skia.py", after the other "ot-svg-example.py") . If the Freetype folks want to port to freetype2-demos, and add the missing renderNode() to support all OT-SVG (I mean Google OT-SVG fonts...) with a different svg rendering engine than rsvg, they can fish it out of freetype-py/examples ... :-).
On Tuesday, 4 July 2023 at 21:58:10 GMT+8, Hin-Tak Leung <htl10@users.sourceforge.net> wrote:
On Tuesday, 4 July 2023 at 21:30:56 GMT+8, Dominik Röttsches <drott@google.com> wrote:
> ... I don't think it would be the right architectural choice to redundantly repeat these concepts inside FreeType itself. Even more so, as fast compositing and gradient implementations require time and effort to make them reasonably fast.
It isn't repeating these concepts in Freetype. Currently, in one (actually two, c and python) implementation, Freetype farms off rendering of OT-SVG glyphs to rsvg, which in turn is cairo-based, to do the actual rendering. FreeType just provides a plug-in system which allows an external library to do the rendering. Basically Freetype gives out the glyph svg outlines etc, and the external library fill in the extent and the actual buffer of a rendered bitmap. This allows any freetype-based applications to use OT-SVG fonts.
_______________________________________________
mpeg-otspec mailing list
mpeg-otspec@lists.aau.athttps://lists.aau.at/mailman/listinfo/mpeg-otspec