Hello David,
I am a final year student of Engineering from Pakistan. It was my GSoC 2019 project to add OTSVG support to FreeType.
The final project report is available at:
https://moazin.bitbucket.io/gsoc-2019/ in case you want to read it. It has all the details of how the project was accomplished. If you have any questions or feedback please let me know. :-)
The code wasn't merged because we were blocking on a functionality needed from the svg-native-viewer library that can give a bounding box of an SVG document. Unfortunately, I couldn't find the time to contribute it myself and at the moment I am busy with my GSoC 2020 project with Inkscape.
That would not prevent us from introducing a new way to "plug" renderers, probably with a new interface, that would be much more specific, and would deal better with subtle issues like deallocating bitmap buffers that were allocated by the renderer.
Yes, the hooks do this.
In the case of OT-SVG, I haven't looked at the problem in detail, but it looks like this would require a new glyph image type to support (doable), and the ability to provide FreeType with an interface it could use to render these with a third-party library.
Yes, FT_GLYPH_FORMAT_SVG and FT_SvgGlyph.
Do you know if the format allows compositing SVG and non-SVG glyphs together? That would be ... difficult to support though.
Umm, not sure, but if I recall correctly no such thing is mentioned in the ot-svg specs. And why would someone want to render both glyphs together (if that's what compositing means)?
I don't think we want to statically link any SVG renderer to the library by default. There are so many subtleties related to vector graphics rendering, that there is no "good" default choice to make. In other words, any default we select at link time would probably be inappropriate for a lot of developers anyway.
Hmm, this is one of the most heavily debated matter of the project. :-D