Every test we run, published.

Four ways into the same run

The same run, read four ways. Pick whichever matches what you came to check.

By directory

ReflowPDF has no JavaScript runtime, so it judges 25.6% of the subtests wpt.fyi measures in css/ (55,955 of 218,751). The percentages below are relative to what is judged.

Where it is weakest

The six specifications the engine loses most often, among those with at least sixty judged tests. Each links to its failing tests and their diffs.

The part WPT doesn’t test

The web suite has almost nothing on paged media, because browsers rarely print. Running headers and footers, footnotes, leaders, named strings, cross-references. We wrote 106 reftests of our own for it, in the same format and judged the same way. They are not counted in the figures above. We wrote them ourselves, so they are a regression net; nobody should score an engine on tests its author picked.

What the number is made of: layout assertions

1,050 WPT files carry their expectation in the markup itself: data-expected-width, data-offset-x and the rest of what check-layout-th.js reads. A browser needs JavaScript to ask offsetWidth; we ask our own layout directly, so every attribute is one subtest. Files whose script rewrites the document before checking are not judged, exactly as script-driven reftests are not.

What the number is made of: parsing acceptance

903 WPT files test the CSS parser with parsing-testcommon.js: a value the property must accept, a value it must reject, a selector that must or must not parse. Each call has two halves. The first — accepted or rejected — is put to the engine’s own declaration parser and cascade, the same path @supports answers with. The second half, the canonical serialization the browser would read back, is judged by the tier below — for the properties whose serializer is written; the rest are set aside with that reason rather than counted either way.

Beyond layout

The file itself has standards to meet as well. Those are checked separately with veraPDF, the reference validator, over every built-in template.

A validator tells you a file does not break the rules it can express, which is a smaller claim than the file being accessible. Our own structural audit exists for the gap: it is what caught a PDF/UA-2 file we shipped with a %PDF-1.7 header that veraPDF passed, because that profile checks prohibitions and not the container version. The same audit found eleven structure-namespace violations and a footnote type that changes name between the two editions. All of it is written up, with the fixes.

We could not find per-specification test results published by any other HTML-to-PDF engine. Prince, PDFreactor and Antenna House publish feature lists; the most recent public conformance marker for this class of tool is Acid2, from 2005. That is the reason this section exists in the form it does, and if one of them publishes a comparable run we will link to it from here.