Generating print-ready A4 PDFs in the browser (and the Safari bug that blanked my images)

Paw Alarm — Tue, 06 Oct 2026 09:33:35 +0000

Building a Print-Ready Lost Pet Poster Generator in the Browser

PawAlarm is a lost-pet alert service I’m building. When a dog or cat goes missing, PawAlarm turns the owner's alert into geo-targeted Facebook and Instagram ads shown to people around the area where the pet was last seen.

One of the free tools inside PawAlarm is much simpler: a lost-pet poster generator. You enter the pet's name, upload a photo, add a description and the last-seen area, and get a print-ready A4 PDF containing a QR code. There’s no account required. I built it because when a pet goes missing, people shouldn't have to fight with Canva or Word before they can start putting posters up.

There were a few constraints that made this more interesting than simply putting some HTML on a page: it needed to work well on phones, produce something that looks good from an ordinary home printer, support 9 languages across 13 locales, and generate the final PDF entirely in the browser.

Architecture

PawAlarm uses Next.js with the App Router and next-intl. Locale-prefixed routes live under app/[locale], while the poster wizard itself lives in components/start.

The actual poster is a React component, poster-artwork.tsx. Rather than treating it like a normal responsive UI, I lay it out as a fixed A4-sized canvas in pixels. The browser ultimately has to rasterize the DOM anyway, so working in a fixed pixel coordinate system makes positioning and fitting predictable. The physical A4 dimensions only really matter at the final PDF step, where the rendered image is mapped onto a 210 × 297 mm page.

The generation pipeline is roughly:

Poster form
    ↓
React poster DOM
    ↓
html-to-image canvas
    ↓
Composite canvas
    ↓
JPEG
    ↓
jsPDF
    ↓
A4 PDF

Keeping the poster itself as React/HTML was useful because the preview and final document could share essentially the same rendering logic. The difficult part was making sure that what looked correct in the browser survived the trip from DOM to canvas to PDF.

Fitting Text in 9 Languages

A fixed-size poster and translated text are not particularly good friends.

A heading that fits comfortably in English might be substantially longer in German or Finnish. Pet names are another variable I can't control. Something like MAX is trivial; a name like CHARLIE-BROWN can suddenly push a heading outside the space that was designed for it. Addresses are even less predictable once street names and locality information are included.

The design can't simply grow vertically because the output still needs to fit exactly onto one A4 page.

The solution is deliberately simple. Elements that need fitting get data-fit attributes, and before generating the poster I run a fitting pass that progressively reduces their font size until their content fits.

The core idea in resolveFitSize() in poster-fit.ts is essentially:

function resolveFitSize(
  element: HTMLElement,
  startSize: number,
  minSize: number
) {
  let size = startSize;

  while (size > minSize) {
    element.style.fontSize = `${size}px`;

    if (
      element.scrollWidth <= element.clientWidth &&
      element.scrollHeight <= element.clientHeight
    ) {
      break;
    }

    size -= 1;
  }

  return size;
}

There are two slightly different cases.

Some elements, such as headings and pet names, need width fitting. They're kept on one line and reduced until scrollWidth <= clientWidth.

Other elements, particularly addresses, need box fitting. They can wrap, but the resulting text still needs to stay within both the available width and height.

A good example of the problem was a last-seen location such as:

Winterthurerstrasse 537, 8051 Zürich

At the normal font size, a string like that could wrap awkwardly or push outside the allocated area. After the fitting pass, the font size is reduced just enough to preserve the layout without making every address unnecessarily small.

I considered handling this entirely with CSS using clamp(), responsive units or container queries. The problem is that those techniques react to the size of the container, not necessarily to whether an arbitrary piece of rendered text actually fits inside it.

Here I care about the final rendered dimensions. Measuring scrollWidth, scrollHeight, clientWidth and clientHeight gives me a boring but deterministic answer: does this exact text, using this exact font and translation, fit?

For a document that's about to become a PDF, that predictability is more useful than having a particularly elegant CSS solution.

Generating the QR Code

Every finished poster includes a QR code pointing to the corresponding lost-pet case.

The QR itself is generated with the qrcode package:

const { toDataURL } = await import("qrcode");

const qr = await toDataURL(url, {
  width: 560,
  margin: 1,
});

