PDF Export and Print Design

Status: Phase 0 implemented in crates/casual-doc-pdf and reachable through the casual-doc-io export registry as application.pdf; Phase 1 (semantic features) and Phase 2 (tagged PDF / PDF-A) remain design-only. Everything below the Implementation status section is the original design, unchanged; its effort estimates now overstate what Phase 0 still costs, because Phase 0 is done. Read Implementation status for what actually exists, family by family, and for what is still missing. Date: 2026-08-05; implementation status updated 2026-09-26. Depends on: ADR-003 (backend-neutral display list); casual-doc-layout::display::DisplayList; casual-doc-render (tiny-skia backend, reference implementation); paginate.rs per-page display lists; casual-doc-io format registry; 40-FONT-MANAGEMENT-DESIGN.md; 94-ORACLE-VISUAL-FIDELITY-HARNESS-DESIGN.md; 21-PARSER-LIMITS.md; 20-ERROR-CODE-REGISTRY.md. Owner decision still required: the Phase-2 scope gate (§10 item 2). ADR-031 is resolved below. Addresses: 104 HF-030 (the output half), 105 RM-04 Phase 0. Still open after it: the print dialog (105 OO-010), live-font parity, and the semantic features listed below.

Implementation status (2026-09-21)

What exists

Entry points: casual_doc_pdf::export_document (lay out, then write) and casual_doc_pdf::write_pdf (write display lists a host already holds — the seam for a viewer that must not paginate twice).

Support, family by family

Absence from a support list is an overstatement by omission, so every family the display list can carry is listed here, including the ones that are not covered.

ADR-031 (PDF writer and subsetter, build vs buy) — resolved: hand-rolled, no new dependency

Step 0 left this open. The decision taken is (A) hand-roll both, for a reason that only became visible once the problem was concrete:

• The subsetter does not need to renumber glyphs. Because the file addresses glyphs through Identity-H with /CIDToGIDMap /Identity, keeping the glyph identity space and emptying the outlines of unused glyphs is both simpler and stronger for parity than a renumbering subsetter — it removes the entire class of "the PDF drew glyph 41 where the shaper chose 42" defects. That is a few hundred lines, not the multi-sprint estimate this design assumed, because the expensive half of a general subsetter is the half we deliberately do not do.
• The container is an object table, a cross-reference table and a trailer. Owning it is what makes byte-determinism a property of the code rather than a hope about a dependency's release notes.
• deny.toml, unsafe_code = forbid and the dependency-policy job all stay simple with zero new supply-chain surface.

Three crates already in the tree are reused rather than added, so Cargo.lock gains no new package: flate2 (FlateDecode; MIT OR Apache-2.0; already pulled by the zip stack), skrifa (font metrics and the cmap inversion; Apache-2.0 OR MIT; already pulled by parley/fontique and casual-doc-render) and image (picture decoding; MIT OR Apache-2.0; the same version and codec feature set casual-doc-render builds).

Reachability — what is wired and what is not

"Built" is not "reachable" (SKILL.md §9 rule 4), so plainly:

• Reachable now from any Rust host. casual_doc_io::register_pdf_exporter(&mut registry) adds application.pdf to FormatRegistry::export_formats(), and registry.export(...) returns bytes, MIME type, suggested extension and a compatibility report in the same shape DOCX and ODT return. Registration is opt-in rather than part of builtin_registry so a host decides when PDF appears in its save-as list.
• Reachable from the product. The built-in registry includes the export-only PDF adapter, so casual-doc-wasm exposes application.pdf from availableExportFormats() and dispatches it through exportAs(...). The web File surface offers Export as PDF… through the same exportDocumentAs path as the other formats. A browser regression downloads the file and checks the PDF 1.7 header, Type0 text font, and ToUnicode map. Physical Print remains a separate 150-DPI raster path and is still open under OO-010 / PDF-PRINT-0.

Remaining work, in the order to take it

