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?
_______________________________________________
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
