ZPL Font Not Printing or Showing Blocks

Three different symptoms have different causes. Match yours first.

Symptom	Most likely cause
Text prints in the wrong (default) font	The font file isn’t found at the path in ^A@/^CW
Text prints as empty boxes or blocks	The font lacks those characters, or the wrong ^CI is set
Nothing prints for the field	Missing ^FS, field off the label, or a size of 0

1. Prints in the wrong font

The printer could not load your font and fell back to the default.

1. List stored fonts: ^XA^WD*:*.TTF^XZ
2. Check the drive letter and exact name in your label: ^A@N,50,50,E:ARIAL.TTF
3. If the font is not listed, download it again, this time to E:.
4. If you use ^CW, make sure the alias is defined before ^A, in the same label or earlier.

2. Prints boxes or blocks

^XA
^CI28
^A@N,50,50,E:ARIAL.TTF
^FO50,50^FDCafé 你好^FS
^XZ

Check, in order:

• The font has the glyph. Arial has no Chinese characters, so 你好 becomes blocks. Choose a font that covers the script.
• ^CI is right. For UTF-8 data you need ^CI28. See Unicode and code pages.
• The host really sends that encoding. Open the print file in a hex viewer and confirm.
• The built-in font is in use. Fonts A to H and 0 cannot show non-Latin scripts.

3. Nothing prints

• Every ^FD needs a closing ^FS.
• Coordinates must be inside ^PW and ^LL. A field at ^FO900,50 on an 812-dot-wide label is invisible.
• A height of 0 or a missing ^A size can produce nothing. Add ^CF0,30 as a safety net.
• The font file may be corrupt. Delete with ^IDE:NAME.TTF and re-download.

4. Checks that save time

Print the configuration and the object directory:

^XA^HH^XZ
^XA^WD*:*.*^XZ

Then preview the same ZPL in the live preview to catch syntax slips before wasting labels.

Still stuck?

Convert the text into a graphic with the text-to-graphic tool. It always prints exactly what you see on screen.

Work from the cheapest test to the most expensive

When a font misbehaves, the temptation is to change five things at once. Resist that. Each test burns a label, and changing several variables makes it impossible to know what fixed the problem. Go in order of cost: first read the ZPL, then check the printer’s directory, then try a minimal label, and only then start suspecting the font file or the printer itself.

Read the label like a stranger would

Open the ZPL in a text editor and read it slowly. A surprising number of “font” problems are plain typos. Is there a comma after the A in ^A@? A missing comma between height and width? Does every ^FD end with ^FS? Is the drive letter and the file name spelled exactly as it appears in the directory? Did you define a ^CW alias before using it, in the same job or earlier?

The preview can help here too. Paste the label into the live preview and see whether the layout appears at all. If the preview shows text where the printer shows nothing, the issue is probably the printer’s side: a font that isn’t loaded, or a character set mismatch. If the preview also shows nothing, you’ve found a syntax or positioning error.

Prove the font is on the printer

Print the object directory with ^XA^WD*:*.*^XZ. Find your font in the list. If it isn’t there, that’s your answer, and everything else is secondary. Check which drive it landed on. A font that’s on R: while your label asks for E: won’t be found, and vice versa. If the font was there yesterday and is gone today, read font disappears after reboot.

If the font is listed, note its exact name, including the extension, and copy that into your label rather than retyping it.

Use a minimal label

Strip the problem down. A label with one field, one font and the plain word “Test” will tell you whether the font itself loads. Then add one more thing at a time: the character set, the real text, the size. The moment it breaks, you know which change did it. This approach feels slow but is nearly always faster than staring at a complicated label.

Boxes and blanks are not the same problem

Boxes where letters should be mean the printer found the font but not the character. Either the font really lacks the glyph, or the bytes are being interpreted with the wrong character set. Check both. A quick way to separate them is to print plain ASCII, such as “ABC 123”, in the same font. If that works and accented text doesn’t, it’s an encoding or coverage issue, and Unicode and code pages explains how to fix it.

A blank field is different. Think about position, size and closing commands. Is the ^FO inside the printable area? Is the height more than zero? Is the text colour reversed against a white background with ^FR? Reverse printing over white gives you black text, but over a black box gives white text, and mixing them up produces invisible text surprisingly often.

When the font is the problem

If a minimal label with that font fails while the same label with a built-in font works, suspect the file. It might be corrupt, truncated during download, or in a format the printer can’t read. Delete it with ^ID and download it again, ideally from a clean copy of the original. If you used a script to send it, check that it sent the whole file and didn’t cut the hex data short. The details are in the download guide.

Don’t forget the media and the hardware

Rarely, the issue isn’t software. A dirty printhead, wrong darkness setting or worn ribbon can make small or thin text vanish while bold text survives. If a test label looks faded in places, clean the printhead and raise the darkness a notch before you rewrite anything. Our guide to small label design explains how media affects readability.

Short answers

The font works in the preview but not on the printer. Why? The preview doesn’t need the font file. Check that the printer has it.

Everything prints except one field. Compare that field’s commands with a field that works.

It worked until I changed the font file. Delete the old file first and then send the new one.

Is there a last resort? Yes. Convert the text to an image with the text-to-graphic tool.