Barcoding Project: Producing Scannable Barcodes

Producing barcode labels requires a number of different hardware and software components. There are many different combinations of these that may work for different setups, but here is what is working for us. 

*  *  *

First, we had to consider how we would be generating the labels. We already use Crystal Reports to connect to our database and produce reports, and luckily Crystal Reports is able to generate dynamic barcodes both out-of-the-box and with purchased add-ons. While it is possible to invest in other barcoding software to do the trick (such as a standalone barcode label program like BarTender), it made more sense (and cost less money) to try and incorporate barcodes into our already-existing system of Crystal Reports labels and printouts.

Next, we needed to be able to encode the relevant information into a barcode that the scanner would read—for us, that means we will need to encode the accession number for each object barcode and a number randomly assigned to each location record by our database (the key field) for every location barcode.

We chose to use a 1D barcode style; these are the standard linear barcodes you might see on a box of cereal at the grocery store. There are also 2D barcodes—these are the small, square-shaped barcodes that have become more popular in recent years to encode large amounts of information, typically seen in advertising. As 2D barcodes tend to be more difficult for a barcode scanner to read, and the information needing to be encoded is reasonably simple, we decided to stick with the 1D barcode option.

There are a great number of 1D barcode symbologies (think of them as different barcode alphabets), but we initially settled on Code 39 as it is commonly used and generally easy for barcode scanners to read because it only encodes the Roman alphabet (no distinction between upper and lowercase letters), numbers, and a handful of special characters. Unfortunately, we quickly realized during our testing phase that a Code 39 symbology was unable to properly encode even our relatively simple accession number system and that even when it did work, the barcodes were sometimes exceptionally long. We then decided to try Code 128 barcodes, which allow for a much greater range of special characters to be encoded into the barcode. We have been using it so far and it seems to work just fine for us.

We researched two ways to create dynamic barcodes in Crystal Reports: one is to use a barcode font in conjunction with a formula within the program, and the other is to use only a formula that produces barcode images within the report. We learned that the out-of-the-box barcode font that comes with Crystal Reports was not complex enough to encode our accession numbers. We then downloaded the demo version of the BarcodeWiz barcode font software that gives you a number of Code 39 and Code 128 barcode styles to choose from as well as the formulas necessary to produce them in Crystal Reports. For comparison, the demo version of the IDAutomation Native Linear Barcode Generator for Crystal Reports was also downloaded for testing, which is the style of software that generates an image of a barcode with a formula.

Both have their advantages and drawbacks. The BarcodeWiz barcode fonts have good readability with the scanner, but we discovered that there is a problem with the Crystal Reports Viewer that will not allow these barcodes to display when generated on remote computers—so, the computers in museum collections around campus would not necessarily be able to generate them.  The barcode images made with the IDAutomation software will generate successfully on remote computers, but there are some reported issues with their readability when printed with thermal printing technology.

In the end, we have resolved to purchase both and use either method where appropriate. It should not make any difference in how the scanner reads each barcode and will allow us to overcome the disadvantages of either method.