Home›Guides›Label Prints Too Large, Cropped or Blank After a CUPS Update
Label Prints Too Large, Cropped or Blank After a CUPS Update
Published:
A label printer on Linux that worked for months suddenly prints the
content blown up and cut off, feeds out blank labels, or turns the barcode
into a solid black block — and the only thing that changed was a system
update. In October 2026 several such reports reached the OpenPrinting issue
tracker. What they have in common: the label was not sent as printer
language. It went through a driver queue that converts a PDF into an image
for the printer, and a change somewhere in that conversion changed the
label.
The symptoms, as the reports describe them
Content about 2.5× too large and cropped. A Zebra ZD220 with a
ZPL driver, printing from gLabels-qt: the label height is still right, the
content is enlarged and cropped. The reporter found it working with
libcupsfilters 2.1.1, broken from 2.2.1 up to a git snapshot (r32) and
fixed again in a later snapshot (r57). A commenter named commits in the
pdftopdf filter as candidates; that is a hypothesis, not a confirmed
cause.
Blank labels with a custom page size. A Dymo LabelWriter 450
with Dymo's CUPS driver: labels feed but come out blank with a custom size,
while the same content with a named media size prints. Downgrading
libcupsfilters fixes it for the reporter; the cause is not confirmed.
Barcode printed as a black area. Barcodes inside a PDF printed
as black zones with libcupsfilters 2.2.x and correctly with 2.1.1. The
reporter closed the issue after a patch to the PDF library pdfio fixed it —
"not a libcupsfilter bug".
Nothing prints after changing the scale. A TSPL printer on a
Raspberry Pi with a community TSPL CUPS driver; the fix was setting the
resolution to 203 dpi instead of 300.
We have not reproduced these on a printer. The list says what the issue
threads say and nothing more; links are under Sources.
Why a system update can change a label
When you print a label from a design program or a browser, the
application hands CUPS a document, usually a PDF. A driver queue then runs
a filter chain: page sizing and scaling, rasterising, and finally the
driver turns the bitmap into the printer's own commands. Each step can
change size, position or pixels, and each step is a system library —
libcupsfilters, Ghostscript, Poppler, pdfio — that updates with your
distribution. Your label file did not change; the conversion did. A raster
driver also has to know the printhead's real resolution: tell it 300 dpi
for a 203 dpi printer and everything is scaled by about 1.48.
Short term: hold or roll back the package
If you have to keep the driver workflow, the reports show what worked for
their reporters: going back to the previous libcupsfilters, or moving to a
build that contains the fix (#300). Your distribution's package manager can
show which libraries changed in the update that broke printing. Treat this
as a stopgap: the next update can move the same chain again.
Durable fix: send printer language to a raw queue
If your system can produce the label as ZPL or TSPL — shipping
platforms, WMS and ERP systems usually can, and so can a template — skip the
conversion chain. A raw queue hands the bytes to the printer unchanged: no
scaling, no rasterising, nothing for a library update to alter.
The CUPS lpadmin manual says the model raw
"clears any existing PPD file". The same manual also says that models other
than everywhere are deprecated and that printer drivers will
not be supported in a future version of CUPS — so recent CUPS versions warn
when you create a raw queue. It still works today. USB device URIs and the
macOS details are in
printing ZPL on macOS and
Linux.
You may see lp -o raw suggested for sending a file through an
existing driver queue. The current lp manual does not document
that option, so we do not build on it here; a dedicated raw queue is the
predictable route.
The route CUPS is heading for: LPrint
CUPS's direction is driverless IPP Everywhere printing. Label printers
rarely speak IPP themselves; Michael Sweet's LPrint is a printer
application that presents each printer as an IPP Everywhere print service.
Its project page lists all EPL2 and ZPL Zebra printers, experimental
TSPL/TSPL2 support, DYMO, Brother and others, and says each printer can
directly print "raw", Apple/PWG Raster and PNG files. One limit to know: the
maintainer notes that LPrint, and IPP in general, has no notion of
indeterminate-length media — the client has to specify a page size.
Check the label before it reaches paper
Paste the ZPL into the online viewer to
confirm size and barcode before you print. If the label was made for a 203
dpi printer and yours is 300 dpi (or the other way round), rescale the
coordinates with the DPI converter
instead of letting a driver scale a bitmap; the background is in
ZPL dots, mm and
DPI. If the printer prints your ZPL source as text, that is the opposite
problem — see printing ZPL
without a driver.
Sources
OpenPrinting/libcupsfilters issues #300, #275 and #272 (October 2026)
Why does my label print too large and cropped after a Linux update?
The label most likely goes through a driver queue that converts a PDF into an image, and a library in that chain changed. One October 2026 report on a Zebra ZD220 saw content about 2.5x too large with libcupsfilters 2.2.1 snapshots, fine with 2.1.1.
How do I stop CUPS updates from changing my labels?
Send the label as printer language (ZPL or TSPL) to a raw queue, for example lpadmin -p label-raw -E -v socket://IP:9100 -m raw. A raw queue passes the bytes unchanged, so there is no scaling or rasterising for an update to alter.
Are raw CUPS queues deprecated?
The lpadmin manual says models other than everywhere are deprecated and printer drivers will not be supported in a future CUPS version. Raw queues still work today; LPrint, which presents label printers as IPP Everywhere services, is the forward route.
