[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]

> I am just curious from a philosophical point of view how come stem 
> darkening is even needed. Gamma-corrected blending might end up 
> paler, but it should be a more correct result, so it just odd that it
> looks wrong and that a compensation is needed. Somewhere we must have
> done something that relied on naive blending. Maybe in the design of
> the fonts?

The result is indeed more correct, but LoDPI screens ruin everything ;)
You could say that this is indirectly the fault of the font's design.
Stem darkening is a pragmatic solution to increase contrast. The
algorithm used by FT adjusts the darkening depending on the pixel size
and font design. Thinner fonts are darkened more than bolder fonts. The
darkening becomes stronger at smaller pixel sizes. Above a threshold (at
larger pixel sizes), no darkening is applied.

This implies that the font engine must have more control over the final
appearance of a glyph and this is... difficult if it involves the
explicit nature of TrueType hinting.

> Also I notice in your example you also use a too low gamma value. The
> standard in screens in between 2.2 and 2.4, and when using that I
> generally see an inversion in the contrast balance.

The 1.8 comes from internal testing at Adobe. I was told they tested
font rendering on a variety of screens and determined 1.8 to be a good
compromise. I think Microsoft uses 1.4 for GDI font rendering?

> Look at the attached example.  Ideally with correct blending text 
> should look equally "bold" regardless of background and foreground 
> color. It is obvious white on black with naive blending is too weak,
>  but the color on white text with GC blending is just as weak, while
>  white on black is now as bold as color on white used to be. If I 
> used a gamma of 1.6 it would look more balanced, but my screen has a 
> gamma of either 2.4 or sRGB , so why does using the right value give 
> the an unbalanced result?

Hm, I think this is a perception issue. In your example, I find the
third column to be more balanced than the first. The brain sees
white-on-black differently than black-on-white, so a designer has to
compensate for the non-linearity :) This is especially noticeable if
your brain is accustomed to naive blending. White-on-black looks similar
on macOS.

> Anyway, on the API front. Forcing to autohinter is probably not 
> acceptable. So we could enable stem darkening where native available,
> but then we need to know if what engine a face is using, or better
> yet specifically if the engine used right now on this face did stem
> darkening.

I can implement something for the TT engine (v40 backwards compat.
mode), maybe even soon. You can test for native stem darkening like so
(src/base/ftobjs.c:633):

```
    error = FT_Property_Get( library, driver->clazz->root.module_name,
                             "no-stem-darkening", &stem_darkening_driver );
    if ( error )
    {
      driver_can_darken_stems = FALSE;
      stem_darkening_driver   = FALSE;
    }
    else
    {
      driver_can_darken_stems = TRUE;
      stem_darkening_driver   = !stem_darkening_driver;
    }
```

(Gotta run, look up the doc for FT_Property_Get. Getting an error back
means that the font driver probably won't do stem darkening. TT is
tricky as noted above, must implement first before I can give a definite
answer)