Letras Diferentes
Unicode research · font metrics and line layout

Font Metrics and Line Height: Baselines, Ascenders, Descenders and CSS Layout

Examine OpenType ascent, descent, line gap, CSS line-height and baseline alignment with practical techniques for diagnosing clipping and layout shift.

Technical referenceStandards-aware implementation guide

The height of a rendered line is not the bounding-box height of its tallest visible letter. Line layout combines font-level metrics, the CSS line-height model, inline formatting rules and possibly metrics from fallback fonts. Understanding which quantity is measured is crucial when fixing clipping, alignment or cumulative layout shift.

Identify the independent metric families

OpenType fonts can contain horizontal-header metrics in hhea and Windows/typographic fields in OS/2. Typical vertical quantities include an ascender above the baseline, a descender below it and some line-gap value. The coordinates and sign conventions differ across formats and consumers.

Some fields are intended for clipping or historical compatibility rather than directly prescribing web line height. Never assume the height of uppercase H or the exact painted ink bounds equals the font's ascent. A font-level metric describes a design-wide coordinate framework, not the outline of one chosen character.

Understand CSS line-height and leading

CSS line-height controls layout contributions of inline content and can exceed or undercut visible glyph ink. A unitless value multiplies the computed font size, while an explicit length is fixed according to its computed-value rules. Extra space can be distributed around the inline box as leading.

The normal keyword delegates important choices to font and user-agent behavior. Consequently two fonts at the same font-size can create different line boxes even when their painted capitals appear similar. Tight line-height settings may clip accents or produce crowding when fallback scripts appear.

Distinguish baseline alignment from visual centering

Inline boxes align through baselines and vertical-alignment rules, not simply centered rectangles. Latin text generally uses the alphabetic baseline, while vertical writing and other scripts can involve different baseline conventions. Superscripts, subscripts and replaced inline elements complicate the line box.

An icon and text that share vertical-align: middle may not align optically. Compensating with arbitrary negative margins can hide the symptom at one font size and fail after fallback, zoom or language changes. First decide whether the desired alignment is a layout baseline, ink alignment or a design-specific optical adjustment.

Fallback can enlarge or destabilize a line box

A system font providing a missing CJK character, emoji or mathematical symbol may have ascent/descent metrics different from the primary Latin face. Whether and how those metrics contribute to line boxes depends on the engine and CSS inline model. One fallback glyph can visibly shift a line's spacing.

Do not assume a user typing a new symbol is changing the DOM's CSS rules. They may be changing the selected font run, and the metrics of that run can affect baseline placement or clipping. Log the actual selected font and test each representative script with the same line-height declaration.

Font metric overrides can stabilize swaps

CSS Fonts supports descriptors such as size-adjust, ascent-override, descent-override and line-gap-override for defined font faces. These can assist with matching fallback and webfont geometry to reduce shifts. However, overrides affect layout measurements, not the actual outlines or Unicode support.

Aggressive overrides can still clip tall combining accents or produce collisions. Calibrate using measured font data and a diverse corpus, then check both pre-load and post-load states. These CSS descriptors cannot substitute for actual glyph coverage or correct shaping.

Canvas text metrics are not complete paragraph geometry

Canvas TextMetrics provides values such as width and supported bounding-box metrics, but measurements of an isolated string do not account for all HTML line wrapping, mixed inline descendants, CSS letter-spacing or browser layout contexts. Interpretation varies by API and environment.

If the application needs caret placement or selection geometry, use the layout engine's available range/hit-testing interfaces rather than reverse-engineering positions from one width measurement. Record which string, font, language and rendering state were measured; those values are not properties of Unicode code points alone.

Decorative symbols and combining marks stress vertical extents

A line with é, Vietnamese stacked accents or combining marks outside ordinary Latin use can exceed the ink rectangle suggested by ASCII samples. Emoji may have color bitmap dimensions or design metrics unlike text symbols. Test these fixtures at multiple font sizes and zoom levels.

A padding-based workaround might be justified for a design but should not alter the stored string. Problems that reproduce only for certain sequences may signal font mark positioning or fallback issues, not merely an insufficient global line-height.

Construct a repeatable baseline and clipping test

Choose an explicit font file, font size, line-height, container width and representative corpus. Inspect computed styles, font-loading state, line boxes and element bounding rectangles. Compare loaded-webfont and fallback conditions before blaming CSS.

Test Latin ascenders/descenders, combining marks, emoji, CJK and RTL text; also verify accessibility zoom and user font substitutions. Record actual observed clipping separately from line-height numeric value. A large numeric line-height is not itself proof that every painted glyph fits.

Reproducible experiment with fully specified input

Preserve the exact Unicode sequence before running the example. For browser comparisons, record the destination application, browser build, font files if relevant, system locale and any optional editor transformations. The example tests representation-level facts; it does not on its own demonstrate that every browser or native application must produce the same visual output.

/* An explicit, testable line-height is a layout decision. */
.sample { font: 400 16px/1.5 'Example Face', system-ui, sans-serif; }
@font-face {
  font-family: 'Example Face';
  src: url('/assets/example.woff2') format('woff2');
  size-adjust: 100%;
  ascent-override: 90%;
  descent-override: 24%;
  line-gap-override: 0%;
}
/* Values above are illustrative, not suitable for an unknown font. */

