[MPEG-OTSPEC] Skia-based ot-svg renderer hook to freetype

[Hin-Tak Leung]

 I think I have finished this venture for now. Just pushed a "ot-svg-draw-skia.py" to freetype-py/examples. The top of the file has block of comments:

<quote>
Limitation:
 Skia-python bundles with Skia m87 (at time of writing this).

 Skia m88 is first version where SkSVG* is considered no longer experimental.

 Skia m103 is the first Skia build which contains 9cbadcd9280dc139af2f4d41d25a6c9a750e0302.
 That introduces "SkSVGDOM::renderNode()" among other stuff,
 necessary for rendering "some" OT-SVG fonts. Guess what, that commit
 is titled "Add optional OT-SVG support to FreeType"!

 So the example below only works correctly for "some" glyphs in
 "some other" OT-SVG fonts, and also with very limited functionality
 beyond what is used below.

 The missing functionality (and support for beyond Skia m103) is filed
 as skia-python issue #192.
</quote>

And with that, I'd also make three more comments:

- m98 is when Google Chrome introduced COLRv1 support (The first entry searching for "COLRv1 renderer" on my android phone is a blog post about "COLRv1 in Chrome 98"...). i.e. Google supports COLRv1 (not yet part of OFF) earlier than OT-SVG (was in OFF 4th in 2019) with m103. That commit is dated April 2022.

- 9cbadcd9280dc139af2f4d41d25a6c9a750e0302 itself contains most of what a "Skia-based ot-svg renderer hook to freetype" would look like, plus everything it depends on. If anybody wants to bolt Skia underneath freetype to enable any application which uses FreeType to use OT-SVG fonts (like adapting ft2-demos to use skia instead of rsvg...), reading that commit is both necessary and sufficient :-), I think.

- the missing "SkSVGDOM::renderNode()" also distinguishes Adobe/Mozilla-origin OT-SVG fonts vs Google-origin OT-SVG fonts. Again this difference reflects how they are made. A higher proportion of glyphs in Adobe/Mozilla-origin OT-SVG are singe-glyph SVG documents, vs multiple-glyph layered SVG documents. Google's way of making OT-SVG fonts is more size-conscious and uses multiple-glyph layer SVG documents more often (for obvious reasons of webfont usage...). This is a per-glyph issue, so I am saying that a higher proportion of glyphs in Adobe/Mozilla-origin OT-SVG fonts works without the missing "SkSVGDOM::renderNode()", than in Google-origin OT-SVG fonts.

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20230708/2a3c99bf/attachment.html>