^IM - Image Move

^IM draws a stored graphic at the current field origin. The guide describes it as

^XG without the size arguments: the same objects, the same lookup, no magnification. The renderer draws it, and ^XG with both factors at one is the exact equivalent.

Syntax

^IMd:o.x

Support

Supportedparsed: full · state: full · rendered: full

Every documented parameter renders the same output Labelary produces.

The renderer recalls the stored graphic at the field origin, the same way ^XG does with both magnification factors at one. ^IM takes a single parameter, the object path, so text written after it is unrecognized content and not a magnification factor. — not pinned by a test

Labelary renders this command.

Parameters

dStorage deviceoptional · single character

Which memory device to read from.

Default: search priority — R:, then E:, B:, A:
Invalid value: discarded, and the default applies
Test coverage: The invalid-value rule is not pinned by a test.

oObject nameoptional · text

Name of the image to draw.

Default: UNKNOWN
Invalid value: discarded, and the default applies
Test coverage: The invalid-value rule is not pinned by a test.

xExtensionoptional · text

Extension of the image to draw.

Default: .GRF
Invalid value: discarded, and the default applies
Test coverage: The invalid-value rule is not pinned by a test.

Behavior

^IM is a field. It takes its position from the preceding ^FO and ends at ^FS, and one object can draw many times at different origins.

The guide notes that ^IM can format faster than ^XG for that reason, but only where the image sits on an 8-, 16- or 32-bit boundary. Off a boundary the printer shifts the raster bit by bit and the advantage disappears. It is a printer-throughput concern and does not reach a rendering API.

^IM takes one parameter, the object path. Text written after it is not a magnification factor: Labelary reports Ignored unrecognized content over it and still draws the graphic at one to one. That is the only syntax difference from ^XG, and the renderer follows it.

A path written without an extension recalls the stored .GRF object. A path no stored object answers to reports the missing file against parameter 1, and the field it sits alone in reports as a field without content. Under ^FT the image's bottom edge rests on the origin row, the rule ^GB and ^GC follow. A field rotation set by ^FW does not turn the raster.

Only the caret spelling is a command. ~IM reports that it does not exist.

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 renders ^IM; the renderer ignores it, so the image is missing here. — not pinned by a test

Example

A stored graphic drawn with ^IM, then a text field below it:

~DGR:LOGO.GRF,00080,010,
FFFFFFFFFFFFFFFFFFFF
8000FFFF0000FFFF0001
8000FFFF0000FFFF0001
8000FFFF0000FFFF0001
FFFF0000FFFF0000FFFF
FFFF0000FFFF0000FFFF
FFFF0000FFFF0000FFFF
FFFFFFFFFFFFFFFFFFFF
^XA
^FO50,50^IMR:LOGO.GRF^FS
^FO50,120^A0N,30,30^FDafter the image^FS
^XZ

Open in viewer

^XG Recall GraphicDraws a previously downloaded graphic, optionally magnified.
^IL Image LoadLoads a stored image as the background of the label.
^IS Image SaveSaves the current label image into printer memory.