In a Windows World DOS Comes to the Rescue

The mysterious encoded-but-invisible Group Separator character is revealed.

By George Wright IV, 
Product Identification & Processing Systems Inc.

Things are not always what they seem. Many bar code application standards require non-printing “control” characters to be encoded in the symbol, but these characters do not show up on the screen when the encoded message is scanned into most PC programs. But that doesn’t mean the control characters aren’t encoded. This “invisibility” can be disconcerting to someone casually checking symbol encodation with a scanner connected to a PC instead of a bar code verifier.

These special characters are essential to the proper operation of bar code data collection systems where multiple data elements are contained in a single symbol. They act as field delimiters, and suitably programmed applications can and do make use of these embedded non-printing characters.

Fortunately, methods and programs do exist that can make these control characters visible on a PC screen for human review or to application programs not designed to discern  non-printing characters.

When GS1-128, GS1 DataMatrix, and other GS1 System bar codes have multiple variable-length data elements (fields), the end of a variable-length field that is not the last field must be delimited so that application software can know where that field ends and the next begins. This situation occurs, for example, when Lot Number is followed by Quantity, such as on HDMA-compliant product identification labels on shipping cases.

The special bar code character FNC1 (Function 1) is specified as the field separator. Since FNC1 is not in the ASCII character set, symbology standards dictate that when FNC1 is used as a field separator (it has other uses as well), a scanner must represent it in the transmitted data as the non-printing control character Group Separator or GS (decimal 29). This is the factory-default behavior of all compliant bar code scanners.

Unfortunately, when a data stream containing a GS character is sent to a PC via a USB or keyboard wedge interface, the transmitted GS character is essentially dropped and is not displayed in a Windows-based program such as Microsoft Notepad, Word, or Excel. It’s as though the FNC1 or GS were not encoded at all, even though the scanner is transmitting the GS character as required.

To the uninitiated, this behavior is completely bewildering. It can cause one to spend hours checking and rechecking the bar code format and experimenting with the scanner configuration to figure out what’s wrong. The fact is, nothing’s wrong (assuming, of course, that FNC1 is encoded and the scanner has not been reprogrammed by the user to strip out the GS character). Common PC applications are not designed to display a graphic representation or “glyph” for the control codes (ASCII values from 00-31). As the name implies, these characters have another purpose: they are meant to provide device control.

This is where DOS comes to the rescue. The key is to use a simple DOS text editor that is designed to display the standardized glyphs associated with the control codes. Figure 1 depicts the graphic representation of the character set of the original IBM PC. It is known as IBM PC or MS-DOS code page 437 (CP437). The first row of 32 glyphs represents the low-order ASCII values from 00-31, starting with NUL (null, essentially a non-significant blank space) and going through US (unit separator). Group Separator or GS (decimal 29) is depicted as “left right arrow” (↔).

A handy, open-source DOS text editor that displays all transmitted ASCII characters (and one we have tested and use at PIPS) is SuperTED (which can be downloaded at this link: http://www.pips.com/support_and_downloads.htm). The ZIP file will extract three files, including SUPERTED.DOC and TED.COM. Double-click on TED.COM, and a DOS window will open with the SuperTED text editor ready to accept scanned data. Scan the symbols on page 37 and all will be revealed. If your scanner has been set to append a Line Feed or LF (ASCII decimal value 10) suffix following the decoded data, you will see the “inverse white circle” character (◙) at the end of the line. Note that the cursor does not move to the next line; this editor displays the character, but does not interpret the control code and act on it.

Figure 2 shows two increasingly common examples in the healthcare supply chain of the use of FNC1 (transmitted as GS) as the required GS1 System field delimiter. The linear bar code is GS1-128. It encodes the secondary attribute data Expiration Date, Lot Number, and Quantity using AI(17), AI(10), and AI(30) as mandated for an HDMA-compliant product identification label on a shipping case. The FNC1 character is encoded as the field delimiter immediately preceding the “30” of AI(30). 

The 2–D bar code is GS1 DataMatrix. It encodes a 14-digit Global Trade Item Number (GTIN-14) followed by a unique Serial Number, Expiration Date, Lot Number, and Quantity using AI(01), AI(21), AI(17), AI(10), and AI(30) as it might appear as a complement to the GS1-128 symbols on an HDMA-compliant product identification label for a shipping case. Two FNC1 characters are encoded as field delimiters, immediately preceding the “17” of AI(17) and just before the “30” of AI(30). These two symbols are shown at approximately 80% of actual size and should be readily scannable from the print version of this article.
Of course, to confirm that the FNC1 symbology character is encoded in the symbol as specified (and not the literal GS character that is sometimes used in error), one needs to use a bar code print quality verifier.

Fortunately, the inability of ordinary PC applications to “see” and display control characters does not mean that a specialized bar code data collection application cannot see and interpret them. As long as the application is properly designed and it captures the decoded character string directly from the keyboard/USB buffer, these special characters can be used to parse the data as intended.

Sometimes, however, one needs to detect and act on the encoded FNC1 character within a Windows application that does not accommodate low-order ASCII characters. In this case a work-around is usually available.

Most modern bar code scanners can be programmed by the user to substitute one character in a decode string for another. For GS1 System applications, this means configuring the scanner to substitute a printable (but otherwise unused) ASCII character for the GS character. Two printable characters often chosen for this are the caret (“^”, decimal 94) and tilde (“~”, decimal 126). In established GS1 System usage, neither of these characters would ever appear as encoded data characters and therefore either one could be substituted for the GS field delimiter, thereby allowing the data to be parsed by an application programmed to treat the caret or tilde as a field delimiter.

Table I illustrates the appearance of data output from a scanner under the various scenarios described here for the symbols in Figure 2.

In summary, common Windows desktop applications do not understand or display low-order ASCII characters transmitted by a bar code scanner. However, suitably programmed business applications such as warehouse management systems, healthcare materials management information systems, and medication administration systems can and certainly must discern and process information based on a transmitted GS character.

A ready work-around to overcome the inability of common Windows applications to discern and act on an embedded GS character is to program the scanner to translate GS to a printable character that Windows applications can understand and display, such as caret or tilde.

For the bar code label developer who simply wants to demonstrate, using a scanner connected to a Windows PC using a USB or keyboard wedge interface, that a symbol does have the required delimiter character(s) encoded, a suitable DOS text editor is a convenient tool that will display all of the encoded characters.

George Wright IV is a certified GS1•US Bar Code Consultant and regular contributor to PMP News. Questions or comments may be emailed to the author at [email protected].