Libre Barcode Project | Hacker News Reader

Libre Barcode Project

graphicore.github.io

99 pointsarthur2e554 comments

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.

I found the opposite to be true.

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!

You generate a vector image and it works like a scalable font.

All standard label printer formats (EPL2, ZPL, etc) support barcodes directly, and have for decades.

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.

Assuming you’re talking about blurring due to raster images, wouldn’t vector images solve that? A font is (generally) just that: vectors, not pixels.

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.

I tried to write my own scanner in Python, but couldn't get it reliable enough to release.

Is there anything wrong with maintenance mode if it works?

In my experience it doesn't really work that well.

I was trying to make a barcode scanner out of a raspberry pi with a camera module during a hackathon once. What an absolute nightmare.

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.

Yeah, image quality was what made us abandon the idea but before that I found it really troublesome to setup and use zxing to do anything at all.

OpenCueCat?

I still have mine! It works as a regular bar code reader for helping organize my library

We’re too young to remember that awesome issue of Wired

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.

There seems to be a problem with code-128 where if you put multiple numbers in it doesn't work (e.g. 123456)

Code128 has a mandatory checksum, so I'm surprised they try to do it with a font.

Code39 is pretty common to convert into a font, since the checksum is optional.

Code 128 has a mode where it can encode 2 digits for every code. It's probably related to that somehow.

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.

> Fonts require a 1:1 mapping between characters and outputs, there's no way to choose an output based on 2 consecutive digits

IIRC ligatures break this constraint - that's how coding fonts get fancy glyphs for "==", "===", "=>" and so on.

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.

The free Fira Code [0] has them.

I don't have the knowledge to respond to your second point.

[0] https://github.com/tonsky/FiraCode

For the reverse, see zbar (https://github.com/mchehab/zbar)

[edit] Updated link

With an emoji for everything known to humankind one would think there were barcode characters in unicode but, nope.

Could be useful, probably not too hard to include but they have other priorities apparently...

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.

Unicode is about the characters themselves, not about the glyphs. Its fonts that provide the connection between them.

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.

It does repeat. Disable remote fonts and clear your cache you'll see. There's a special pattern at the start and at the end.

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.

Why do we use barcodes?

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.

It is simpler technology, just 1D.

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.

> Why do we use barcodes?

Barcode readers are cheaper.

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].

[0] https://www.freecodecamp.org/news/lets-enhance-how-we-found-...

I think the average QR code has what, 15-30% redundancy?

a 100 pixel high 1d barcode is 10,000% redundant in one axis :)

I found that if you damage one of the edges (with the positioning markers), most software will fail to read it.

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.

Actually barcode readers are expensive. Barcode printers are cheap though.

[Edit] I misunderstood the context as being optical scan codes vs other technologies, not 2d vs 1d

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%

There are many 1d standards. How many did you try?

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

That's an interesting observation. I'd expect C128 to be good because the checksum character should reject most bad scans.

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.

Reply on news.ycombinator.com