The import is dynamic because QR generation isn't needed for the initial application bundle.

There's also an important distinction between the preview and the downloaded poster.

The preview displays a placeholder QR code. The real case URL is created immediately before the PDF is downloaded, and the QR code in the exported poster is generated from that URL.

That prevents an important class of bug: generating a nice-looking poster whose QR code points to placeholder or stale content.

I kept the QR code comfortably larger than the theoretical minimum rather than trying to save a few millimetres of space. On an A4 poster it ends up at roughly 30–35 mm square, which gives it plenty of margin for normal home-printer quality and for posters that aren't perfectly flat when someone scans them.

I tested scanning from both iPhone and Android devices using their normal camera apps. The important test wasn't whether it scanned from a pristine PDF on a monitor, but whether it remained easy to scan after being printed on ordinary A4 paper.

For error correction I use the library's normal QR generation behaviour rather than pushing the density unnecessarily high. The URL is relatively short, and keeping the resulting QR visually simple helps scanning.

DOM to PDF, Entirely in the Browser

There is no server-side PDF renderer involved.

For the final export, html-to-image renders the poster DOM to a canvas using a pixel ratio of 3. That canvas is exported as a JPEG at 0.95 quality and then placed into a PDF using jsPDF.

Conceptually, the final step looks like this:

const canvas = await toCanvas(element, {
  pixelRatio: 3,
});

const image = canvas.toDataURL("image/jpeg", 0.95);

const pdf = new jsPDF({
  orientation: "portrait",
  unit: "mm",
  format: "a4",
});

pdf.addImage(image, "JPEG", 0, 0, 210, 297);
pdf.save("lost-pet-poster.pdf");

The advantage is that everything happens locally in the browser. There's no PDF-generation endpoint to maintain and no need to send the rendered poster to another service just to turn it into a PDF.

The main compromise is that the resulting poster is rasterised. The text isn't real vector PDF text anymore, so resolution matters. Rendering at pixelRatio: 3 gives the raster enough detail for A4 printing without producing unnecessarily enormous files.

In practice the PDFs are usually around the low single-digit megabyte range, depending mostly on the uploaded pet photo. That's larger than a carefully constructed vector PDF would be, but still perfectly reasonable for something the user downloads once and prints.

More importantly, printed text, photos and the QR code remain sharp enough on a normal home printer. I didn't see much value in chasing professional prepress quality for a document whose actual destination is usually a home printer, notice board, shop window or lamppost.

The Safari/WebKit `foreignObject` Bug

This was probably the strangest problem in the implementation.

The poster looked correct in Chrome. On iOS, however, generated posters could contain all of the text while the pet photo and QR code were simply blank.

That immediately made the bug confusing because the DOM itself was correct. The poster looked fine on screen. It was specifically the rasterized output that was broken.

The underlying problem was the way html-to-image renders DOM content. Part of the process goes through an SVG <foreignObject>. WebKit could render the HTML inside it while failing to reliably paint the raster <img> elements.

That meant the poster couldn't simply be snapshotted as one DOM tree.

The workaround was to treat images separately.

Before taking the snapshot, I measure every image that needs special handling and preserve its position, dimensions, rotation and border radius. I then generate a transparent snapshot without relying on those images being correctly rasterised by WebKit.

The final canvas is built in layers:

white A4 background
        ↓
"under" images
(pet photo)
        ↓
DOM snapshot
(text + artwork)
        ↓
"over" images
(QR code)
        ↓
final canvas

The relevant part of elementToA4Pdf is conceptually:

const rect = element.getBoundingClientRect();

const images = [...element.querySelectorAll("img")].map((img) => {
  const imageRect = img.getBoundingClientRect();
  const style = getComputedStyle(img);

  return {
    img,
    x: imageRect.left - rect.left,
    y: imageRect.top - rect.top,
    width: imageRect.width,
    height: imageRect.height,
    borderRadius: style.borderRadius,
    transform: style.transform,
    layer: img.dataset.pdfLayer ?? "under",
  };
});

// Capture the DOM separately from the raster images.
const snapshot = await toCanvas(element, {
  pixelRatio: 3,
  backgroundColor: "transparent",
  filter: (node) => !(node instanceof HTMLImageElement),
});

