[HN Gopher] Writing a printer driver in JavaScript
___________________________________________________________________
Writing a printer driver in JavaScript
Author : pastudan
Score : 52 points
Date : 2022-02-01 14:21 UTC (2 days ago)
(HTM) web link (kubesail.com)
(TXT) w3m dump (kubesail.com)
| mschuster91 wrote:
| > But in this tarball's filter directory there are only x64 and
| x86 filters.
|
| 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...
| pastudan wrote:
| Thank you! I went down that rabbit hole, but didn't have as
| detailed of a guide to follow, and quickly gave up. I might
| still try this so it can show up as a native printer in CUPS.
| frankenst1 wrote:
| Misleading title. "Printer driver" suggests a piece of software
| which makes the printer accessible for other programs. The
| software in this article merely converts an image into a
| different format.
| Cloudef wrote:
| Lots of printers usually dont need a driver nowadays. They
| listen to some port where you can input data. Sometimes even
| simply netcat a pdf.
|
| Here's "driver" i did for star's receipt printer:
| https://git.cloudef.pw/escpos2raster.git/tree/src/bin/starpb...
| pastudan wrote:
| I suppose you're right... "CUPS Filter" might be a better word
| than "Driver", but I'm not sure most people would be familiar
| with that term before reading the full post. It would not be
| hard to add this script into CUPS as a filter so that it's
| accessible to all programs. At the end of the day, that's all
| that a driver is: a filter + a PPD, and the PPD already exists.
| AlisoPaletto wrote:
| davman wrote:
| I did something pretty similar for a Brother thermal printer, it
| took a couple of weeks and I completely lost my mind at one point
| when I tried to print a single pixel and it ended up as a
| gigantic block... https://daveirvine.me/#ninety_bytes_is_720_bits
| mikece wrote:
| The phrase "Just because you _can_ doesn 't mean you _should_ "
| immediately comes to mind.
| bauerd wrote:
| Similarly, some years ago I prototyped an ESC/POS client (?) for
| a Bluetooth thermal printer. It was implemented as a Chrome
| Extension/Chrome App pair, because only Apps were allowed to use
| Chrome's proprietary Bluetooth API back then. Extension and App
| communicated via postMessage IIRC. I was shocked how well that
| hack actually worked. Google then sunset Chrome Apps, and Web
| Bluetooth never happened.
| notpachet wrote:
| As someone who has spent an unfortunate amount of time working on
| shipping label software for ecommerce companies, my advice is to
| stay the hell away from ZPL. It's the layout language equivalent
| of C -- too many low-level footguns. Just send 4x6 PDF's to your
| thermal printer and be done with it. There are so many more
| tools, of much better quality, available for composing PDF's than
| you'll ever find for ZPL or other vendor-specific layout
| languages.
|
| 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.
| tcas wrote:
| As someone who's dealt with these protocols as well I agree.
|
| 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)
|
| ZPL is a beast.
|
| 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
|
| And then print the generated png.
| pastudan wrote:
| Completely agree. I tried scaling down the PDFs but Ghostscript
| on the Raspberry Pi is far slower than just scaling the 1200px
| wide PNG to 800px. I still got very readable barcodes, and a
| 100% delivery rate on my first batch of orders, even with that
| downsampling.
|
| 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.
| kayodelycaon wrote:
| Did you try using imagemagick to convert to the pdf?
___________________________________________________________________
(page generated 2022-02-03 23:01 UTC)