> Looking at EBLC data, there's only one strike available, metrics are:
>
> ---
> Horizontal Line Metrics
> Ascender: 8
> Descender: 8
This is a bug in the font, making the strike's glyph height
effectively zero (or not, see below).
> What freetype does in tt_face_load_strike_metrics():
>
> ---
> metrics->ascender = (FT_Char)strike[16] * 64; /* hori.ascender */
> metrics->descender = (FT_Char)strike[17] * 64; /* hori.descender */
> metrics->height = metrics->ascender - metrics->descender;
> ---
>
> The question is mostly if it's reasonable to have some kind of
> workaround for that in freetype itself, like ignoring descender
> entirely in such cases or something else?
This is a good question. First of all, there is a problem with the
specification. It doesn't tell us whether positive or negative
`descender' values in the `sbitLineMetrics' record indicate ink below
the baseline. Looking into the corresponding Apple specification for
the `bloc' table, I see similar fuzzy wording.
I've now taken a look into some EBLC tables of (older) fonts
distributed by Microsoft (Windows 7), and even here I find strikes
with invalid ascender and descender values all set to zero
(`calibri.ttf' version 5.62), fonts where we have positive descender
values (`cour.ttf', version 5.11), and fonts where we have negative
values (`simsun.ttf', version 5.03). In other words, it's a complete
mess, and I came to the conclusion that we must not trust those
values.
In the git repository you can now find some heuristics to change a
positive bitmap strike descender value to a negative one (this fails
for your Misaki version since the values are too broken), and to get a
non-zero height (which always works). Please test.
Werner
_______________________________________________
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
