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…

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.
Done: sibling families (e.g. Alegreya + Alegreya Sans) come first. A pair counts if either entry lists the other in its siblings field (set in Add a typeface). Only serif + sans siblings are suggested; small-caps (SC), mono, stencil and same-style siblings are skipped. Small-caps and similar single-purpose cuts are also left out of the regular body-text matches. The sibling is labeled "Designed together" and still shows its match score, and the scored matches follow it.
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.

Font pairing tool — working prototype

What kind of headline font are you looking for?

How the two fonts are built