zpl.tools
Format control

^XF - Recall Format

Recalls a stored format and merges the current label's data into it.

^XF pulls a template stored by ^DF into the current format, and merges the variable data of the current label into it. It is the read half of the store-and-recall pattern: the host sends the layout to the printer once, and each label after that carries the values that change only. The saving is bandwidth only. The printer stores the recalled format as ZPL text, so it formats the layout afresh at every recall.

Syntax

^XFd:o.x

Support

Supportedparsed: full · state: full · rendered: full

Every documented parameter renders the same output Labelary produces.

The renderer replays the stored format at the point the command stands, and binds each ^FN placeholder inside it to the ^FN and ^FD pair the recalling label carries. A recall of a path that holds no format reports that the file does not exist. Measured against Labelary on 2026-08-20. — not pinned by a test

Labelary renders this command.

Parameters

dStorage deviceoptional · single character

Which memory device holds the format. Unlike ^DF, an omitted device searches every device rather than assumes R:.

Default
searched in the order R:, E:, B:, A:
Invalid value
discarded, and the default applies
Test coverage
The invalid-value rule is not pinned by a test.
oFormat nameoptional · text

Name ^DF stored the format under. One to eight alphanumeric characters.

Default
UNKNOWN
Invalid value
discarded, and the default applies
Test coverage
The invalid-value rule is pinned by 1 test, including the diagnostic it emits.
xExtensionoptional · one of a set

Object extension.

Default
.ZPL
Invalid value
discarded, and the default applies
Test coverage
No documented value is exercised by a test (.ZPL). The invalid-value rule is not pinned by a test.
.ZPL
The only extension a stored format can have (default)

Behavior

^XF can appear anywhere inside ^XA^XZ, and more than once, so a label can join several stored pieces and fields written out in full.

The merge is the caller's responsibility. ^XF supplies the layout, and the recall format must repeat the ^FN numbers with ^FD data attached. The guide is blunt that data does not merge properly without them. Fields the template filled with literal ^FD text need nothing from the recall.

An omitted device letter behaves differently here than for ^DF. The guide searches R:, then E:, B:, A: for the name rather than assumes R:, so a bare ^XFSHIPTO.ZPL finds a template stored in flash. Labelary documents a flat R:UNKNOWN.ZPL default instead.

This renderer ignores ^XF, so the recalled layout is not there. A label whose whole design lived in the template renders blank. The renderer discards the ^FN data for the merge rather than prints it loose on the page (measured 2026-07-30).

Differences from the specification

Labelary against the ZPL II guide

Where Labelary — our compatibility target — behaves differently from the printed specification.

  • Labelary documents the whole path as one argument with the default R:UNKNOWN.ZPL, so it gives the device the same R: default as ^DF. The guide instead searches R:, E:, B:, A: in order for an omitted device. — not pinned by a test

zpl.tools against Labelary

Where our output differs from Labelary for the same input. These are the differences that break a migration.

  • Labelary renders the recalled format; the renderer ignores the command, so the layout is missing. A format whose whole layout came from ^XF renders blank, and the renderer drops the ^FN data with it. We measured this on 2026-07-30. — not pinned by a test

Example

The recall half of the pattern, against a template defined in the same request.

^XA
^DFR:SHIPTO.ZPL^FS
^FO25,25^A0N,25,25^FDSHIP TO^FS
^FO25,60^A0N,40,40^FN1^FS
^XZ
^XA
^XFR:SHIPTO.ZPL^FS
^FN1^FDZEBRA^FS
^XZ

Open in viewer