Dimension units: support physical units (pt, mm, cm, in) for print/PDF design systems

[deadczarvc]

Dimension units: support physical units (pt, mm, cm, in) for print/PDF design systems

Problem

The dimension grammar accepts only px, em, rem (spec §"Dimension"). For
print-oriented design systems — academic papers, book layouts, PDF artifacts
rendered through page.pdf() / WeasyPrint / LaTeX-adjacent pipelines — the
native units are pt and mm. CSS itself accepts them everywhere that
matters for print (@page margins are conventionally mm; body type is
specified in pt), so a DESIGN.md that targets print cannot express its
normative values without lossy conversion.

Reproduction (verified, @google/design.md 0.4.0, Windows, npx)

DESIGN.md front matter for an A4 academic print document:

typography:
  body-md:
    fontFamily: PT Serif
    fontSize: 10pt
    lineHeight: 1.45
spacing:
  page-margin: 20mm

$ npx -y -p @google/design.md designmd lint DESIGN.md
errors:
  typography.body-md.fontSize: "'10pt' has an invalid unit 'pt'.
    Only px, rem, and em are allowed."
summary: 1 error

Related silent behavior: the same file's spacing: page-margin: 20mm
produces no finding — per the consumer-behavior table ("Unknown spacing
value: Accept; store as string if it is not a valid dimension") it is
stored as an opaque string. So within one document, mm in spacing survives
lint while pt in typography is rejected, and the spacing token quietly
loses its dimension semantics for exports.

Why it matters

Agents consume DESIGN.md to build artifacts that end in print. A concrete
case: a Russian-language academic dossier (A4 portrait + A3 landscape
inserts, justified body, first-line indent) rendered via headless Chromium
page.pdf. The typography spec for such a document is authored in pt
(10 pt / 1.45 body, 20 mm / 16 mm margins, 12.5 mm paragraph indent) — these
are the units of the GOST print standards and of the CSS @page rules the
agent ultimately emits.

The current grammar forces a two-system workaround: convert every pt/mm
token to px (×4/3, ×3.7795) so the linter passes, while the agent's print
CSS still needs the original pt/mm values. The token file then no longer
matches the document it describes — exactly the drift DESIGN.md exists to
prevent.

Proposal

1. Extend the dimension grammar with physical units: pt, mm, cm,
   in (and Q). CSS defines them; every print-capable consumer
   (Chromium, WeasyPrint, browser print) honors them.
2. Exports that must linearize (Tailwind theme JSON) can either pass them
   through as strings or convert at a fixed ratio (1in = 96px = 72pt).
3. Alternatively, if the scope must stay screen-only, document a canonical
   print workflow in the spec (e.g., "for print systems, express tokens in
   px at 96 dpi and keep pt/mm values in prose"), so agents have one
   sanctioned path instead of improvising.

Environment

• @google/design.md 0.4.0 (npm, via npx)
• Node 22, Windows 10
• Use case: A4/A3 academic print artifacts (Chromium page.pdf, KaTeX
  formulas, GOST typography rules)