DEV Community: David

Zooming a web editor without losing your place

David — Thu, 05 Nov 2026 11:22:29 +0000

Put your cursor over a small piece of text in an editor and zoom in. You should be able to keep looking at the same text.

It's a small test, but it catches a surprising amount of unfinished zoom behavior. The percentage changes, the document gets bigger, and the detail you wanted to inspect slides somewhere else.

I build Repceipt, a receipt editor that runs in the browser. Receipts have plenty of small text packed into a narrow space. Zooming in on a price or a line of text needs to keep that detail within reach.

The implementation uses DOM elements inside a scaled wrapper. The interesting part is how the scale interacts with coordinates and scrolling.

There are two sets of coordinates to keep straight: positions within the document, and positions on screen. Here, screen coordinates mean CSS pixels relative to the browser viewport.

A block at document position x = 300 stays at x = 300 when you zoom. At 50%, it appears 150 CSS pixels from the document's left edge. At 200%, it appears 600 pixels from that edge.

Keeping those stored coordinates stable means zoom can change the view without rewriting every block.

Our wrapper scales from its top-left corner. Around it, an untransformed frame gets an explicit width of documentWidth * zoom and height of documentHeight * zoom.

That outer frame matters. A CSS transform changes rendering while leaving normal flow layout intact. Transforms can affect overflow, but applying scale() doesn't rewrite the element's layout dimensions. The CSS transforms specification describes that distinction.

The explicit frame gives centering and scrolling a box whose layout dimensions match the displayed document size.

Once that's in place, zooming around the cursor has three steps:

Find the document point currently beneath the cursor.
Apply the new zoom.
Adjust scrolling to put that point back beneath the cursor.

For a document scaled uniformly from the top-left corner, the first calculation is simple:

const documentX = (cursorX - frameLeft) / currentZoom;

Suppose the frame starts at screen position 100, the cursor is at 250, and zoom is 50%. The cursor is over document coordinate 300:

(250 - 100) / 0.5 = 300

Zoom to 100%, keeping the same frame origin, and that point would appear at screen position 400. Scrolling right by 150 brings it back to 250.

In the real editor, the frame origin can change too. A centered document gets wider as you zoom, and its left edge moves. So we measure the frame again after the update.

Here's the geometry from the wheel handler, with the event setup and zoom-limit calculation left out:

import { flushSync } from 'react-dom';

// Inside the handler, after choosing nextZoom:
const before = frame.getBoundingClientRect();
const documentX = (event.clientX - before.left) / currentZoom;
const documentY = (event.clientY - before.top) / currentZoom;

flushSync(() => setZoom(nextZoom));

const after = frame.getBoundingClientRect();
viewport.scrollLeft +=
  after.left + documentX * nextZoom - event.clientX;
viewport.scrollTop +=
  after.top + documentY * nextZoom - event.clientY;

The final two lines calculate where the original document point has landed, compare it with the cursor, and scroll by the difference.

Both measurements use getBoundingClientRect(), which gives viewport-relative positions and accounts for scrolling. That keeps them in the same coordinate system as clientX and clientY.

The order matters. Measuring immediately after requesting a React update can give you the old layout. We use flushSync at this boundary so the second measurement sees the updated DOM. It forces synchronous work and can affect performance, so it's a deliberate choice in this handler.

A toolbar button needs a different anchor. The mouse is over the toolbar when you click it; anchoring there wouldn't help you inspect the document.

Our zoom buttons use the center of the current selection when that center is visible. Otherwise, they use the center of the editing viewport. That lets you select a small label, press the plus button a few times, and keep the label in roughly the same place.

The same coordinate calculation works for each input. What changes is the anchor:

Input	Anchor
Wheel zoom	Cursor position
Two-finger pinch	Point initially beneath the fingers' midpoint
Toolbar zoom	Visible selection center, otherwise viewport center

