How to kerning storage formats: kern vs gpos vs class-based
- Step 1Legacy kern table — Simple pair-based encoding: list of (left glyph index, right glyph index, kerning value) triplets. Easy to parse; large for fonts with many pairs (all explicit). Browsers still read it.
- Step 2GPOS pair-pos lookups — Modern equivalent of kern. Same per-pair encoding but inside GPOS for richer feature integration. Browsers read it via the kern feature in GPOS.
- Step 3GPOS class-based lookups — Most efficient: groups glyphs into classes (e.g., 'all caps with vertical strokes'), kerning defined between class pairs. 1000 individual pairs collapse to 30 class pairs. Hard to enumerate — needs class-resolution logic.
Frequently asked questions
Why does opentype.js miss class-based kerning?+
Resolving GPOS class-based lookups requires walking the class definitions and expanding them to individual glyph pairs. opentype.js's audit logic uses the simpler pair-based extraction. For class-based fonts, use desktop fonttools or accept that the visible audit is incomplete.
Which storage do most fonts use?+
2010+: GPOS exclusively. Pre-2010: kern table dominant. Some fonts ship both for compatibility. The auditor surfaces pairs from both tables.
Do browsers prefer one over the other?+
Browsers read GPOS first (richer features), fall back to kern. If both are present, GPOS wins. The kern feature flag in CSS controls both — disabling kern via font-feature-settings: 'kern' 0 disables both tables.
Privacy first
Every JAD Font tool runs entirely in your browser using opentype.js and the wawoff2 WASM Brotli encoder. Your fonts never leave your device — verified by zero outbound network requests during processing.