The Browser as Typesetter: Printing With the Wrong Tool on Purpose

Two Notes From The Same Evening

On the 5th of March 2026, somebody sketched out a small factory. Take data and images, hand them to a language model, get back a page of hypertext markup, run it through a pagination library, and have a headless browser turn the result into a print-ready file. A big model writes the first version, a small cheap model does the tweaking, and the whole thing sits behind an interface on a server. The note gave it a name: Sättaren. The typesetter. The old Swedish word for the person who set the type.

A few notes later the same evening, a related and much broader question.

Are there any tools similar to Canva or InDesign, where you can design and move things around, adapt, change fonts, everything you need to make a nice looking design, but the tool is programmable?

Those 2 notes are the same question asked from opposite ends. One asks how to build a specific pipeline. The other asks whether the category exists at all. And the answer to the second one is genuinely strange, because the thing being asked for was invented 3 decades ago by a man who then spent the rest of his career watching browsers refuse to implement it.

The Man Who Wrote The Stylesheet

In the mid-1990s, the web had a formatting problem, which is a polite way of saying it had no formatting at all beyond what individual browser makers felt like doing. A Norwegian working at the physics laboratory where the web had been born proposed a solution: separate the content from its presentation, and describe the presentation in a small, cascading language of its own. That proposal became Cascading Style Sheets, and the Norwegian was Håkon Wium Lie.

The part of the story that gets left out of the standard telling is what he wanted it for. From very early on, the ambition was not only screens. A language that could describe how a document should look ought to be able to describe how a document should look on paper, and paper has requirements that a scrolling screen simply does not have. Paper has pages. Pages have edges. Content that does not fit must break somewhere, and where it breaks matters enormously. A heading stranded alone at the bottom of a page is a defect. A single line of a paragraph carried over to the next page is a defect with its own name.

So the specifications grew a section about paged media, and that section is remarkable if you read it now. It describes running headers that pull their text from whatever chapter you happen to be in. It describes footnotes that reflow correctly when the content above them moves. It describes cross-references that resolve to actual page numbers, so a line saying "see page 47" knows it says 47. It describes margin boxes, named page templates, and multi-column layouts where the columns balance.

That is a description of a typesetting system. It was written into the standards for the web. And then the browsers, almost entirely, did not build it.

Why The Browsers Said No

The reason is not conspiracy, and it is worth stating fairly, because it explains the shape of everything that came after.

A browser's job is to render a document of unknown length into a window of known width and unlimited height. Scrolling makes the hard problem disappear. There is no page, so nothing has to break, so no decision about where to break ever has to be made. Every one of the paged media features costs real engineering, benefits a small fraction of users, and has to be maintained forever against a rendering engine that changes constantly for other reasons.

Printing from a browser was therefore treated as a courtesy feature. It works, in the sense that you get paper with your content on it. Nobody at any browser vendor was ever going to be promoted for making footnotes reflow correctly.

Which left a gap of exactly the shape that a business fits into.

Prince, And The Chairman

In 2003, a small company began selling a program that read hypertext and stylesheets and produced print-quality documents, implementing the paged media specification properly rather than treating it as an afterthought. It was and remains commercial software, priced in the range where individuals wince and publishers do not, with comparable engines from other vendors sitting in the same bracket, running from roughly 2 thousand to 7 thousand dollars a year depending on what you need.

And its chairman, decades after writing the original stylesheet proposal, is Håkon Wium Lie.

There is something almost novelistic about that. The man invents a language for describing documents, writes into it the ability to make books, watches the browser industry decline to implement that part for 20 years, and ends up chairing the company that implements it properly and sells it to publishers. The web took his idea and used half of it. He built a business on the half that was left on the floor.

The commercial engines remain the best tools for the job, and any honest account has to say so. If your output is a book, a manual, a scientific paper, or a catalogue that needs footnotes and cross-references and page-number resolution and proper print colour output, the paid engines have the widest specification coverage and they are worth the licence. That is not marketing. That is what the comparisons keep finding.

