>> I'm working on FreeType and want to merge a new API (FT_Face_Option) >> that would allow setting LCD filter weights and stem darkening >> properties on a per-face basis. > > I'm fascinated but clueless !
https://www.freetype.org/freetype2/docs/text-rendering-general.html#experimental-stem-darkening-for-the-auto-hinter Correct font rendering with linear alpha blending and gamma correction can make text look pale like reported in https://bugreports.qt.io/browse/QTBUG-41590 due to the way the math behind it works out. Stem darkening compensates for the paleness. The new API is trying to make it practical for toolkits to opt into correct rendering of fonts by making it easy to toggle stem darkening (older toolkits without opt-in will get the same glyphs as before to keep backwards compatibility). No more bug reports about pale text! (Windows, macOS and Adobe's own font software render fonts correctly (read: compose glyphs correctly onto surfaces). macOS and I think Adobe software also use stem darkening to counteract paleness. The effect is most obvious on macOS. No toolkit on X11/Wayland does any of this currently. I want to change that. Stem darkening was introduced to FreeType by Adobe, by the way.) >> A side issue this is trying to solve is making the API thread-safer, > > The concept "thread-safer" amuses me. As far as I understand, FT is not by itself thread-safe, the developer has to use the API in a certain way to not blow things up. This API is supposed to be another stepping stone towards usefulness/pain-lesser-ness in a multithreading context. > I've (as ediosyncratic) reviewed; nothing struck me as obviously > problematic. I am not, however, a graphics expert. Thanks! :) _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
