[CTS 1] Expanded Bar Code capabilities

[PhilterPaper]

Subject: CTS 1 - Expanded Bar Code capabilities January 31, 2017, 02:12:57 PM by Phil

The BarCode area of PDF::Builder 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::Builder 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::Builder, 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.

February 09, 2017, 09:37:54 AM by 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::Builder implementation, or is it performance?

April 01, 2017, 12:26:38 PM by 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.

[PhilterPaper]

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.

[PhilterPaper]

See #46 for a suggestion that possibly there is a bug in the barcode code that produces bad XObject Form entries.

[PhilterPaper]

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.

[PhilterPaper]

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.

[PhilterPaper]

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. :(

[PhilterPaper]

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

[PhilterPaper]

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.

[PhilterPaper]

Once in a while I take another look at implementing bar codes. GD::Barcode still looks pretty good, although it's still missing Codabar and Code128 (and Code93 is a separate package). An idea I'm kicking around is to release a library containing all the Public Domain bar code generator algorithms, that would produce a generic format line/thickness/length and space/thickness length set of commands, along with a minimum quiet zone around it and where to write human-readable text. It would take the BC content and validate or add check digits, as well as verifying the alphabet and the length. This would be returned to a renderer that actually draws the BC on the desired device (PDF via PDF::Builder, GD, HTML, Javascript/Nodejs, etc.) at the desired size.

No package out there seems to include all the desired bar codes. GD::Barcode comes close, but is missing Codabar, Code128, and Code93 (the last available in a separate package). There are lots and lots of packages on both CPAN and GitHub producing lots and lots of different format bar codes. I'm wondering if it would be worth grabbing all the algorithms for all the different BCs from all these packages (with proper acknowledgment, of course), and consolidating them into this one library. PDF::Builder would then only have a generic driver for rendering the requested code, and would not have to be updated when new BCs are added to this package. The package would be extremely generic (no rendering) and so could be used for a wide variety of outputs (back ends). It could have new BCs added to it frequently.

If someone out there is looking for a project, perhaps they would be interested in this one? If so, please leave a comment here that you are attempting it, so that I don't waste time reinventing the wheel by working on it at the same time!

[PhilterPaper]

A barcode library that produces a "generic" graphics output (just lines, text, color) would not need to have a full SVG renderer (see #89) -- it could output directly to the same routine used for, say, an HPGL library (or, eventually, the SVG reader itself?). It might even be simply GD output, letting us use the existing GD graphics library support, but I think it may only be raster output, which is not desirable.

[PhilterPaper]

As discussed in #89, I'm thinking of using HP-GL as the "generic" graphics language to do the rendering (convert to PDF primitives) of the barcode routine outputs. Since barcodes shouldn't be scaled up or down all that much, I don't know how critical it would be to use scalable vector output rather than raster graphics.

Add: Johan Vromans (@sciurius) is writing an SVG-to-PDF XObject library (name not yet certain), which sounds usable for not only Bar Codes in PDF::Builder, but also general SVG image file usage, equations (via MathJax), and GnuPlot graphing. I'm looking forward to using it! BTW, there are supposedly HP-GL-to-SVG converters, so if for some reason you have HP-GL to plot, it should be possible to convert it to SVG and incorporate it into a PDF or HTML document. However, at this point, I'm no longer planning to support HP-GL as a "generic" graphics language (but use SVG instead).

[PhilterPaper]

First of all, Johan's SVG-to-PDF library has been released as SVGPDF. Second, I just put out to GitHub changes to implement image_svg() and make use of SVG images (using SVGPDF). I hope to get PDF::Builder 3.027 out to CPAN by the end of the month.

Regarding the expanded bar code capability, I just came across SVG::Barcode::QRCode, SVG::Barcode::DataMatrix, and SVG::Barcode::Code128 on CPAN. I think they only output the three specific bar codes, but could be expanded to implement others. Unfortunately, they do appear to use various libraries that do not necessarily come standard with various OS's, so that will still need to be investigated. A Pure Perl solution would be desirable from the point of view of a clean install, but undesirable from the POV of the extra work needed to create each bar code. Anyway, that might be a good point of departure... maybe the owner will accept many additional formats?

[sciurius]

At first glance they all look Pure Perl.

[PhilterPaper]

SVG::Barcode::QRCode uses Text::QRCode which in turn expects the libqrencode library to be installed. Apparently that's fine on Linux, but it's not available on Windows and will have to be built and installed. I really hate the thought of telling some random Windows user that if they want to produce QRcodes in their PDF documents, there are a whole bunch of extra complicated steps they'll have to perform. And I can only tell them how to do it with Strawberry Perl; I have no idea about others such as ActiveState.