For historic reasons, there are three sets of values that deal with your vertical metrics. They’re known as
usWin) metrics. Depending on which OS you’re on and which application you’re in, a different set is used for rendering the font on the screen.
Unfortunately, all of these values relate to each other in a pretty complicated way. Fortunately, Glyphs does its best to calculate them based on the vertical metrics you enter for each of your masters. This might lead to problems, however, if these values change between masters.
And in order to avoid vertical jumping between different fonts of your family, it is a good idea to synchronise all values across all masters. You will do this with Custom Parameters in File > Font Info > Masters (Cmd-I). Set the values in one master, then copy and paste the parameters into the Custom Parameters fields of all other masters.
But what do these values mean?
The hhea Values
hhea refers to the
hhea TrueType table. I believe it’s an abbreviation for horizontal typesetting header. Macs and iOS devices use these values for rendering.
hhea knows three vertical metrics values. (For convenience, I’ll use the Custom Parameter names that Glyphs uses.)
hheaAscender: the height of the ascenders in units
hheaDescender: the depth of the descenders in units (negative value)
hheaLineGap: the recommended whitespace between lines
The OS/2 Values
These values are part of the
OS/2 TrueType table. Anybody remember the operating system by the same name? Type pros commemorate it every day. Sometimes, they are also referred to as
sTypo values, though. To quote Yannis Haralambous (p.724), these values ‘are oddly similar to ascent, descent, and lineGap in the hhea table but that should not necessarily be so precise or so closely tied to the vagaries of the glyphs’ outlines. Windows supposedly uses these values to find the ideal parameters for layout; thus we have a certain degree of artistic freedom.’
typoAscender: the height of the ascenders in units
typoDescender: the depth of the descenders in units (negative value)
typoLineGap: the recommended whitespace between lines
The big layout apps, XPress and InDesign, use the
typoDescender values to determine the offset of the first baseline in a text box and the minimum size of a text box below which the display of type is suppressed.
There is one thing you need to watch out for, though. For whatever reason, the difference between
typoDescender should be as large as the font’s UPM (usually 1000). This is the first thing that’s going to make things complicated for us. We’ll come back to that later.
The usWin Values
usWin) values are also part of the
winAscent: the top extremum of the font rendering box
winDescent: the bottom extremum of the font rendering box (positive value)
Attention: whatever extends above or below these values, will likely be cut off when rendered by the Windows text engine. Hence, the easiest way, it seems, is to make sure everything in the font fits into the
win span. So, usually, the
win span will encompass more than 1000 units (or whatever your UPM value is). Now, I suppose you can already guess what the problems are going to be.
In any event, with these Custom Parameters, you can override the automatic calculation and set the values manually. But beware: amongst font nerds, there are fierce disputes going on about what is the best strategy. Let me show you the most popular strategies for manually setting your vertical metrics.
The Adobe Strategy
hhea values are synchronized with the
With this strategy, the linegap tends towards the small end of the spectrum. So it may be a good idea to use this method if your font has a low x-height (below half UPM). Advantage: better synchronization of font display between Mac apps and layout apps (XPress, InDesign). Disadvantages: differences between Mac and Win display; accents on caps may be cut off in office apps.
The Microsoft Strategy
hhea values are synchronized with
win values, thus to the BBox maxima.
For the rest, as already mentioned above, the span from
typoDescender must add up to your UPM value (usually 1000). You could put the depth of the descender into
typoDescender (e.g. −200), you put the rest (800) into
typoAscender. In this strategy, the sum of the
win ascender and descender will most likely be much more than 1000, or whatever your UPM is. Subtract your UPM value from that sum and put the result into
With this strategy, the linegap tends towards the large end of the spectrum. So it may be a good idea to use this way if your font has a large x-height (above half UPM). Advantages: better synchronization of font display between Win and Mac apps; accents are not cut off in Mac apps because WinAscent tends to be higher than OS/2 TypoAscender. Disadvantage: differences between Mac apps and layout apps (XPress, InDesign).
There is one more thing. If you can safely ignore older (i.e., pre-2006) MS Office versions, you can get away with the Adobe strategy and fsSelection bit 7. For this, you simply add a Use Typo Metrics parameter to your instance:
Use Typo Metrics boolean If checked, applications that respect this setting (in particular, versions of Microsoft Office since 2006) will prefer typoAscender, typeDescender, and typoLineGap over winAscent and winDescent for determining the vertical positioning. Default is off. Corresponds to bit 7 (‘don’t use Win line metrics’) of the fsSelection field in the OS/2 table. According to the MakeOTF User Guide, this bit was introduced ‘so that reflow of documents will happen less often than if Microsoft just changed the behaviour for all fonts.’
The Webfont Strategy
Here, you set the
winDescent values first, because what is clipped and what not is most important on Windows machines. Then, in Windows browsers, the bounding box (and thus, the relative vertical placement of the glyphs) is derived from the
win values. But on the Mac and iOS, most browsers will prefer the
hhea values for the same thing. But for maximum compatibility with layout apps, you also need to sync the
hhea values with the
OS/2 values. That means that the relative distribution of ascenders and descenders must be the same, but still fit into the UPM. So, this is what we get:
winDescent) round this value
This is a good compromise between the two other strategies. The differences in vertical placement are not zero, but reasonably minimised between apps, operating systems, and especially browsers.
Careful: This method assumes that you have fairly regular measurements, i.e., that all important parts of your font more or less fit into your UPM, give or take a few units. Consider adapting your UPM if you still see a lot of cropping.
If the calculations lead to large line gap values (anything larger than a fifth of the UPM), consider reducing the line gaps and increasing the hhea and typo ascenders by the same value. This may lead to a situation where the typo metrics do not add up to the UPM anymore, but experience shows that fonts work well when this dogma (see further reading below) is broken. Do not forget to do extensive testing.
If you are exporting TTFs and still experience cut-offs in apps like Microsoft Word, especially with double accents (like the ones in Vietnamese or Pinyin), then try this: First make sure your
winDescent are properly set, e.g., they encompass the highest and lowest glyphs you want to keep from being cut off. And now, you need TT zones at
winDescent. These additional zones cause the renderer to include everything up to their position.
If you are manually TrueType hinting, you can add the
winDescent zones with the TTF Zones parameter in File > Font Info > Masters (Cmd-I).
If, however, you are relying on ttfautohint, there is an even easier way. All you need to do is go to File > Font Info > Instances > Custom Parameters enable the Windows Compatibility option in the TTFAutohint options parameter. Repeat that for every TTF instance, and you are done:
Recommended Further Reading
In his Vertical Metrics How-to post, John Hudson gives his own recommendations for optimising Vertical Metrics with special consideration for Microsoft Word. (Hint: The
fsSelection bit he is talking about is the
Use Typo Metrics parameter I explained above.)
Graham Wideman conducted a detailed analysis of vertical metrics behavior in various environments.
In recent discussions, the ‘UPM dogma’ (the spec requirement that typoAscender and typoDescender add up to the UPM) has been under fire, especially for complex non-Latin scripts. One of the proponents of letting go of the UPM dogma is Victor Gaultney from SIL, who wrote both Best Practice: Design Metrics and Best Practice: Line Metrics.
And there are two ways of visualising the vertical metrics: Jan Janeček’s Vertical Metrics Tool, and a Reporter plug-in for Glyphs called Show Vertical Metrics. You can find it in Window > Plugin Manager.
Whoa. And now, for a coffee break. Or some ice cream. Or both.
Update 2013-05-25: Updated to new parameter naming scheme, fixed a few wordings.
Update 2015-07-17: Corrected a mistake (typoDescender must be negative), removed Typophile link and reference for version 1.3, added Webfont Strategy.
Update 2016-12-02: Added section about TT Zones.
Update 2017-04-25: Added note, corrected typo in Webfont Strategy, added Further Reading.
Update 2017-11-30: Added note about Use Typo Metrics parameter.
Update 2018-07-04: Added link to John Hudson’s Vertical Metrics tutorial.
Update 2018-10-11: Changed outdated Wideman link to Wayback Machine.