W3C home > Mailing lists > Public > www-style@w3.org > August 2010

Re: Em box and font data

From: John Hudson <tiro@tiro.com>
Date: Wed, 04 Aug 2010 08:52:29 -0700
Message-ID: <4C598CBD.9020606@tiro.com>
To: Stephen Zilles <szilles@adobe.com>
CC: www-style@w3.org
Stephen Zilles wrote:

> 2.       All OpenType fonts and many TrueType fonts have values for 
> sTypoAscender and sTypoDescender in the OS/2 table which are font (not 
> glyph) metrics that specify the intended typographic upper extent and 
> lower extent of the collection of glyphs in the font. 

This is not quite accurate. The OS/2 sTypo values typically do not 
correspond to the upper and lower extent of the glyphs in the font, 
which are properly recorded in the usWin values.

 > It is recommended
> (but not required) that distance between the two values in design space 
> be 1 Em (i.e., the distance between the two values total the number of 
> UnitsPerEm as defined in 1. Above).

I get the impression that more font makers are following this 
recommendation, but there are a lot of fonts out there in which this is 
not the case.

A typical approach to setting these sTypoAscender and sTypoDescenderer 
values, for a European script typeface, is to sum the actual ascender 
(d) and descender (p) distances from the baseline, than add to divide 
between each the difference between this sum and the font em. Some font 
makers will divide the difference equally between the sTypoAscender and 
sTypoDescender, others will divide them proportionally.

Your notes do not mention the sTypoLinegap value, which is the third 
font metrics value that specifies the default leading value. This is 
most commonly set so that the sum of all three sTypo values (taken as 
positive integers) equals 120% of the em, i.e. 10pt type on 12pt 
leading. But this value may vary significantly, especially for non-Latin 

> 4.       There is a third set of values, usWinAscent and usWinDescent, 
> which are Microsoft Windows specific values that specify (essentially) 
> the top and bottom of the bounding box for the area marked by the glyphs 
> in the font. These values are used for clipping the line to insure the 
> all possible characters on the line will be completely visible. It is 
> the existence of these metrics that has lead to text in 10.6.1 which 
> says, A UA may, e.g., use the em-box or the maximum ascender and 
> descender of the font. These values are not appropriate for this 
> discussion.

It should be noted that close to 100% of Windows applications 
(erroneously) use the usWin values to calculate default linespacing in 
addition to defining the non-clipping zone. In other words, the sTypo 
values are ignored.

To ensure cross system and application compatibility, it is recommended 
to have all three metrics sets -- OS/2 sTypo, OS/2 usWin, hhea -- sum to 
the same total, unless there is a pressing need otherwise.

The fairly recent version 4 OS/2 table includes an fsSelection bit (7) 
setting that is meant to instruct an application to use a font's sTypo 
values rather than usWin values for default linespacing. This is useful 
if a font has some unusually tall variant forms that require very large 
usWin values to avoid clipping, but which in typical use would not 
require such huge linespacing. Examples of fonts with this bit setting 
are Microsoft's Cambria Math and Gabriola fonts. However, the only 
shipping software I am aware of that currently respects this bit setting 
is Word 200, and it does so idiosyncratically.

Received on Wednesday, 4 August 2010 15:53:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:48 UTC