Home›Guides›Previewing and debugging EPL without a printer
Previewing and debugging EPL without a printer
Published:
EPL is the older Eltron language, and it is still in
service on a large installed base — which is exactly why it hurts: the
people who wrote the original templates have often moved on, and the
printers outlive the documentation. Reading an EPL job on screen is the
cheapest way to find out what it actually does.
A minimal EPL job, line by line
N
q812
Q1218,24
A50,50,0,4,1,1,N,"HELLO"
B50,120,0,1,3,7,80,B,"123456"
P1
N clears the image buffer — leave it out and the previous
job's content can print again. q sets the label width in
dots and Q the height plus the gap between labels.
A places text and B a barcode, both with
positional arguments. P prints; without it the printer
receives a description and does nothing with it.
Two things surprise people coming from ZPL. There is no field
terminator: an EPL line is complete in itself. And everything is dots —
there is no unit-bearing size command, so the label's physical size lives
entirely in q/Q and the media you loaded.
The findings you will actually meet
Unknown command — the line is not EPL; usually a
stray line from another language or a corrupted export.
Wrong field count — A and
B take a fixed number of comma-separated arguments. Miss one
and every following value lands in the wrong slot, so the command is
skipped instead of drawn wrongly.
Font outside 1–5 — the built-in font range the
preview draws. Double-byte sets 6 and 7 are not in it, and the finding
says so rather than substituting a different font silently.
Barcode type outside the supported set — the preview
covers Code 128 (type 1), Code 39 (3), EAN-13 (E30) and UPC-A (UA0);
anything else is reported, not faked.
Invalid rotation — EPL takes 0–3 for
0°/90°/180°/270°. A different value is a typo that changes the layout
silently on a real printer.
Empty barcode data — no symbol is produced, which on
paper reads as "the barcode did not print".
Commands the preview will not draw
D (density), S (speed), I
(character set), JF, ZB and ZT are
recognised and reported as printer-behaviour commands. They change how the
mechanism burns and feeds, not what the image contains, so drawing them
would be a lie. If your on-screen label is right and the printed one is
too light, too dark or feeding oddly, those are the lines to look at.
Stored-form commands (FS, FR, V,
?) are a different case: the preview has no printer memory,
so the form's content is drawn only when you paste the
FS…FE block itself — and a form that prints
shifted is usually a q/R setting, see
EPL label content shifted.
Migrating away from EPL
Many EPL fleets are being replaced by ZPL-capable hardware, and the
temptation is to translate line by line. The mapping is not mechanical:
EPL's positional arguments and ZPL's caret-prefixed fields express the
same ideas with different defaults, and the field terminator
(^FS) has no EPL counterpart to translate from. Rebuild the
layout from the measurements, then compare renders side by side rather
than trusting a conversion.
Start here: the EPL viewer renders the
job, the EPL validator lists findings,
and the command reference shows
every command the engine understands with its coverage level. If you are
not certain a file is EPL at all, the
language detector settles
it from the code.