But most people do not have a licence, and most people do have a browser.

The Polyfill

The workaround that grew up in the open is a library that does something slightly outrageous. Rather than asking the browser to implement pagination, it implements pagination inside the page, in the browser, at runtime.

You load your document. The library runs, measures everything, and cuts the content into page-sized pieces, rebuilding the document as a sequence of explicit page containers with headers and margins and numbered footers, all of it constructed live in the document structure. Then a headless browser prints that, and because the pages are now real elements rather than a formatting request, the output comes out paginated correctly.

It is a polyfill in the original sense: filling a gap in the platform with code that runs on top of the platform. It is actively maintained, and it is used by university presses, scientific publishers, and design studios who need book-shaped output without a commercial licence.

The cost is honest and worth knowing before committing. Because the pagination happens in JavaScript inside the page being rendered, it adds somewhere between 2 and 10 seconds to every render, and it makes debugging considerably harder, because the thing you are looking at in the developer tools is not the document you wrote. It is a document the library built out of yours. When a page breaks in the wrong place, you are debugging a transformation, not a stylesheet.

For a book, 10 seconds is nothing. For an invoice, it is absurd, and using this library for invoices is a genuine case of the battleship in the canal.

The Cost Of Bringing A Browser To The Job

The other half of that pipeline is the headless browser, and it deserves a clear-eyed look because it is the single heaviest component in most document systems.

Driving a real browser gives you everything a browser can do. Every modern layout feature, every stylesheet trick, web fonts, charts drawn by scripts, dynamic content assembled at load time, and pixel-for-pixel agreement with what you see in your own browser window. Nothing else offers that, and for anything where a designer will compare the printed output to a screen mockup, it is close to non-negotiable.

The bill is substantial. Comparisons in 2026 put browser-engine tools at something like 6 to 11 times the processor and memory cost of a lightweight document library. Under concurrent load you are looking at roughly 85 to 200 megabytes of memory per conversion. The container images run to 1.5 or 2 gigabytes. And in any environment where the process is not kept warm, cold starts run 5 to 15 seconds before a single page is rendered.

That last number is the one that decides architecture. A browser that stays running and takes jobs is fast, with benchmarks putting warm renders 15 to 75 times quicker than the lightweight alternative. A browser that starts fresh for every job is slow and expensive. So the moment you choose this path, you have chosen to keep a browser alive on your server permanently, which is a service to monitor, restart, and update, forever.

The Engine That Skips The Browser Entirely

There is a third option that sits between the paid engine and the browser, and it is the one most people underuse.

There exists a pure library implementation of the paged media specification that does not involve a browser at all. It parses the markup, applies the stylesheets, hands the text to a proper text-shaping engine, and writes the document out directly. There is no browser, no JavaScript engine, no page in any interactive sense. You get exactly what your markup and stylesheets describe, and nothing else, because nothing else is running.

The consequences of that design show up clearly in measurements. The output files are dramatically smaller: on the same test document, roughly 21 kilobytes against 125 kilobytes from the browser path, and a simple document coming in around 8 kilobytes. The dependency footprint is a fraction of the 300 or so megabytes of browser that the other route ships.

The trade-off is equally clear. It cannot run your scripts, so anything that assembles itself at load time will come out empty. And there is no warm mode: every call spins up a fresh render cycle through its text and drawing libraries, because that is an architectural decision rather than a missing feature. So it is slower per render than a warm browser, while being far cheaper to keep alive when idle, which for a server that produces documents in bursts a few times a week is very often the better trade.

The practical pattern that keeps appearing in production setups is to run both. The light engine handles the high-volume, simple, script-free documents where cost matters. The browser handles the ones with charts and modern layout and a designer's expectations attached.

The Dead Tool Still Running Everywhere

One warning belongs in any discussion of this area, because the tool in question is still embedded in an enormous number of working systems.

For over a decade, the default answer to "how do I turn a web page into a document" was a small command-line utility built on an old browser engine. It was easy, it was everywhere, and it worked well enough that thousands of production systems still call it today.

