How paged is tested
The verification system across paged — unit suites, end-to-end and DTP journeys, the fidelity gate against InDesign, the conformance corpus, and how all that evidence flows into the capability registry.
In short paged is verified at four tiers, and every tier's results flow into the capability registry as evidence. The registry claims what's implemented; the tests verify it; this documentation renders both. That's why a green badge here means a passing test exists — not someone's say-so.
36 chapters · generated from the capability registry @ b996869c.
The four tiers
1. Unit (per repo, language-native)
The engine runs Rust cargo nextest across its
crates (parse, layout, mutation, color, export). The
editor and server
run TypeScript suites; the plugins run vitest (TS) and,
where they're Rust/WASM, nextest. Several plugins enforce a registry-driven
coverage gate — every kernel/function declared must have at least one test.
2. End-to-end & DTP journeys
The editor runs Playwright across three sub-tiers: isolated gesture/op specs, journey tests (real desktop-publishing workflows built from a blank document), and per-page fidelity specs. Plugin journeys exercise each plugin in the real editor.
3. The fidelity gate
The decisive correctness check: render a corpus document and diff it against an InDesign-exported PDF using ΔE2000 + SSIM, with hard thresholds. The rule is never loosen a threshold to hide a regression — fix it first. This runs on both the engine's own fixtures and the editor's canvas.
4. Conformance corpus
A central harness runs the corpus (deterministic generated fixtures, real InDesign exports) through the engine at each level — parsed → rendered → mutatable → round-trips — pinned to a core release. Each fixture declares which features it exercises, so results route to features. See the live conformance ladder.
How evidence becomes status
Each repo's CI publishes its results; a converter maps them to registry stages and
features (by suite, by a test→feature map, or by inline @feat: tags). The
paged-state generator joins claims with evidence into the matrix you see on the
capability state pages — and into every
<SupportBadge> across the IDML reference.
A claim with no passing test renders as untested, not green; a mapped test going red renders as failing. The honesty is structural — see how the capability state works.
How the capability state works
The registry, the test-evidence overlay, and the generation pipeline that keeps these pages in lock-step with the software — by construction, not by hand.
Recent activity
A live, interleaved feed of the latest commits across every paged repository — pulled from GitHub at build time, refreshed nightly.