^FV - Field Variable
Supplies field data that is cleared after the label prints, unlike `^FD`.
^FV supplies a field's data exactly as ^FD does, with one difference: the printer
clears a ^FV field after the label prints, and keeps a ^FD field. That matters
only alongside ^MCN, which keeps the rendered label as the background for the next
one: the fixed parts stay, and the following label replaces the ^FV parts.
Syntax
^FVaSupport
Every documented parameter renders the same output Labelary produces.
A ^FV field prints exactly what the equivalent ^FD field prints, so the two differ only under ^MCN, where the renderer clears the variable field and carries the fixed one into the next label. — pinned by test_fv_renders_exactly_like_fd
Labelary renders this command.
Parameters
aVariable field dataoptional · textData for the field, subject to the same caret and tilde restrictions as ^FD.
- Default
- empty, in which case the command is ignored
- Accepted range
- 0 to 3072 bytes
- Invalid value
- not possible — any value is accepted
- Test coverage
- No test at the minimum, maximum or one step outside the range.
Behavior
^FV accepts everything ^FD accepts: the same 3072-byte limit, the same ban on a
literal caret or tilde, the same ^FH escapes, the same use as bar code content.
The printer ignores an empty ^FV, and prints no empty field.
^FV exists for a two-part format. The first label draws everything and ends with
^MCN, which suppresses the usual clear. Each label after it sends only the fields
that change, as ^FV, and ends with ^MCY to release the retained image. This
avoids a heavy layout in every label. It differs from ^DF/^XF stored formats,
which recall a layout by name and fill numbered fields with ^FN.
The renderer clears the page at every ^XA and treats ^FV as ^FD, so such a
format loses everything the first label drew. Send each label complete, or use ^DF
and ^XF once the renderer supports them.
Known issues
Tested behavior
Differences from the specification
zpl.tools against the ZPL II guide
Where our renderer behaves differently from the specification.
- The parser reads
^FVinto its own command variant carrying the same payload as^FD, so the two render alike. The variant is what lets^MCNtell a variable field from a fixed one. — pinned bytest_fv_renders_exactly_like_fd,test_fv_wraps_in_a_block_like_fd
zpl.tools against Labelary
Where our output differs from Labelary for the same input. These are the differences that break a migration.
- After
^MCNthe previous label's^FDfields and graphics carry into the next label; only its^FVfields are cleared, matching Labelary (measured 2026-07-30). — pinned bytest_mc_retains_nothing_for_the_next_label
Example
The guide's own pattern: the first label draws the box and both text fields and holds them with ^MCN; the second replaces only the variable field:
^XA
^FO40,30^GB300,120,4^FS
^FO55,50^A0N,28,28^FVVARIABLE ONE^FS
^FO55,100^A0N,28,28^FDFIXED DATA^FS
^MCN
^XZ
^XA
^FO55,50^A0N,28,28^FVVARIABLE TWO^FS
^MCY
^XZ
Related commands
^FDField DataSupplies the text or barcode content of the field.^MCMap ClearKeeps the previous label's image as the background of the next label, instead of a blank page.^FSField SeparatorEnds the current field.^FHField Hexadecimal IndicatorLets the following `^FD` carry bytes as hexadecimal escapes.