For a pinch, we save the initial distance between the fingers and the starting zoom. The new zoom is the starting zoom multiplied by the ratio of the current distance to the initial distance.

We also track the midpoint as the fingers move. The document point saved at the start follows that moving midpoint. This lets a pinch zoom and pan together, which feels much closer to moving a piece of paper under your fingers.

There are limits to how precisely an anchor can stay fixed. Scroll containers have boundaries. Zoom out until the document fits inside the viewport and the browser may have no remaining scroll range to compensate. At that point, the layout's centering rules take over.

It's also worth checking that every edge remains reachable when zoomed in. Centering an oversized document inside a fixed-width flex row can leave content overflowing on the left where you can't scroll to it. Our row grows with the document, and auto margins center the frame when there's spare space.

Zoom affects interaction distances too.

Our editor snaps blocks to alignment guides within an eight-pixel screen distance. If that were eight document pixels, the visible snapping distance would shrink to two pixels at 25% zoom and grow to sixteen at 200%.

To keep the visible distance consistent, the threshold passed to the document-coordinate calculations is:

const snapThreshold = 8 / zoom;

At 25%, that's 32 document pixels. At 200%, it's four. Both cover eight pixels on screen.

The same question comes up with drag handles, tap tolerance, and selection outlines: should this measurement grow with the document, or stay comfortable to use on screen?

One of our browser tests checks zoom by recording the document point beneath the fingers, expressed as a fraction of the document's width and height. After pinching, those fractions must remain within one percentage point of their starting values.

That checks something useful about the interaction. A zoom readout changing from 50% to 100% would pass even if the text disappeared off screen.

For a quick manual check, put the cursor over the last digit of a price and zoom in a few times. Then select the price and try the toolbar buttons. You should be able to keep looking at the digit you started with, without needing another gesture to find it.

The hard part of undo is deciding what counts as a change

David — Thu, 05 Nov 2026 09:47:52 +0000

If one drag takes twelve presses of Undo to reverse, the history code probably recorded exactly what it was told to record.

Twelve changes.

The person using the editor remembers moving a block once.

I build Repceipt, a receipt editor that runs in the browser. You can move text around, resize elements, change fonts, and select several blocks at once. Undo has to make sense across all of those interactions.

The stack operations are straightforward. Deciding when to put something on the stack takes more thought.

A snapshot in the editor contains the document and its selection:

type Snapshot = {
  template: Template;
  selectedId: BlockId | null;
  selectedIds: BlockId[];
};

There are arrays for the past and future. An edit saves the current snapshot to the past and clears the future. Undo restores the last past snapshot and puts the current one at the front of the future. Redo moves it back.

This is the familiar approach described in the Redux undo history guide. Our store uses Zustand, but the same structure works there.

Notice what's missing from the snapshot: zoom, the active tool, and whether a panel is open.

Suppose you change some text, zoom in to inspect it, then press Undo. You probably want the old text back while staying zoomed in. Recording every store update would make you undo the zoom first.

Selection is a useful exception. Clicking a block doesn't create a history entry, but selection travels with document snapshots. Delete a selected block, then undo the deletion, and the block comes back selected. You can carry on working without finding it again.

Dragging needs a similar distinction between what appears on screen and what becomes an edit.

In Repceipt, the block follows the pointer through temporary transforms during the gesture. The saved document still contains the starting coordinates. When the drag ends, the temporary styles are cleared and the final movement is committed to the store.

That produces one history entry, however many movement events arrived along the way. A group drag commits the selected blocks together, so Undo moves them all back together too.

You could also update a temporary document throughout the gesture and record its starting state once. The important part is having a clear boundary around the action. You shouldn't have to guess whether a slow drag contains three edits or thirty.

Cancellation needs a boundary as well. On a phone, a second finger can turn a block drag into a pinch to zoom the canvas. Our editor cancels the block drag, restores its temporary transforms, and leaves history alone.

