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
