Symptom
QR codes printed on die-cut tape have no usable quiet zone on one edge, which makes them unreliable to scan.
Correction (2026-07-30). This issue originally carried a table of per-label scan results ("this payload decoded, these two did not"), gathered by photographing the tape with a webcam. That evidence has been withdrawn: the camera was serving frames from a stale V4L2 buffer queue (see impuls42/cam2mcp#1), so a given photo cannot be attributed to a given label with any confidence, and a "no decode" may simply have been an older frame. The measurement below does not depend on the camera and stands on its own.
The measurable defect
The layout leaves almost no margin on the right. Measured directly on the render — no camera involved — for a QR plus one line of text at 12.012 × 30 mm, which is the geometry the agent produces on 15 mm tape with the 96-dot head:
render 240x96px, ink spans x=16..234
left margin = 16px (2.00mm)
right margin = 5px (0.63mm)
ink width = 219px (27.40mm)
A QR needs a 4-module quiet zone. At this size a module is roughly 4 px, so it wants about 16 px and gets 5.
It still decodes from a clean PNG, because the image ends in white and zxing tolerates a thin zone. On tape the zone is whatever physically follows the print — the next label's material, a die gap, or the end of the roll — so scannability depends on something outside the label's control. That is the defect: not "codes never scan" but "whether a code scans is not determined by what we print".
Why the asymmetry
TextElement defaults to flex=1.0 and QrElement to flex=0.0, so the QR is a fixed square pinned at one end while the text absorbs the slack. 2.00 mm on the left against 0.63 mm on the right suggests the outer padding is applied on one side only, or that the QR's quiet zone is counted inside its allocated box rather than outside it.
Suggested direction
Reserve the quiet zone outside the QR's box so a neighbouring element cannot squeeze it, and make the outer margin symmetric.
Worth adding a test that asserts a minimum white run on all four sides of a rendered label at the real head width. The existing scan-marked tests assert that a code decodes from a clean PNG, which is exactly the check that passes while tape output is marginal — a quiet-zone assertion would have caught this and a decode assertion never will.
Not urgent for text-only labels; it only affects codes.
Symptom
QR codes printed on die-cut tape have no usable quiet zone on one edge, which makes them unreliable to scan.
The measurable defect
The layout leaves almost no margin on the right. Measured directly on the render — no camera involved — for a QR plus one line of text at 12.012 × 30 mm, which is the geometry the agent produces on 15 mm tape with the 96-dot head:
A QR needs a 4-module quiet zone. At this size a module is roughly 4 px, so it wants about 16 px and gets 5.
It still decodes from a clean PNG, because the image ends in white and zxing tolerates a thin zone. On tape the zone is whatever physically follows the print — the next label's material, a die gap, or the end of the roll — so scannability depends on something outside the label's control. That is the defect: not "codes never scan" but "whether a code scans is not determined by what we print".
Why the asymmetry
TextElementdefaults toflex=1.0andQrElementtoflex=0.0, so the QR is a fixed square pinned at one end while the text absorbs the slack. 2.00 mm on the left against 0.63 mm on the right suggests the outer padding is applied on one side only, or that the QR's quiet zone is counted inside its allocated box rather than outside it.Suggested direction
Reserve the quiet zone outside the QR's box so a neighbouring element cannot squeeze it, and make the outer margin symmetric.
Worth adding a test that asserts a minimum white run on all four sides of a rendered label at the real head width. The existing
scan-marked tests assert that a code decodes from a clean PNG, which is exactly the check that passes while tape output is marginal — a quiet-zone assertion would have caught this and a decode assertion never will.Not urgent for text-only labels; it only affects codes.