typeface-pairinglisted

# Typeface pairing Most pairing problems are solved by not pairing. The second face must earn its payload, its licence, and its maintenance. ## 1. When to invoke - Choosing a heading face to sit with a body face. - Adding a face to an existing system. - A pairing "clashes", or the two faces are indistinguishable. - Deciding whether one family with more weights would do the job. ## 2. Required context - The **roles** each face will play, and where they meet on the page. - The **existing face** and its full range (weights, widths, optical sizes, italic). - Whether a **superfamily** or **variable axes** could cover both roles. - Combined **payload budget**. - Script coverage for **both** faces — a pairing breaks when only one supports a required language. ## 3. Invariant principles - **Two faces need a reason.** One family with a real weight and width range covers most hierarchy needs. State the reason before choosing. - **Contrast or unity — never in between.** Faces that are clearly different read as intentional. Faces that are subtly different read as a mistake. The failure mode is similarity, not clash. - **Something must be shared.** Successful pairs share a skeleton, a proportion, an x-height, an era, or a mood. Nothing shared reads as accidental. - **Pairs are judged where they meet** — a heading directly above its body text, not on separate specimen slides. - **The body face is the constraint.** It's doing the reading work; the display face adapts to