DEV Community: Philipp Staudt

The preview that lies, and the one that doesn't

Philipp Staudt — Thu, 29 Oct 2026 09:37:36 +0000

Every document editor has a preview, and the PDF is always made somewhere else. The question worth asking of any preview is not whether it looks right, but whether page 1 ends where the PDF's page 1 ends. A browser window has no pages at all. Switching it to print styles (@media print) changes the styles and still has no pages. The browser's print dialog does paginate, but with its own margins and, unless you untick them, its own header and footer — not the ones your API renders.

Our editor has a flow preview for writing and a paged preview for layout. The paged one uses Paged.js, which paginates HTML in the browser following the CSS paged-media rules; the PDF comes from headless Chromium on our render servers. So we measured whether the two agree.

The test

One short report: a heading, a banner, and 24 cards. Each card is height: 22mm with padding: 5mm and a border, the way a template sets a box to a height — and each is kept whole with break-inside: avoid. A4 with margins of 20 mm at the top and bottom and 18 mm at the sides, and a page-number footer. We printed it with our render worker, laid it out in Chromium with Paged.js as it ships and with our paged preview, and counted the cards on every page.

	Cards per page	Pages
Paged.js as it ships (left)	9 · 10 · 5	3
Our paged preview (middle)	6 · 7 · 7 · 4	4
The PDF (right)	6 · 7 · 7 · 4	4

The preview and the PDF agree card for card. Paged.js as it ships gets every page wrong and the page count too.

The rule that made the difference

The two previews differ in one thing. Paged.js's own stylesheet contains .pagedjs_pagebox * { box-sizing: border-box }. It is meant for the boxes Paged.js builds around each page, but the selector reaches everything inside a page, your template included. Under border-box, a height includes the padding and the border; under the browser's default content-box, which Chromium uses when it prints, they come on top. So each card is 22 mm tall in Paged.js as it ships and a little over 32 mm in the PDF, and Paged.js fits nine where the PDF fits six.

Our preview rewrites that one rule as the stylesheet arrives, before anything is laid out, so that it applies only to Paged.js's own boxes ([class*="pagedjs_"]). Your elements keep the box model they will have in the PDF. The same thinking applies to our print reset: the preview's header and footer boxes are left out of it, because Chromium's header and footer templates get none of it either.

The case no preview can show

Now make the banner "full width" the usual way: width: 100% plus its padding: 5mm 10mm. Under content-box that is 20 mm wider than the space between the margins.

Each picture in this post is page 1 of the same document, from three sources — not three pages. Paged.js as it ships does not even show the problem: under its border-box rule the padding counts inside the 100 %, and the banner fits. Our preview shows what the document asks for: the banner runs past the right margin. The PDF does something else. Chromium scales the whole document down until its widest element fits the page — here to 89.7 %, so the 10 pt card titles come out at 8.97 pt — and does it on every page, not only the one with the banner. Smaller pages hold more: 7 · 8 · 8 · 1 cards instead of 6 · 7 · 7 · 4.

No preview that lays out at 100 % can reproduce that, ours included. What it can do is find the cause, and ours now says it in words: the preview measures the widest element after every layout, and when one reaches past the margin, the editor lists it under Problems — how many millimetres too wide, and to what size the PDF will shrink (here 20 mm and 89.7 %) — with a link to the tag in the template. Give such an element box-sizing: border-box, or leave its width alone — a block is as wide as its container without being told.

What we take from it

A preview earns trust by breaking where the PDF breaks, and that is a property you can measure: same document, same page size, count what lands on each page. Ours does, until a template asks Chromium to shrink. For the last word, the editor's True render sends the draft through the same worker that printed the PDFs above, and costs nothing.

The editor tour shows the preview modes and True render, and the invoice example is a document to try them on.

Measured on 21 September 2026 with Chromium 153.0.8010.12 on the render worker and Paged.js 0.4.3.

Let the agent write the data, not the HTML

Philipp Staudt — Mon, 05 Oct 2026 10:53:23 +0000

There are two ways to let an AI agent produce an invoice. You can ask it for the invoice: it writes HTML, something prints it, and a PDF comes out. Or you can hand it an invoice template someone has already reviewed and ask it only for the facts — who, what, how many, at what rate — as JSON.

The first way works in a demo. The second one is the one that survives a second run.

A document is a promise to look the same

A model writes by sampling. Ask it twice for "an invoice for these two line items" and nothing ties the second answer to the first: the column order, the wording of the VAT line, whether the payment terms mention a due date, whether the legal footer is there at all. Each run is a new draft that nobody reviewed. For a birthday card that is charming. For an invoice, which in Germany has to carry a list of mandatory details, it means reviewing every single one the agent sends — at which point the agent saved nobody any work.

A template turns that around. The layout, the legal lines, the arithmetic and the payment code are written once, looked at by a person, versioned and published. What varies between runs is the data, and the data is the part a model is actually good at: pulling a customer name out of an email, the quantities out of a spreadsheet, the rate out of a contract.

The shape that works has four parts, and our MCP server has a tool for each:

