Parity & conformance evidence

Conformance

PDF/UA-1 and PDF/A, per document

Validated with veraPDF 1.30.2. The corpus is 5 shipped templates (invoice, receipt, report, shipping-label, letter) and 4 HTML fixtures (letterhead, dashed-borders, statement, zebra-invoice). Each PDF/A column is the archival-and-accessible render — the same file validated against the PDF/A profile and PDF/UA-1.

Any failed profile shows its veraPDF clause list here; there are currently none. PDF/A-2u/3u are supported and reachable but not gated separately (the a-levels are the strictest of each part).

E-invoice container

Factur-X / ZUGFeRD (PDF/A-3)

One render call produces the human-readable invoice PDF and embeds the caller-supplied EN 16931 CII XML as a conformant PDF/A-3 associated file (pdfa:3b + pdfUa + facturX{EN 16931} via @formepdf/core renderDocument). The XML is ZUGFeRD corpus EN16931_Einfach.cii.xml (FeRD, Apache-2.0). Forme validates the container, not the invoice semantics — the XML content is the caller's.

Determinism

Byte-for-byte, across build targets

The same document renders to byte-identical PDFs across the native binary and the WASM targets, over the four HTML fixtures. These are distinct strengths of evidence and shown as such: native, node, and web are compared byte-for-byte; the bundler target embeds a hash-identical WASM module (so it computes identically by construction) and is exercised by functional browser and workerd renders — it is not itself byte-diffed here.

Regression evidence

Structural assertions from Chrome reference & third-party corpus

Boolean structural assertions (page count, break positions, table structure, valign) read from Chrome's rendering of these fixtures and asserted exactly. NOT a general browser-parity claim or a measured diff.

Hand-reduced repros distilled from the ironpress parity corpus (third-party test material, MIT). Not upstream copies.

Source: gastongouron/ironpress (MIT).

Test coverage

Suite counts

Passing tests per suite, parsed from an actual run. Stated as a fact, not a percentage.

Benchmarks

Measured performance — including where we lose

Process/isolate start through first PDF byte, including module instantiation. Steady state after warm-up; median and p95 over the published iteration count. Puppeteer reuses one browser across iterations (setContent + page.pdf each). All targets and Puppeteer render byte-identical HTML from the fixed corpus, so every column is the same document. Corpus is fixed, committed, and hash-checked (6 documents).

Two environments are published side by side and neither is cherry-picked: a dev machine (clean, quiet, single run) shows the engine on good hardware; CI ubuntu-latest (a shared, noisy runner) is the conservative number and the one that is regenerated on every push. Where a document ran on one but not the other, the gap is shown rather than the row hidden.

Cold start — start to first PDF byte

The ~7.1MB WASM module compiles and instantiates in 1-10ms — cold start is dominated by first-render JIT warmup, not module size: the module is large on disk and cheap to instantiate. Puppeteer here is on a warm machine; cold serverless is 3-10s, and on many consumption tiers Chrome cannot boot at all.

workerd caveat miniflare runs a workerd subprocess whose routing overhead the real edge does not pay; wall time OVERSTATES production cold start (true edge isolate spin-up ~5ms). Instantiate/render split is accurate. Real production cold start needs a deployment (out of scope).

Serverless memory

What fits under the Cloudflare Workers 128MB ceiling

Peak WASM linear memory per document (engine allocation — the same on any machine). This decides whether a document is renderable on Workers at all.

Practical guidance: comfortable under ~50 pages, approaching the ceiling near ~100 pages, use node or native beyond that. A margin, not a threshold — a slightly wider table shifts the number.

Local miniflare has generous memory and will run documents the real edge would OOM: the 500-page ledger completes locally but its 839MB peak would exceed the 128MB edge limit.

Warm render

Forme vs Puppeteer, identical HTML

Median warm render (node target for Forme; Puppeteer reuses one browser). Both environments shown; the rows where Forme loses are here, in order, not reordered.

Forme is ~2× faster on small documents with ~15× smaller output, and — after the allocation fixes below — now edges a warm pooled Chrome on the large table-heavy documents too (50p and 500p), where it previously trailed ~2–4×. Iteration counts per cell are in the raw artifact.

Where the time goes

The large-document gap, measured then closed

Forme originally trailed Puppeteer ~3.8× on ledger-500p, decomposed as two independent linear factors: ~2× from the page-number second layout pass (ledger crosses the 2→3 digit-width boundary at page 100, so it re-lays-out to widen the page-count field), and ~1.9× from per-node allocation churn. That decomposition was directionally right and quantitatively wrong in the engine's favor: fixing the allocation churn (−74% allocations, −88% bytes allocated; benchmarks/harness/dhatprofile) dropped per-pass layout from ~7.3 to ~1.8 ms/page — a ~4× per-pass gain, not the estimated ~1.9×. It isolates cleanly because parse and serialize (both untouched) didn't move. That alone flipped both large docs — ledger 9997→2284 ms, invoice 534→147 ms — from behind Puppeteer to ahead (ledger 2284 vs 2665 ms, invoice 147 vs 232 ms; same M3 Max, Puppeteer as a stable control moved <2%). The ~2× sentinel factor is NOT eliminated: ledger still runs 2 passes — it is now masked by the throughput win, i.e. forme leads while doing twice Chrome's layout work. Removing that second pass on digit-change docs is the remaining known inefficiency (scoping it to just the running element proved unsound — see the sentinel tracked-fix note) and would roughly halve ledger's layout again.

The full layout tree is retained until serialize (~2 MB/page), so peak memory is linear in document size and freed at exit — not a leak. The allocation fixes did NOT move peak (ledger wasm ~890 MB before and after): they removed transient churn, not retained state — a throughput/allocator-pressure win, not a memory-ceiling one.

