Sure, if you know you're always going to be using a Zebra printer, and you control the whole pipe from software to the physical label, then you're going to have a lot more explicit control if you use ZPL over a PDF. But the second any of those presuppositions change, it's back to the drawing board. (Actually, even the Zebra assumption isn't sound, because they themselves are not always 100% reliable in following their own specifications. And the specifications... boy howdy.)
The old argument in favor of ZPL is that you can be much more precise with the instructions you're sending to your thermal, resulting in higher print quality, and therefore more reliable barcode scans and OCR. But the world doesn't stand still, and shipping carriers have been steadily improving their scanning capabilities over the last 20 years, even while thermal printer capabilities have remained largely stagnant. After all, USPS has to also optimize for people who are printing labels on shitty desktop inkets. The increase in barcode quality you'd get out of using ZPL is overkill.
TLDR: Save yourself a lot of heartache and just sling PDF's. Postscript/Ghostscript is so much easier to cajole into cooperation.
I find the print quality of PDFs perfect on Zebra's as long as you keep the following in mind:
- Make sure the DPI of the document is correct (e.g. 203dpi)
- Make sure the document does not need to be scaled (and scaling to fit is disabled) (for 4x6 that means 812 x 1218 pixels max)
- Make sure the document is black and white (no grayscale)
Some PDFs embed a single image in them, in which case you can do the following;
pdfimages -all <input_file>.pdf <out_prefix>
convert <generated_png>.png -filter point -density 203 -units PixelsPerInch out.png
I could be wrong, but I don't think pixel perfect barcodes are necessary with modern scanners. The only thing going for ZPL is the ability to store the label data as simple ASCII text.
- you can target PDF
- you’re married to a JS stack
- your motivation is (quoting the article)
> When you purchase a shipping label through them, they give you the output in either a PDF, PNG, or ZPL format. ZPL would be ideal, since it's just ASCII text which can easily be modified, or even stored in a database along side each order.
It seems like a much more reasonable intermediate format is SVG or JSX, both of which have mature to-PDF solutions, and both of which have much more well-known manipulation stories. Of course, that doesn’t lead to an absolutely bonkers blog title like this. But for anyone considering a similar setup, there are much more conservative options.
https://github.com/jhallen/joes-sandbox/tree/master/doc/zebr...
It's a simple macro-based typesetting language that can be used to quickly make many different label images from a database. You uploaded the compiled labels into a handheld computer so that labels could be printed on a production line. One option for the computer was the Psion Organizer II.
For next time you are stuck with that problem: qemu + binfmt_misc can transparently run cross-architecture apps, see https://ownyourbits.com/2018/06/13/transparently-running-bin...
[0] https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetoo...
Here's "driver" i did for star's receipt printer: https://git.cloudef.pw/escpos2raster.git/tree/src/bin/starpb...
Secret: Go to Alibaba and find suppliers that will sell you a Zebra ZP888 for around ~$125/unit. They're a Chinese-market version of the venerable LP2844, a workhorse in the shipping industry for over two decades now, and they're brand new.
Edit: Also forgot: If you use a service like Shippo (https://goshippo.com/), you can get an API that'll dump ZPL shipping labels out. Chain your warehouse system to Shippo for the label, then chain the ZPL out to the script and out to the printer.