Hi Alexei,
Whatever external SVG renderer you choose, please use FT_Renderer facility to hook it up with FreeType instead of creating a set of SVG specific functions: an SVG glyph should be tagged as FT_GLYPH_FORMAT_SVG, which is then picked up by the dedicated SVG FT_Renderer with hooks to external library. The SVG support can be enabled/disabled using the renderer modules, say "svg-ot", in modules.cfg.
I have been looking at FT_RendererRec_, FT_Renderer_Class, FT_Module_Class. FT_Module and how these modules are initialized in FT_Init_FreeType. The SVG Renderer Module will have the SVG library hooks which it'll call when the `render' function is called by FT_Render_Glyph.
1. I see that all default modules (including the renderers) are initialized in FT_Init_FreeType. Whatever hooks we decide to have, there is likely to be one for initiating the external library. The function this initialization hook points to, will usually instantiate the rendering backend (for example, in case of cairo, cairo surface and context) and maybe the library will have some object of its own too which will be initialized. If we choose this initialization hook to be called by the `module_init' function, the initialization will be done on every FT_Init_FreeType call (as long as SVG feature is enabled), regardless of whether the font contains an SVG table or not, regardless of whether the user wishes to do any SVG rendering or not. Is this a problem from performance and memory point of view? If it is, how can we move this initialization to be done in FT_New_Face depending on whether there exists an SVG table or not. That'll solve it a bit, I think. If this is to be done, is there a standard approach to this?
2. If the users of FreeType want to inject their own hooks (instead of using the default ones we place for our out-of-the-box renderer) where and how should they do it? Some FreeType API function they can call which will grab the rendering module and replace the hooks? An FT_Renderer only exposes only one or two functions, `render' and `raster_render', how do I call the one that will replace the hooks? Do I subclass FT_RendererRec or FT_Renderer_Class and create a new structure having that function? Or is there some other way?
Note about # 1 and # 2 that the both questions can be generalized to, "how do I expose some more functions from SVG Renderer module?" If this is not how it is to be done at all, please let me know and tell me about the right approach too.
3. I have observed that in FT_Load_Glyph, glyph data is loaded, which is further used by FT_Render_Glyph (except in case of bitmap embedding when there's nothing to be done). After FT_Load_Glyph is called, in simple monochrome fonts, the Glyph Slot contains vector data, for SBIX and CBDT, it contains everything (the bitmap itself too) and for CPAL/COLR, it doesn't contain much because of the recursion mechanism in which it is called again multiple times where it behaves just as with monochrome fonts. However, what will it contain for an SVG Glyph? I think it could contain a pointer to a stream of the SVG document in which that glyph is located along with a glyph ID (multiple glyphs can live inside a single document). If this is true, will I need to modify the FT_GlyphSlot structure to add these fields? or is there another way?
Note about # 3 that I am only asking this to confirm my understanding about the FT_GlyphSlot "getting" some new fields. What fields those will exactly be, is hard to answer at the moment. We still haven't decided whether a caching mechanism (for those SVG documents which have multiple glyphs) will live inside FreeType or the external library sitting behind the hooks will handle that for us.
If any part of my questions is not understandable, please let me know, I'll try phrasing it in a different way and elaborate it more.
Regards,
Moazin