Step	Tool	Costs
Find the template	`list_templates`	nothing
Learn what it expects	`get_template_schema` — the JSON Schema of the data, plus the sample data it was designed with	nothing
Check the data	`validate_template`	nothing: the API checks a stored template without rendering it; ad-hoc HTML is checked inside the MCP server
Render	`render`	nothing with a test key; with a live key one unit per started five PDF pages

Test keys (ff_test_…) render the same templates through the same pipeline and are never metered; their outputs are kept for 24 hours, and on the Free plan they carry a watermark.

Where the data still goes wrong

Giving the model the data to write does not make the data right. So we took a short invoice template and fed validate_template the data an agent tends to produce, then rendered each version. We passed the template itself as HTML, which the tool checks offline, inside the MCP server:

<table>
  {% for line in invoice.lines %}
  <tr><td>{{ line.description }}</td><td>{{ line.qty }}</td><td>{{ line.price | money }}</td><td>{{ line.total | money }}</td></tr>
  {% endfor %}
</table>
{% set net = invoice.lines | sum('total') %}
{% set vat = net * invoice.vat_rate / 100 %}
<p>Gesamt {{ (net + vat) | money }}</p>

With the data it was written for, validation reports nothing and the invoice ends in Gesamt 3.760,40 €. Then the agent's versions.

The agent leaves out the line totals, expecting the template to multiply quantity by price. This one does not. validate_template answers:

{
  "ok": true,
  "diagnostics": [
    {
      "severity": "warning",
      "code": "unknown-variable",
      "message": "\"line.total\" is not present in the sample data",
      "line": 3,
      "column": 101
    }
  ]
}

and the rendered invoice ends in Gesamt 0,00 €.

The agent calls the list items, because that reads as well as lines to a model that did not look at the schema. Validation warns five times, once for invoice.lines and once for each field under it, again with "ok": true. The rendered invoice has no lines and totals 0,00 €.

The agent writes the rate as "19 %", the way it appears on the contract it read. The offline check reports nothing: it knows which names the template reads, not what kind of value belongs in them. When we first ran this, the rendered invoice ended in Gesamt NaN. That was a bug in our money helper, and it is fixed: money, number and numToWords now stop the render with money: got NaN, the result of a calculation with a value that is missing or not a number rather than print NaN on a document. Text that is not a number, such as "on request", still prints as it is.

The check that knows the values

An agent rarely brings its own HTML. It fills a template stored in Formfeed, and for a stored template validate_template does not check offline: it asks the API, free and without rendering, to check the version a render would use. That check runs the template once with the data, so the "19 %" above comes back as an error before anything is printed, and it compares the data with the template's stored JSON Schema:

{
  "severity": "error",
  "code": "data-validation",
  "path": "data.invoice.vat_rate",
  "message": "data.invoice.vat_rate: must be number"
}

The schema check needs a stored schema. Every template has one inferred from its sample data, which is what get_template_schema hands the agent, but only a schema you stored decides what counts as wrong — an inferred one would reject data for leaving out a field the sample happened to have. In the editor, Store as contract in the data and schema panel stores one; with the CLI, a schema.json next to the template does. Store one for every template an agent fills.

Two things follow either way. First, ok: true means nothing will fail, not the data is right: missing data is a warning, because a template may deliberately leave optional fields out. An agent should treat every warning as a question to answer before it renders. Second, a check only knows what it has been told. While you set an agent up, connect it with a test key: every render costs nothing, and reading a handful of results checks what no validation can, such as whether the right customer ended up on the invoice.

The offline results above come from a test in the MCP server's own repository, which runs the real tools with a network stub that fails on any request, so it also shows that ad-hoc HTML and its data never leave the machine the server runs on while they are checked: validate-agent-data.spec.ts.

What to tell the agent

The MCP server already tells a connected agent the order: list, read the schema, validate, render. What it cannot know is how strict to be with your documents. A few lines in the agent's instructions close that gap:

Before rendering a document:
1. Read the template's schema and sample data with get_template_schema, and use the same field names.
2. Call validate_template with your data. Fix every diagnostic, warnings included.
3. Numbers are numbers: 19, not "19 %"; 1200.5, not "1.200,50".
4. Before handing a document on, compare its totals with the data you sent.

The model still writes the part that changes. The part that must not change was written by a person, once, and the agent never gets to touch it.

The agents page has the setup for Claude Code, Cursor, VS Code, Codex and a dozen more clients and frameworks, and the MCP documentation lists every tool with its arguments.

Checked on 5 October 2026. The schema check in validate_template needs @formfeed/mcp 0.3.6 or later.

Page breaks in tables: what Chromium honours in 2026

Philipp Staudt — Wed, 30 Sep 2026 08:34:24 +0000

A table that fits on one page is easy. The trouble starts at the page break: a header that does not come back, a row cut through the middle, a total printed under the first thirty rows, a footer lying on top of the last line. Most advice about this was written for browsers that paginated differently, and gets copied forward.

