Kerning Tables: KERN vs GPOS

The KERN Table (Legacy Format)

The KERN table is the original TrueType kerning format, predating OpenType. It stores explicit pair-by-pair adjustments: glyph A + glyph B = adjustment value.

KERN Table Format 0 (Most Common)
├── Version: 0x0000
├── Number of subtables: 1+
└── Subtable
    ├── Version: 0x0000
    ├── Length: size in bytes
    ├── Coverage: format + flags
    └── Pairs Array
        ├── [0] Left: 'A' (glyph ID 36)
        │       Right: 'V' (glyph ID 57)
        │       Value: -80 (units)
        ├── [1] Left: 'T' (glyph ID 55)
        │       Right: 'o' (glyph ID 82)
        │       Value: -60 (units)
        └── [n] ...more pairs

The KERN table's internal organization uses a sorted array of glyph ID pairs for efficient lookup. When a text renderer encounters two consecutive glyphs, it computes a 32-bit key by placing the left glyph ID in the high 16 bits and the right glyph ID in the low 16 bits, then performs a binary search through the sorted pairs array. This O(log n) lookup makes even large KERN tables with thousands of pairs fast to query at render time. The sort order is critical—a corrupted pair array where records are not strictly sorted by the combined key will produce incorrect kerning for some pairs and miss others entirely, since binary search produces undefined behavior on unsorted data. Font validation tools check this sort order as part of KERN table verification.

The scalability problem with KERN becomes acute for multilingual fonts. A Latin typeface might kern 500 specific pairs for its base character set. Adding thorough Western European accented character coverage expands the glyph set to 400+ characters, and each base glyph's kerning relationships must be duplicated for every accented variant. The letter "A" and its 18+ accented forms (À Á Â Ã Ä Å Ā Ă Ą and others) share essentially the same left-side shape. Against similarly grouped right-side characters like [V W Y T], KERN requires up to 18 × 4 = 72 explicit pair records for A-variants against these four right-side characters alone. GPOS class kerning replaces all 72 with a single class definition requiring just one stored value per class pair.

The GPOS Table (Modern OpenType)

GPOS (Glyph Positioning) is the modern OpenType approach to kerning and positioning. It supports pair kerning like KERN but adds powerful features including class-based kerning, mark positioning, and contextual adjustments.

GPOS Class Kerning Structure

Class Definition 1 (Left side):
├── Class 1: [A À Á Â Ã Ä Å]  → Similar left edges
├── Class 2: [T Ţ Ť Ŧ]        → T-shaped left
└── Class 3: [V W]            → V-shaped glyphs

Class Definition 2 (Right side):
├── Class 1: [V W Ý]          → V-shaped right
├── Class 2: [o ò ó ô õ ö]    → Round lowercase
└── Class 3: [a à á â ã ä]    → a-shaped right

Kerning Values (Class1 × Class2):
├── Class 1 + Class 1 = -80   (A-V, À-W, Á-Ý, etc.)
├── Class 1 + Class 2 = -40   (A-o, À-ò, etc.)
└── Class 2 + Class 2 = -60   (T-o, Ť-ò, etc.)

Result: 7 + 6 + 6 glyphs × 3 combinations
        = 3 values instead of 7×3 + 4×6 + 2×6 = 57 pairs

KERN vs GPOS Comparison

Kerning in Format Conversion

Both KERN and GPOS tables are preserved when converting between TTF, OTF, WOFF, and WOFF2. These tables are copied without modification—the conversion doesn't affect kerning data itself.

/* Modern approach (recommended) */
.kerned-text {
  font-kerning: normal;  /* Enable kerning */
}

/* Legacy approach */
.kerned-text {
  font-feature-settings: 'kern' 1;
}

/* Disable kerning if needed */
.no-kern {
  font-kerning: none;
  /* or: font-feature-settings: 'kern' 0; */
}

When kerning is applied, the browser's layout engine adjusts glyph advance widths during the text shaping phase. On modern platforms, HarfBuzz handles OpenType shaping—applying GSUB substitutions first, then GPOS positioning adjustments in lookup order. A GPOS pair adjustment of −80 units in a 1000-UPM font rendered at 16px produces a spacing reduction of −80 ÷ 1000 × 16 = −1.28 pixels. This fractional pixel offset is applied through subpixel positioning on modern displays. At body text sizes the tightening is subtle; at display sizes of 48px and above, the absence of kerning becomes clearly visible in headline text, particularly for classically problematic pairs like AV, To, Wa, and Ty where the letter shapes create natural-looking gaps without correction.

A subtle interaction occurs when a font contains both KERN and GPOS kerning tables. Most modern text engines apply GPOS first for its richer class-based support, and may additionally apply KERN as a fallback for software that doesn't support GPOS. In HarfBuzz, KERN table kerning is only applied when no GPOS kern feature is present, preventing double-application. However, some legacy applications that exclusively read the KERN table will apply only those values, potentially applying different (often less complete) kerning than the GPOS version. Foundries maintaining both tables should verify that the KERN values represent a correct subset of the GPOS kerning to avoid inconsistency across rendering environments.

Related Technical Guides