PDF rendering and limits
How PDFs are printed, what the renderer needs, and what it cannot do yet.
The renderer
A headless Chromium, driven by playwright-core, prints the publication's
self-contained HTML. One browser is launched on the first request and reused.
- Each document gets a fresh browser context with JavaScript disabled, and every network request is refused. Authored content therefore cannot make the server fetch a URL.
- At most two documents print at once; others wait. Each has 60 seconds to load and print.
- Pages are A4 with 20 mm top, 18 mm side and bottom margins.
Getting Chromium
- The server image includes Debian's Chromium and sets
OPEND_CHROMIUM_PATH=/usr/bin/chromium. - Outside Docker, install a browser with
pnpm exec playwright-core install chromiumin the OpenD checkout, or pointOPEND_CHROMIUM_PATHat one. - Chromium's own sandbox is off by default, because unprivileged containers usually cannot create the
namespaces it needs.
OPEND_CHROMIUM_SANDBOX=1turns it on where the runtime allows it.
Limits
- The contents list has links but no page numbers: Chromium does not support
target-counter(). Use the PDF outline for page-accurate navigation. - The header and footer also appear on the cover.
- External images (
https:URLs) are not loaded, because the renderer refuses network requests. Keep images in the project. url()references in the theme are not resolved.- The first request for a new release and entitlement set takes a moment, about a second for a small manual. Later requests are served from the cache.