(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
<ht...@users.sourceforge.net> wrote:
On Tuesday, 4 July 2023 at 21:30:56 GMT+8, Dominik Röttsches
<dr...@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-ots...@lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
