Paste code or load the sample — the result appears below, with the line and severity of each finding.
2Result
Health report
The format draws several boxes or graphics, the printout
shows just the final one. Seen most often on mobile units. The reflex is to
rearrange the ZPL — but when a renderer draws every shape from the very same
file, the file has already been acquitted, and the investigation belongs on
the printer's side.
1. Acquit the file first
Paste the format into a ZPL preview. If every ^GB renders
and no warnings appear, nothing in the format is being silently dropped by
the interpreter — the same bytes produce different results on screen and on
paper, so the difference lives in the device. That single check saves the
hours usually spent reordering commands that were never the problem.
2. Why a mobile printer can differ
Mobile printers commonly ship interpreting a different page language by
default, with ZPL handled by an emulation layer whose coverage varies by
firmware. An emulation that implements only part of the drawing model can
keep the last shape and lose the earlier ones — behaviour no ZPL edit can
fix, because the format was never the cause.
3. Settle the language question in a minute
Two ways, no guesswork:
Hold FEED while powering on. The configuration label
that prints lists the active printer language / control mode.
Or send both ! U1 getvar "device.languages" (a CPCL-style
control query) and ^XA^HH^XZ (a ZPL host query) — whichever
one answers tells you which interpreter is listening.
Not sure which language your file is written in? The
printer language detector
answers that half — note it reads the code, not the device.
4. The fix, and its honest limit
If the configuration label reports anything other than native ZPL,
switch the printer to ZPL mode — setting device.languages to
zpl is usually the whole fix. If the firmware offers only the
emulation, the gap is the emulation's, and the workaround is to simplify
what the format asks of it rather than to fight the ordering.
