Vertical metrics
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 hhea, typo (a.k.a. sTypo or OS/2) and win (or 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.
Custom parameters
So, in order to avoid vertical jumps when you switch between different fonts of your family, it is a good idea to synchronize 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
The name 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 unitshheaDescender: 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 unitstypoDescender: 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 typoAscender and 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 typoAscender to typoDescender should be as large as the font’s UPM (usually 1000 or 2048). This used to make things really complicated.
A few years ago, the ‘UPM dogma’ has gotten under fire, because it simply did not work for scripts that require different metrics than Latin. 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.
In the meantime, the dogma was dropped altogether from the OpenType 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 (legacy) Adobe and Microsoft strategies discussed below.
OS/2 usWin (win)
The win (or usWin) values are also part of the OS/2 table.
winAscent: the top extremum of the font rendering boxwinDescent: 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, nothing you do in your font will exceed the win span.
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. 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.
Technically, what it does is set 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 underlinePosition and 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, underlinePosition plus 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 (see below) will be a good idea then.
Strategies
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 methods, the Adobe and Microsoft strategies. They are handy to know because you may have to make your font compatible with legacy software. But keep in mind that both of these strategies are outdated because they both adhere to the UPM dogma. Therefore, if you need a good overall compromise for DTP, Office and web use, I recommend to employ the Webfont strategy described below.
Legacy: the Adobe strategy
The hhea values are synchronized with the OS/2 values.
hheaAscender=typoAscenderhheaDescender=typoDescenderhheaLineGap=winAscent+winDescent–UPMtypoLineGap=hheaLineGap- 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.
Legacy: the Microsoft strategy
The hhea values are synchronized with win values, thus to the BBox maxima.
hheaAscender=winAscenthheaDescender= −winDescent(negative value)hheaLineGap= 0typoLineGap=winAscent+winDescent–UPM- Font Info > Font > Custom Parameters: Use Typo Metrics = yes
For the rest, as already mentioned above, the span from typoAscender to 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 hhea and 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 typoLineGap.
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 winAscent and winDescent values first, because what is clipped and what not is most important on Windows machines.
On the Mac, the Safari and Chrome browsers use the hhea values for positioning text, regardless of the Use Typo Metrics setting. When text is placed inside an HTML element such as <div> or <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 hhea values.
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 hhea and typo values. So we can use the hhea and 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 typo and hhea values. So what we get is this:
winAscent= vertical maximum round this value upwinDescent= vertical minimum (positive value) round this value uptypoAscender=hheaAscender= include important uppercase diacritics (e.g. É, Å, Ñ, Ő, etc., or the letters reaching high above the baseline you care most about) round this valuetypoDescender=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 downtypoLineGap=hheaLineGap= sensible padding between lines: approx 10–20% of the sum oftypoAscenderandtypoDescender, 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 (OS/2 and hhea) ascender and descender positions.
And if, for whatever reason, you cannot or do not want to enable Use Typo Metrics, you can try:
typoLineGap=hheaLineGap= (winAscent−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 winDescent and typoDescender happens to be exactly the same as the difference between winAscent and typoAscender.
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 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.
InDesign:
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.
Find more info about InDesign text frames on the Adobe help page.
Illustrator:
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.
Find more info about Illustrator text frames on the Adobe help page.
TT Zones
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 winAscent and 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 winAscent and winDescent. These additional zones cause the renderer to include everything up to their position.
If you are manually TrueType hinting, you can add the winAscent and 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 > Exports > Custom Parameters enable the Windows Compatibility option in the TTFAutohint options parameter. Repeat that for every TTF instance, and you are done:
Useful plug-ins and scripts
The plug-in View > Show Vertical Metrics can visualize your custom parameters in Edit view. 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 win 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.
Update 2021-09-12: cleanup and updates for Glyphs 3.
Update 2024-02-20: added note about typo metrics on Apple devices.
