Troubleshooting
^FD data does not appear on the label
A field whose data never prints is usually missing its ^FS, carrying a caret in the data, or drawing in white on white.
The missing ^FS
^FD starts field data and ^FS ends the field. Without the ^FS, everything that follows — including the next field's commands — is swallowed into the data of the field that never closed.
^XA
^FO50,50^A0N,40,40^FDShipment 4821
^FO50,120^A0N,40,40^FDNext line^FS
^XZThe symptom is rarely one missing field. It is usually one field printing a long run of nonsense and everything after it missing, because the printer is treating a dozen commands as text.
A caret or tilde inside the data
^ and ~ start commands, and the printer does not stop looking for them inside ^FD. A price written as R$ 100^Reais ends the field at the caret and reads ^Re as a command, so the field prints truncated and something unexpected happens afterwards.
^XA
^FO50,50^A0N,40,40^FDR$ 100^Reais^FS
^XZThe fix is ^FH, which turns on hexadecimal escapes for the field: an underscore followed by two hex digits stands for that byte, so _5E is a literal caret. The other option, if the data is yours to control, is to not put control characters in it — which is usually the better answer when the value comes from a database.
^XA
^FO50,50^FH^A0N,40,40^FDR$ 100_5EReais^FS
^XZPrinting white on white
^FR reverses a field against what is behind it, and ^LR does the same for a whole format. A reversed field over a black box prints white and is exactly what you want; the same field over the blank label prints white on white and is invisible.
This is the one to suspect when a field disappeared after someone added a black band to the design and turned on ^LR — every field after the band inverted too, because ^LR runs to the end of the format unless it is turned off.
Accented characters that vanish
If the missing part is specifically the accented characters, that is an encoding question rather than a field one. ^CI28 puts the printer into UTF-8, which is what most systems are sending, and without it a byte outside ASCII is interpreted against whatever code page the printer is on.
The symptom varies by how wrong the guess is: sometimes a wrong glyph, sometimes nothing at all. Either way ^CI28 near the top of the format is the fix.
Check the field in the validator
The unclosed field above, loaded and ready. The validator reports the ^FD that never got its ^FS, with the position of the field that opened.
Check the field in the validatorCommon questions
- Where exactly does ^FS go?
- Immediately after the data, ending the field: ^FO50,50^A0N,40,40^FDtext^FS. Every field needs one, and the linter reports the ones that do not have it with the line and column of the ^FD that opened them.
- How do I print a literal ^ or ~?
- Turn on ^FH for the field and write the character as an underscore plus its hex code — _5E for ^ and _7E for ~. There is no way to print either character in a plain ^FD.
- Accented characters print as the wrong glyph. Is that the same problem?
- It is a related one: the printer is decoding your bytes against the wrong code page. Add ^CI28 to put it into UTF-8, which is almost certainly what your data already is.