[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] Stem darkening toggling API
From: |
Nikolaus Waxweiler |
Subject: |
Re: [ft-devel] Stem darkening toggling API |
Date: |
Sat, 29 Oct 2016 14:26:00 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
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?