1. Font parity on the registry path. export_document paginates with a fresh shaper, so a host's live font registry (the browser's network-fetched CJK faces) cannot simply be handed over: those ids belong to a different registry and handing them over would embed the wrong face rather than a fallback. Either let a caller seed the export's pagination with an existing FontRegistry, or have the browser host drive write_pdf with the display lists it already holds. Until then the registry path embeds bundled and system-tier faces only.
2. Exact ToUnicode — done for model text, open for the rest. GlyphRun carries a node: Option<NodeId> anchor (a fixed-size anchor, not a String per run) and the exporter resolves each glyph's cluster against that paragraph's own text, so ligature and substituted glyphs now map to their real characters. What is still on the cmap inversion alone, and would need work of its own: a run with no source characters at all (list marker, tab-leader fill, inline math box, recomputed PAGE field — none of these has model text to name, so this is a limit of the concept rather than a gap in the implementation), a cluster drawn by several glyphs, an offset where the model text and the shaped text diverge (w:vanish contributes model bytes but no glyphs, w:caps rewrites case — the same divergence that misplaces a caret in those paragraphs, so the fix belongs to the offset accounting, not here), and write_pdf called without a PdfTextSource, which the browser viewer seam will need once it drives export itself (item 1).
3. Phase 1 semantics (§6): the StructureTree bridge first, then XMP metadata, hyperlink annotations, destinations, the outline tree and page ranges.
4. CFF subsetting, so OpenType faces stop being embedded whole.
5. Oracle extension (§9): diff the PDF's text layer and page geometry against the LibreOffice-PDF oracle.
6. Fuzz targets for the subsetter and the picture path, as §9 specifies. The subsetter is the highest-risk surface here: it parses font bytes that came out of an imported document.

Guards, and the mutations that drive them red

Each guard was driven red by mutating the production code before it was trusted (SKILL.md §4). The mutations used: dropping /ToUnicode from the font dictionary; shifting the text matrix by 10 pt; forcing whole-face embedding; skipping glyph emission entirely; deriving the file /ID from a counter; ignoring OS/2.fsType; dropping the placeholder mark; disabling picture de-duplication; dropping /Title; skipping the composite-glyph closure; claiming can_import; downgrading a degraded finding to Mapped; and — for the exact-ToUnicode guards — restoring the cmap-inversion-only map, and separately dropping the GlyphRun::node anchor the shaper populates. Both turn "Rich document-properties fixture body." back into "…fixture…" and "often afflicted by fjords" back into "oen afflicted by ords", which is what the reader saw before the fix. Those two guards also assert the bundled face really substitutes — fewer glyphs than characters, and at least one drawn glyph genuinely outside the face's cmap — because without that the assertions would hold whether or not it did.

The guards assert the guarantee rather than the mechanism: the file is parsed back and interrogated the way a reader would — text extractable and matching the document, every run within 0.01 pt of where layout put it, fonts embedded and subset under a six-character tag, no page delivered as a picture, repeat exports byte-identical, and a lost picture reported through the registry's compatibility report.

Problem

The engine can render a document to screen (DisplayList → casual-doc-render CPU raster) and paginate it against a LibreOffice oracle, but it cannot produce a PDF. The support matrix (18-SUPPORT-MATRIX.md) lists "PDF render/export — Backend decision pending", the architecture doc names "Headless raster/PDF" as the third paint target, and the ADR register lists "PDF generation backend" as a pending decision. This document specifies that backend end to end.

Two hard requirements shape the whole design:

1. A real, proper PDF — never a page of images. Output must carry a genuine text layer (selectable, searchable, copyable), vector graphics, and embedded subset fonts. Text-as-outlines or rasterized pages are explicitly rejected.
2. Two simultaneous parity targets:
• Editor parity (structural): the PDF must look identical to what the user sees in the editor. Any drift is a defect.
• Word feature parity (capability): the PDF must expose the same feature set Microsoft Word's "Export → Create PDF" produces (outline/bookmarks, hyperlinks, metadata, tagged/accessible structure, PDF/A option). This is feature parity, not an independent rendering target — layout fidelity to Word is earned in the layout engine, not here.

The parity model (the single most important design constraint)

Editor parity is structural, not aspirational

The editor pipeline is model → layout → DisplayList → tiny-skia. The PDF exporter consumes the exact same DisplayList, produced by the same layout pass, and maps each PaintItem to PDF content-stream operators. Because both backends share pagination, shaping, and glyph positions, editor↔PDF drift is architecturally impossible — provided the exporter never does its own layout. This yields the governing rule of the whole feature:

The PDF exporter performs zero layout, zero re-shaping, and zero metric adjustment. It is a deterministic transcription of the shared DisplayList. It is never permitted to be "smarter" than the editor.

