[Development] Font rendering on X11/Wayland: New FreeType API to toggle LCD filters and stem darkening on a per-font basis, would love a review

Nikolaus Waxweiler madigens at gmail.com
Sat Nov 19 01:25:13 CET 2016


>> 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. 
> 
> Any idea why exactly? 

I'm not sure what you're asking. Do you mean why LAB+GC results in
pale(r) text? The paleness is an expected side-effect of gamma
correction on low-DPI screens.

Have a look at https://www.freetype.org/image/BlendingExamples.png. All
(grayscale) examples are composed onto the surface using linear alpha
blending. Column 1 has no gamma correction, column 2 uses a gamma
correction factor of 1.8. The result in column 2 is clean but paler
text. The glyphs that FreeType outputs are really 8-bit alpha maps in
linear space: a pixel that has zero coverage of a glyph is white (255),
one with 100% coverage is black (0), one with 50% coverage is set to a
value of 127, or a middle shade of gray. Since most monitors out there
do not have a linear gamma curve, you need to bend your alpha map after
you have composited onto a surface. The 50% coverage or 127 value in
linear space maps to a value of around 180 or so on a standard sRGB
surface, 127 would be much darker. So now you go and bump that 127 up to
180 -- tada, the pixel and by extension the entire glyph is now lighter,
or paler. But also nice and clean.

You can also have a look at ftview from the freetype2-demos package. It
uses LAB+GC by default. Using LCD filtered rendering actually makes
little difference to my own surprise (press 'A' and 'C' to switch
between grayscale and LCD filtered rendering, respectively).

Since 1) a pixel's chance of being 100% covered is much higher on HiDPI
screens and 2) black is the same thing in linear space and all other
gamma curves, this is primarily an issue on LoDPI screens, so 99% of
screens out there.

> Anyway from an API point of view, the easiest implementation would be if Qt 
> could read on initialization if freetype can do stem darkening on all outline 
> fonts. Since it can't do that currently, an alternative would be to be able to 
> query it per face, and then carry the information on.

If the new FT_Face_Option() is present, FT can do stem darkening on
(almost entirely) all outline fonts :) The toolkit just has to invoke
the function on all FT_Faces to be rendered.



More information about the Development mailing list