There is nothing wrong with two SVG modules. From your emails it
sounds that this can actually be much simpler to implement.
Yes, maybe. It's easier to create different SVG modules for each SVG
rendering library than to create one SVG module with a callback API
generic enough to work with all major SVG rendering libraries.
I only want to avoid additional API calls. I do hold a grudge against
the current state of COLR/CPAL for this very reason. I wantted to have
a renderer do the job instead of the whole new complexities of glyph
color and glyph layer management.
Well, as far as API calls from the *user* side are concerned, it's only
one extra function call and that too if the *user* wants to plug in their
own SVG rendering library. Just a single call to `FT_Set_Svg_Hooks'.
I feel like if multiple rendering modules are created, it'd have a lot of
duplication. So imagine if I have one that links with `librsvg'. To create
another one I would need to copy paste the whole folder, rename some
things and change the bodies of two to three functions and that'd be it.
Also, if I am getting your point correct here, the whole idea of hooks go
away with this? Is that true?