On Sat, Jul 6, 2019 at 2:16 PM Moazin Khatri <[email protected]> wrote: >> >> Do you plan runtime selection of SVG library? This is not very user >> friendly. Perhaps it is better to have separate rendering modules for >> each SVG library, selected at compile time. I will take a detailed >> look at your code soon. > > Well, yes, at the moment it is selected at runtime. Once we decide > on a default rendering library we could create default hooks, so the > end user won't need to set them unless they want to plug a different > library (other than the default one).
We should not decide this if both libraries work. We should have both modules available so that user can FT_Add_Module or FT_Remove_Module at runtime if user wishes. With both modules loaded, FT_Render_Glyph will find the first one that works for FT_GLYPH_FORMAT_SVG. It is not worth overdesigning the interface. > All along, I have been under the impression that only > ONE SVG rendering module will exist which will basically act as a > bridge between FreeType and the SVG rendering library. There is nothing wrong with two SVG modules. From your emails it sounds that this can actually be much simpler to implement. > The problem of user-friendliness can be solved by putting in a > default rendering library. Then the user won't need to do anything > extra. However, are there more potential problems with the current > approach? 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. > I am totally good with doing it with the approach that you mentioned. > Whatever the community agrees on. :) -- Alexei A. Podtelezhnikov, PhD _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