It was archived in January 2023. There are no active maintainers. There are known unpatched security vulnerabilities. There are no builds for modern processor architectures on either major platform. And the browser engine underneath it is years behind on standards, so it fails on grid layouts, on stylesheet variables, and on many of the page rules that the whole exercise depends on.

Anyone whose invoices or reports are being produced by something installed 5 years ago and never thought about since should go and check which tool is doing it. This is exactly the kind of forgotten component that costs nothing until the day it costs everything.

What The Broader Question Was Really Asking

Now back to the second note, the one asking whether a programmable design tool exists.

The honest answer is that the browser is that tool, and has been for years, and almost nobody thinks of it that way because it arrives disguised as something else.

Consider what a page layout program actually gives you. A canvas of fixed dimensions. Objects placed on it with precise coordinates. Typography with real control over spacing and hyphenation. Reusable master pages. Styles applied by name so that changing one definition changes 200 headings. Text that flows from one container into the next. And output suitable for a printing press.

A modern browser with a good stylesheet does every one of those. Fixed page dimensions, absolute placement, grid systems, named styles, and with the pagination polyfill, flowing text across generated pages. What it does not give you is the direct-manipulation part: the ability to grab a box with a mouse and drag it 3 millimetres to the left.

And that is the real content of the question, once you strip the tool names off it. The gap is not rendering. Rendering is solved several times over. The gap is iteration. In a visual program, you see the result while you change it, and your hand and your eye are in the same loop. In a code-driven pipeline, you change a value, wait for a render, look at a file, and change it again, and every loop costs 10 seconds and a small amount of attention.

Which means the highest-value part of a pipeline like the one in the first note is not the model that writes the markup, and it is not the engine that renders it. It is the preview. Something that watches the source, re-renders on every save, and shows the current page next to the code. That single piece of infrastructure is the difference between a system that gets used and a system that gets abandoned after 3 documents. And it is far less work than any of the rendering questions, which is why it usually gets built last, if at all.

Where The Model Actually Belongs

The idea in the first note was that a large model writes the document and a small cheap model does the adjustments. That division deserves a second look, because it is the wrong axis.

Models are excellent at producing structure and content. Given data, they will produce a well-formed document with sensible headings and a reasonable hierarchy, and they will do it quickly. Models are considerably worse at fine visual judgement, because they cannot see the result, and a model iterating blind on a stylesheet is a slow random walk with occasional confident regressions.

The stable division is not big model versus small model. It is content versus template. The template should be written once, by a person, with real care, and then frozen: page size, margins, type scale, colour, the whole grammar of how the thing looks. That is a day of work and it lasts for years. The model then only ever produces content that flows into it. It never touches the stylesheet.

The moment a model is allowed to write layout, every document becomes a slightly different document, and you have lost the one thing that makes a publication look like a publication, which is that all of it looks the same. A house style is not a constraint on the design. It is the design.

The Detail That Bites Newspaper People

One last practical matter, and it matters more here than in most contexts.

Browser output is designed for screens. The colour model is the one screens use, and colour management through the print path is limited. Commercial print production, the kind where a press produces thousands of copies, generally wants a different colour model and often a specific certified document standard that guarantees fonts are embedded, colour is defined, and nothing unpredictable happens on the imposition machine. That standard is one of the things the paid engines support and the browser path does not, at least not natively.

For a screen document, a downloadable sheet, a poster on a village noticeboard, or a file someone prints on an office machine, none of this matters at all and the browser path is entirely fine. For a job going to a commercial press, it is the first thing to check with the printer rather than the last, because discovering it at the proof stage is expensive and discovering it after the run is worse.

Which gives the pipeline in the note a clean shape. The browser path for everything internal and everything digital, where speed of iteration is what matters and the output is looked at on a screen or run off on a laser printer. The lighter engine for high-volume repetitive documents where a browser is silly. And a real conversation with the printer before anything from either path goes near a press.

The typesetter, in other words, gets to set almost everything. Just not the front page, not yet, and not without asking.