For an editor using pointer events directly, remember that a gesture can end with pointercancel, including when the browser takes over for scrolling or zooming. Decide how to restore the preview on that path, too.

Typing and keyboard nudges are a different case. The document should update as you type, but undoing a label one character at a time gets tedious.

The store groups consecutive updates when they have the same key and arrive less than 400 milliseconds apart. Here's the decision, stripped down:

const coalesce =
  key !== undefined &&
  lastCommit?.key === key &&
  now - lastCommit.at < 400;

The first update saves the starting snapshot. Matching updates keep changing the document without pushing more snapshots. Each update refreshes the timestamp, so the window measures the gap between updates, rather than the total length of the typing session.

The key identifies what is changing. Editing a block's text has a different key from changing its size. Repeated arrow-key nudges use a key based on the selected block IDs.

The number alone wouldn't be enough. Two unrelated edits can easily happen within 400 milliseconds. They still need separate undo steps.

And that number is a product choice. Pause long enough while typing and you'll get another step. A text editor might want word boundaries or explicit editing sessions instead. For these short labels and repeated nudges, a small window keeps the implementation manageable. Drags already have start and end events, so they don't need the timer.

Undo and Redo also reset the grouping marker. Otherwise, a quick edit after Undo could accidentally join the group you just left.

There's another small detail that becomes obvious once you try this sequence:

Move a block.
Undo the move.
Click the block without moving it.
Press Redo.

The move should still be available.

A zero-distance drag exits before committing. Selecting the block doesn't commit either. Both decisions matter because a commit clears the future array. If a click records an unchanged document, it can silently throw away the redo history.

The movement code also checks the final delta after rounding and clamping. A pointer can move while the block ends up in the same place. That's still no change to the document.

Some real document updates should stay out of history, too.

When fonts finish loading, the editor measures text so selection outlines fit the glyphs the browser actually drew. That can update stored geometry. It shouldn't make the receipt appear modified, and Undo shouldn't restore an inaccurate selection outline.

That measurement has its own update path. It leaves history and the modified flag alone. There's a regression test for exactly that behavior: opening a template and measuring its text must leave the undo stack empty.

Snapshots also depend on keeping old objects intact. Our edits create new document and block objects, leaving previous versions available to history. Mutating a shared block would change what an older snapshot points to. React's guide to updating objects in state explains why treating those objects as read-only matters.

We cap history at 80 snapshots. That bounds the number of retained versions; it isn't a guarantee about memory usage, especially if a document contains large assets.

When checking undo behavior, these are the sequences I'd start with:

Drag several blocks, then undo once. Every block should return.
Undo, change selection or zoom, then redo. The edit should still be there.
Undo, make a new document edit, then try Redo. The abandoned edit should be gone.
Start dragging on a phone, then add a second finger to pinch. The block should stay at its original position.
Open a document and wait for its fonts. Undo should remain unavailable until you edit something.

Those sequences say more about how the editor feels than a test that only checks whether an array got shorter.

For each new control, I now want an answer to one question before wiring up its change handler: what should one press of Undo reverse here?

I counted the fonts on 632 receipts. The most popular one is a barcode.

David — Sat, 31 Oct 2026 09:51:40 +0000

I build Repceipt, a receipt editor that runs in the browser. Its template library is made by redrawing real receipts, one element at a time, and each redraw records which typefaces it uses and at what sizes. By August we had 632 of them, which meant we were sitting on a dataset I'd never seen anyone collect: what fonts receipts actually use.

I went in assuming the answer was "one". Some bitmap face burned into every thermal printer on earth, end of story.

It's 24.

This post is the numbers, and then the parts that matter if you ever have to draw a receipt yourself: why they're monospaced, how to fake that in CSS when they aren't, what to do about the barcode, and the four silent bugs between "looks right in the browser" and "looks right in the exported PNG".

First, what this data is and isn't

