Font Metrics: Understanding Vertical Measurements

OS/2 Table Metrics

The UPM value—whether 1000 or 2048—is a historical artifact with practical consequences. CFF fonts inherited 1000 from the PostScript Type 1 specification, where fonts were designed on a 1000-unit grid that could be scaled arbitrarily. TrueType fonts adopted 2048 because higher coordinate resolution gives more granularity for hinting instructions: TrueType's bytecode hinting operates in integer font units, so a 2048-UPM font allows finer positioning of hint control values than a 1000-UPM equivalent. Changing UPM requires scaling every metric value, every glyph coordinate, and every table reference proportionally—it is not a simple header field change. Conversions that silently change UPM can introduce systematic rounding errors across the entire glyph set.

Diagnosing cross-platform line height inconsistencies is one of the most common font metrics challenges for web developers. The reliable test is to apply line-height: 1 on an element and compare its computed height in pixels across Chrome on Windows and Chrome on macOS. A font without USE_TYPO_METRICS set will produce different computed heights because Windows and macOS query different metric sources when calculating line boxes. After setting USE_TYPO_METRICS and verifying that OS/2 sTypo values and hhea values agree, the computed height should be identical across platforms. The fonttools CLI command fonttools inspect -t OS/2 font.ttf shows all relevant fields, and the --layout-features flag on pyftsubset preserves these values during subsetting.

hhea Table Metrics

The hhea (horizontal header) table contains Mac-style vertical metrics:

The hhea table's ascender and descender fields were originally designed for macOS's QuickDraw rendering system and carried different design philosophy than the OS/2 sTypo fields. Early font designers often set hhea values to the actual maximum glyph extent—the tallest ascender and deepest descender found anywhere in the character set—rather than the typographic design values that define the intended rhythm. This made hhea-based line height significantly larger than the designer's intent, because occasional extreme glyphs (accented capitals reaching unusually high, below-baseline swash letters) inflated the spacing for every line of text. Modern practice aligns hhea ascender and descender with sTypo equivalents and uses USE_TYPO_METRICS to ensure Windows also applies the intended values.

Excessive line height caused by inflated hhea values is often misdiagnosed as a CSS problem when it is actually a font metrics problem. A font with hhea.ascender of 1200 and hhea.descender of −400 in a 1000-UPM font produces a line box of (1200 + 400) ÷ 1000 = 1.6 line heights at any font size—significantly more spacing than the 1.2 that most UI design assumes. Setting line-height: 1 in CSS does not fix this because hhea metrics determine the natural line box size that is then scaled by the CSS line-height multiplier. Correcting the hhea values in the font itself is the only way to restore normal spacing behavior across all rendering contexts.

CSS Metric Overrides

CSS provides descriptors to override font metrics, primarily useful for matching fallback fonts to custom fonts to prevent layout shift:

@font-face {
  font-family: 'CustomFont-Fallback';
  src: local('Arial');
  /* Match Arial metrics to your custom font */
  ascent-override: 92%;
  descent-override: 24%;
  line-gap-override: 0%;
  size-adjust: 105%;
}

body {
  font-family: 'CustomFont', 'CustomFont-Fallback', sans-serif;
}

To calculate the correct percentage values for ascent-override and descent-override, divide the font's metric values by the UPM, then multiply by 100. For a font with UPM 2048, sTypoAscender 1900, and sTypoDescender −480: ascent-override: 92.77% (1900÷2048×100) and descent-override: 23.44% (480÷2048×100). The size-adjust property compensates for overall glyph size differences between the custom font and the fallback.

Related Technical Guides