Re: [ft] Misaki Mincho metrics issues

[Werner LEMBERG]

> 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