These are redrawn receipts. Each one rebuilds a real document as closely as possible, so the fonts are the typefaces chosen to reproduce receipts. Where the original came off a printer's built-in bitmap font, the redraw uses the nearest web font. So this tells you what receipt typography looks like and how much it varies. It is not a survey of printer firmware.

We also only measured structure: typeface names, sizes, element types, canvas dimensions. No text contents. Real receipts carry real card digits and addresses, and none of that belongs in a blog post.

The numbers


Receipts measured	632
Distinct typeface families	24
Distinct family combinations	176
Distinct type-size ranges (smallest to largest on one receipt)	545

And the most common families, by share of receipts they appear on:

Typeface	Share of receipts
Libre Barcode 39	35.1%
Thermal Receipt1	31.3%
Arvo	23.9%
Thermal Receipt2	16.1%
Lekton	14.6%
Open Sans	11.1%
Roboto	9.3%
B612 Mono	7.8%

Number one is a font nobody has ever read a word of. Libre Barcode 39's glyphs are barcode bars, and in the source data barcodes are stored as text set in it, so a barcode wins a font ranking.

Third place surprised me more. Arvo is a slab serif, and it's on nearly a quarter of all receipts. My best guess is that its chunky strokes are a decent stand-in for the slightly smeared output of a worn thermal print head.

176 combinations across 632 receipts works out to a new pairing roughly every three and a half receipts. And there are almost as many distinct size ranges as there are receipts. They all look the same from a metre away and differ a lot up close.

One confession: our own data has a typo in it. "Thermal Receipt2" and "ThermalReceipt2" (4.7%, just below the cut) are the same face spelled two ways, so 24 is the count of family strings, and the real number of typefaces is slightly lower. I'd rather show you that than quietly merge it.

Bonus fact while we were measuring: the median receipt is exactly three times as tall as it is wide.

Monospace is the layout engine

A receipt is a two-column table. Item on the left, price on the right. The printer doesn't measure text, and with a fixed-pitch font it doesn't need to: every character is one column, so if every line is the same number of characters, the prices line up on their own.

If you're generating text for an actual receipt printer, that's all your layout code is. Pad strings:

const line = (left, right, cols = 32) =>
  left.slice(0, cols - right.length - 1).padEnd(cols - right.length) + right;

line('FLAT WHITE', '3.80');
// "FLAT WHITE                  3.80"
line('SOURDOUGH LOAF, SLICED, EXTRA LONG NAME', '6.50');
// "SOURDOUGH LOAF, SLICED, EXT 6.50"

The slice matters. Without it, a long item name pushes its price onto the next line and the whole column falls apart, which is exactly what a real receipt does when a POS system gets a product name longer than anyone planned for.

Doing it in CSS when the font isn't monospaced

Here's the bit the data made clear: nearly half the receipts mix in a proportional face. Open Sans, Roboto and Raleway are all in the top dozen. Look at a real receipt and they're in the store name, the header and the "thanks for shopping" footer. The fixed-pitch constraint only applies to the money in the middle.

On a screen you don't have to pad anything. Something like this gets you most of the way:

<div class="receipt">
  <h1 class="store">Corner Bakery</h1>
  <div class="row"><span>Flat white</span><span class="amt">3.80</span></div>
  <div class="row"><span>Croissant</span><span class="amt">2.90</span></div>
  <div class="row"><span>Sourdough loaf</span><span class="amt">6.50</span></div>
  <div class="row total"><span>Total</span><span class="amt">13.20</span></div>
</div>

.receipt {
  width: 32ch; /* ch = the width of "0", so in a monospace font: 32 columns */
  font: 14px/1.3 'Roboto Mono', monospace;
}
.store {
  margin: 0 0 1em;
  font: 700 20px 'Arvo', serif;
  text-align: center;
}
.row {
  display: flex;
  justify-content: space-between;
  gap: 1ch;
}
.amt {
  font-variant-numeric: tabular-nums;
  white-space: nowrap;
}
.total {
  border-top: 1px dashed;
  font-size: 16px;
}