Any attempt to improve fidelity inside the exporter (nudging positions to look "more like Word") would create the editor↔PDF drift the requirement forbids. The exporter's only job is faithfulness to the display list.

Word parity is a layout goal the PDF inherits — with one exception

Because the PDF must match both the editor and Word, the editor must match Word. The exporter cannot add Word rendering fidelity the editor lacks; it inherits exactly the layout fidelity the on-screen renderer already has (tracked separately under the fidelity-corpus / pagination work, 60/94/P1F). **Word feature parity, by contrast, is this document's job** — see §6 (semantic features) and §10 (tagged PDF / PDF-A).

The font parity trap (must-fix, not optional)

The one place editor↔PDF parity most easily breaks is fonts. The system-fonts build lays out with real system faces (Arial/Times/Calibri); the deterministic / WASM build uses bundled substitutes (Roboto). Different face → different metrics → different line breaks → different pagination. Therefore:

**The PDF must embed and emit the exact same font faces the layout pass used — the same FontId, the same bytes from FontRegistry, the same glyph indices at the same advances. The exporter must never re-resolve fonts independently.**

GlyphRun already carries glyph indices into those specific faces, so embedding the same face and emitting the same GIDs at the same advances produces a PDF that is glyph-for-glyph identical to the editor. This is enforced by a CI golden (§9).

Goals

• A casual-doc-pdf backend that transcribes a per-page DisplayList into a valid, deterministic PDF (ISO 32000-1) with a real text layer and embedded subset fonts.
• Byte-deterministic output: identical input → identical bytes (no timestamps, no random file IDs; IDs derived from content). Same discipline as the rest of the repo.
• Word feature parity delivered in phases (§6, §10): outline/bookmarks, internal + external links, document metadata; then tagged/accessible PDF and PDF/A as a gated second phase.
• Print support that reuses the PDF pipeline (§8), with host-owned device policy.
• Integration through the existing casual-doc-io registry and the WASM/SDK export_as / available_export_formats seam.
• Security: untrusted font bytes and image bytes handled under the 21-PARSER-LIMITS discipline; bounded, fail-closed, no panics on adversarial input.

Non-Goals

• Any rendering/layout fidelity work — that lives in the layout engine, not here. This document adds no shaping, line-breaking, or pagination logic.
• Round-trip PDF import. This is export-only.
• Experimental local PDF semantic reconstruction is evaluated separately in doc 131 and proposed ADR-034. It does not alter this design's export-only scope or the current can_import: false product behavior.
• Text-as-outlines or rasterized-page output (explicitly rejected).
• Editing PDFs, PDF forms (AcroForm) authoring, digital signatures, JavaScript, or embedded multimedia.
• Font procurement. Which faces are legally embeddable is a licensing decision (§7), out of engineering scope; this document only specifies the embedding mechanism and the fallback policy.

Architecture

                    ┌─────────────────────── shared layout pass ───────────────────────┐
           model ─▶ layout ─┤  paginate.rs → Vec<DisplayList> (one per page)  +  FontRegistry   │
                            │  (NEW) StructureTree  — logical/semantic side-channel (§6)         │
                            └───────────────┬───────────────────────────┬──────────────────────┘
                                            │                           │
                               ┌───────────▼──────────┐     ┌──────────▼───────────┐
                               │ casual-doc-render     │     │ casual-doc-pdf (NEW) │
                               │ tiny-skia (screen)    │     │ DisplayList → PDF    │
                               │ REFERENCE traversal   │     │ ops + semantics      │
                               └───────────────────────┘     └──────────┬───────────┘
                                                                        │
                                             ┌──────────────────────────┼───────────────────────┐
                                             │ pdf-writer (container) │ font subsetter │ image XObjects │
                                             └──────────────────────────┼───────────────────────┘
                                                                        │
                                             casual-doc-io registry ◀───┘  format_id = "pdf"
                                             WASM/SDK export_as("pdf", …)  → bytes / print target (§8)

New crate casual-doc-pdf (naming per workspace convention). It depends on casual-doc-layout (for DisplayList/PaintItem/GlyphRun/FontRegistry) and casual-doc-model (for Definitions.media, colors, metadata). It must not depend on casual-doc-render — it is a sibling backend consuming the same seam (ADR-003). It reuses casual-doc-render's traversal shape as the reference for correctness, not as a dependency.

Step-by-step design

