zpl.tools
Format control

^DF - Download Format

Stores the rest of the label as a reusable format instead of printing it.

^DF turns the format it appears in into a template. The printer saves everything after it to memory under the given name rather than prints it, for

^XF to recall later with data merged in. The printer saves the ZPL text, not a rendered image. A stored format therefore saves transmission time on every later label, and no format time: the printer lays it out from scratch at every recall.

Syntax

^DFd:o.x

Support

Supportedparsed: full · state: full · rendered: full

Every documented parameter renders the same output Labelary produces.

The renderer stores every command between ^DF and ^XZ under the named path, and prints no page for the label that carries the definition. The path is a d:o.x triple whose device letter is resolved through ^CM, and whose extension defaults to ZPL rather than to the GRF a graphic takes. ^JB erases a stored format; ^EG does not. Measured against Labelary on 2026-08-20. — not pinned by a test

Labelary renders this command.

Parameters

dStorage deviceoptional · single character

Which memory device to store the format on.

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

Name the format is stored under, for ^XF to recall. One to eight alphanumeric characters.

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

Object extension. Always .ZPL for a format.

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

^DF goes immediately after ^XA, and it consumes the rest of the format. Anywhere else, or before the ^XA, it leaves part of a label and part of a template. Nothing between ^DF and ^XZ prints.

The template earns its keep through

^FN: each field whose contents change per label reads ^FNn with no ^FD, and the recall format supplies ^FNn^FD…^FS for each one. Fields with literal ^FD data are fixed, and print identically at every recall.

The device letter decides how long the template lives: R: is volatile RAM, and E: and B: survive a power cycle. The name is one to eight alphanumeric characters, and a recall must match it exactly.

This renderer does not implement ^DF yet, and the failure is not a quiet one. The renderer ignores the command, treats the template body as an ordinary label, and prints it. On the example below Labelary returns one page, the merged label. This renderer returns two: the bare template with its ^FN field empty, and then a blank page for the recall (measured 2026-07-30). A stored-format workflow is therefore wrong here in both the pixels and the page count until milestone 5.9 lands.

Differences from the specification

zpl.tools against Labelary

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

  • Labelary stores the format and returns no page for the definition. The renderer prints the definition as a label. We measured this on 2026-07-30. A request that defines a template and then recalls it returns one merged page from Labelary. Here it returns two pages: the bare template, then a blank page for the recall. — not pinned by a test

Example

Define a template with one variable field, then recall it.

^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