^TO - Transfer Object
Copies a stored object from one memory device to another.
^TO copies a stored object between the printer's memory devices, usually out of volatile
DRAM into flash so that a logo survives a power cycle. It copies and does not move: the
source stays in place. The renderer performs the copy, so a recall under the new name finds
the object.
Syntax
^TOs:o.x,d:o.xSupport
Every documented parameter renders the same output Labelary produces.
Labelary renders this command.
Parameters
s:o.xSource objectrequired · textObject to copy, as s:o.x. An omitted name or extension defaults to *, which selects every matching object; a wildcard cannot transfer *.FNT.
- Invalid value
- enough to make the whole command be ignored. Only a device letter no printer has is reported. Every other source failure is silent and copies nothing, including a path with no device at all.
- Test coverage
- The invalid-value rule is pinned by 3 tests.
d:o.xDestination objectrequired · textWhere to copy it, as d:o.x. Labelary requires the device, the name and the extension, and accepts a destination on the same device as the source.
- Invalid value
- enough to make the whole command be ignored. All three pieces are required. A missing device, name or extension is reported and cancels the copy.
- Test coverage
- The invalid-value rule is pinned by 4 tests.
Behavior
The asterisk works on both sides, and the destination pattern renames as it copies:
^TOR:LOGO*.GRF,B:NEW*.GRF turns LOGO1.GRF, LOGO2.GRF and LOGO3.GRF into
NEW1.GRF, NEW2.GRF and NEW3.GRF in one command. Two limits apply. A wildcard cannot
transfer a font object, because a multiple transfer excludes *.FNT, so an old example of
the form ^TOR:*.FNT,B:*.FNT does nothing. Zebra's own resident files, Z:*.*, do not
transfer at all.
On a printer the copy can also fail for space. In a multiple transfer the printer ignores a file too large for the destination, and continues with the rest. A partial result is the normal outcome rather than an error. The printer cancels a single transfer that does not fit.
The two sides are judged by different rules, all measured against Labelary on 2026-08-19.
A destination must name a device, a file name and an extension; each one missing is
reported and cancels the copy. A source can omit its name or its extension, because both
default to *, and only a device letter no printer has is reported. A source with no
device at all copies nothing and says nothing, which is not how ^XG
reads a device-less path.
Two of the guide's rules do not hold on Labelary. The devices need not differ, and an omitted destination extension is an error rather than a fallback to the source object's.
Differences from the specification
Labelary against the ZPL II guide
Where Labelary — our compatibility target — behaves differently from the printed specification.
- The guide requires the two devices to differ. Labelary does not: we measured
^TOR:LOGO.GRF,R:C.GRFon 2026-08-19, and the copy is made. — not pinned by a test - The guide says an omitted destination extension keeps the source object's. Labelary reports
Path 'E:COPY' is missing file extensionand copies nothing, measured 2026-08-19. — not pinned by a test
Example
A graphic downloaded to DRAM, copied to flash, and then recalled under its new path:
~DGR:LOGO.GRF,00080,010,
FFFFFFFFFFFFFFFFFFFF
8000FFFF0000FFFF0001
8000FFFF0000FFFF0001
8000FFFF0000FFFF0001
FFFF0000FFFF0000FFFF
FFFF0000FFFF0000FFFF
FFFF0000FFFF0000FFFF
FFFFFFFFFFFFFFFFFFFF
^XA
^TOR:LOGO.GRF,E:COPY.GRF
^FO50,50^XGE:COPY.GRF^FS
^FO50,120^A0N,30,30^FDcopy recalled^FS
^XZ
Related commands
^IDImage DeleteDeletes a stored object from printer memory.~DGDownload GraphicDownloads an ASCII-hex bitmap into printer memory as a `.GRF` object.^HWHost Directory ListSends a listing of the objects held in printer memory back to the host.