Tracked fixes (no dates promised):

• Streaming layout — cap peak so large docs render in a 128MB Workers isolate Investigated 2026-09 across THREE reframings, each cheaper than the build it prevented; parked with a well-scoped next project. (1) "Streaming serialize" is a misnomer — the ~1GB peak is NOT the serializer, which only borrows &[LayoutPage] and is already ~90% streaming-ready (Pass 1 consumes+compresses everything heavy; Pass 2 touches only scalars + lightweight lists). It is the retained Vec<LayoutPage> (~2MB/page) the CALLER holds. (2) "Streaming layout" (a restartable count-then-emit producer) is SOUND — layout() is a deterministic pure function of (document, sentinel_digit_count) so a discarding count pass and an emitting pass produce identical pagination; byte-identity is achievable (only the lifetime of the heavy element vecs changes, provided font/image/gstate/shading registration still runs globally up-front in page-order); compliance is NOT a blocker (TagBuilder/link_slots/StructParents are lightweight, stay whole-document, veraPDF 9/9 by construction); PageCursor forward-state is already resumable. BUT it does nothing for the acceptance-test doc. (3) THE REAL FINDING: the peak on ledger-500p is not "the layout Vec" in general — it is ONE document-spanning table (8001 rows / 500 pages) whose RETROACTIVE wrapper (layout_table mod.rs:3488-3538, and the same pattern in layout_breakable_view, flex, paragraph) reaches back into every page it covered, after the table closes, to wrap each page in a border/background/tag container. For a doc-spanning table "after it closes" is end-of-document, so all 500 pages stay resident regardless of streaming. THE ANSWER is item 3: convert that retroactive wrap into FORWARD, at-page-finalize emission via an open-container stack on the cursor (each open container records draw_cmd + per-page start-y; on finalize it wraps the finalizing page from start-y; on new_page start-y resets to content_top; on close it wraps the current page). Feasible and byte-identical (each wrapper uses only its own page geometry), but it is 4 container types + linearizing table-overflow ordering — the hardest pagination code, highest output-correctness risk, and roughly as large as the two-pass work it enables. SEQUENCING: items 1-2 (streaming producer + writer restructure) are UNOBSERVABLE on the acceptance test until item 3 lands — do NOT start with them expecting a win. Parked because Workers-isolate 500p rendering has zero requesters (real users render invoices/reports well under the ceiling); revisit item 3 as its own byte-identical project, gated by the full corpus + a new isolate acceptance test, only if a real need appears. Peak floor after a full fix (item 3 done): ~3-5MB for ledger — 1 resident page (~1.8MB) + accumulated compressed content objects (≤1.3MB, the single-file-xref floor); going lower needs incremental xref (linearized PDF), out of scope.
• Reduce per-node allocation (arena / SmallVec / drop style clones) dhat-profiled 2026-09 (benchmarks/harness/dhatprofile + dhat-top.mjs). TWO FIXES LANDED, output byte-identical, all gates green. (A) PositionedGlyph.font_family String→Arc<str> — #1 site by allocation COUNT; every glyph owned its own family string, so each of the millions of glyph clones heap-allocated one. Arc<str> makes clone a refcount bump. (B) Table-cell rollback checkpoint elision — the dhat BACKTRACES (not the profile guess of "measure_node_height trial-layout") showed ~76% of all allocated BYTES came from ONE line: layout_table_row cloned the whole PageCursor (which owns elements: Vec<LayoutElement>, every element on the page) before each cell as page-break rollback, then discarded it unused whenever the cell fit. Guard added: skip the clone when the row fits (row_height <= remaining_height) and its subtree forces no break — byte-identical by construction since an elided checkpoint would never be restored. Combined result: allocations −74% (ledger-500p 182.8M→46.3M, invoice-50p 9.24M→2.45M), bytes allocated −88% (invoice-50p 2476MB→304MB). Peak memory unchanged (churn, not peak). REMAINING (Design 2, parked): the residual at-risk-cell clones near page boundaries — a length-based checkpoint replacing the clone entirely — carry intricate mem::take/cell_pages rollback semantics + ~20-field exhaustive capture; own go/no-go, likely not worth it after (B).
• Sentinel re-pass re-measures only the running element Investigated 2026-09 and set aside: not scopable as written. The sentinel width is consumed during injection (footer/margin-box layout), not the flow pass, and HTML @page margin boxes are Fixed nodes — so a "reuse flow + re-inject" split has no guard signal to read and silently skips the correction (byte-identity caught it). Would need injection-time or model-scan detection.

Self-audit

A number we found wrong on our own homepage

The published ~26ms figure was measured on a document doing two layout passes; the honest single-pass number is ~21ms. Benchmarking our own engine surfaced an unconditional second layout pass — a document with no page-number placeholder was re-laying out the whole tree for nothing. We fixed it; here is the before and after on identical documents.

A/B: pre-fix WASM rebuilt from HEAD~1 vs the fix, same machine/harness, node target, warm median.

Known gaps & deliberate divergences

What isn't claimed

• Not a general browser-parity claim. The Chrome-reference checks above are specific structural properties (page count, break positions, table structure, valign) read once from Chrome and asserted exactly — they do not claim pixel or layout parity with any browser.
• position: absolute resolves against the nearest positioned ancestor (matching browsers), which changed in 0.15.0 — an intentional divergence from the earlier direct-parent behavior.
• Collapsed table borders use a widest-wins approximation, and vertical-align: baseline maps to top in table cells where a true baseline isn't resolved — both documented, deliberate scope debts.
• The supported HTML/CSS subset is explicit; anything outside it is reported as a named warning at render time, never silently dropped. See the HTML subset documentation.