On 15-12-15 05:08 PM, Werner LEMBERG wrote: > >>> A new function operating on FT_Library, as Jan suggests, is the way >>> to go, I think, cf. `FT_Library_SetLcdFilter'. >> >> I recommend against that, as it makes the FT_Library non-threadsafe. >> I hvae plans to replace SetLcdFilter with bits in the load_flags to >> make FT_Library fully threadsafe eventually. > > Hmm. It's not clear to me what you want. Where should metadata be > stored? With `metadata' I mean stuff that acts globally on many > faces.
How is that different from, say, other hinting settings? I don't see any distinction. To you and your model of the world, these might "act globally on many faces". To a fontconfig-using-, or cairo, or Chrome, or Firefox, or Skia, or Android, or Qt, or any other large-enough platform, there's no global setting, there's just per-face configuration that needs to be enabled. If you push that to FT_Library, that makes FT_Library thread-unsafe and bound to one face at a time. > Or do you want to get rid of metadata altogether, this is, > moving the global properties in FT_Library to private data in FT_Face? > This would be a major change in FreeType 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. All the module, and service, and property API, those are things the user doesn't care about. They don't render fonts. FT_Face does. >, and I'm not sure that this > would be a wise decision, since it would make FT_Face larger. We > would also need a new API for handling FT_Face properties. This goes back to the original discussion around whether we need runtime properties at all :). > Note that load_flags is the wrong place for setting the LCD filter > IMHO. Why? How is that different from other load flags that control aspects of rasterization? > Additionally, we are slowly running out of available bits in > load_flags... Sure, that's a tangible problem we can discuss. Cheers, behdad > > Werner > -- behdad http://behdad.org/ _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
