freetype
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Khaled Hosny
Subject: Re: [ft] Working around a bad ascender value?
Date: Fri, 15 May 2015 00:41:58 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Thu, May 14, 2015 at 09:29:23AM -0700, mathog wrote:
> On 13-May-2015 22:13, Werner LEMBERG wrote:
> >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"/>
> >    ...
> >
> <SNIP>
> 
> >
> >>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);
> 
> Ah good, that is not hard.
> 
> >
> >>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.
> 
> I don't have a lot of experience with font bugs, so it isn't entirely clear
> to me what the "most sensible" choice would be.  Here the choices are two
> values for ascender which are less than half of yMax, which is very suspect,
> or yMax itself.  yMax is always the fall back, the trick is figuring out
> which of the other 3 is "most right", and if any are "right enough".  I
> guess the largest of the 3 would normally be "most right" so long as it
> isn't larger than ~yMax.  Unless of course the largest one is something like
> 0.2*yMax.

I’d rather just ignore font bugs, if a font is broken, it is broken, and
whoever made the font should just fix it. Using the largest value of the
three is not right either, the Win values should be big enough to fit
the largest glyph in fonts, and even make room for combining marks since
applications use it for clipping, and for some fonts (e.g. math fonts)
it can be rather big and using it for line spacing will result in huge
gaps between lines.

Regards,
Khaled



reply via email to

[Prev in Thread] Current Thread [Next in Thread]