Font Pairing Dataset

Font pairing tool — working prototype

Flow: pick serif or sans serif for the headline, browse a gallery of headline fonts in that category, then land on the best-scoring body-font pairing. From there you can edit the sample copy, adjust size and weight (limited to the weights each font actually ships), cycle down the ranked candidate list with "Next," and see a side-by-side comparison of structure, contrast, x-height, aperture, and stress axis.

Loading font library…

Carved by hand, read from the trail

Routed wooden signs have guided park visitors for generations, and their lettering is a design lesson in itself

Every letter on a routed trail sign has to survive a router bit, a paintbrush, and decades of weather.

Click any line above to edit it

Header 36px

Subhead 24px

Body 16px

Every weight each font ships. Click a style to use it in the preview above.

StructureHumanist

Geometric

Stroke contrastLow

High

X-height ratio0.45

0.75

Aperture

Moderate vs Open

Stress axis

Oblique vs None

Developer notes

This now loads live from sample-fonts.json and scores every candidate pairing with the real pairing-engine.js — the fonts, weights, and structural attributes below reflect whatever is actually in the dataset, not a hardcoded example set. The list below tracks what's done and what's still stubbed.

Done: sample copy is now original (no NASA text), with 8 sets of varied length, each with multi-paragraph body text (shown in 2 columns by default, with a 1/2 column toggle) — short/long/very long headlines, a numbers-heavy set for checking figures, a long body. "Shuffle copy" cycles through them; each is labeled so you know what it's testing.
Done: the "Aa Bb" specimen cards are replaced by a Compare panel with three views: Styles (a type tester showing every weight of both fonts, click to apply), Letters (telling characters side by side), and Proportions (both fonts on one baseline with x-height and cap-height guides measured live from the font files).
Done: fonts now load live from sample-fonts.json instead of being hardcoded — the gallery, weight chips, and comparison panel all reflect whatever's actually in that file.
Done: pairing suggestions now come from pairing-engine.js's suggestPairings() — every eligible body font is scored (cross-category vs. the chosen headline), and "Next" walks down that ranked list instead of a fixed 2-item shortlist. The match score is shown next to the pairing label.
Estimated, not measured: the "Structure" dot (humanist↔geometric) uses the schema's optional structure field when a font has it, but none of the current entries set that field — so it falls back to a rough per-classification estimate (e.g. geometric classification → high structure score). Worth tagging structure properly per font rather than relying on the fallback long-term.
Still stubbed: no handling yet for superfamily pairs — the schema doesn't have an isSuperfamily/superfamilyName field yet, so faces designed together (e.g. a serif/sans superfamily) aren't surfaced as "guaranteed" pairs separate from the algorithmic matches.
Still stubbed: weight chips are always discrete, even though the schema has an isVariable field — none of the current entries set it, so there's no continuous-slider path for variable fonts yet.
Still stubbed: no handling for long/short custom text overflowing the layout differently per font (condensed vs. wide, high x-height vs. low).
Still stubbed: the category step only splits by serif vs. sans (mapped from the schema's finer category values — slab-serif/monospace-serif bucket as "serif", monospace-sans buckets as "sans"). script-category fonts don't fit either bucket and are currently excluded from the gallery entirely — none exist in the library yet, but worth a third bucket once one is added.
Still stubbed: only source: "googleFonts" entries get their font files loaded automatically (via a dynamically built Google Fonts link). adobeFonts entries are labeled "Adobe Fonts" and render with the copy on the student's computer if they've activated it in Creative Cloud; system entries (e.g. Georgia) use the built-in version. Loading Adobe fonts directly would need an Adobe Fonts web project (kit ID) with the class fonts added.