Barcodes in ZPL: ^BC, ^BQ and why the scanner refuses them
The three barcodes that turn up on shipping labels, the command that sets bar width, and the two reasons a barcode looks perfect in the PDF and fails at the scanner.
The three you will meet
| Command | Barcode |
|---|---|
| ^BC | Code 128. The linear barcode of shipping labels: takes letters and digits, and it is what most carriers use. |
| ^BQ | QR Code. Square, holds far more data, and usually carries the tracking URL. |
| ^BX | Data Matrix. Also square, common on small part labels and in pharmaceuticals. |
All three render on conversion, and we tested all three. Zebra's manual lists others, but outside these the odds of meeting one are low.
The anatomy of a Code 128
A complete barcode is two lines, and they are inseparable:
^BY3
^FO50,50^BCN,120,Y,N,N
^FD7891234567895^FSThe first sets bar thickness. The second positions and describes the barcode. And ^FD carries the content, exactly as in any other field: the barcode does not hold its own data, it draws whatever ^FD hands it.
The five values of ^BC, in order:
| Position | What it means |
|---|---|
| N | Orientation. N is normal, R turns it 90 degrees. |
| 120 | Bar height, in dots. |
| Y | Print the number under the barcode. N hides it. |
| N | Put the number above instead of below. |
| N | Would ask for a check digit. We measured it: it changes nothing here. |
^BY is the command people forget
^BY sets the width of the narrowest bar, and that is what decides the barcode's final size. With no ^BY at all, the result matches ^BY2: we rendered both and the output is identical byte for byte.
Here is the catch: ^BY applies from where it appears to the end of the label, not just to the next barcode. In a file with two barcodes of different sizes, the second comes out with the first one's thickness unless someone repeats the command. We tested that too: repeating ^BY before the second changes the drawing.
Why the barcode fails to scan after printing
The barcode looks perfect on screen, reaches the PDF, prints, and the scanner refuses it. It is nearly always one of two causes, and neither of them lives in the ZPL file.
Wrong density. If the file was written for 203 dpi and you converted at 300, the whole drawing shrinks in proportion, narrowest bar included. A barcode whose bar measured 0.25 mm now measures 0.17 mm, and from there it is down to the scanner: some read it, many do not. The telltale symptom is a barcode that works on one scanner and fails on another.
The office printer cannot resolve that bar. A thermal label printer is built for this; ordinary inkjet and laser printers blur the edge of the bar enough for a scanner to misread it. Raising ^BY from 2 to 3 fixes most cases, because a thicker bar forgives more blur.
Before blaming the file
Open the PDF and zoom into the barcode. If the bars are sharp and separated, the file is fine and the problem is the printing or the scanner. If they already look grey or merged on screen, the problem is density, and the route is the guide on 203, 300 and 600 dpi.
One test worth the ten seconds: scan the barcode straight off the screen, without printing. If it reads on screen and not on paper, you have isolated the problem to printing.