Vertical Metrics

by Rainer Erich Scheichelbauer
en fr zh

18 February 2020 Published on 10 July 2012

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.

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.


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:

  1. hheaAscender: the height of the ascenders in units
  2. hheaDescender: the depth of the descenders in units (negative value)
  3. 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.

  1. typoAscender: the height of the ascenders in units
  2. typoDescender: the depth of the descenders in units (negative value)
  3. 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 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)

The win (or usWin) values are also part of the OS/2 table.

  1. winAscent: the top extremum of the font rendering box
  2. 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 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 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

The hhea values are synchronized with the OS/2 values.

  1. hheaAscender = typoAscender
  2. hheaDescender = typoDescender
  3. hheaLineGap = winAscent + winDescentUPM
  4. typoLineGap = hheaLineGap
  5. 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

The hhea values are synchronized with win values, thus to the BBox maxima.

  1. hheaAscender = winAscent
  2. hheaDescender = −winDescent
  3. hheaLineGap = 0
  4. typoLineGap = winAscent + winDescentUPM
  5. 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, 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 <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:

  1. winAscent = vertical maximum round this value up
  2. winDescent = vertical minimum (positive value) round this value up
  3. typoAscender = hheaAscender = include important uppercase diacritics (e.g. É, Å, Ñ, Ő, etc., or the letters reaching high above the baseline you care most about) round this value
  4. typoDescender = 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
  5. typoLineGap = hheaLineGap = sensible padding between lines: approx 10–20% of the sum of typoAscender and 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
  6. 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 = (winAscenttypoAscender) × 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.

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.

Find more info about InDesign text frames on the Adobe help page.


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 > 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.

Useful Scripts

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.