On Wed, Dec 21, 2016 at 3:59 PM, Nikolaus Waxweiler <[email protected]> wrote:
> So, would this API achieve what you want to see, i.e. making FreeType > thread-safe for the common use case? Or is there something missing? > As long as the API doesn't change anything in FT_Library, then yes, it's thread-safe to the level that the library is right now (except for the LCD filtering options..) > And what would a better API look like, separate functions for separate > options? > Yes, that's what I would do. FreeType should not be a linker. The linker should be the linker. :) But Werner likes it this way, so that's fine with me. > I'm currently still unable to find the time to contact the Qt, cairo and > Skia people (again). So I'm not sure if an option getter is required, I think all can live without it for now. > if the automatic switching to the autohinter when the native font driver > won't darken (TT, Type1) is a good idea and if there is more API work > needed to make working with stem darkening easy. And the font drivers > and autohinter would need work, too, because the CFF driver is currently > the only one that darkens well (or at all)... > Essentially we are enabling even more head-scratching my-fonts-look-bad moments. I'm glad I'm not the one having to deal with those anymore... -- behdad http://behdad.org/
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
