How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
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).
Disagree that this is a novel horror—TTF hinting is already Turing complete, so it's not surprising someone could brute-force a QR renderer in it. Cursed, sure. Groundbreaking, not really.
I love seeing nonsense like that. How that work graphically though? Just keep adding to a same QR code that keeps getting denser as more text is added? I guess it doesn't have to practical though :)
TrueType hinting is Turing-complete, so it's possible in principle. The real constraint is the instruction execution limit rasterizers enforce — you'd need to fit QR generation logic within a budget designed for glyph outline nudging, not general computation.
Fair, that's Code 128 specifically - the checksum's computed from the encoded characters via mod 103, not something you type in. EAN13 does have its own manual check digit calc though, IIRC, just different algorithm entirely.
Neat! Barcodes are much more complex that I knew before looking into it. I used JsBarcode [1] to create a special barcode that reprograms a cheap barcode scanner we got on Amazon to be able to scan both UPS and FedEx tracking numbers. It is published on CodePen [2].
Love it. Flashbacks to CE1 and CE2 (2nd and 3rd grade in the US system) in a French embassy school, simultaneously handling "immersion in real french", "using a fountain pen for the first time", "different long division" (https://en.wikipedia.org/wiki/Long_division#Eurasia) and "different cursive" (I think the method I was coming from was D'Nealian? https://en.wikipedia.org/wiki/D%27Nealian)
Nice! That looks pretty similar to the one in "Cuadernos Rubio", a system that was super popular from the 60s to the 90s in Spain (that still exists) for learning handwriting in primary school.
Yeah cursive fonts are a pain to get right digitally. We ended up hand-tracing stroke connections in FontForge for a school project, way more finicky than block letters. This looks like someone actually solved that properly.
This would be more interesting if you wouldn’t need to calculate checksums yourself, and could just write the barcode value. Good luck doing that with something like Reed-Solomon (QR, Data Matrix, etc.) or the shenanigans they’re doing with GS1 DataBar.
The fact that this is standard practice does not mean that it is not perverse. It kind of works sanely for plain Code39 (and even then you will see effects of doing that in weird places, like VAG stamping human readable VIN on a chassis, including the Code39 start/stop symbols), once you start using barcode fonts for Code128-derived symbologies (ie. UPC/EAN) the whole thing becomes a pointless exercise.
They are simpler and can be read by more devices, especially legacy devices that are still pretty widely deployed. Other than that, not much to say in their favor. They have lower data density compared to 2D codes such as QR or datamatrix. Many linear barcode symbologies have weak or nonexistent error correction capability. But often you don't need that extra data, and the cost of changing processes and equipment to upgrade to a new barcode format is seen as not worth it.
Code 128 supports some ISO-8859-1 indeed, but it requires switching between encodings (there are 3 of them), and couldn't work with 128B (I guess the one used by the font, as it supports ASCII). See the table on Wikipedia: https://en.wikipedia.org/wiki/Code_128
Even with plain ASCII we sometime struggle with the various scanners, as they emulate keyboards. So for instance using : in the barcode as a separator of values becomes wonky if the OS has a different input language than expected.
Font-based barcodes go back to Crystal Reports and Bartender in the 90s, same tricks. Fine for print, terrible once someone scans at an angle or the renderer subpixel-hints the bars wrong.
