Skip to content

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 chromium in the OpenD checkout, or point OPEND_CHROMIUM_PATH at one.
  • Chromium's own sandbox is off by default, because unprivileged containers usually cannot create the namespaces it needs. OPEND_CHROMIUM_SANDBOX=1 turns 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.