A reliable technical report separates the original input, the representation delivered to an API and the outcome visible to the user. When a copy/paste or rendering test fails, retain the raw specimen and compare successive representations so that display-only differences do not get mislabeled as encoding changes.

Evidence matrix for font metrics and line layout

FeatureControlled specimenInterpretation
font-size16pxCSS size does not equal uppercase ink height
line-height1.5controls line layout, not Unicode scalars
OS/2 typographic metricssTypoAscender / sTypoDescenderdistinct from a glyph ink rectangle
fallbackemoji/CJK glyphsmay alter measured extents and baseline
metric overridesascent/descent/line-gapmust be calibrated, not guessed

The entries above serve distinct roles: some characterize Unicode text data, while others specify font selection, layout, security policy or clipboard representation. Do not convert an environment-specific observation into a claim that Unicode mandates identical visuals or editing behavior across every platform.

Validation protocol for real-world applications

  1. font-size: Establish a controlled specimen for 16px, record the input at the scalar level, then compare its output in the intended editor or rendering environment. CSS size does not equal uppercase ink height. Document the location and circumstances of any transformation instead of treating a screenshot as sufficient evidence.
  2. line-height: Establish a controlled specimen for 1.5, record the input at the scalar level, then compare its output in the intended editor or rendering environment. controls line layout, not Unicode scalars. Document the location and circumstances of any transformation instead of treating a screenshot as sufficient evidence.
  3. OS/2 typographic metrics: Establish a controlled specimen for sTypoAscender / sTypoDescender, record the input at the scalar level, then compare its output in the intended editor or rendering environment. distinct from a glyph ink rectangle. Document the location and circumstances of any transformation instead of treating a screenshot as sufficient evidence.
  4. fallback: Establish a controlled specimen for emoji/CJK glyphs, record the input at the scalar level, then compare its output in the intended editor or rendering environment. may alter measured extents and baseline. Document the location and circumstances of any transformation instead of treating a screenshot as sufficient evidence.
  5. metric overrides: Establish a controlled specimen for ascent/descent/line-gap, record the input at the scalar level, then compare its output in the intended editor or rendering environment. must be calibrated, not guessed. Document the location and circumstances of any transformation instead of treating a screenshot as sufficient evidence.

Include adversarial and multilingual input, not only a short English word. Save code-point lists, serialized bytes when available, input method context, observed UI behavior and environment metadata. Repeat after browser, editor, operating-system or font updates; changes in renderer behavior do not imply that source strings were modified.

Frequent failure patterns and how to interpret them

  • Confusing evidence about font-size: A visual or API observation involving 16px is not a comprehensive test of Unicode integrity. CSS size does not equal uppercase ink height. Preserve the input, label the expected behavior and compare two independent stages before deciding whether a regression occurred.
  • Confusing evidence about line-height: A visual or API observation involving 1.5 is not a comprehensive test of Unicode integrity. controls line layout, not Unicode scalars. Preserve the input, label the expected behavior and compare two independent stages before deciding whether a regression occurred.
  • Confusing evidence about os/2 typographic metrics: A visual or API observation involving sTypoAscender / sTypoDescender is not a comprehensive test of Unicode integrity. distinct from a glyph ink rectangle. Preserve the input, label the expected behavior and compare two independent stages before deciding whether a regression occurred.
  • Confusing evidence about fallback: A visual or API observation involving emoji/CJK glyphs is not a comprehensive test of Unicode integrity. may alter measured extents and baseline. Preserve the input, label the expected behavior and compare two independent stages before deciding whether a regression occurred.
  • Confusing evidence about metric overrides: A visual or API observation involving ascent/descent/line-gap is not a comprehensive test of Unicode integrity. must be calibrated, not guessed. Preserve the input, label the expected behavior and compare two independent stages before deciding whether a regression occurred.

In corrective workflows, preserve the user's original text until the responsible transformation has been identified. Avoid blanket removal of combining marks, variation selectors, joiners or directional controls: each can carry useful meaning in its intended context. If a product offers cleanup, make the behavior explicit and reversible.

Primary standards and implementation documentation

The references distinguish Unicode character properties and algorithms from browser APIs, CSS layout and particular implementation strategies. Normative conformance is narrower than identical visual output; document assumptions whenever a standard permits implementation-dependent behavior.

  • W3C CSS Inline Layout Level 3 — normative definitions or authoritative technical documentation relevant to font metrics and line layout. Check the precise implementation conditions and distinguish platform behavior from the standard's guarantee.
  • W3C CSS Fonts Level 4 — normative definitions or authoritative technical documentation relevant to font metrics and line layout. Check the precise implementation conditions and distinguish platform behavior from the standard's guarantee.
  • OpenType OS/2 Metrics — normative definitions or authoritative technical documentation relevant to font metrics and line layout. Check the precise implementation conditions and distinguish platform behavior from the standard's guarantee.
  • MDN line-height — normative definitions or authoritative technical documentation relevant to font metrics and line layout. Check the precise implementation conditions and distinguish platform behavior from the standard's guarantee.

The Fonts, Shaping & Text Rendering virtual silo groups practical investigations without adding category pages. The following already-published references cover adjacent layers needed to interpret this problem.

In a reproducible bug report, always preserve the exact text fixture and record the implementation version. The difference between an actual data transformation and a change of presentation determines both the correct fix and the risk of introducing further loss.