> > Or, you can just prioritize the separate renderers. Do not waste
> > your work.
>
> While the concept of having different renderers sounds nice in theory,
> I think it is a hassle to implement, since it moves the burden of
> properly supporting various SVG rendering libraries to FreeType.
>
> I still favour the model of having a *single* default renderer for
> SVG, providing hooks that can be overridden at run-time for another
> library.
Werner, Moazin,
This is not user friendly and users will resist it. How many calls a
user has to make to initialize the library:
1) FT_Init_FreeType
2) FT_Library_SetLcdFilter (how many people forget this already)
3) FT_Property_Set
4) FT_Set_SvgHooks (at least use FT_Property_Set instead)
Quite on the contrary. Since FreeType is the kind of library that needs explicit initialization anyway, adding one more line there is trivial. Some libraries (like HarfBuzz) don't have explicit initializations. It would be more annoying in those libraries if something similar was required...
librsvg depends on cairo which depends on freetype. Any SVG renderer optionally-supporting-text would depend on FreeType. Don't add these recursive dependency cycles. Client should just add one call that's it. No default required.
All I care is that the SVG rendering is properly abstracted as a
renderer module that can be FT_Add/Remove_Module and customized by
FT_Property_Set. Moazin made the right steps already by removing any
special code form FT_Render_Glyph_Internal.
Thank you,
Alexei
_______________________________________________
Freetype-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/freetype-devel