Do not do this unless you do not have any other choice. Preferrably use whatever native barcode support of the printer involved, if it does not have that, just generate the barcode as vector image or bitmap with a resolution that is a integer fraction of the printers resolution. Generating correct Code128 as a SVG is about the same amount of work as generating the correct input for some sort of barcode font (the hard part is determining the switches between character sets, not generating bars from bytes).
Shameless plug for my web-based Zint frontend: https://barcode.new (in-browser WASM)
I wrote it specifically because most online barcode generators don’t support vector output or suck in some other way: ads, signup necessary, code payload exposed to server-side processing etc.
Aside from obfuscating the source code to sell licenses, how does this benefit from WASM?
Barcodes have been generated for decades on low-resource embedded devices. Even what would have been a modest-to-low-end machine 25 years ago would have no problem handling the compute needed for this job.
On this end, it just looks like the user has to deal with the penalty of dealing with 1 MB of resources when hitting the main page.
The benefit of WASM in this case is that you can wrap a mature library written in C/C++ (in this case, Zint), and run it in a runtime that supports WASM, e.g. the browser. There's plenty of people who occasionally need to create barcodes, and not in some industrial, automated way, and a browser is just an easy way to accomplish that. Yes, you have 1MB loaded when you load the page, but hopefully that will be served from a cache.
One MEGAbyte?? How could you!?
I once worked at a company that used a Code39 font cartridge in HP Laserjets. When HP stopped putting font cartridge slots in their printers, I had the task of intercepting print jobs and detecting the font selection sequence, then taking the text and converting it to a Code128 bitmap graphic. It wasn't hard at all, kind of fun actually.
'font' cartridge? the what now?
You're one of today's lucky 10,000.
Like another poster said, laser printers "back in the day" were freestanding computers with various communications interfaces that happened to have fancy paper handling and printing peripherals attached. In the case of the Apple LaserWriter, for example, it was arguably a more powerful computer[0] than the Mac machines of the day that were sending print jobs to it.
There were different ROM "personalities" available for laser printers, some of which came on pluggable cartridges.
Check these links out:
- https://www.pagetable.com/?p=1673
- https://www.pagetable.com/?p=1721
- https://www.pagetable.com/?p=1850
Michael Steil, the blogger responsible for those links, has done work extracting code and PostScript data out of some of those old cartridges. It's a really cool aspect of retrocomputing many people aren't even aware of.
[0] https://web.archive.org/web/20240404213221/https://lowendmac...
In the dark ages, when printers were PostScript and more powerful (and expensive) than the computers which printed on them, you added fonts by installing additional hardware modules, similar to a game console cartridge.
They were ROM cards that stored extra typefaces or other PostScript functions.