So we measured. We rendered 21 small table documents through our render worker — the same headless Chromium, version 153.0.8010.12, that prints every Formfeed PDF — and read the finished PDFs back with pdf.js to see which page every row, header and total landed on. Every case below links to its PDF.

The starting point

Every Formfeed document starts with a short print reset. Four of its lines are about tables (in effect; the real rules sit in :where() so that any rule of the template wins):

table { break-inside: auto; border-collapse: collapse; }
tr { break-inside: avoid; }
thead { display: table-header-group; }
tfoot { display: table-footer-group; }

The tr line is ours, not Chromium's: without it, Chromium splits a row wherever the page ends. The cases use A4 with 20 mm margins, ten-point text, and a page-number footer from Chromium's footer template unless they say otherwise. Rows are numbered, and a tall row's lines are numbered too (08·5 is the fifth line of row 8), so a split shows.

What Chromium keeps

Case	CSS	What the PDF shows
60 rows	—	the header row repeats at the top of page 2	PDF
rows six lines tall	`tr { break-inside: avoid }`	7 whole rows per page, none split	PDF
the same rows	`tr { break-inside: auto }`	rows 8, 16 and 24 split across pages	PDF
one row of 90 lines	`tr { break-inside: avoid }`	the row starts a new page and then splits anyway; all 90 lines are printed	PDF
groups of six rows, each its own `tbody`	`tbody { break-inside: avoid }`	page 1 ends after row 30, a group boundary, instead of row 32	PDF
a heading at the foot of a page	`h2 { break-after: avoid }`	the heading moves to the next page with its table	PDF
the last row alone on a page	`tbody tr:last-child { break-before: avoid }`	row 8 goes along: 7 rows, then 2	PDF
the last two rows as their own `tbody`	`tbody.tail { break-inside: avoid }`	the same, 7 and 2	PDF
the table inside a flex, grid, `overflow: auto`, `overflow: hidden` or absolutely positioned wrapper	—	paginates like a bare table, header repeated	flex · grid · auto · hidden · absolute

The last row surprised us most, because every one of those wrappers turns up in advice on why a table stopped paginating. In Chromium 153 none of them stops it.

The two keep-together rules are the ones worth having in every template. Without them, the heading stays behind on its own:

and the last row of a table ends up alone on a page of its own:

With break-before: avoid on the last row, Chromium takes the row before it along, so no page holds a single row:

And this is what a tall row looks like when nothing asks Chromium to keep it together — the amount stays on page 1 and the last two lines of the description go to page 2:

Three ways to get it wrong

The total on every page

tfoot looks like the place for a total. But a tfoot is a footer group, and Chromium repeats it at the foot of every page the table reaches, just as it repeats thead at the top. The grand total turns up under row 31 on page 1:

Two fixes. Put the total in a last tbody of its own. Or keep the tfoot and turn it into an ordinary row group, tfoot { display: table-row-group; } — then it prints once, on the last page, as long as it comes after the tbody in the markup. HTML also allows the tfoot before the tbody; with the override, such a total prints above the first row.

The repeat cannot carry a running subtotal either. What Chromium repeats is a copy of the same content, so a "carried forward" line that sums the rows above it on each page is not something a tfoot can do.

A row cut in half

Wrap the table in display: inline-block — a common way to centre it or shrink it to its content — and Chromium stops paginating the table inside. It prints the box across the page edge as it is: row 33 is cut through the middle, and page 2 has no header.

A block wrapper does not do this. thead { display: block; }, which some scrolling-table CSS sets, keeps the rows whole but loses the repeated header.

The row under the footer

A footer made with position: fixed; bottom: 0 does repeat on every page. The table does not know it is there. Row 32 slides underneath, and since the table thinks row 32 fitted, page 2 carries on with row 33 — row 32 is never printed whole:

The clean fix is not to put the footer in the page at all. Chromium's own footer template is printed in the bottom margin, where content never reaches; every other case in this post has one, and none lost a row to it. If the footer has to live in the page, the repeat that caused the first problem solves this one: an empty tfoot row as tall as the footer repeats on every page and keeps the rows clear of it.

<tfoot><tr class="reserve"><td colspan="3"></td></tr></tfoot>

tr.reserve td { height: 10mm; padding: 0; border: 0; }

The short version

Keep rows whole with tr { break-inside: avoid }, and groups of rows with a tbody each and break-inside: avoid.
Keep headings with their table: h2 { break-after: avoid }.
Keep the last row company: tbody tr:last-child { break-before: avoid }.
Put totals in a last tbody, or make the tfoot a table-row-group after the tbody.
No inline-block around a table, no display: block on its thead.
Footers go in the footer template, not in position: fixed.

In Formfeed

The print reset above is on by default and every line of it can be overridden. The Footer tab of the editor is Chromium's footer template, so a footer made there sits in the margin. The editor's paged preview is built to lay out like the PDF, and True render sends the template through the same worker these cases went through. The page-break section of the docs has the reset, and the report example is a two-page document with a chart and a table of monthly figures.

Rendered and measured on 21 September 2026 with Chromium 153.0.8010.12. Chromium's layout changes between versions; we re-run the cases when the worker's Chromium does.