Typography Font Mapping

ALPA Mobile · UI Refresh Epic AB#1821 · Updated: 2026-07-30 17:52 ET · Audited: 2026-07-30 11:57 ET

1 · The provided font files

Read from the binaries themselves, not from filenames — the filename is not authoritative and had previously been recorded incorrectly.

Registered via @font-face in alpa-components.css (two rules, one per weight). The native side registers the .ttf equivalents in MauiProgram.cs as FuturaPTBook / FuturaPTBold.

2 · Census — what the design declares

The design system defines 8 type styles across 4 families. Family is itself tokenised for three roles; Body and Button carry their family as a literal inside the type style rather than as a token.

Line heights are ratios and letter spacing is a percentage. Both reproduce the values observed in Figma Dev Mode exactly: 20 × 1.2 = 24, 18 × 1.2 = 21.6, 12 × 1.4 = 16.8; 5 % of 12px = 0.6px.

2.1 · Node provenance

Each type style below was read from the variable definitions attached to these component nodes in owEYzHf7FrHRvWC2u82UOl.

Queried and returned no typography variables (size tokens only, or colour/spacing only): 4128:7717 button-sm · 4128:7690 profile info block · 4555:7483 flight segment card · 4596:11818 section title · 4038:1037 navBar-bottom · 5251:15088 button link.

3 · The mapping decision

All values belong in alpa-components.css and must route through the family tokens (--font-heading-family, --font-body-family, --alpa-eyebrow). No inline style= attributes and no literal family stacks in component rules.

3.1 · Why the mapping is visually safe

Measured on device by rendering identical text at each weight in Futura PT and comparing rendered widths:

The browser already applies exactly this mapping through CSS font matching. Writing it into the stylesheet makes explicit what already happens at render time — it does not change how anything looks.

3.2 · Hierarchy check

Verified against the My MEC card, whose three roles exercise three different families.

Serif/sans contrast is lost. The title-versus-body hierarchy survives, re-expressed as Bold-versus-Book. Title and eyebrow both land on Bold 700 but stay clearly separated by size, casing and colour.

4 · Where the code departs findings

4.1 · Non-provided families in use

4.2 · Off-palette weight declarations — 109

Declarations asking for a weight with no corresponding file. Each already resolves to Book 400 or Bold 700 by the rule in §3.

The /dev/font-specimen demo ladder is excluded from these counts — it declares 300/500/600/800 deliberately, to demonstrate the gap.

4.3 · Cost of closing each gap

5 · Documentation staleness action needed

25 docs carry family claims inherited from that capture — Lora ×51, Inter ×47, Futura LT Pro ×23, SF Pro ×2, Hind ×3 (counts exclude each document's own <style> block, so these are content assertions, not page styling). Highest-authority affected: design-tokens.html, design-questions.html, home-page-audit.html, the card-* and button-* specs, list-component.html, naming-decisions-record.html.

5.1 · Families to retire from the docs

The census found no Futura LT Pro and no SF Pro anywhere in the working file's typography. Both should be treated as obsolete in the documentation.

This retires an earlier concern: the docs' apparent "two Futura cuts in one design" is a stale-capture artifact, not a real design inconsistency. All three components the old capture attributed to Futura LT Pro — search bar, mobile nav, mobile hero — no longer resolve at their captured node ids.

5.2 · A family the docs have never recorded

League Spartan is absent from every document in /docs, yet it is the current, live font for every button in the design system (Other/Button, five components in §2.1). The documentation gap is real even though the mapping outcome is unchanged.

5.3 · Dead captured node ids — 7 of 39

5.4 · Typography scale in design-tokens.html

design-tokens.html predated this census and its typography scale did not correspond to the current type-style set. The differences found are below.

The last row is marked unconfirmed rather than differing: a larger display style (Display/L or above) may exist that this census did not surface, in which case 28px may map to it correctly.

6 · Method and coverage limits

Typography was read from Figma variable definitions (get_variable_defs), which are reachable remotely and return the design system's type styles directly. That makes this census authoritative for the type-style set.

• It would not capture a one-off override applied directly to a text layer outside the defined type styles.
• Node 21223:222 is unreachable — the My MEC card the mapping was validated against. Its id postdates the snapshot the connector serves, so its values were supplied from Figma Dev Mode output rather than read directly. They agree with the census exactly.
• get_design_context requires the page open in the Figma desktop app; it returns "invalid node selection" for nodes not visible on canvas, so it could not be used for a bulk sweep.
• Code Connect is unavailable — list_file_components_for_code_connect requires a Dev or Full seat on an Organization/Enterprise plan.
• Page enumeration is limited — the connector lists only 0:1 💅 Thumbnail, so components were reached by node id rather than by walking pages.

7 · Scope

In scope for this document — the mapping (§3), the census (§2), and the record of code and documentation departures (§4, §5).

Not in scope — applying the mapping. No CSS has been changed. Weight normalisation, Inter/Georgia removal, the design-tokens.html scale reconciliation, and correcting the 25 affected docs are follow-on work.