Re: [ft-devel] Stem darkening toggling API

[Nikolaus Waxweiler]

> Just to sum up what we currently have to control stem darkening (for
> CFF).  The same essentially holds for all other parameters that
> control FreeType modules.
>
>   1. A configure-time option (more or less).
>   2. A run-time option to globally control stem darkening for all
>      faces.
>   3. An environment option to globally control stem darkening for all
>      faces.
>   4. Your proposed interface to control stem darkening for a specific
>      face.

Does it make sense to be able to adjust 1 per face? Maybe it will if I 
implement stem darkening for the TT engine, depending on whether I want 
to implement stem width analysis or go with what Dave outlined Adobe did 
with their mobile renderer at one point. I'll see.

I originally thought about removing 2 and 3 (the global toggles) and 
stick with per-face-options only, but I guess that will just break 
compatibility and expectations. I'm somewhat unhappy that this would be 
another property setter besides FT_Property_Set, though.

What about the LCD stuff? FT_LibraryRec_ includes

```
    FT_LcdFilter             lcd_filter;
    FT_Int                   lcd_extra;        /* number of extra pixels */
    FT_Byte                  lcd_weights[7];   /* filter weights, if any */
    FT_Bitmap_LcdFilterFunc  lcd_filter_func;  /* filtering callback     */
```

and there's FT_Library_SetLcdFilter() and 
FT_Library_SetLcdFilterWeights(). I guess all of these must stay for 
compatibility. The functions can be turned into parameters for 
FT_Face_Option(), the lcd_* members can be copied to FT_Face's internal 
struct. They would be font-specific overrides for the library defaults.

Behdad, would this suffice to make FT_Face thread-safe, provided clients 
keep their hands off FT_Library?