The work is ordered so each step lands as an adversarially-reviewed slice (the repo's working pattern) and so nothing downstream is blocked by an undecided upstream.

Step 0 — ADR-031: PDF-writer + subsetter build-vs-buy (BLOCKING)

Decide, against deny.toml and unsafe_code = forbid, whether to:

• (A) Hand-roll a minimal PDF writer and TrueType/CFF subsetter (max control, zero new supply-chain surface, deterministic by construction; higher eng cost — the subsetter is real work); or
• (B) Vet crates — e.g. a low-level PDF writer + a font-subsetting crate — against the dependency policy (lower eng cost; requires audit, cargo-deny clearance, determinism verification, and pinning).

This choice moves Phase 0 by ~1.5 sprints (§ effort). No code starts before it is recorded as ADR-031. Recommendation: prefer (B) for the writer (well-trodden, low risk) and evaluate (A) vs (B) for the subsetter specifically, since subsetting is the correctness- and security-critical part.

Step 1 — PDF container writer

• Object model: indirect objects, xref table (or cross-reference streams for compactness), document catalog, page tree, per-page resource dictionaries.
• Content streams: Flate-compressed (reuse the workspace zip/flate stack already present).
• Determinism: object numbering is assignment-order stable; the file /ID is derived from a content hash, not time/random; no /CreationDate//ModDate unless sourced from DocumentProperties (and then normalized). This mirrors the repo's existing byte-fixed-point contracts.
• Page geometry comes straight from pagination (page size + margins already in twips; convert twips → PDF points, 1 pt = 20 twips, origin flip to PDF's bottom-left).

Step 2 — Vector paint mapping (DisplayList → content operators)

Walk PaintItem in back-to-front order (identical order to casual-doc-render) and emit operators. The mapping is mostly mechanical because the display primitives already exist:

Gradients map to PDF axial/radial shadings (ShadingType 2/3); dashes to d; ShapeTransform (rotate/flip about center) to a cm matrix. All geometry is device- independent twips → points; no device scale is applied (PDF is resolution-free), which is the one deliberate divergence from the raster backend's paint path.

Step 3 — Text as a real, selectable layer

For each GlyphRun:

• Open a text object (BT/ET), set the embedded font + size (Tf), set fill color (rg), set the text matrix (Tm) from run.origin (+ character_scale_percent as a horizontal-scale Tz, matching how the raster backend scales outlines).
• Emit glyphs by glyph index into a Type0/CID font with Identity-H encoding and explicit positioning from Glyph.advance (TJ with advance adjustments), so the on-page positions equal the display list exactly.
• Decorations (underline/strikethrough/double_strike), highlight, and run shading are painted as rects behind/over the run — identical to the raster backend — not as font features.
• ToUnicode CMap: Glyph.cluster is the UTF-8 byte offset into the paragraph's source text. This is exactly the data needed to build the ToUnicode map (glyph → source scalar[s]), which makes selection, search, and copy work. This is what separates a "proper" PDF from an outline dump, and the mapping data already exists in the display list.
• List-marker runs (is_marker) are emitted as text too, but tagged as artifacts in the Phase-2 structure tree (§10) so they don't pollute the reading order.

Step 4 — Image XObjects

• Resolve PaintItem::Image.media against Definitions.media (the exporter is given the media bytes by the host, exactly as the raster backend is).
• JPEG → DCTDecode passthrough (no re-encode). PNG/other → decode then FlateDecode (or DCTDecode for photographic content per the size/quality knob, §6).
• Honor crop (source sub-rect via clip + scaled placement) and transform (rotate/flip via cm).
• Reuse casual-doc-render's decode limits verbatim (MAX_DECODED_IMAGE_* from 21-PARSER-LIMITS): bounded dimensions/pixels/bytes, fail-closed with a finding.

Step 5 — Font embedding + subsetting (the long pole)

For every FontId referenced by any emitted GlyphRun:

• Pull the exact face bytes from FontRegistry (face_bytes/FontBytes/DynFace) — the same face the shaper used (parity guarantee, §"font parity trap").
• Subset: retain only the referenced glyph indices. TrueType path: rebuild glyf/loca/cmap/hmtx/maxp/head/hhea for the kept set; CFF/OTF path: subset the CharStrings INDEX. .ttc/.otc collections: extract the single face by index (DynFace already carries the face index).
• Wrap as a Type0 font with a CID-keyed descendant (CIDFontType2 for TrueType / CIDFontType0 for CFF), Identity CIDToGIDMap, a W array from the run advances /hmtx, a FontDescriptor (flags, bbox, ascent/descent/stemV), and the subset embedded (FontFile2/FontFile3). Subset-tag the PostScript name (ABCDEF+Name).
• Untrusted-font hardening: the face bytes may originate from an imported document. Subsetting parses untrusted tables → apply 21-PARSER-LIMITS bounds (table sizes, glyph counts, offsets), reject malformed tables fail-closed with a reported finding, and never panic. This is the highest-risk security surface in the feature and gets its own fuzz target (§9).
• Fallback policy (no images): if a face genuinely cannot be embedded (unsupported outline format, or a licensing flag the host declines), the run is emitted with a substitute embeddable face and a loss finding — never rasterized, never dropped silently. Word offers a "bitmap text when fonts can't be saved" fallback; we do not (it violates requirement 1).

Step 6 — Semantic features (Word feature parity, Phase 1)

A flat display list has no logical structure, so feature parity needs a semantic side-channel carried from the model through layout to page positions. Introduce a StructureTree (logical order: headings, paragraphs, lists, tables, links, figures) with per-node page + rect resolved from the same layout pass. Every Phase-1 feature hangs off this one bridge:

• Document metadata → /Info dict + XMP packet, from DocumentProperties (title/author/subject/keywords/lang). Nearly free.
• External hyperlinks → Link annotations with URI actions; rects come from the link runs (layout must expose link geometry — a small, additive layout change). The URI scheme allowlist mirrors the import/export security allowlist (no javascript:/unsafe data:), consistent with the ODT work.
• Internal links / TOC / cross-refs → GoTo actions to named destinations minted from bookmark anchors (model already has bookmarks; T1 ODT work modeled them).
• Outline / bookmark tree → /Outlines built from Heading-style paragraphs (named-style identity exists), i.e. Word's "Create bookmarks using Headings".
• Page range / selection → emit a subset of pages.
• Image quality knob (Standard vs Minimum size) → image re-encode/downsample policy in Step 4.

Step 7 — Public surface + registry wiring

• Register a "pdf" export adapter in casual-doc-io (export-only descriptor).
• Route through the existing WASM/SDK export_as(format_id, mode) and advertise it in available_export_formats. mode carries options (page range, metadata inclusion, image quality, and — Phase 2 — tagged/PDF-A toggles).
• SDK facade method on casual-doc-sdk (consumers depend on the SDK, not the crate — ADR-004). Emit a compatibility/loss report (unembeddable fonts, dropped features) in the same shape as the other adapters' findings.

Fonts and licensing (must be settled early)

Requirement 1 (real text) forces font embedding, which forces redistribution rights for the embedded faces. Two independent concerns:

1. Mechanism (this doc, Step 5): subset + embed the exact layout face.
2. Rights (owner decision, out of eng scope): the bundled substitute faces must be embeddable (verify their licenses permit PDF embedding — most open faces do). To reach true Word layout parity you additionally need metric-compatible or genuine MS faces (Calibri/Cambria → Carlito/Caladea substitutes are the standard answer) in the layout engine, not here. Flag: the closer you want editor+PDF to match Word's line breaks, the more this licensing choice matters — but it is a layout- engine input, and this backend faithfully embeds whatever the layout used.

Print

Print reuses the PDF pipeline; it is not a second renderer.

• Web/WASM host: "Print" = generate the PDF (same path) and hand the blob to the browser print dialog (window.print() on a PDF object/hidden frame). No new rendering code. ~1–2 eng-days.
• Native host: OS device policy (CUPS/Quartz, GDI/XPS) is host-owned (AGENTS.md — hosts own device/resource policy; the runtime must not). The contract: the runtime hands the host either the PDF or per-page DisplayLists; the host drives the printer. A thin host-side adapter, ~2–4 eng-days, not core work.

Net: budget print as a small addition to PDF, provided "print = PDF routed to a print target" is accepted (the standard approach for an embeddable engine).

Security

• Untrusted font bytes (Step 5) and image bytes (Step 4) are parsed under 21-PARSER-LIMITS: bounded sizes/counts/offsets, fail-closed, no panics, reported findings. Dedicated fuzz targets for the subsetter and the image path.
• URI/link schemes mirror the existing import/export allowlist; blocked schemes degrade to a reported remainder, never emitted (a non-PDF-origin model must not smuggle a javascript: link into an annotation).
• No JavaScript, launch actions, embedded files, or auto-actions are ever written.
• Determinism is a security property here too (reproducible builds / no entropy leak): no time, no RNG, content-derived /ID.

Testing and gates

Every slice must pass the standard gates: cargo test --workspace, cargo clippy --workspace --all-targets -- -D warnings, cargo fmt --check, WASM check, plus:

• Determinism golden: export a fixture twice → byte-identical; export₂ == export₃ fixed point (the repo's standard contract).
• Editor↔PDF parity golden (the key invariant): for each corpus page, assert the PDF text-run positions/advances/glyph-ids equal the shared DisplayList geometry (zero/epsilon). This converts "the PDF matches the editor" from a hope into a CI gate — if the exporter ever does something the display list didn't say, it fails.
• Structural validity: validate against a PDF parser (and, if PDF/A is in scope, a veraPDF-class check on the re-bless workflow, not per-CI).
• Oracle extension: extend the docs/94 harness to diff the PDF's page geometry + text layer against the LibreOffice-PDF oracle (Word as tie-break authority per §"Word parity"). Reuses the existing pinned-soffice re-bless flow.
• Fuzz: font subsetter and image decode paths get cargo fuzz targets with the all-fields-explicit limit literals (note: adding a new PdfExportLimits field breaks those literals — update them or cargo fuzz build fails, same gotcha as ODT).
• Text-layer proof: automated pdftotext extraction of a known fixture equals the source text (selectable/searchable proof), and a copy-paste spot check.

Docs to update per slice: this doc, 18-SUPPORT-MATRIX.md, 08-ADR-REGISTER.md (ADR-031 + any Phase-2 ADRs), 14-EXECUTION-TRACKER.md, and a new 99-PDF-EXPORT-PROFILE.md (supported/loss/limits table, mirroring 95/96).

Phasing, slices, and effort

Estimates are planning-grade (±40%), for one experienced Rust engineer fluent in this codebase, and include the per-slice adversarial review + all gates. Sprint = 2 weeks ≈ 8 productive eng-days after reviews. Biggest swing = ADR-031 (crate vs hand-roll). Excluded: layout-engine Word-fidelity work and font procurement.

Phase 0 — proper vector PDF (selectable text, embedded fonts, images)

→ ≈ 2–3.5 sprints (crate) / 3.5–5.5 sprints (hand-rolled). Font subsetting is the long pole and the reason ADR-031 matters.

Phase 1 — semantic features (Word-equivalent for ~95% of users)

→ ≈ 1.5–2.5 sprints.

Print

→ ≈ 0.5 sprint.

Phase 2 — accessibility / archival (GATED — decide in/out up front, §10)

→ ≈ 3.5–6 sprints.

Roll-up

Parallelism: Phase 0's font work (PH0-2) and paint work (PH0-1) can run as two concurrent tracks (2 engineers compress Phase 0 to ≈2 sprints). Phase 1 largely serializes after the container exists.

Open decisions (§10)

1. ADR-031 — writer/subsetter build-vs-buy (BLOCKING; §Step 0). Moves Phase 0 by ~1.5 sprints.
2. Phase-2 in or out. Tagged PDF + PDF/A roughly doubles the project. Decide up front, because the StructureTree (§6) should be designed with tagging in mind from day one rather than retrofitted. Drive by whether accessibility/archival compliance is an actual customer requirement.
3. Font substitute licensing (§7) — owner/legal, not engineering. Caps how close to Word's line breaks either the editor or the PDF can get.
4. Oracle tie-break policy — reaffirm §"Word parity": LibreOffice PDF = automatable CI oracle, Word = correctness authority on disagreement (already the repo's posture for on-screen rendering; PDF stays consistent with it).

Recommendation

Adopt Phase 0 + Phase 1 + Print as the committed scope (≈ 4–7 sprints, one engineer) — a proper vector PDF with selectable text, embedded fonts, links, outline, metadata, and print: genuine Word-equivalence for what users notice, with editor parity guaranteed structurally and by a CI golden. Gate Phase 2 (tagged PDF / PDF-A, ≈ doubles the effort) on a concrete accessibility/archival requirement. Settle ADR-031 first; nothing else starts before it.