Live data from Hacker News

Libre Barcode Project

graphicore.github.io

61–70 of 71 posts

Re: Libre Barcode Project

#61
post #24

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…

I did exactly that ( bitmap ) for a retail application back in ~2000. It was just a couple of constants for the stop and start sigils plus an array of bits for the digits....it was a quick work.

Re: Libre Barcode Project

#62

Earlier quoted context omitted.

'font' cartridge? the what now?

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.

The links someone else shared are pretty cool, a little before my time (born late 80s). That's kinda neat, it makes me think of a post on HN some time back by Donald Knuth on the letter S and the technical challenges back then about that as a letter, mathmatically. I'm guessing given that, that's why printers needed these modules and were set up this way. Neat!

Re: Libre Barcode Project

#63

Earlier quoted context omitted.

'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 diffe…

commented elsewhere but The links you shared are pretty cool, a little before my time (born late 80s). That's kinda neat, it makes me think of a post on HN some time back by Donald Knuth on the letter S and the technical challenges back then about that as a letter, mathmatically. I'm guessing given that, that's why printers needed these modules and were set up this way. Neat!

Re: Libre Barcode Project

#64

Earlier quoted context omitted.

'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 diffe…

And if you don't know the origin of the phrase "lucky 10,000" then it's your lucky day too!

https://xkcd.com/1053/

Re: Libre Barcode Project

#65

Earlier quoted context omitted.

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 diffe…

commented elsewhere but The links you shared are pretty cool, a little before my time (born late 80s). That's kinda neat, it makes me think of a post on HN some time back by Donald Knuth on the letter S and the technical challenges back then about that as a letter, mathmatically. I'm guessing given that, that's why printers needed these modules and were set up this way. Neat!

The LaserWriter was like something from the future compared to the Laserjet. I think they used the same Canon print engine, but the HP was far less sophisticated. It only used bitmap fonts, nothing scalable like Adobe's Type 1 for Postscript. Knuth probably used a supercomputer for his typesetting.

Re: Libre Barcode Project

#66
post #35

Earlier quoted context omitted.

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?

Don't say it too loudly. I'm sure HP would love to introduce 'Font as a service'

Re: Libre Barcode Project

#67
post #24

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…

I'm sorry, after reading your comment several times I still don't understand why we shouldn't use this. What is the problem with it?

Re: Libre Barcode Project

#68

Earlier quoted context omitted.

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 mai…

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 f…

> There's plenty of people who occasionally need to create barcodes

> hopefully that [1MB] will be served from a cache

Re: Libre Barcode Project

#69

Earlier quoted context omitted.

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 f…

As a connoisseur of SVG, I like the approach, the results, the use of Zint and WASM. That said, there are a few opportunities. The version string isn't needed these days, nor the XML header or the doctype. The code/url/page title can go in the SVG title, to make it show on mouseover. The id=barcode is also superfluous. Since id codes should be unique, this could be a problem when many QR codes exist on a page. The ba…

This is super cool, thank you!

The SVG is actually generated by Zint itself, only lightly patched in the wrapper. Zint is a pretty old barcode generator (not meant disrespectfully, quite the opposite actually), it's quite possible that some of its decisions when rendering to SVG are out of date or very conservative. The use of id/global namespace does feel like a potential pain point though, which I will take up with the upstream project.

Post reply on HN