Dev.to WebDev 🛠 Dev 👁 0 📖 3 min read

Building PosterTiler: The Geometry Behind Printing One Image on Multiple Pages

Turning an image into a wall-sized poster sounds like a straightforward canvas task: split it into rectangles and export a PDF. The difficult part is making those rectangles assemble into the physical size the user expec

Building PosterTiler: The Geometry Behind Printing One Image on Multiple Pages

Turning an image into a wall-sized poster sounds like a straightforward canvas task: split it into rectangles and export a PDF. The difficult part is making those rectangles assemble into the physical size the user expects.

I'm working on PosterTiler, a browser-based tool for printing an image across ordinary sheets of paper. Here are a few implementation details that matter more than they first appear to.

PosterTiler controls and four-sheet layout with printed labels off

An example with labels off: four A4 sheets, 5 mm margins and 10 mm overlap produce a 39.0 x 56.4 cm image area. The label-enabled example below reserves additional space.

1. Start with millimetres, not preview pixels

A zoomed preview is a view of the print plan, not the print plan itself. Keep paper dimensions, margins, overlap and the finished size in physical units. Convert to PDF points at the export boundary:

const mmToPoints = mm => mm * 72 / 25.4;

Changing preview zoom must not change the exported poster size. The preview and PDF export should consume the same geometry model rather than independently calculating their own tile positions.

2. Four A4 sheets do not make a 420 x 594 mm image

That is the combined paper footprint of a 2-by-2 portrait grid, before trimming and assembly. It is not necessarily the finished image area.

Consider this specific setup:

  • A4 portrait paper: 210 x 297 mm
  • Printer margins: 5 mm on each edge
  • A removable label band: 5 mm per sheet
  • Repeated-image overlap: 10 mm at each join

The image area on one sheet is:

width  = 210 - 5 - 5     = 200 mm
height = 297 - 5 - 5 - 5 = 282 mm

For a continuous poster, adjacent sheets share the overlap. That region is counted once in the assembled image:

finishedWidth  = columns * imageWidth
                 - (columns - 1) * overlap

finishedHeight = rows * imageHeight
                 - (rows - 1) * overlap

With two columns and two rows, the finished size is 390 x 554 mm, or 39.0 x 55.4 cm. The label band explains why this example differs from a layout without printed labels.

Exported assembly map showing the A1, A2, B1 and B2 sheet positions for a 390 x 564 mm layout

The exported assembly map for the no-label variant is 390 x 564 mm. Enabling the 5 mm label band on each sheet reduces the two-row height to 554 mm. Keep the chosen label setting consistent when comparing dimensions.

This calculation is worth exposing beside the controls. A preview can look convincing while hiding a physical-size mistake.

3. Margins, overlap and gaps need separate meanings

These settings can all look like spacing on a screen, but they do different jobs:

  • Printer margins reserve edges the printer may not be able to print.
  • Overlap repeats a strip of the image to help align neighbouring sheets.
  • Panel gaps deliberately leave space between trimmed panels in a decorative grid.

For a continuous poster, overlap reduces the assembled dimensions relative to the sum of the image areas. For a spaced grid, gaps increase the displayed dimensions. Treating both as a generic padding value produces the wrong result.

4. Fit and Fill must preserve proportions

Fit keeps the whole source image and may leave unused space. Fill covers the target area and crops the excess. Neither should stretch the image.

Use the same source image to demonstrate both modes. Otherwise, users have to separate a layout difference from a content difference before they can make a decision.

An actual exported poster sheet showing part of the mountain artwork

One exported sheet contains a crop of the source artwork. The assembly map tells you where that crop belongs in the finished poster.

5. Local processing still has limits

The free local poster export runs in the browser without an account or uploading the source file for conversion. Optional cloud processing and AI tools are separate features.

Keeping conversion local does not make memory unlimited. Compressed file size, decoded pixel count and output sheet count are different constraints. A small compressed file can still expand into a large image in memory.

Give users actionable limits and error messages before starting expensive work, and avoid promising that every device can handle the largest allowed job.

6. Test the print instructions too

Useful checks include asymmetric margins, zero overlap, landscape paper, label bands on and off, and exact dimensions near a sheet-count boundary.

The final printing instruction also matters: use Actual Size / 100%, with the PDF paper size matched to the printer settings. A print dialog that scales the PDF can undo otherwise correct geometry. A calibration sheet gives users something measurable before they commit to the full poster.

If you want to explore the dimensions without selecting an image, the poster size calculator shows how paper, margins and overlap affect the result.

For developers building browser-based document tools: which has been harder in your experience, keeping the geometry consistent or explaining the print settings clearly?

Disclosure: I work on PosterTiler. This post was written by an AI assistant on my behalf, using the project's current geometry implementation.

📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.