[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: |
Tue, 22 Nov 2016 16:58:39 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
> Here you can see a small weakness in the idea of shifting the property
> control from FT_Library to FT_Face: FreeType modules are not the same
> as FreeType font drivers; the latter is just a subset.
What do you mean?
> Get the font format with `FT_Get_Font_Format'; the returned string can
> then be mapped to the corresponding module name.
>
> CFF -> cff
> TrueType -> truetype
>
> For the auto-hinter this doesn't work, of course, since it is
> completely agnostic of the font format.
Hm. This also means that client libraries have to keep track of the
names of modules should they change in any way. Not good. Maybe a getter
of some sort becomes necessary.
Something else became appararent while I looked at a WIP for Qt: If a
library wants to decided on a face-by-face basis if stem darkening can
be enabled, it needs to know if the autohinter or the font driver will
do the hinting *before* calling FT_Load_Glyph so the appropriate module
can be queried for stem darkening capabilities. The trouble is that the
final decision is made by FT_Load_Glyph, so you'd have to embed
assumptions about the decision process into a client library. Suboptimal.
Also, the code currently just uses the autohinter if a font driver can't
darken stems. Should it not do that?
- Re: [ft-devel] Stem darkening toggling API, (continued)
Re: [ft-devel] Stem darkening toggling API, Werner LEMBERG, 2016/11/10
Re: [ft-devel] Stem darkening toggling API, Nikolaus Waxweiler, 2016/11/13
Re: [ft-devel] Stem darkening toggling API, Nikolaus Waxweiler, 2016/11/20