One layout engine for the phone and the browser: how we made label printing come out the same everywhere

Вера Саенко — Sun, 25 Oct 2026 18:19:05 +0000

Disclosure. I work on ChZ Scanner, an Android app and a web workspace for Russia's product marking system. This post is about one engineering problem we hit while building it; the app is linked at the end.

The problem

Our users print labels with a DataMatrix code, a product name, dates and a counter. They print from a React Native app (to a Zebra printer over ZPL, or to PDF) and from a web page (to the browser's print dialog). A user designs the layout in the app and expects every printout to look exactly like the preview. For weeks they did not: the same layout came out different on the phone and on the website, and sometimes different from the preview itself.

What was wrong

Two layout implementations. The site had a simplified label builder; the app had the real one. Anything the simplified one did not know (a name, dates, side-by-side text) silently disappeared.
Data-dependent layout. The layout engine chose between "text beside the code" and "text below the code" by picking the largest code that fit. When a label had no product name or dates, a different layout won, so the printout changed shape depending on what data happened to be present.
Printer rounding. A 203 dpi printer prints a module as a whole number of dots, so a DataMatrix of 36 modules jumps in steps of about 4.5 mm. The preview used the exact size; the printer rounded down.

What we did

One engine, two targets. The layout code is plain TypeScript with no React Native imports. We bundle the same source for the browser with esbuild into a single file and load it on the web page, shimming the barcode library that the page already ships. The page's strict Content-Security-Policy (no inline styles) shaped the output: labels are rendered as SVG paths built from the same primitives the PDF and ZPL generators use, never as styled DOM.
Decide the layout from the template, not from the data. Missing fields are replaced with samples only to choose the shape and the code size; then the real, possibly shorter, data is rendered in that shape. A label without a product name now looks like the preview with the name line left empty.
Round like the printer. The preview now has a second mode that snaps module size to the printer's dots (to the nearest dot, not down) and warns when the printed code differs from the PDF.
Tests that compare outputs. A test builds a page with the app code, builds the same page with the bundled browser code and asserts that the path data is identical.

Lessons

A "simplified web version" of a layout is a bug waiting to happen. Share the code, even if it needs a build step.
Layout that depends on data is acceptable only if the choice is made from the template. Otherwise users see "random" changes.
Test the printer, not just the preview: quantisation is invisible on a screen.

About the app

ChZ Scanner turns a smartphone into a working tool for Russia's "Chestny Znak" marking: batch scanning with code status checks, aggregation, documents, and label printing. It is a third-party app, free during early access.