When I've had to work with barcodes I found it easy enough to generate an image rather than using a font. Font mapping for things that aren't characters, like stop codes, is always a tricky business.
Yes, generating the image isn't that complicated, but getting them to scale correctly so that your label printer will produce a printed barcode that will both fit on the label and be readable by a barcode reader is a nightmare.
Having to scale a font seem to be much easier to deal with, but I might be wrong.
I’m a solo developer that built and maintains https://label.live, a label design and print app (Electron) that has the ability to generate barcodes thanks to the open source project BWIP-JS (and all the turtles beneath it).
My app renders canvas data down to 1-bit images and sends them off to the printer as raster images. Each printer handles image data a bit differently. Although Zebra printers do support in-printer-barcodes (put a barcode of type Z at x,y) I opted to send full-sized images for every label and lose efficiency for greater reproducibility. I also support DYMO and BROTHER thermal printers that do not have built in barcode support.
One of the things that people don’t think about (ie my loving users) is how a minimally sized barcode doubles in size due to DPI. If your barcode has narrow bars equaling one dot width, then your next choice larger is literally 2x the size. There is no gray in thermal printers, just black or white. And on the flip side, barcode scanners need the highest contrast to scan.
Where people get in trouble is pixel misalignment, thinking that you can scale a tiny barcode by 20% at 200 DPI. Nope, sorry dear user!
The last few years have been a ton of fun. I really enjoy HN posts about barcodes. It makes me feel relevant. Ha!
I made the bar widths configurable in the functions I wrote. If you know the DPI of your printer and how big you want your barcode to print, it's simple division to get that figure. I printed both to laser printers and Zebra label printers.
No, not blurring, you can only "stretch" a barcode so far, before the spacing confuses the scanner.
The issue we faced was a bit stupid and a result of trying to save money. The type of barcode we used, and I forget the type, was actually a little to large for the labels we wanted to use, and the labels where very skinny. Trying to maximize the size of the barcode, so our cheap scanner would read the, meant pushing the barcode almost to the edge of the label. That involved fiddling with the size and margins on the Zebra printers, and if you don't get it right the scanner would either fail to read the barcode because the margin was to small (at least our cheap scanners require a margin of some minimal size to identify where the bars start) or the lines where to short and scanners can't read the bars if they're to short.
The barcode standards themselves specify the amount of white space you need before and after the barcode proper. Even the cheapest scanners should work if you met that.
Especially for code 128C. I wrote a little image generator back in 2001-ish in the space of a few hours - the hardest part was just writing out the symbol table.
We need a modern opensource barcode reader. The best thing (zxing) is in maintenance mode, and the newer barcode scanners with niceties like neural scan, 90% scan, bortched barcode scan are all closed source.
I agree, I once took a shot at porting ZXing to the Microsoft Hololens. I was amazed that there aren't very many open source barcode interpreters available right now.
This is so true. It blows my mind that nothing exist beyond zxing. Barcodes are everywhere, and quick access to them is the gate-way to a million cool apps, etc.
My code probably would have worked with good image quality, but I wanted something more robust that would work with a cheap webcam. I imagine the pi camera module is about the same.
I had trouble understanding the example at first. It turns out that it relies on fonts.googleapis.com, so if you block that domain, the barcode is shown as regular text.
Thank you. Same problem. For the most part, I notice a great speedup and functionality improvement from blocking google fonts...The designer in my does die a little however when completely wrong fonts are rendered.
I just had a closer look and yes that's definitely the problem. Fonts require a 1:1 mapping between characters and outputs, there's no way to choose an output based on 2 consecutive digits so it needs to be mapped to an arbitrary character. If you scanned the resulting barcode I'm sure you'd see that it works just fine.
Good point, but that's probably too much work for a free font. Especially since you need to output a code to mode switch before you can use the 2-digit barcodes, the font won't have any way of knowing what mode you're in.
This is not possible for several reasons, one of which being that as mark-r says, Unicode defines the characters themselves; hence why a font works so well.
The second reason is that there are a LOT of barcode algorithms, so you would be duplicating the entire encodable codeblock (which is sometimes larger than ascii) a bunch of times.
The third issue is that barcode algorithms are not usually literal 1:1 stand ins. Barcodes usually have the equivalent of a header and footer, and often, a character will influence how the next one looks. At a guess, this font can (and probably does) handle that with font ligatures.
The bar coding itself. I had always figures it wuld be a direct replacement of letters/numbers, like a glyph, but when I input two characters e.g. pp, I do not get an exact doubling of the bar code.
I have a large project that uses qrcode stickers to identify hardware. I tried with barcodes and found that iOS doesn't scan them as quickly or easily.
There is a massive industry, sets of standards, and infrastructure relying upon barcodes. For example, anyone who does ships product to their partners as part of an EDI/X12 workflow utilizing advances shipping notifications, will need to be able to generate a UCC compliant shipping label.
Warehouse management systems, same story. In fact, in supply chain, QRCodes are extremely rare. All the portable "brick on a stick" wireless terminals rely upon barcodes.
Production workflow, where jobs move from station to station often rely on barcodes to identify jobs and components.
Not to mention the most obvious one: shopping. Cash register scanners don't do QRCode. They follow the UPC standard along with the entire retail industry. That's likely never going to change.
Hmm, a lot of the in-store imagers/readers are 2D capable now (eg: readers at HD and Kroger in USA). Not all, but when these facilities get a hardware refresh they get 2D - but still have nothing to read. Scanners have to be deployed first, then 2D can move to on-package
No, it's just not that simple. It's not a question of what readers are capable of. It's multiple universal standards that would have to change, and for what? Packaging has a bad enough time with UPS codes getting distorted to the point of being unreadable, and that would be even worse with 2D codes. Furthermore, 2D codes take longer to decode.
1D scanners are able to scan the entire surface of an object to find the codes quickly, or even two surfaces at the same time. Think cashiers again, quickly plowing through a cartload of merchandise. They don't have to aim to do that. They just have to know what side the barcode is on. It's a non-trivial engineering issue to make 2D as efficient to scan as 1D.
There is absolutely no reason to move to 2D codes for the majority of existing 2D applications.
You can read it with a led or laser, a motor with a mirror, a filter, a photodetector and a cheap microcontroller that cost cents.
The technology is so simple. A point of light moves and you get an output of ceros and ones, edges are supersharp.
There are lots of cheap chinese guns with the components already integrated.
If you have already a video camera and big microprocesor, QR are much better.Scanning barcodes with cameras is tricky, because barcodes edgess are blurry.
Professionals are going to use a gun anyway so it makes sense for them.
Also, QR codes don’t work too well with damaged or faded paper. Think receipts. 1D barcodes work much better there as there’s redundancy in the second direction. Basically, QR codes do have the advantage in the density department, but are more complicated (relatively) to parse and more susceptible to damage. Tradeoffs that depend on your situation.
This just isn't true. QR codes have a high degree of redundancy built into them via error correcting codes. For example there is the famous case of a bitcoin private key being recovered from a small amount of a qr code and a blurry shot of the full one[0].
My job involves scanning damaged codes of both types on a regular basis. QR codes are way more reliable than you'd expect, and will often scan even with partial codes, on damaged labels. Barcodes meanwhile always need a complete code to work.
Barcodes are easier and more reliably scanned by dedicated devices; QR codes are easier and more reliably scanned by general-purpose devices like phones.
I've used scores of different hardware readers (zebra, motorola, star, el-cheapo, etc). All of them read 2d faster than they read 1d. And we get a higher first-try success on 2d. IIRC 1d was like 80% and 2d was over 95%
C128(ABC) and 39 got the most testing (other players in my space like C128). I'd also like to add that the fail rate on C128 increased as the encoded values got complex. That is to say 15 numeric chars was "very reliable" but 17 alpha-numeric+1 symbol had was "very unreliable"
And if you're in the <12 digits only space C128 is still a safe choice
Yessir, that's my (perhaps unclear) point. Give it the trigger on the "complex" C128 and we get a read fail. But scan success on attempt 3 or 4. QR scans with high success on first bread.
Does QR include some kind of error correction code? That would be far more sophisticated than a checksum, and lead to more salvageable results from bad scans.
