> > 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?
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
