Browse Prior Art Database

Multiple Character Encoding for Bar Code Objects in a Print Data Stream Disclosure Number: IPCOM000021166D
Original Publication Date: 2003-Dec-31
Included in the Prior Art Database: 2003-Dec-31
Document File: 3 page(s) / 67K

Publishing Venue



Systems to print bar code symbols, such as Bar Code Object Content Architecture (BCOCA) within the Advanced Function Presentation architecture, traditionally use a single, fixed encoding scheme to specify the data to be bar encoded. For example, BCOCA requires data for linear bar codes to be encoded as single-byte EBCDIC data. Some bar code symbologies (as defined by industry standards, such as AIM) are also defined assuming a particular data encoding, such as single-byte ASCII. In addition, multibyte encodings, such as Unicode, are being used more widely for many kinds of data (but not bar code data). When the symbology-defined encoding is different from the print-system encoding, a method is needed to specify and transform between the different encodings. This article discloses a method of using a variety of encodings with bar code data.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

Multiple Character Encoding for Bar Code Objects in a Print Data Stream

Disclosed is an extension to a bar code system, such as the BCOCA architecture used within an Intelligent Printer Data Stream (IPDS) printer, to allow for the specification and processing of an input encoding that is different from the bar code symbology-required encoding:

A parameter (flag) is added to specify that an alternate encoding (such as

EBCDIC or Unicode) is used for the input data A 2nd parameter is added to identify a specific alternate encoding; this parameter

    is not needed for all symbologies. In both cases, the printer automatically converts the user-specified input bar code data into the symbology-defined encoding before creating the bar code symbol. Differences and limitations between the two encodings are resolved by the printer in a predefined manner. When the flag is off (B'0'), the input bar code data is assumed to be encoded as defined by the symbology.

    The first capability is useful for system environments that normally use a different encoding than the bar code symbology; for example, most mainframe environments support EBCDIC data. The first BCOCA capability allows a mainframe user to specify the bar code data using EBCDIC code page 500 and set the flag in the bar code object to cause the printer to accept and correctly translate this data into the encoding required by the bar code symbology. The Data Matrix and Maxicode 2D bar code symbologies use the ECI 000003 encoding (which is equivalent to the IBM ASCII code page 819); the PDF417 2D bar code symbology uses the GLI 0 encoding (which is not identical to any IBM code page).

    The second capability is also useful for EBCDIC system environments, but allows for multiple input data encodings. The QR Code 2D bar code, which is used in Japan for automotive industry applications, defines a default data encoding called ECI 000020 which is a single-byte code page representing the JIS8 and Shift JIS character sets. The ECI 000020 encoding is equivalent to the IBM ASCII code page 897, but there are multiple EBCDIC codes pages for JIS8 and Shift JIS that are commonly used in Japan.

    Either scheme can also be used for data streams that use multiple-byte encodings, such as Unicode. The type of Unicode data (UTF-8, UTF-16, etc.) can be specified either with individual flags or with a 2nd parameter.

    The following is an example syntax diagram of the bar code parameters specific to the QR Code 2D bar code together with a description of the encoding flag and encoding parameter. Byte 5, bit 0 shows the 1st method using a flag to identify encoding; byte 6 shows the 2nd method of providing a selectable set of input encodings.

  BCOCA Architecture syntax: QR Code Special -- Function Parameters