I have discovered a strange behavior when instructing Zebra GK420t printer to make stickers containing some text and a QR code. Consider the following example:

A QR code without a rotation on the left and the QR code rotated by 180 degrees on the right

Both QR codes are perfectly fine. They both can be printed with moth printers, including the trusty GK420t and they both can be decoded by the camera on the phone or the bar code scanner.

The difference is that the QR code on the right is rotated by 180 degrees. Rotation of the QR code should not be a problem, as the decoder can adjust for the orientation using position detection patterns. This is how a QR code is designed, to convey the same information no matter which angle it is viewed from.

ZPL instructions for a QR

However, using Zebra Designer 3 Essentials, the code generated for the left one looks like this:


While the one on the right creates a completely different output:


The codes are almost identical, why such a difference in the code?

Printing graphic fields

The problem is in the features the actual printer supports. This particular printer supports ZPL instruction ^BQ for the QR code bar code. The instruction however accepts no input that describes it's rotation.

Because of no way to tell the printer how should the QR code be rotated, the software has to first encode the rotated code into the ^GF instruction for the graphic field. This way, the printer can still print it.

Problems with variable data

In order to encode variable data in the QR code, which is most of the time the stickers are printed in the industrial environment, encoding details such as product model, time and date, and maybe even an operator ID, we have to be able to modify it's instruction on the fly.

Modifying the data is simple in the case of ^BQ, as the data are stored in the plain text. It however becomes increasingly difficult to do the same with the rotated QR code, as the data there have to be first converted to the graphical representation of the QR code, then rotated and then encoded in what is presumably a Base64 encoding.

Such would be a routine, which I could not find a straightforward documentation for. Even if it was readily available, it would be required to port it to the local environment where the printer is connected to, for instance the PLC.


Most of the modern printers use Ethernet connection, which is superior for more complicated designs, but GK420t does not. It uses a serial connection, implying a rather low-level controller. Unless absolutely unavoidable, printing rotated QR codes with variable data should be avoided with printers of this family.

This is a 68th post of #100daystooffload.