Optimizing Printed Barcodes

Thursday, June 25, 2009
Posted in: Verification

When I was a kid my Dad had his car serviced at a local garage where the proprietor had a sense of humor. Customers would pull up to the garage entrance where a sign instructed you to “Beep 2 ½ times”. My brother and I thought that was hilarious. We were easily entertained—but the logic has stuck with me, and applies to the challenge of matching barcode design software to the output device (printer) resolution.

Unless the printer is analog, the file and the printer must be optimized to each other. Like a horn beep or a hole in the ground, there ain’t no such thing as half a pixel. If the file and printer resolutions aren’t matched, the printer goes through all sorts of gyrations trying to resolve the conflict. But the ultimate outcome is that lines are moved to new locations, not the ones that reside in the barcode specification, and this causes all sorts of mayhem in scanning and decoding. In verification it shows up in the ANSI parameter “decodability”.

For illustration purposes we’re going to tell you how to optimize a Subset C Code 128 barcode containing 30 digits.

But first, let’s standardize the nomenclature.

“Pixel” means the smallest dot a printer can produce.
“Element” means a bar or space in a barcode, regardless of width. A Subset C Code 128 has three possible bar or space widths.
“Module” means the X dimension which is the basic building block of a bar code. A Subset C Code 128 encodes pairs of characters, not individual characters, using 11 modules. The only exception to this rule is the stop code, which is 13 modules wide—the start code is 11 modules wide.

By “optimizing” I mean matching the design file (software) resolution to the printer or output device resolution. Barcode bars (elements) are usually printed in multiple pixel widths. “Optimizing” is defined as making sure elements (bars and spaces) are produced by whole pixels, not fractional pixels (which is impossible).Here’s how it’s done:

Calculate the printer resolution to determine pixel width. For example 300 DPI means that in one linear inch there are 300 possible pixels, so each pixel must be 1/300th of an inch or .00333 (three and one-third thousandths) of an inch wide.
At 240 DPI, pixels are .00417” wide, etc.
A 30-digit Code 128 (Subset C) contains 15 pairs of encoded characters, each comprised of 11 modules, or 165 modules. The start character adds another 11 modules and the stop character adds 13, so the total is 189 modules.
At 300 DPI, if each module is two pixels wide the symbol would be 1.25874 wide, not including quiet zones.
At 240 DPI, if each module is two pixels wide the symbol would be 1.57626” wide, not including quiet zones.

As you can see, you cannot simply define a symbol width and expect the printer to provide it. You must compromise to the nearest acceptable width because pixel width drives the outcome, and there are no fractional pixels.

Here’s what it looks like when you don’t optimize:
barcode_test_results

The “mayhem” is obvious. Bars are moved on their centers to new locations. If it is moved to the left, it steals real estate from the left space; if it is moved to the right, it steals it from the right space. If the bar width isn’t an even number of pixels, it is interpolated into some strange, new width which could be wider or narrower than specified. If it is wider, it steals the extra width from the flanking spaces. Yes, this is truly mayhem.

Anybody out there still think they don’t need to verify barcodes?

*Name	*Email
*Comment
*For security, enter the word you see below

Optimizing Printed Barcodes

Comments