On 15-12-31 09:50 PM, Nikolaus Waxweiler wrote: >> It's not. To you, there might be a lot of things in FT_Library. To the user >> of FreeType, none of them are relevant. A user of FreeType only cares about >> FT_Face objects. The only piece of FT_Library, so far, used by major >> clients, >> is the SetLcdFilter API. > > Hm. So you would only move the lcd_* members to FT_Face and go for a > FT_Face_SetLcdFilterWeights()?
Historically things were added in load-flags. But that's not scalable, so adding new functions for new properties sounds like a more scalable approach. I like this. > If I understand your thread model > correctly, properties are okay as long as they are confined to a > FT_Face? Yes, because an FT_Face cannot be used from multiple threads currently. What I did last year was to make FT_Library usable from multiple threads (within certain limitations). Otherwise, client libraries would have to create one FT_Library per FT_Face. That's what I like to avoid. > I would model my stem darkening property after your proposal. Werner has to make the call. Thanks, -- behdad http://behdad.org/ _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
