The first thing we have to understand about barcodes is that we want to work on the microscopic level. That means one pixel at a time. The quickest way I found to get started with that was to crack open the Paint application supplied with Windows or your favorite operating system and configure it as follows:
Use the Image>Resize facility to apply the dimensions of the barcode. For code 128, that’s 11 Horizontal by 1 Vertical. Not all barcodes will be only one pixel high, but most of them will be.
Next, select the tool. Since we want to adjust our 11×1 image one pixel at the time, we must select the Tool>Pencil. That’s the little guy in the upper left pictured here.
Finally our color pallet is the most boring available, black and white, so set your Colors up as follows:
That’s black for the foreground and white for the background, although I suppose it could be done the other way. The Zoom level should also be set to the maximum. For paint, that’s 800x. If you are brave enough to try this with Photoshop or some other editor you are more comfortable with, you might try 1600x. I believe the paint bitmap is just a bit too small. Next, resize your Paint application so it looks like mine. You may also want to turn on gridlines and rulers.
You now have a lean, mean barcode generating machine. Except that it isn’t really all that lean, we’ll get to that in a little while. The above final screen shot shows the bit pattern for the Code 128 symbol for the value 0. That’s the number zero, not the character zero. The character zero is a totally different animal. But before I get all confusing and lose you, you are possibly asking how I “know” that. I certainly wasn’t born with that bitmap and I am definitely not the author of the Code 128 specification.
I have a friend and it’s called http://en.wikipedia.org/wiki/Barcode. At that site, you can learn all about the barcode, its inventor, Norman Joseph Woodland (September 6th, 1921 – December 9th, 2012), his explanation of the symbols as Morse code, his co-inventor Bernard Silver (September 21st, 1924 – August 28th, 1963), and a wealth of other barcode related information.
Most useful on this page, for our discussion, is a link to the Code 128 “chart” found here. Please take some time to open that link up in a new browser tab, as I am not going to duplicate it here. For authoring barcodes, the two most important columns from that table are “Value” and “Bar/Space Pattern”. In fact the “Bar/Space Pattern” column is where the rubber meets the road and I am very grateful to the author for including it in that table. We will find that not all symbologies are documented so agreeably.
So let’s take a look at the “Bar/Space Pattern” or binary representation of the symbol for the value of 0 (zero). The table has it as “11011001100” that’s eleven binary bits of information and it succinctly and completely describes the symbol. There is no need to measure rectangle widths or the width of the white space between bars. “11011001100” is all we need to know. If you recall the screenshot in Figure 5, examine the name of the file in the title bar. It’s 128_0.png. That’s a naming convention I have adopted to keep the PNG files straight. PNG stands for Portable Network Graphics and is a lossless graphics format supported universally by web browsers. The keywords in the previous sentence are “lossless” and “supported”. Any graphics file format used must be lossless to prevent corruption of the integrity of the file, and supported to provide interoperability between web browsers, word processors, document publishing systems and printing software.
It is evident by the binary representation of the number zero (11011001100) and the bitmap visible in the canvas area of the paint program that black pixels represent ones and white pixels represent zeros. For the Code 128 symbology, there are 107 unique binary patterns. It took me a couple of hours, but I actually sat down and implemented all of them. You are welcome to repeat my efforts, but the Code 128 Barcode page on this website (link found at the top) is ready for use.
For demonstration purposes, let’s look at what Paint does with our miniscule masterpiece. I’ve copied the Code 128 symbol for the exclamation character (or the numerals “01” if you are using 128C) into a working file and brought it up in Paint. That’s “11001101100” for all you people who think in binary. Here is the picture in Figure 1.
What paint does is conform the graphical description you see in the bitmap drawing into a standard PNG file format as Paint understands them. When you view the saved file in HEX/ASCII (using UltraEdit or some other programming editor / viewer), you’ll see what I typically call “bloat”. This is the waste generated when you try to use a general purpose tool to get something specific done.
For many of you, the ASCII representation of the bytes in the file holds the most information, so I will direct your attention there. I won’t go into too much detail on the file layout of PNGs, so if you are curious about exactly how they are structured, you’ll want to read that elsewhere.
Probably the best place on the web to view information on the PNG file format is Greg Roelofs’ book online at http://www.libpng.org/pub/png/book/cover.html. The book itself is out of print, so you’ll need to use the online version or order it used.
Let’s examine the format as Paint stores them, then as we would like to have them for our barcode support.
I’ve highlighted the chunk names in the file as saved by the Paint program. All PNG files must have a file signature (&PNG), a header chunk (IHDR), a data chunk (IDAT) and an end indicator (IEND). The other chunks (sRGB, gAMA, pHYs, and tEXt) are useful for other processing applications or color images. We don’t use color and our goal is not to use the PNG file in its created format, so all of this information can go away. That “bloat” takes up a majority of each file’s byte count.
But we can’t just delete the extraneous information, because the Paint program saved our black and white image as a full color picture. Removing the unneeded chunks would break the image integrity.
For the purpose of putting the graphic images on a diet, and reducing the amount of unnecessary data, I use Gimp. Gimp stands for GNU Image Manipulation Program and is free, user-supported software for image composition and authoring. You can learn more about Gimp and download it at http://www.gimp.org. Here is a screenshot:
As you can see, Gimp thinks our file is a 1-layer RGB color image. That’s what Paint is telling it, anyway. What we really want is a grayscale bitmap image with no extraneous data. So we will want to export this file with those attributes from Gimp to get our goal accomplished.
We select from Gimp’s menus “Image->Mode->Grayscale” to begin. This tells Gimp it can drop the color support from the file. Then we export the file by using “File->Export” from Gimp’s menu system and we are greeted with a dialog similar to the ones below:
We are going to want to change the default settings on the left with the ones on the right, which basically tells Gimp not to save any extraneous data.
Our new file looks the same when displayed, but it’s size has been reduced from 182 bytes to 82 bytes.
Our PNG file is still not in its ideal format. We would like to embed these files into HTML pages, providing true client-side scripting support for our applications. We’ll do this by using a base64 converter.
The final weblog entry in the current Code 128 Barcode series is about the finishing touches that had to be put on the Code 128 Barcodes to get them to be client-sided. This is useful if you want to generate HTML files that stand alone and can be placed on a memory stick or other media without having the browser rush back to the web server to pick up a bunch of graphics files. The real data behind each barcode is the PNG graphic that is represented by its Base 64 encoding.
Base 64 conversion is a very old technique for mapping the contents of a binary file into a subset of ASCII. This allows us to move binary information back and forth over communication channels without inadvertently triggering unwanted behavior on either side of the interface. You can assume that binary data contains bytes and words in all bit combinations under the sun. Some of these combinations can be reserved to invoke functions within the sending or receiving program.
Because we want to transfer the raw data back and forth without invoking functions we have to “mask” all of the special combinations behind data that is highly unlikely to be used by any but the most extreme programmers to trigger functions.
So the Base 64 encoding scheme utilizes characters that are fairly innocuous in byte streams and are not likely to be altered in transit by the sending or receiving application. Namely, it uses upper and lower case letters found in the English alphabet, numbers and a few characters used in mathematics (+, / and =). Base 64 encases binary data in a stream of these characters meant for human consumption by laying a message’s bits out end to end and having a CPU look up 6 bits at a time out of a table of 64 characters. On the receiving side, the computer looks the characters up in a table and builds three bytes (24 bits) out of the bits that it finds. This technique allows a lossless transfer of binary information between two systems at a relatively small (33.3%) amount of overhead.
Base 64 is important for our barcodes because it is what enables them to be client-side barcodes. In other words, we can create barcodes in a web browser without having any connection to the internet. You might think that’s not important, but when your computer is considered “down” because its connection to the internet is “down” then I would say that you are underutilizing your processing power. The enabling technique is to have the barcode “font” embedded in the webpage without having to download auxilliary files from a server which may or may not be operational onto a client platform which may or may not think these auxilliary files are a secure thing.
If you take a close look at the Code 128 Barcode page, you’ll find that each symbol has its binary data (the PNG files generated with the technique illustrated in the last installment) represented in Base 64. We explain this to the browser by the codewords in the ‘src’ field “data:image/png;base64,”. The rest of the data is the binary information of each code symbol represented in Base 64.
I suppose I could have rifled through old hard drives and tape backups to find the source code for a utility that I wrote in the C programming language many years ago to encode/decode Base 64. Instead, I spent about an hour and a half online with a Base 64 encoding website and individually encoded each of the 107 symbols.
After I had all the Base 64 encoded data, I spent another two hours or so prettying up the HTML encoding for all the images and adding the fly-over text, etc. In all, it probably took me ten hours to create and test these barcodes over the course of a week. I hope that you find them fun, amusing and/or useful. Feel free to try this technique in your own application.