Skip Policy

Most of ZPL does not draw anything. It configures a printer: which sensor to use, how fast to feed, the network settings, what to write to an RFID tag. This API has no printer, no sensors, no radio and no network stack, so those commands have nothing to act on.

The renderer parses these commands and ignores them, as Labelary does. That is the ignored status in the command support matrix.

Ignored commands

113 of the 231 commands in the reference carry the ignored status. The table groups them into the same categories as the command reference.

The table shows 114 spellings for 113 commands: ^HL and ~HL are one command with two prefixes.

The families behind the categories:

• RFID and tag operations:

  • tag reads, writes and locks
  • tag passwords
  • the AFI and DSFID bytes
  • EPC structure

  A tag payload is not label content. ^RF, ^RQ, ^RZ, ^WT and ^WF take their data from the following ^FD. The renderer consumes that data and draws nothing. See ^RF for the detail.

• Host status and inquiry. ~HS, ~HQ, ^HH and the rest ask a printer to send data over its serial or network connection. This API has no connection, and no status string reaches the page.

• Printer, job, device and network configuration:

  • darkness and print speed
  • tear-off position, cutter behavior and backfeed
  • the head-cleaning schedule
  • the display language
  • wired and wireless network settings
  • SNMP and SMTP

  All of it is printer state that outlives one label.

• Sensor calibration and media setup:

  • media type and tracking
  • the sensor profile
  • ribbon tension
  • label-length calibration

  These commands tell a printer how to find the edge of a label. Your API request already gives the label size.

Why this is safe

1. The command cannot change a rendered label. Nothing in the ZPL II specification gives these commands an effect on the page. They set device state, move media, or send a message to the host.
2. Labelary ignores them too, and silently, so a label that renders correctly there renders correctly here. ^XA^ZZ60,N^FO50,50^A0N,40,40^FDhi^FS^XZ draws the same pixels on both.
3. Where an ignored command could become visible, tests pin the behavior. ^LL sets label length on a printer, but the output page size here comes from the dimensions in your request, exactly as on Labelary. Regression snapshots pin that behavior.

An ignored command is not the same as an unimplemented one. The matrix publishes a gap that changes pixels as planned or unsupported, never as ignored.

What you see in diagnostics

An ignored command reports IGNORED_COMMAND at info severity. A rendering-relevant gap reports UNSUPPORTED_COMMAND at warning.

The API's X-Warnings header excludes info-severity diagnostics, so ignored commands never appear there. They do appear in the online viewer and the desktop app, which show every diagnostic with no limit.

This body carries eight device commands, an RFID write, and one gap in ^PM (print mirror image, not yet implemented):

^XA^MMT^MTD^MD10^PR4^JUS^SS,,,,,,,,^HH^ZZ60,N^RFW,H^FD1234ABCD^FS^PMY^FO50,50^A0N,40,40^FDShip to^FS^XZ

With X-Linter: On it reports exactly one warning, for ^PM:

X-Warnings: 65|3|^PM||command "^PM" is valid ZPL but is not supported by this renderer yet; it was skipped

Find every ignored command

Diagnostics do not show every ignored command. Two places do:

• the command support matrix, which lists every command with its status and a note;
• each command's own reference page, reachable from that matrix, which says what the command does on a printer, and what the renderer does instead.

If a command on the ignored list changes your labels, send us the counter-example.

Related pages

• Linting and warnings — how the X-Warnings header works and what reaches it
• Diagnostics reference — every code, its severity, and where it appears
• Command support matrix — per-command status for all 231 commands