Palatine vs PrinceXML

Prince has been the reference for printing HTML since the early 2000s: publishers, banks and documentation teams use it, directly or through DocRaptor, because it implements the CSS paged-media specifications that browsers ignore. Palatine targets the same documents — books, reports, invoices — with a different design. This page is our honest comparison; it will be wrong in places Prince improves, so check their documentation too.

In short

Same documents, same pages

We test Palatine's paged media against Prince 15.1. Our running-header and footnote corpora — a novel, a report, a dictionary, a 48-page annotated book, footnotes in flex rows, right-to-left notes, pandoc output — are rendered by both engines, and the same checks run on both PDFs: page count, the position of every header, rule and footnote, the text of each margin box.

Most documents agree to the point. The 48-page book has 48 pages in both engines, with the same footnote areas and rules; reports with long, split footnotes match line for line. Where the two differ, it is mostly a choice the specification leaves open:

• Short footnotes near the end of a page. Prince may defer a note to the next page and leave its call behind; Palatine moves the line with its note, so a call and its note stay on the same page. Both are what footnote-policy: auto allows.
• Floats crossing a page break. Prince splits the float; Palatine moves it whole to the next page and fills the space with the text that follows.
• Blank pages. Prince gives a blank parity page the default page style; Palatine gives it the name of the next content page, so @page chapter:blank works.

In one case Prince departs from the specification: string(name, start) on a page that opens with the element. Palatine follows GCPM 3. And there are things Prince does that Palatine renders in a degraded, documented way — a footnote inside a running element, running strings in vertical text: Palatine keeps that content in place and warns.

Typography

Justified text is where the engines feel different. A line-by-line breaker decides each line on its own, then stretches or squeezes its spaces to fill the measure. Prince does this well: in our tests it tightens spaces by up to about 15% when a word almost fits. Palatine adds the alternative of book typesetting: a Knuth–Plass composer that chooses all the breaks of a paragraph together, with bounded word spacing, hyphenation penalties, last-line control and optical margin alignment. For a novel or a magazine column, that is the difference between pages that look typeset and pages that look printed from a browser.

Deployment

Prince is a native program: you install it on a server, a container or a desktop, and call it. Palatine also ships as a WebAssembly module, the same engine compiled for any JavaScript runtime. A PDF can be produced inside a Cloudflare Worker or the user's own browser tab, without a rendering service and without the document leaving the machine. On our benchmark server, a 106-page book renders in under 0.8 s in WebAssembly, an invoice in 74 ms with the native build.

For an expanding server fleet, we strongly recommend against a per-machine Prince deployment on cost grounds: one license covers one machine, so licensing grows with your fleet. Palatine covers the entire company with one license per build. See the volume cost comparison.

Which one to pick

• Choose Prince if your documents rely on JavaScript, if you need tagged or archival PDF (PDF/UA, PDF/A), or if you need Windows or macOS binaries today.
• Choose Palatine if you typeset long-form text and care about justification, if you want to render in the browser, at the edge or in serverless functions, or if you want SVG and WebP from the same layout.

The quickest way to decide is to try your own documents: the API costs €5 a month + €0.005 per document, regardless of page count.

All articles