How to standardise opentype feature usage in your design system
- Step 1Audit your fonts' feature support — Run the Features Inspector against every brand font. Capture which features exist where. Some fonts have extensive ss01–ss20; others have just kern + liga.
- Step 2Define the standard set — Body: kern + liga + calt. Tables: kern + liga + calt + tnum + lnum (tabular lining numbers). Display headings: kern + liga + calt + (optional dlig + ss01 if defined). Code: kern only (often disable liga for character accuracy).
- Step 3Pin in design system tokens — Emit font-feature-settings tokens per typography role: --feature-body, --feature-table, --feature-display, --feature-code. Components reference the role-appropriate token.
Frequently asked questions
Why tnum for tables?+
Default fonts use proportional numerals (different widths per digit). Tabular numerals (tnum) force monospaced widths so columns of numbers align. Critical for financial dashboards, data tables, transit timetables.
What about lnum vs onum?+
lnum = lining numerals (1234567890, all uppercase-height). onum = old-style numerals (oldstyle figures with descenders on 3 4 5 7 9). Body text often uses onum for refined typography; tables always use lnum.
Should I expose features to designers?+
Yes — designers should pick features per surface deliberately. Avoid hard-coding features in CSS without documentation. Tokens with descriptive names ('typography.body.features') prevent the cargo-cult where every component just enables 'kern liga calt'.
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.