Vertical metrics determine the first baseline in a text, the distance between lines of text, and the padding to the following object below the last baseline. For historical reasons, there are no less than 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: ascender, cap height, x-height and descender. You may run into problems, however, if these values change between masters.
The Custom Parameters
So, in order to avoid vertical jumps when you switch 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? Let me give you a quick rundown.
hhea refers to the
hhea OpenType table. ‘hhea’ is supposed to be an abbreviation for ‘horizontal typesetting header’. Apple devices such as Macs, iPhones, iPads, etc., use these values for rendering. The
hhea table knows three vertical metrics values. For convenience, I will list them here with 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
OS/2 sTypo (typo)
These values are part of the
OS/2 OpenType table. Anybody remember the operating system by the same name? Type pros commemorate it every day, thanks to vertical metrics. Sometimes, they are also referred to as
sTypo or simply
typo values, though. I have seen designers refer to them as
OS/2 values, but that is a little imprecise, because the
win values are also part of the OS/2 table.
typoAscender: the height of the ascenders in units
typoDescender: the depth of the descenders in units (negative value)
typoLineGap: the recommended whitespace between lines
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.’
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. In DTP apps, the line gap is set by the user, hence
typoLineGap is ignored.
Office software and browsers should prefer the
typo values over
win if the
Use Typo Metrics parameter is set to yes. In that case,
typoLineGap will be respected as well.
The UPM Dogma
There is one thing you need to watch out for, though: the ‘UPM dogma’. In the dark past of electronic typesetting, the TrueType/OpenType specifications used to stipulate that the span from
typoDescender should be as large as the font’s UPM (usually 1000 or 2048). This is the first thing that’s going to make things complicated for us.
In recent discussions, however, the ‘UPM dogma’ (the former 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 was Victor Gaultney from SIL, who wrote both Best Practice: Design Metrics and Best Practice: Line Metrics.
As a consequence, the dogma was dropped altogether in the latest OT specification:
It is not a general requirement that sTypoAscender - sTypoDescender be equal to unitsPerEm. These values should be set to provide default line spacing appropriate for the primary languages the font is designed to support.
(Source: OS/2 sTypoAscender specification on Microsoft Typography)
Yet, the UPM dogma still plays a role in the (historic) Adobe and Microsoft strategies discussed below.
OS/2 usWin (win)
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.
Pro tip: In order to find the highest and lowest points in your font, try the mekkablue script Test > Report Highest and Lowest Glyphs. For every master, highest and deepest points in all glyphs will be listed.
Use Typo Metrics
There is one more thing. If you can safely ignore older (i.e., pre-2006) MS Office versions, you should add a
Use Typo Metrics parameter to File > Font Info > Font. Quoting the Glyphs Handbook:
Use Typo Metrics boolean If checked, applications that respect this setting (in particular, versions of Microsoft Office since 2006) will prefer typoAscender, typoDescender, 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.’
All modern fonts should have this parameter. It tells Office apps to prefer the
OS/2 values over the
win metrics. So if you do not have a good excuse, add it to your font.
Alas, one good excuse may be that, with this parameter, legacy Office software (i.e., pre-2006) may apply clipping at the
OS/2 values rather than at the
win values. If you find yourself in the position of needing to support ancient software: Duh. Everyone else is entitled to consider this a problem of the past.
Another problem is that, in Microsoft Office software, values for
underlineThickness are ignored when Use Typo Metrics is on. Even if it is off, and if the underline does not fit above
winDescent, it will be raised accordingly. In other words,
underlineThickness must be smaller than
winDescent. If Use Typo Metrics is on, default underline values will be used instead. If you find the correct display of underlines in Microsoft Word more important than proper linespacing, disable Use Typo Metrics, and follow one of the legacy strategies. Most likely the Microsoft Strategy will be a good idea then.
Different type designers employ different strategies on how to find the best values for the vertical metrics. But beware: amongst font nerds, there are fierce disputes going on about what is the best strategy.
To give you one example, in his Vertical Metrics How-to post, John Hudson gives his own recommendations for optimising Vertical Metrics with special consideration for Microsoft Word. Reminder: The
fsSelection bit he is talking about is the technical term for Use Typo Metrics.
In any event, with the custom parameters listed above, you can override the automatic calculation and set the values manually. Let me show you the most popular strategies for manually setting your vertical metrics. First, two historical ways, the Adobe and Microsoft strategies. They are handy to know because you may have to make your font for a specific audience, i.e., either the Adobe-using DTP folks or the average Office users. Both crowds have come to expect certain behaviours from their (pre-installed) fonts. And if you cater to these audiences, it is probably best to simply make your font blend in. However, both of these strategies are kind of outdated because they both adhere to the UPM dogma. Therefore, especially if you cater to web usage, and/or if you need a good overall compromise for DTP and Office users, I recommend to employ the Webfont strategy described below.
The Adobe Strategy
hhea values are synchronized with the
- Font Info > Font > Custom Parameters:
Use Typo Metrics= yes
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), and usually tight default leading. 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.
- Font Info > Font > Custom Parameters:
Use Typo Metrics= yes
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
typoAscender. Disadvantage: differences between Mac apps and layout apps (XPress, InDesign), and default leading may appear to be too much.
The Webfont Strategy (2019)
Here, you set the
winDescent values first, because what is clipped and what not is most important on Windows machines.
On the Mac, Safari and Chrome use the
hhea values for positioning text, regardless of the
Use Typo Metrics setting. When text is placed inside an HTML element such as
<p>, these browsers will add
hheaAscender plus half of
hheaLineGap, and use this to calculate the position of the first baseline in respect to the top edge of the HTML element. Similarly, the distance from the very last line of text inside an HTML element to the bottom edge of the same element is determined by
hheaDescender plus half of
hheaLineGap. That’s right, the line gap is distributed evenly above and below the line.
Notable exception on the Mac: Firefox respects the
Use Typo Metrics setting, and will do the same with the OS/2 typo metrics if it is set, i.e., the first baseline will be put at
typoAscender plus half
typoLineGap, and the space below the last baseline is equal to
typoDescender plus half
typoLineGap. If, however,
Use Typo Metrics is not set, it will act like the other browsers on the Mac and employ the
On Windows, all browsers respect the
Use Typo Metrics parameter. If it is set, first baseline will be positioned at
typoAscender plus half
typoLineGap, and the distance between last baseline and bottom edge will be
typoDescender plus half
typoLineGap. If, however,
Use Typo Metrics is not set, then all Windows browsers will default to the
win values. In that case, the first baseline will be at
winAscent from the top edge, and the bottom edge will be padded
winDescent away from the last baseline.
As a consequence, if we do make use of the
Use Typo Metrics parameter as we are supposed to, the
win values are now completely independent of the
typo values. So we can use the
typo values for what they were intended for, including the line gap. Simply set the
win values to the vertical extremes in your font family, and make sure, like in the Adobe strategy, to sync
hhea values. So what we get is this:
winAscent= vertical maximum round this value up
winDescent= vertical minimum (positive value) round this value up
hheaAscender= include important uppercase diacritics (e.g. É, Å, Ñ, Ő, etc., or the letters reaching high above the baseline you care most about) round this value
hheaDescender= include descenders completely (the lowest point in j, g, p, q, y, or the letters reaching below the baseline you care most about) round this value down
hheaLineGap= sensible padding between lines: approx 10–20% of the sum of
typoDescender, consider more if descenders and ascenders touch each other across lines (in browsers and Office software), less if your ascender and descender values are pretty large
- Font Info > Font > Custom Parameters:
Use Typo Metrics= yes
About finding a proper linegap value (point 5): Simply imagine a word on a button or in a box on a web page. Half of the linegap amount will be padded above, and half below the (
hhea) ascender and descender positions.
And if, for whatever reason, you cannot or do not want to enable Use Typo Metrics, you can try:
typoAscender) × 2
The offset of the first baseline will be consistent even without the
Use Typo Metrics parameter. That may make sense if you want to support legacy software as described above. However, the leading may still differ unless the difference between
typoDescender happens to be exactly the same as the difference between
Careful: The Webfont Strategy 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. Consider adapting your UPM if you still see a lot of cropping.
Likewise, 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.
First Baseline Offset in Adobe Apps
You may do everything right, and still get complaints from users, particularly about the positioning of the first line of text in a text frame. In InDesign and Illustrator, the the first baseline offset depends on the settings in the respective document.
The weirdest thing though is that the default setting, ‘Ascent’, is the measurement of the Latin lowercase d. So, if you need to make sure that your font aligns well with others, and you do not want to spend a lot of your precious lifetime on explaining to Adobe users the two dialogs below, consider synchronising the heights of your lowercase d’s.
Especially if you are making a layered font, and the shapes must align, you may need to make use of the lowercase-d hack. See the Layered Color Font tutorial for details.
In InDesign, select a text frame, and choose Object > Text Frame Options… (Cmd-B), and in the dialog, pick the Baseline Options tab at the top, and where it says First Baseline, you have the following Offset options:
- Ascent: The height of the “d” character in the font falls below the top inset of the text frame.
- Cap Height: The top of uppercase letters touch the top inset of the text frame.
- Leading: Use the text’s leading value as the distance between the baseline of the first line of text and the top inset of the frame.
- x Height: The height of the “x” character in the font falls below the top inset of the frame.
- Fixed: Specify the distance between the baseline of the first line of text and the top inset of the frame.
- Min: Select a minimum value for the baseline offset. For example, if Leading is selected and you specify a minimum value of 1p, InDesign uses the leading value only when it’s greater than 1 pica.
In Adobe Illustrator, select a text frame and choose Type > Area Type Options…, and in the dialog that pops up, pick an option in Offset > First Baseline:
- Ascent: The height of the “d” character falls below the top of the type object.
- Cap Height: The tops of uppercase letters touch the top of the type object.
- Leading: Uses the text’s leading value as the distance between the baseline of the first line of text and the top of the type object.
- x Height: The height of the “x” character falls below the top of the type object.
- Em Box Height: The top of the em box in Asian fonts touches the top of the type object. This option is available regardless of the Show Asian Options preference.
- Fixed: Specifies the distance between the baseline of the first line of text and the top of the type object in the Min box.
- Legacy: Uses the first baseline default used in Adobe Illustrator 10 or earlier.
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:
Visualising Vertical 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.
In the mekkablue scripts, you will find Font Info > Vertical Metrics Manager and Test > Report Highest and Lowest Glyphs.
The Vertical Metrics Manager will try and apply the Webfont Strategy as much as possible. It can measure any set of glyphs and determine viable values to some extent. You can edit the values yourself, before you apply them to the font. Extensive documentation is available in the tooltips: if there is a thing you do not understand, just hover the mouse over it for a second or two. Once you run the script functions, the script will document its process in Window > Macro Window.
Report Highest and Lowest Glyphs simply spits out the most extreme glyphs in terms of vertical extension, and writes a small report in the Macro Window. This can be useful for finding good sTypo values.
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.
Update 2019-05-16: Added more general variant of Webfont Strategy, made Use Typo Metrics more prominent.
Update 2019-08-20: Corrected typos (thanks Nathalie).
Update 2019-09-12: Reworked Webfont Strategy (2019), updated spec info about the UPM dogma in Further Reading; updated screenshots; partial rewrite.
Update 2019-10-30: Added chapter about Adobe first baseline offsets.
Update 2020-02-18: Added Useful Scripts, and a paragraph about underlineThickness and underlinePosition (thanks Henrique Beier.).
Update 2020-03-02: Clarified the wording about how the Mac browsers use the hhea values (thanks Nathalie).
Update 2020-03-05: Changed defer to differ.