I couldn’t believe how expensive the software was for writing barcodes, so I wrote a short program in R to do it for FREE. And, frankly it should be faster and easier if you already have your labels in an Excel file. You don’t really need to understand the program or even R functions to use it, as long as you know how to run an R program.
Setup and Overview:
[UPDATED (see notes below)] – R-code. Start with this (Note I could not upload a .R file, so this is .txt but still an R program).
Input – barcodes128.csv – You need this file to run the program. Save it in your working directory (see comments in R code for how to set this). AND labels.csv – This is a sample file showing the format for your labels. Even though it’s a .csv, it is a single column with each label as a separate row, so there are no actual commas
Output – BarcodesOut.pdf – A sample output: a pdf file for the 0.5″x1.75″ Worth Poly Label WP0517 (Polyester Label Stock), currently in the lab
That’s really all you need to know, everything that follows is extraneous info. If you have any problems, check out the Detailed Instructions, Troubleshooting Tips, or add a comment below.
I’m doing this for a few reasons: First, it looks like the labelRIGHT software in Kathryn’s Blog post is gone or not working properly on the lab computer. Second, I want to print barcodes from my own computer. Third, I want to have something that I can integrate with other automated software down the line for dealing with large numbers of seed samples. Fourth, it seemed like a fun challenge, but turned out not to be so much fun or challenging. But a little R-exercise is never a bad thing.
There are a number of different barcode formats, but I’m going to start with the relatively simple ‘Code 128’, which is a 1-dimensional code that can use any of the 128 ASCII characters, which should work well for plant tags. After reading the Wikipedia entry it seemed relatively simple. The hardest part was calculating the check character. At some point in the future I might write a 2D version to integrate with Android software… maybe…
How it works:
Details of this method should be evident when you read through the Wikipedia link and then the R code. Briefly, each character is defined by a series of wide and narrow lines. From there, it’s just a matter of translating an input code to a series of these lines, and then outputting them in a size that works for plant tags.
It’s not as hard as it seems because the Wikipedia page provides a binary code for each ASCII character. This binary represents black and white lines, so for each label it’s just a matter of:
- Read the label.
- Break-up the label string into individual characters.
- Translate each character into its corresponding binary code.
- Combine the binaries for each character into a long string of 1s and 0s.
- Calculate the check code character and translate to its corresponding binary.
- Add ‘quiet zones’ of 10 zeros, start code, check code and stop code.
- Set up the pdf and graphics output.
- Draw the barcode using the binary code. This is essentially just a graph: Moving from 0 to N where N=number of binary digits in the barcode, draw a black (1) or white (0) vertical line.
- Add the label name in regular ASCII since most of us are not fluent in Code128.
- Close the pdf file
Detailed instructions (follow along in the R comments):
1. Save the ASCII barcode conversion file “barcodes128.csv” in your R working directory. Here are a few lines of the file:
ASCII holds the ASCII code for each character (e.g. 32 is the ASCII number for space, 33 is !, etc.)
Barcode is a binary code that will be used to convert each ASCII character into the corresponding lines (1) and spaces (0).
2. Create a .csv file for your barcode labels. If you are using Excel, just create a single column with each label in a separate row, then choose “Save As” and then in the pull-down tab in the save window choose “.csv”. You can save this as “labels.csv” in you R working directory if you don’t want to bother changing the file name in the R code.
3. Change the ‘setwd()’ from “C:/Users/Alliaria/Documents/Barcode Generator” to the path of your working directory (containing ‘barcodes.csv’ and ‘labels.csv’). This is where the pdf will be saved.
4. Run the script.
5. Open the pdf and print!
Barcodes not lining up correctly with the labels. Make sure you choose ‘Actual Size’ in the Print Options. The output is a paper of EXACTLY 8.5”x 11” dimension. Unfortunately, when I initially printed from Acrobat Reader, the settings default to ‘fit’ (sometimes called ‘scale to fit page’). This messed up all the margins.
Want to use a different paper/size. This is possible but you will have to mess around with the ‘par’ and ‘pdf’ settings to get all the margins to line up.
Long label name not scanning properly. There is no strict limit to the number of characters you can use. However, the line width scales down as the number of characters increases to fit on the page, so at some point the lines will be too thin for the printer. Shorten the label name or buy a better printer.
Moderate/short label not scanning properly. Make sure you are using ASCII characters and the correct ‘start code’ if you use anything other than basic alphanumeric characters. See the StartCode variable and the Wikipedia link for more info about this.
[UPDATE OCTOBER 30, 2012]
Here is updated R-code (DIYBarcodes.R), with a couple small additions:
1. User-defined “blankgraphs” – sets N blank labels before adding the “labels.csv” labels. This is useful for printing on partially-used pages. Simply count the number of used/empty labels and input that to “blankgraphs”. Note that the numbering is across columns, then down rows, so for example the top-left is #1, and top-right is #4, and the first label in the second row is #5.
2. Limit to label length – “MaxLength” variable was added and set to 15. I have found out (the hard way) that this is the maximum number of characters that can be scanned by our WORTHData Tricoders. Labels can still exceed this length but will be printed without a barcode and instead will have an error message “CODE TOO LONG”. For this reason you should inspect the PDF output file before printing.