const output = document.createElement("canvas");
output.width = snapshot.width;
output.height = snapshot.height;

const ctx = output.getContext("2d")!;

// 1. White page
ctx.fillStyle = "#fff";
ctx.fillRect(0, 0, output.width, output.height);

// 2. Pet photo and other background images
drawImages(ctx, images.filter((img) => img.layer === "under"));

// 3. DOM/text snapshot
ctx.drawImage(snapshot, 0, 0);

// 4. QR and foreground images
drawImages(ctx, images.filter((img) => img.layer === "over"));

The real implementation has more bookkeeping around scaling, transforms and clipping, but that's the important part of the workaround.

The distinction between under and over images matters. The pet photograph belongs behind parts of the poster artwork, while the QR code needs to remain cleanly visible above it.

Finding the problem took longer than implementing the eventual fix. I initially treated it like an image-loading or CORS problem because missing images in a canvas export usually point in that direction. Once it became clear that the same DOM and image URLs worked in Chromium but failed specifically during the WebKit snapshot, I could isolate the foreignObject rendering path.

The fix itself was fairly straightforward after that. Isolating the browser-specific rendering behaviour was the time-consuming part.

I now treat iOS Safari as a separate target for this feature rather than assuming that a successful Chrome export proves the PDF pipeline works. Whenever the poster rendering changes materially, I generate an actual PDF on an iPhone and check the image, text and QR output.

Testing

There are three main test files around the poster flow:

poster-fit.test.ts
poster-pdf.test.ts
poster-show-step.locales.test.tsx

poster-fit.test.ts covers the text-fitting behaviour: whether overflowing elements step down correctly, whether the minimum font size is respected, and whether width-only and box-fitting elements use the appropriate dimensions.

poster-pdf.test.ts focuses on the export pipeline. It verifies the expected A4 dimensions and generation options, and covers the image-layer behaviour that prevents the Safari issue from being accidentally reintroduced.

poster-show-step.locales.test.tsx renders the poster flow across the supported locales. This is useful because localization isn't just a translation concern here. A translation can be semantically perfect and still break a fixed physical layout.

The automated tests catch the deterministic parts, but I still use manual visual checks for the final output. The poster is tested in Chromium and Safari, including an actual iPhone, and periodically printed on A4 paper.

That last check is important. Browser screenshots don't tell you whether the smallest text is comfortable to read on paper, whether the photo has enough contrast after printing, or whether someone can point their phone at the QR code from a realistic distance.

For something designed to end up on paper, the printer is ultimately part of the test environment.

What I'd Do Differently

The biggest architectural question is raster versus vector output.

Generating the entire poster as an image makes browser rendering relatively straightforward, but a proper vector PDF would give sharper typography and potentially smaller files. It would also avoid depending quite so heavily on browser-specific DOM rasterisation behaviour.

If I were building a substantially more complicated poster system, I'd seriously consider generating the PDF directly rather than converting HTML into an image first.

That said, HTML has one major advantage: the poster is just another React component. Styling it, previewing it and iterating on the design is much faster than working with low-level PDF drawing primitives.

Server-side rendering is another trade-off. A server-controlled browser or PDF renderer would give much more deterministic output across devices. But it would also introduce an entire rendering service for what is currently a completely client-side feature.

For this use case, I'd probably still keep generation on the client. The Safari workaround is ugly, but the operational simplicity is worth quite a lot.

The other thing I'd think about earlier is the physical environment in which the poster will be used.

A lost-pet poster isn't a webpage printed onto paper. Someone might see it from several metres away, in poor light, through a shop window, or while walking past it. The pet photo, name and basic call to action matter much more than squeezing another paragraph of information onto the page.

That affects accessibility too. Contrast, type size, hierarchy and QR-code placement aren't just visual design decisions when the final interface is a sheet of paper hanging outdoors.

That was probably the main lesson from building this feature: generating a PDF is easy. Generating one from arbitrary user content, in multiple languages, across browsers, that still looks right after someone sticks it to a lamppost is where most of the engineering ended up.

PawAlarm, the lost-pet alert service I'm building, is at https://www.pawalarm.com/en – the poster generator is one free feature of it. Disclosure: the alert service itself is paid.

DEV Community: Paw Alarm