[Phil]

The BarCode area of PDF::API2 already creates a number of bar codes. I need to print out examples of each, to tell for sure, but I think they are all (or mostly) "one dimensional" bar codes. PDF::API2 needs some "2D" barcodes (look like badly pixelated images) and QR codes (those funky square things you scan with a smartphone). Preference would be given to standalone libraries (not requiring a dependency on other libraries), but where that would involve a ridiculous amount of code to be added to PDF::API2, a glue interface to another (existing and currently supported) CPAN module would be acceptable. 

Depending on how many flavors of 2D and QR codes we might end up supporting, we should think about the organization up font. If there are enough, there could be BarCode2D/ and QRCode/ directories as siblings of Resource/XObject/Form/BarCode/.

And of course, additional "1D" barcodes are always welcome, so long as they are in reasonably wide use. No "company-proprietary" or experimental/one-off codes, please.

[Phil]

In RT 119962, there was a comment that the API3 version of one of the barcodes (2of5int) "seems to work better". It might be worth looking at the PDF::API3 package and seeing if indeed, anything works better, and if so, was it because something was rewritten before the project was abandoned? It might be something very general in the support, or the barcode module itself was redone. Of course, the first thing to know is what is "better" -- is there a bug in the PDF::API2 implementation, or is it performance?

[Phil]

I have added a demo file examples/BarCode.pl for release 3.003 to generate all 11 barcode variations currently supported. I have no way of telling whether the bar codes are in fact correct. it would probably take someone with various scanners to determine whether they are correct, and do more testing within each type (valid characters, etc.). They look nice, though.

It would be nice to add at least the various forms of UPC bar codes — anyone up for a project? Then come 2D and QR codes.

[Phil]

 PhilterPaper commented Dec 29

Vector-QRCode-IntoPDF might be a good starting point for QRCode support. I haven't looked at it in detail yet, but it uses PDF::API2 so it should translate easily.

Also look at PDF-Report "barcode.pl" for an example of using PDF::API2 barcodes -- this might improve the examples.

[Phil]

PhilterPaper commented Dec 31

See #46 [RT 119962 Found a bug when creating a new XObject Form] for a suggestion that possibly there is a bug in the barcode code that produces bad XObject Form entries.

[Phil]

The site freebarcodefonts.dobsonsw.com has several "free" barcode fonts, including Code 128, Interleaved 2 of 5, Codabar, USPS Postnet, Code 93, and Code 39. There are lots of tools for sale, and I have not yet checked the font licensing in detail (whether it's truly free) or whether it's even in a standard format that PDF::Builder could make use of. Anyway, it's an interesting alternative to drawing the codes line by line.

[Phil]

PDF::Reuse::Barcode looks like it might be interesting. It pulls in a lot of stuff, so it might be made "optional". It also does QR codes. If it's too dependent on the PDF::Reuse package itself, the algorithms might be pulled out into a simpler form (with due credit given to the author!).

barcodegen also looks interesting, but pulls in a lot of GD stuff and Image::Magick, so again it would have to be optional.

The current barcode support is very suspicious, producing what don't look like proper barcodes when scale changes, so the entire current support might have to be dropped in favor of something else.

[Phil]

GD::Barcode also looks nice, but may be missing a few key barcode types:  Code 128 and Codabar. To get a really complete set, we may have to combine several different barcode libraries into one.

[Phil]

I made a minor change in the barcode examples, to only specify the font used (for labels) once per page, instead of once per barcode. This reuse greatly cuts down on the size of the resulting PDF.

I'm still pondering why in some barcodes, bars (black) run together (touch). I'll still try to fix that, even if I bring in another barcode library (as optional alternative library).

[Phil]

The bars may not actually be run together, but may be an effect of various display drivers and resolutions. For example, my low-end laptop "runs together" a number of bars (in different barcodes on the example page), but the same PDF prints (almost) acceptably on my laser printer. At least, I can see the discrete bars, even if a laser scanner might not be able to reliably separate them. It remains to be seen if something needs to be done about "bleed" on the edges of black bars, something that may be even worse on an inkjet printer.