Re: [ft] Misaki Mincho metrics issues

[Nikolay Sivov]

On 24.10.2015 11:13, Werner LEMBERG wrote:
> > 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.

Right, I tried to look it up before sending initial request, and nothing 
solid came up.

> 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.

Thank you for a quick fix. I just tested it, and with enabled tracing I 
can see this new code is used, and fixed up height is there. But there's 
one issue that zeroes height anyway by the time it gets back to me. I'm 
using 'available_sizes' to access that, and it seems the problem is that 
new fixed up metrics are not using 26.6 format - see attached patch. 
With this fixed I don't get 0 height anymore. Thanks again.

Nikolay

>      Werner

0001-sfnt-Fix-bitmap-strike-metrics-scaling.txt
Description: Text document