Print Any Font on a Zebra Label by Converting Text to a ^GF Graphic

There’s a point in many label projects where fonts stop being the interesting part and start being the obstacle. The printer is out of memory. Or the script needs shaping the firmware can’t do. Or the design team insists on a typeface you can’t legally embed. In all those cases there’s a simple escape hatch: skip fonts entirely and print a picture of the text.

What ^GF actually is

^GF is the “graphic field” command. It takes a black-and-white image, written as rows of dots, and prints it at the position you set. In the common form the image is sent as a long string of hexadecimal characters, where each pair of hex digits is eight dots across, one bit per dot. A 1 is a black dot and a 0 is white.

That’s all it is. The printer doesn’t know the picture contains letters. So anything you can draw on a computer, in any font, any script, any size, can be printed.

^XA
^FO40,40
^GFA,total,total,bytes-per-row,<hex data>
^FS
^XZ

The numbers say how many bytes the whole image has and how many bytes make up one row. You’ll rarely write them by hand.

How you’d make one

The process has four steps. Draw the text onto a canvas, using whichever font and size you like. Convert the canvas to pure black and white, usually by choosing a brightness threshold. Pack the dots into bytes, eight per byte, row by row. And write the bytes as hex into a ^GFA command, optionally compressing runs of repeated data.

You can do all of that with our text-to-graphic converter. It runs in your browser, so the text and fonts you use never leave your computer. Type your text, choose a font, adjust the size and threshold, and copy the generated ZPL. It also takes an uploaded font file, which is useful for a brand typeface.

If you need to do this in an application rather than by hand, every mainstream language has a way to draw text to a bitmap, and the packing step is a few lines of code. The tool’s output is a good reference to test your own implementation against.

When graphics are the right answer

They’re ideal for text that doesn’t change: a legal notice in several languages, a brand name set in a specific font, a slogan. You make it once, check it with a native speaker and print it forever.

They’re also the dependable fix for complex scripts. Arabic and Devanagari need shaping that the printer may not support, as discussed in printing Hindi and Arabic on Zebra labels. Drawing the text on a computer, which handles shaping properly, sidesteps the whole thing.

And they’re a lifeline on printers with very little memory, where no font will fit.

When they’re not

For text that changes on every label, such as names and quantities, graphics mean generating a new image each time, which adds work to your software and makes the data larger. The result also isn’t selectable or editable on the printer, and a corrected typo means regenerating the image.

Size is another factor. Even a short line can be a few hundred bytes to a few kilobytes of ZPL. A full-width image of a paragraph may be tens of kilobytes. Compression helps a lot because text images are mostly white. On a fast network you won’t notice. Over a slow serial or wireless link, you might.

Quality has limits too. A bitmap is fixed at the resolution you generated it for. Make it for a 203 DPI printer and send it to a 300 DPI one and it prints smaller, since the dots are the dots. You’d need a version per resolution, as explained in why text looks different on 203 and 300 DPI printers.

Getting good results

Render at the printer’s native resolution. If you’re drawing at screen size and scaling up, edges will be fuzzy. Use a threshold that keeps thin strokes without turning bold ones to blobs, and check it by looking at the one-bit preview. Pick a font with sturdy strokes for small sizes, since a thin font won’t survive being reduced to black and white. Make sure the width of the image is a multiple of eight, which the tool does for you.

Place it with ^FO as with any field, and check it in the live preview, which decodes ^GF data including the compressed form.

Store or send?

A graphic that never changes can be stored on the printer’s flash and recalled, rather than sent with every label. That saves bandwidth for high-volume jobs. Mind the flash-wear point from Zebra flash memory explained: store it once, don’t rewrite it per job. For graphics that change, just send them with each label.

Putting it together

Use real fonts when you can, since they’re small and flexible. Use graphics when you can’t, or when exact appearance matters more than flexibility. Many labels mix both. For help deciding, see how to choose the right ZPL font, and for the options on offer, downloading TrueType fonts.