One engine, editor and output

A template is only useful if the documents made from it look as it did when it was designed. A headline that fits on one line in the editor must fit on one line in the thousandth PDF the API makes from it. Paprika is built around that promise.

One layout, decided once

Many tools lay a design out twice: once in the editor, with the browser’s text engine, and again when exporting, with another. Two engines break lines a little differently, so text that fitted in the editor overflows in the PDF.

Paprika lays out a page once, with its own layout engine, the same code in the editor and on the server. Layout decides everything about where things go: which words go on which line, where each glyph sits, how far each frame grows, where anchored frames move to, how an image is cropped. Its result is a display list: every glyph run, shape, line and image of the page, fully positioned.

The editor’s canvas draws that list, and so does the PDF writer, and so do the image outputs. None of them moves, wraps or resizes anything: they only draw what layout decided. So a new kind of output is a new way of drawing the same list, never a second layout.

The same code, to the last bit

The editor runs in your browser and the API on a server, yet they agree exactly, not approximately. Both run the same JavaScript and the same WebAssembly build of the text shaper (HarfBuzz) on the same kind of JavaScript engine (V8, in Chrome and Edge, and in Node.js on the server). WebAssembly arithmetic is deterministic, JavaScript’s is standard floating point, and the few trigonometric functions rotation needs are V8’s own: the same inputs give the same numbers on both sides.

That is why Paprika’s server renders in Node.js and not in another language: a second implementation would round differently in places, and agreement would become a tolerance.

Checked, not assumed

The editor can ask the server to lay the template out again and compare the two results: every item that would be drawn, every error and every warning. They must be identical. Paprika’s own tests do the same on every change, and a difference is treated as a bug to fix, never a tolerance to widen.

What a template can’t do

The same principle sets some limits. Everything must be decided by layout from the template and its values alone, so a template can’t depend on what the viewer’s computer has: fonts are always embedded from the template or the organisation’s library, never taken from the system, and images are always files in the template or the organisation’s storage, never addresses on the internet. See what Paprika doesn’t do yet.