Two things worth knowing. tabular-nums only does anything if the font ships tabular figures (the tnum OpenType feature), so check before you set your prices in some display face and expect the decimals to line up. And notice there are three sizes: store name, body, total. Receipts don't really have a type scale, they have those three tiers, and every design sets them a little differently (hence 545 distinct size ranges).

The barcode: font or SVG?

Since a third of our receipts use a barcode font, it's tempting to just do the same:

<span style="font: 48px 'Libre Barcode 39'">*A-1234*</span>

It works, with two catches. Code 39 needs the asterisks: they're the start and stop characters, and the Libre Barcode docs tell you to wrap your text in them. Leave them off and you get bars that look fine and won't scan. And plain Code 39 is uppercase letters, digits, space and - . $ / + %. Anything else needs the Extended variant or a different symbology.

In the editor we draw barcodes with JsBarcode into an SVG instead, which also gives you Code 128, EAN-13, UPC and friends:

import JsBarcode from 'jsbarcode';

JsBarcode(svgElement, 'A-1234', {
  format: 'CODE39',
  displayValue: false,
  margin: 0,
});

Four silent bugs between the browser and the PNG

Exports are rendered on the server with @napi-rs/canvas, and they have to match what the browser showed pixel for pixel. None of these four throw an error. Your PNG just quietly looks wrong.

1. The name inside the font file isn't the name you use. The two thermal fonts are referenced as "Thermal Receipt1" and "Thermal Receipt2". Ask the files what they're called:

$ fc-scan --format "%{family}\n" ThermalReceipt1.ttf
DotLatin_D31

Register the file without an alias, ask canvas for "Thermal Receipt1", and it falls back to a default font without a word. Pass the name you actually use:

import { GlobalFonts } from '@napi-rs/canvas';

GlobalFonts.registerFromPath('fonts/ThermalReceipt1.ttf', 'Thermal Receipt1');

2. Some fonts name every weight as its own family. This one's my favourite. The regular-weight Source Code Pro file from Fontsource:

$ fc-scan --format "%{family} / %{fullname}\n" source-code-pro-latin-400-normal.woff2
Source Code Pro ExtraLight / Source Code Pro ExtraLight Regular

The regular file says its family is "Source Code Pro ExtraLight". Ask for "Source Code Pro" and nothing matches. Aliasing fixes this too, and the weights survive because each file still carries its weight metadata.

3. letter-spacing adds a gap after the last character as well. In Chromium, abcde in a 20px monospace font measures 60px. Add letter-spacing: 10px and it measures 110px: five gaps, not four. If you measure text yourself, for a canvas renderer or a selection box, and count length - 1 gaps, every spaced line comes out one gap short and right-aligned text drifts. Count length.

4. An SVG and drawImage disagree about stretching. Give an <svg> with a viewBox a box of a different shape and the browser scales it to fit, centred, keeping its aspect ratio (preserveAspectRatio defaults to xMidYMid meet). drawImage into the same box stretches it to fill. Draw it naively and the exported barcode comes out stretched to fill the box. The server has to do the browser's maths:

const scale = Math.min(boxW / img.width, boxH / img.height);
const w = img.width * scale;
const h = img.height * scale;
ctx.drawImage(img, x + (boxW - w) / 2, y + (boxH - h) / 2, w, h);

What I'd tell myself before starting

Use monospace for the columns with money in them, and anything you like for the header and footer.
For a printer, pad strings. For a screen, flexbox and tabular-nums.
Check a font's real family name with fc-scan before you register it on a server.
letter-spacing gaps = number of characters.

The full tables (all twelve top typefaces, element counts and the height-to-width bands) are in the write-up of our 632-receipt typography measurement, and the aggregate figures are free to reuse.