zpl.tools
Fields

^FL - Font Link

Chains a fallback font onto a base font for characters the base font lacks.

^FL chains one font onto another, so the extension font draws a character the base font has no glyph for. One format can then print Latin text and CJK text in the same field. Like ^FE, ^FL is absent from the ZPL II Programming Guide's command index, so the argument list here comes from Labelary's reference.

Syntax

^FLd:o.x,d:o.x,l

Support

Recognised, deliberately skippedparsed: full · state: none · rendered: none

Accepted and skipped, because it configures the printer rather than the label. It cannot change the rendered output, and Labelary skips it too.

The parser reads both font paths and the link indicator, and the renderer makes no link, because no font this command can name is one the renderer draws with. Only a TTF or TTE file can be linked, and no resident font is one: ^A@ answers File 'Z:TT0003M_.TTF' does not exist for the TrueType path a printer carries, measured 2026-08-22. So the extension font is always one a ~DY or ~DU download placed on a device, and the renderer does not read a downloaded font file. Reading the slots is what raises the argument reports Labelary raises. — not pinned by a test

Labelary renders this command.

Parameters

extensionExtension fontrequired · text

The font for a character the base font has no glyph for, as d:o.x.

Invalid value
enough to make the whole command be ignored. Measured on live Labelary 2026-08-22. This slot alone is held to the TTF/TTE whitelist: Z:A.FNT answers File extension 'FNT' cannot be used here, using null instead; valid extensions are 'TTF', 'TTE' and then Path 'Z:A.FNT' is missing file extension. A path with no device answers Path 'QQQ' is missing device; available devices are 'R', 'E', 'B', 'A', 'Z', an impossible device Device 'Q' does not exist, an empty name Path 'R:.TTF' is missing file name, and no extension Path 'Z:0' is missing file extension. A well-formed path to a file that is not there draws no report.
Test coverage
The invalid-value rule is pinned by 8 tests.
baseBase fontrequired · text

The font this command extends, as d:o.x.

Invalid value
enough to make the whole command be ignored. The same path reports as the extension font, minus the extension whitelist: ^FLR:A.TTF,Z:B.FNT,1 and ^FLR:A.TTF,R:B.XYZ,1 are both silent, measured 2026-08-22.
Test coverage
The invalid-value rule is not pinned by a test.
lLink or unlinkoptional · one of a set

Whether this command establishes the link or removes one.

Default
0
Invalid value
enough to make the whole command be ignored. Measured on live Labelary 2026-08-22: a number that is neither 0 nor 1 answers Command was ignored because 5 is not a valid link indicator (0/1) and the two paths are then not read. A slot that reads as no number answers Value 'XX' is not a valid number and was ignored and the paths are read as usual.
Test coverage
No documented value is exercised by a test (0, 1). The invalid-value rule is pinned by 2 tests.
0
Unlink the two fonts (default)
1
Link them

Behavior

The link is a property of the printer, not of a field. It applies to every following field that selects the base font, and it survives the end of the label. The guide states the link lasts until something breaks it or the printer switches off, and that ^JUS saves it permanently. l=0 breaks a link a previous format established.

Both fonts take a path in the d:o.x form the font commands use: a drive letter, an object name and an extension, as in R:NOTOCJK.TTF. The renderer reads both paths and the link indicator, and it reports the same problems Labelary reports: a path with no drive letter, a drive letter no printer has, a path with no file name, and a path with no extension. The third slot is a flag rather than a character code, so a number that is neither 0 nor 1 leaves the command ignored and its two paths unread.

Only the extension font is held to the TTF and TTE extensions. A base font written with any other extension draws no report, which the renderer copies.

The link itself never takes effect here. Only a downloadable TrueType font can be the extension font, and no resident font is one: ^A@ answers File 'Z:TT0003M_.TTF' does not exist for the TrueType path a printer carries. So the extension font is always a font that ~DY or ~DU placed on a device, and this renderer does not read a downloaded font file. A field that needs a character its font lacks keeps the renderer's own font substitution.

That is the same gap as the ~DY font download, not a second one, and it closes when downloaded fonts render.

Differences from the specification

Labelary against the ZPL II guide

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

  • Labelary documents ^FL, which the ZPL II Programming Guide's command index does not list; its reference is the only source for the argument list here. — 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.

  • Both engines read ^FL the same way and report the same problems. The link itself never takes effect here: it can only name a downloaded TTF or TTE, and this renderer does not read a downloaded font file. That is the same gap as the ~DY font download, not a second one. — not pinned by a test

Example

Linking a CJK font behind a Latin one, then printing a field that needs both. The third slot is the link indicator, and 1 makes the link. Both fonts have to be downloaded to the printer, so this renders as intended only where R:NOTOCJK.TTF and R:NOTO.TTF are present:

^XA
^FLR:NOTOCJK.TTF,R:NOTO.TTF,1
^FO50,50^A@N,40,40,R:NOTO.TTF^FDMixed script^FS
^XZ

Open in viewer