Re: ascender, descender, cap-height and x-height

Greg Hitchcock wrote:
> 
> Ascender/Descender
> 
> TrueType/OpenType use the typoAscender and typoDescender in the OS/2 table.
> These are represented by OutlineTextMetrics->otmAscent & otmDescent in
> Windows. When calculating these values, TrueType traditionally uses the
> height of l/c f and the depth of l/c g for ascender and descender
> respectively. Type1 typically uses l/c d and l/c p.

However, in a message previously sent to this mailing list, David Lemon
said that a future version of the OpenType spec may specify that
typoAscender and typoDescender must sum to the em square height:

  http://lists.w3.org/Archives/Public/www-font/1999OctDec/0010.html

David, does this basically mean that OpenType would mandate that the em
square be from the top of the "nominal" ascender to the bottom of the
nominal descender?

> CapHeight/x-Height
> 
> TrueType/OpenType does expose this, but in my opinion not reliably. Both the
> PCLT table and the V 2.0 OS/2 table have these metrics, but there is not
> consistent support for these values in the fonts. The Windows
> OutlineTextMetrics return these values, but they are guessed at (I forget
> the formula, but it is something like Em / 3 for x-height.) One could
> examine the bounding box for l/c x and u/c H to make reasonable guesses,
> these BBox would be in the 'glyf' table for TrueType.

It would be nice if the next version of the OpenType spec would mandate
that cap-height and x-height be accurate. Then the font vendors might be
motivated to start updating their fonts, so that apps would eventually
be freed of the need to calculate the median ascent of the appropriate
glyphs.

Erik

Received on Monday, 24 January 2000 16:23:17 UTC