Re: [ft] Working around a bad ascender value?

[Werner LEMBERG]

> After much debugging it was determined that the ascender and
> descender values returned by Freetype for the problem font are not
> good.
>
> Ascender:750
> Descender:-170
> Bbox: xMin  -430 xMax  3162 yMin  -885 yMax  3080
> UpEM: 4096
>
> The ascender is much smaller than yMax, and the descender much
> greater than yMin.

What FreeType returns are the value present in the font.  From a ttx
dump:

  <hhea>
    ...
    <ascent value="750"/>
    <descent value="-170"/>
    <lineGap value="9"/>
    ...

  <OS_2>
    ...
    <sTypoAscender value="750"/>
    <sTypoDescender value="-170"/>
    <sTypoLineGap value="30"/>
    <usWinAscent value="3080"/>
    <usWinDescent value="885"/>
    ...

> (The height value also looks wrong, it is only 929.)

Well, this is simply the value of `hhea's

  ascent - descent + lineGap

> In the Freetype documentation there are references to sTypoAscender,
> which is said to be pretty reliable.

As you can see from the above, you would get again the far too small
values.  This font was obviously checked on the Windows platform
only...

> How does one retrieve information from the OS/2 table (assuming one
> is present)?

  TT_OS2* os2;

  os2 = (TT_OS2*)FT_Get_Sfnt_Table(face, FT_SFNT_OS2);

> Is there some other common workaround for this sort of problem?

Unfortunately, the answer is no.  It's definitely a font bug, or
rather a font conversion bug, since it seems that the converter only
scaled the `usWin*' fields from 1000 (PostScript) units per EM to the
actually used 4096 upem, failing to do it for the other values.

I guess you have to implement some heuristics that compares the three
`metric systems' (i.e., `usWin*' from `OS/2', `sTypo*' from `OS/2',
and the `hhea' values), using the one that appears most sensible.  Or
maybe you add an interface that allows the user to select which one to
use.


    Werner