The ZPL commands conversion ignores, and why

A ZPL file does not only describe the label's artwork. It also describes how the printer should behave: how many copies to run off, how much heat to burn the ribbon with, how fast to pull the paper, which way round to start.

Converting is drawing, not printing. There is no ribbon to burn, no motor to speed up, no roll to pull. Commands in that second category have nothing to act on, and conversion passes over them in silence.

This is not a limitation of the converter: it is what separates the two jobs. Knowing which commands they are is worth the five minutes, because nearly all of them raise the same question ("but it says so in the file").

^PQ is the copy count. This file asks for three:

^XA
^FO50,50^A0N,30,30^FDPedido 1234^FS
^PQ3
^XZ

Converted, it returns one page. We measured it against the renderer EasyZPL uses, and there is a test keeping it that way.

The reasoning: ^PQ tells a printer to repeat the same label, it does not describe three labels. The file holds one label, so the PDF has one page.

If you want three pages, the file needs three ^XA … ^XZ blocks, one per label. It is more verbose and it is more honest: what the file contains becomes what the PDF gives you.

^PW declares the print width and ^LL the label length, both in dots. We rendered with and without them: the output is identical, byte for byte.

The size used for conversion comes from the width and height fields on screen, in millimetres, not from what the file declares. That is deliberate, and the reason is practical: most files in circulation carry no ^PW at all, because the destination printer was already configured. Obeying the file when it speaks and guessing when it stays quiet would give one screen two behaviours.

The practical consequence: if the label came out cropped or with extra margin, the place to fix it is the screen, not the file.

^MD adjusts print darkness, ^PR the speed, ^PO the orientation and ^LT the top offset. We tested all four, including ^POI, which flips the label 180 degrees: the output is identical byte for byte in every case.

It makes sense once you look at what they control. Darkness is how much heat the printhead applies to the ribbon; speed is the motor; orientation and top offset describe how the label leaves the roll. None of that exists in a PDF.

So if your printed label comes out too faint, the adjustment belongs on the printer, and the PDF has nothing to do with it.

This is the case that surprises people most: a mistyped command, or one that simply does not exist, produces no warning at all. The label converts as though it were not there.

^XA
^ZZinventado
^FO50,50^A0N,30,30^FDPedido 1234^FS
^XZ

That label comes out identical to the same one without the middle line.

It is not an oversight: it is how ZPL was designed. Different printer models understand different command sets, and a file written for a new model has to keep printing on an old one by ignoring what it does not recognise. That tolerance is what lets one file travel across a ten-year-old fleet of machines.

You pay for it, and the commonest typo shows how: writing ^F0 with a zero instead of ^FO with the letter O. The command stops existing, so the position it carried goes with it, and the field is drawn in the top left corner, on top of whatever is already there.

Recognising that failure saves time: when an element turns up stacked in the corner instead of where it belongs, look for a zero where an O should be before looking for any other cause.

If it is in the file and did not come out the way you expected, it is nearly always one of three cases: a machine command, ignored on purpose; a mistyped command, which gives no warning and takes its setting down with it; or content positioned outside the label area. The first two are here, the third is in the guide on why a label never reaches the PDF.