Chapter 39: Disadvantages - No Lowercase or Extended ASCII |
Brief Summary |
At first glance, Code 39 appears to be a complete alphanumeric solution. It handles numbers, uppercase letters, and a handful of punctuation marks with ease. However, this convenience masks a fundamental limitation: Code 39, in its standard form, has no concept of lowercase letters or the full set of special characters that we take for granted on a modern computer keyboard. To access these characters, users must deploy the 'Full ASCII' variant. This workaround relies on a two-character shift system, effectively doubling the physical length of the barcode for any lowercase or special character. While this expands the symbology's utility, it exacerbates the existing drawback of low data density, presenting a significant challenge for industries that rely on small labels or need to encode detailed product information. This chapter explores how this limitation impacts real-world applications, forcing industries to choose between the simplicity of Code 39 and the spatial constraints of its extended variant. |
|
1. The Alphabet's Upper Half: The Origins of the Limitation |
To understand why a barcode cannot read a simple lowercase letter, we must look back to the origins of Code 39. Developed in 1974 by Intermec, Code 39 was a revolutionary step forward in automatic identification . Before its introduction, most barcodes were limited to numeric data. Code 39 was the first symbology to support both letters and numbers, opening the door for applications that required human-readable codes like part numbers or initials . |
The symbology was designed to encode a specific set of 43 characters. This set includes the digits 0 through 9, the 26 uppercase letters A through Z, and a small selection of special characters: the space, minus sign (-), period (.), dollar sign ($), slash (/), plus sign (+), and percent sign (%) . This seemingly arbitrary selection was a deliberate choice based on the symbology's encoding structure. |
Every character in Code 39 is represented by a pattern of five bars and four spaces. Within this pattern, three of the nine elements are wide, and six are narrow---hence the name 'Code 3 of 9' . The specific combination of wide and narrow elements for each character was defined by the original specification. Because there are only so many valid patterns (specifically, 43), the character set was fixed. There simply was no room for lowercase letters within this original framework. Adding them would have required redefining the fundamental encoding structure of the barcode, which would have broken compatibility with all existing readers. |
This limitation was not seen as a major flaw in the 1970s. The primary use cases for early barcodes were inventory tracking, logistics, and military applications, where data was often in the form of numeric IDs or uppercase alphanumeric codes. For many years, the 'no lowercase' rule was an accepted quirk of the technology, much like the fact that early computers often displayed only uppercase text. However, as computing became more sophisticated and barcodes were applied to a wider variety of data, the inability to encode a simple name like 'Smith' in its proper case became a significant hurdle. |
|
2. The Full ASCII Workaround: A Double-Edged Sword |
Faced with the growing demand for a more comprehensive character set, developers created an extension to the Code 39 specification, known by several names: Code 39 Full ASCII, Code 39 Extended, or Code 39 ASCII . This variant cleverly uses the existing 43-character set to represent all 128 characters defined in the standard ASCII (American Standard Code for Information Interchange) character set. |
The solution is a two-character shift system. In the Full ASCII variant, specific two-character combinations from the basic 43-character set are used as 'shift' codes to signal that the following character should be interpreted differently. For example, the lowercase 'a' is represented by the combination '+A', while the lowercase 'b' is represented by '+B' . The plus sign (+) acts as a signal to the barcode reader to interpret the following letter in a specific way (in this case, as lowercase). |
This approach was elegant because it required no changes to the barcode's physical structure or the fundamental reader hardware. It's purely a software-based translation. However, this elegance comes at a steep price. |
|
The Cost of Completeness: Doubled Length |
The most critical disadvantage of the Full ASCII variant is the devastating impact on data density. Since each lowercase letter or extended character is represented by two symbols instead of one, the physical length of the barcode increases dramatically. |
Consider a simple example. To encode the word 'CODE' (all uppercase), the barcode pattern is simply *CODE*, with each of the five characters (four letters plus start/stop delimiters) taking up the same amount of space. However, to encode the word 'code' (all lowercase), the barcode pattern becomes *+C+O+D+E* . For just four letters, the barcode length has effectively doubled. This is not a linear addition; it is a direct multiplication of the physical space required for any non-uppercase characters. |
The impact on a real-world label can be catastrophic. If a company needs to encode an email address, a file path, or even just a person's name with a capital first letter, the resulting barcode can become unwieldy. The low data density of standard Code 39 was already a recognized weakness. With the Full ASCII variant, the issue is compounded to the point where the barcode can easily become too long to fit on a standard label, especially for small products. |
|
Technical Considerations: The Reader and the *Asterisk |
This issue is further complicated by the fact that the barcode reader itself must be specifically configured to interpret Full ASCII codes. A standard reader set to its default, 'regular' Code 39 mode will not translate the '+A' pattern into an 'a'. Instead, it will simply transmit the literal characters '+' and 'A' to the connected system . For a business, this means that adopting the Full ASCII variant may not be as simple as using a different piece of software to generate the barcode. They must also ensure that every scanner in their supply chain is configured correctly. This introduces a potential point of failure, as a single misconfigured scanner could read a barcode and transmit the raw shifted code, causing errors in inventory or order processing. |
Furthermore, the start and stop characters (typically represented as an asterisk, *) are encoded in the same way in both regular and Full ASCII variants . This means the barcode itself does not automatically signal to the scanner that it is a Full ASCII barcode. The scanner must be told to look for these two-character shifts. This lack of automatic detection is another operational challenge for organizations looking to use the extended character set. |
|
3. Industry Impact: Real-World Applications and Constraints |
The choice between the simplicity of regular Code 39 and the expanded but lengthy Full ASCII variant is a critical decision for businesses. This section explores how different industries have navigated this limitation, often opting for the more compact variant to maintain efficiency. |
The Military and Defense Industry: The LOGMARS Standard |
One of the most prominent users of Code 39 is the United States Department of Defense (DoD), which adopted the symbology as part of its LOGMARS (Logistics Applications of Automated Marking and Reading Symbols) program . The DoD uses Code 39 to track millions of items, from small electronic components to large vehicle parts. |
In this environment, the 'no lowercase' rule is not a problem but a feature. Military identification systems often use a specific, standardized alphanumeric format for part numbers and serial numbers. These formats are usually designed to be all uppercase and numeric, making them perfect for standard Code 39. The use of uppercase-only codes is a deliberate choice to prevent human-readable errors. On a battlefield or in a busy warehouse, a lowercase letter can be misread or obscured, so the system is designed to avoid them entirely. |
The DoD application also highlights the importance of density. Military items can be very small, and the labels must adhere to strict size standards. Using the Full ASCII variant would double the length of the barcode for many items, potentially making them impossible to fit on the required label. Therefore, the rigid structure of the military's identification system and the physical constraints of the labels themselves make standard Code 39 the ideal choice. The limitation is not a disadvantage; it's a design constraint that ensures system integrity and logistical efficiency. |
|
The Automotive Industry: VINs and Assembly Lines |
Similar to the military, the automotive industry relies heavily on standardized data formats. The Vehicle Identification Number (VIN) is a prime example. This 17-character code, which is unique to every vehicle, consists of uppercase letters and numbers. It does not use lowercase letters or special punctuation marks. |
For automotive manufacturers, Code 39 is a robust, reliable, and easily scannable way to encode the VIN for tracking vehicles through the assembly process and for inventory management of parts . In a factory environment, speed and reliability are paramount. Barcode readers must be able to scan labels accurately under less-than-ideal lighting conditions, at high speeds, and often from varying distances. |
The low data density of Code 39 is actually an advantage in this environment. The wide, chunky bars are easier for industrial scanners to read than the more compact patterns of a symbology like Code 128. The absence of a check digit in the standard Code 39 is mitigated by the self-checking nature of the code . An error in printing one bar is unlikely to produce another valid character, so the risk of a misread is low. Because the data to be encoded is standardized and uppercase, the automotive industry enjoys the benefits of Code 39 without having to deal with its most significant limitation. |
|
Government, Healthcare, and Postal Services |
The U.S. government and many state agencies also make extensive use of Code 39 for asset tracking, document management, and identification cards . In many of these cases, the data is again restricted to the standard 43-character set. Employee IDs, equipment tags, and reference numbers are frequently designed to be uppercase alphanumeric to comply with legacy systems and to ensure human readability. |
In the healthcare sector, Code 39 is used via standards like HIBCC (Health Industry Business Communications Council) . This organization defines standards for labeling medical devices, which often require a specific, alphanumeric format. This format is designed to be compatible with the standard 43-character set of Code 39, ensuring that medical device labels are scannable by a wide variety of equipment. |
The postal service uses Code 39, although the Universal Postal Union recommends Code 128 for its superior density . The need to encode complex routing information often necessitates the more compact symbology. |
|
Manufacturing and Logistics: The Challenge of Variable Data |
The limitation of Code 39's character set becomes most apparent in manufacturing and logistics environments that require labels with variable data, such as customer names, product descriptions, or order-specific instructions. In these scenarios, companies frequently need to use lower-case letters, and often special characters like parentheses, slashes, and ampersands. |
For example, consider a high-end logistics company that ships premium consumer goods. They might want to print a label that includes the customer's name and a short description of the item. Encoding 'John Doe' in standard Code 39 is impossible because it uses a lowercase 'o' and a lowercase 'e'. To encode this, they must use the Full ASCII variant, resulting in a barcode pattern that is significantly longer. If the company also needs to include a reference number and a tracking code, the label's barcode area could easily become enormous, taking up more space than the label itself. |
This creates a practical dilemma. If the label is too big, it won't fit on the package. If the company compresses the barcode to make it fit, the bars become too small and narrow, making it difficult or impossible for standard scanners to read them. In such cases, companies are often forced to abandon Code 39 entirely and adopt a more modern, compact symbology like Code 128, which can encode the full ASCII character set without doubling the length of the code. |
|
4. Comparative Perspectives |
To fully appreciate the disadvantage of the missing lowercase and extended ASCII, it's helpful to contrast Code 39 with other barcode symbologies. This comparison illustrates why, despite its ubiquity, Code 39 is often the wrong choice for modern applications that require rich data. |
The Code 128 Alternative: The Superior Successor |
Code 128 is a high-density linear barcode symbology introduced in 1981. It is specifically designed to address the limitations of Code 39. In terms of our focus, Code 128 offers a decisive advantage: it can directly encode all 128 ASCII characters without the need for a space-doubling 'shift' mechanism . |
This means that a Code 128 barcode encoding the word 'code' is only a few characters longer than one encoding 'CODE.' The density of Code 128 is significantly higher than Code 39's anyway, so even with the lower-case letters, the Code 128 barcode is much more compact than its Code 39 Full ASCII counterpart. For any application that requires encoding diverse data---like names, descriptions, or special characters---Code 128 is simply superior. |
Code 128 also includes an optional check digit, which adds another layer of error detection . While Code 39 is self-checking, it does not have a built-in check digit in the same way, making Code 128 more robust for critical data. The success of Code 128 is a testament to the fact that the industry recognized the limitations of Code 39, particularly its low density and restricted character set, and actively developed a better alternative. |
Code 93: A More Compact Code 39 |
Another alternative is Code 93. As the name suggests, it is a more compact version of Code 39. It was developed to provide higher data density and security while maintaining the same character set . Code 93 encodes 43 characters, just like Code 39, but it does so in a more space-efficient way. |
However, Code 93 suffers from the exact same limitation as Code 39 when it comes to lowercase letters. The Full ASCII variant of Code 93 exists and uses the same two-character shift mechanism. So, while Code 93 offers better density for uppercase data, it does not solve the fundamental problem of encoding lowercase characters without doubling the barcode's length. For industries stuck with legacy systems that require a 9-element barcode, Code 93 is a slight upgrade, but it is ultimately a patch, not a solution. |
|
5. The Enduring Appeal: Why Still Use Code 39 |
Given these severe limitations, one might wonder why Code 39 remains in use at all. The answer lies in its simplicity and legacy. |
Ubiquity and Legacy |
Code 39 is ubiquitous. It is the 'lingua franca' of older barcode systems. Because it was one of the first widely adopted alphanumeric symbologies, it is hardwired into millions of systems, printers, and scanners. Replacing these systems is expensive and time-consuming. |
Many legacy systems, especially in government and military applications, are not designed to handle lowercase data anyway. Their databases are built on uppercase alphanumeric formats, and the people using them are accustomed to that constraint. In these environments, Code 39 remains a perfect fit. |
Ease of Use and Printability |
Code 39 is incredibly easy to generate. Many printers support it natively, and a barcode font can be installed on almost any computer . This do-it-yourself nature makes it a default choice for small businesses and hobbyists. |
Furthermore, the lower data density means the bars themselves are wider and more forgiving. Code 39 is robust to minor printing defects like ink spread or a slightly scratched surface . This ruggedness is why it persists in industrial environments where labels are exposed to harsh conditions. |
Detailed Summary |
The story of Code 39's lowercase limitation is a story of technological progress and the constraints of legacy systems. While Code 39 was a groundbreaking achievement that democratized barcoding, its rigid character set reflects the era of its creation. The 'no lowercase' rule is not just a minor inconvenience; it is a fundamental architectural flaw that forces a difficult choice upon users. |
The Full ASCII variant provides a clever but technically awkward workaround. By using two-character shifts, it opens the door to encoding the full ASCII set. However, the price---a doubling of the barcode length for any affected character---is often too high to pay. This spatial penalty directly impacts real-world applications, making Code 39 impractical for many modern use cases where data is rich and labels are small. |
In practice, this has led to a fascinating divergence. On one hand, Code 39 thrives in 'industrial' environments like the military, automotive, and healthcare sectors, where data is standardized and the self-checking nature of the code is valued. In these cases, the 'disadvantage' of no lowercase is a non-issue, as the data is deliberately designed to fit the format. On the other hand, in commercial, retail, and logistics environments where variable data is the norm, the limitation is often a deal-breaker, forcing a migration to more modern symbologies like Code 128. |
|
Ultimately, the absence of lowercase letters and extended ASCII in standard Code 39 serves as a stark reminder of the trade-offs inherent in technology. The symbology offers unparalleled simplicity, reliability, and compatibility, but only for those willing to work within its predetermined constraints. For everyone else, the Full ASCII variant is a cautionary tale: sometimes, what seems like a solution can create more problems than it solves. |
cs@easiersoft.com