Global printing system and method for rendering encoding scheme independent labels having serialization data

Abstract

An apparatus and method for formatting a label are provided. An example method includes receiving data, a first portion of the data being encoded in a first encoding scheme; defining, via a processor, a first field block based on first text layout information received in association with a first field block command, the first field block for rendering text on a label; and formatting, via the processor, the first portion of the data within the first field block according to a first text display direction received in association with a first field parameter command.

Claims

1. A method of formatting a label, comprising: receiving data, a first portion of the data being encoded in a first encoding scheme; defining, via a processor, a first print area based on first text layout information received in association with the data, the first print area for rendering text on a label; receiving a first field parameter command in association with the data, the first field parameter command having: a first parameter to control a primary text display direction; and a second parameter to control a secondary text display direction; and formatting, via the processor, the first portion of the data for the first print area according to the first parameter for the primary text display direction and the second parameter for the secondary text display direction.

2. A method as defined in claim 1, wherein the first field parameter command is {circumflex over ()}FP.

3. A method as defined in claim 1, wherein: the primary text display direction is one of left to right, right to left, top to bottom, or bottom to top; and the secondary text display direction is one of left to right, right to left, top to bottom, or bottom to top.

4. A method as defined in claim 1, wherein a second portion of the data is encoded in a second encoding scheme, and further comprising: defining a second print area based on second text layout information received in association with the data, the second print area for rendering text on a label; and formatting the second portion of the data within the second print area according to another primary text display direction and another secondary text display direction received in association with a second field parameter command.

5. A method as defined in claim 3, wherein the primary text display direction is different than the secondary text display direction.

6. A method as defined in claim 4, wherein the first encoding scheme is the same as the second encoding scheme.

7. A method as defined in claim 4, wherein the second print area is for English text and the first print area is for text from the Middle East, Southeast Asia, China, Japan, Korea, or Vietnam.

8. A method as defined in claim 1, wherein the primary text display direction is bottom to top, and the secondary text display direction is one of (i) left to right or (ii) right to left.

9. A method as defined in claim 1, wherein the primary text display direction is top to bottom, and the secondary text display direction is one of (i) left to right or (ii) right to left.

10. A method as defined in claim 1, wherein the first parameter of the first field parameter command has four possible values.

11. A method as defined in claim 10, wherein the second parameter of the first field parameter command has four possible values.

12. An apparatus, comprising: memory including computer-readable instructions; and a processor to execute the instructions to perform operations including: receiving data, a first portion of the data being encoded in a first encoding scheme; defining a first print area based on first text layout information received in association with the data, the first print area for rendering text on a label; receiving a first field parameter command in association with the data, the first field parameter command having: a first parameter to control a primary text display direction; and a second parameter to control a secondary text display direction; and formatting the first portion of the data for the first print area according to the first parameter for the primary text display direction and the second parameter for the second text display direction.

13. An apparatus as defined in claim 12, wherein the first field parameter command is {circumflex over ()}FP.

14. An apparatus as defined in claim 12, wherein the operations further comprise printing the label with the formatted first portion of data.

15. An apparatus as defined in claim 12, wherein: the primary text display direction is one of left to right, right to left, top to bottom, or bottom to top; and the secondary text display direction is one of left to right, right to left, top to bottom, or bottom to top.

16. An apparatus as defined in claim 15, wherein the primary text display direction is different than the secondary text display direction.

17. An apparatus as defined in claim 12, wherein a second portion of the data is encoded in a second encoding scheme, and the operations further comprise: defining a second print area based on second text layout information received in association with the data, the second print area for rendering text on a label; and formatting the second portion of the data within the second print area according to another primary text display direction and another secondary text display direction received in association with a second field parameter command.

18. An apparatus as defined in claim 17, wherein the first encoding scheme is the same as the second encoding scheme.

19. An apparatus as defined in claim 17, wherein the second print area is for English text and the first print area is for text from the Middle East, Southeast Asia, China, Japan, Korea, or Vietnam.

20. An apparatus as defined in claim 12, wherein the primary text display direction is bottom to top, and the secondary text display direction is one of (i) left to right or (ii) right to left.

21. An apparatus as defined in claim 12, wherein the primary text display direction is top to bottom, and the secondary text display direction is one of (i) left to right or (ii) right to left.

22. An apparatus as defined in claim 12, wherein the first parameter of the first field parameter command has four possible values.

23. An apparatus as defined in claim 22, wherein the second parameter of the first field parameter command has four possible values.

Description

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

(1) Having thus described the invention in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:

(2) FIG. 1 is a diagram depicting a printer in communication with a plurality of host computers according to one embodiment of the present invention;

(3) FIG. 2 is an exemplary product label depicting multiple scripts according to one embodiment of the present invention;

(4) FIG. 3 is an exemplary shipping label depicting multiple scripts according to an additional embodiment of the present invention;

(5) FIG. 4 is an exemplary label depicting multiple fonts according to one embodiment of the present invention;

(6) FIG. 5 is an exemplary {circumflex over ()}FO command according to another embodiment of the present invention;

(7) FIG. 6 is an exemplary list of characters prohibited from beginning a line of text;

(8) FIG. 7 is an exemplary list of characters prohibited from ending a line of text;

(9) FIG. 8 is an exemplary text box illustrating that the size of the text box is inadequate to accommodate all of the text therein according to another embodiment of the present invention;

(10) FIG. 9 is an exemplary command having ASCII characters in the data field according to one embodiment of the present invention;

(11) FIG. 10 is an exemplary command having non-ASCII characters in the data field according to one embodiment of the present invention;

(12) FIGS. 11A and 11B are flowcharts illustrating a process for encoding scheme interleaving according to one embodiment of the present invention;

(13) FIG. 12 is a flowchart depicting a process for encoding barcodes according to another embodiment of the present invention;

(14) FIG. 13 is a flowchart depicting a process for serializing data based on combining semantic clusters according to one embodiment of the present invention; and

(15) FIG. 14 is an exemplary sequence of code points and its associated printed representation illustrating one potential application of a combining semantic cluster according to another embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

(16) The present invention now will be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments of the invention are shown. Indeed, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like numbers refer to like elements throughout.

(17) Referring to the drawings and, in particular, FIG. 1, the present invention provides a global printing system 10 that includes a printer 12 that is capable of communicating with a plurality of host computers 14. Each of the host computers 14 transmits commands to the printer 12 that may be formatted in different encoding schemes. The printer 12 is capable of determining the encoding scheme for the commands from each host computer 14 such that the commands may be interpreted correctly. Thus, the printer 12 is capable of printing various language scripts regardless of the encoding scheme and/or language script used. Moreover, the printer 12 is capable of printing multiple scripts on a single label (see FIGS. 2 and 3), as well as in multiple fonts (see FIG. 4). The printer 12 is capable of effectively printing the scripts on labels regardless of the orientation of the text and/or the complexity of serialized data. Additionally, the printer 12 is capable of encoding barcode labels such that the data input by the user matches the data that a scanner scanning the barcode sends back to the computer regardless of the encoding scheme employed.

(18) The printer language referred to herein is Zebra Printer Language (ZPL) that is compatible with printers manufactured by ZIH Corp., the present assignee. For example, exemplary commands referred to herein include: {circumflex over ()}CI (change international font); {circumflex over ()}DT (download TrueType font); {circumflex over ()}DY (download graphics); {circumflex over ()}FB (field block); {circumflex over ()}FD (field data); {circumflex over ()}FO (field origin); {circumflex over ()}FP (field parameter); {circumflex over ()}FV (field variable); {circumflex over ()}SF (serialization field with a standard {circumflex over ()}FD string); {circumflex over ()}SL (set mode and language for real-time clock); {circumflex over ()}SN (serialization data); and {circumflex over ()}XZ (end format). Thus, ZPL is known to those of ordinary skill in the art as a programming language for generating commands for the printer 12. However, it is understood that the programming language is adaptable to other printers such that any equivalent programming language may be written to carry out the functions set forth herein with any suitable printer.

(19) Moreover, the printer 12 is typically employed to render data received from one or more host computers 14 and print the rendered data on labels, such as barcode labels. However, the term label is not meant to be limiting, as the printer 12 may be configured to print on any suitable medium capable of rendering one or more glyphs thereon. For instance, the label could be paper, cloth, plastic, metal, or other medium capable of having human-readable text, graphics, or barcodes depicted thereon.

(20) The printer 12 is typically a thermal printer for printing labels. However, the printer 12 could be any suitable printer capable of rendering data on a label. For instance, the printer 12 could be a computer peripheral device that produces a hard copy (permanent human-readable text and/or graphics, usually on paper) from data stored in a computer connected to it.

(21) The printer 12 is capable of supporting Unicode. If employing Unicode, the printer 12 is required to comply with at least portions of the Unicode Standard, namely, Chapter 3 of the Unicode Standard that sets forth the details for conformance. For example, if the printer 12 claims to support the Arabic or Hebrew scripts, then the system must support the bi-directional text layout algorithm. Another example is if the printer 12 does not support certain character blocks, such as the pre-composed Hangul characters, documentation that those characters are not supported is required. It is understood that the printer 12 may be alternatively configured to support subsets of Unicode by excluding particular scripts that may not be relevant to a printing application, such as Mongolian, Ethiopic, Cherokee, Canadian Aboriginal, Byzantine Music Symbols, Braille, and Historic scripts.

(22) The printer 12 supports contextual mapping, which is prevalent with Arabic letters. The printer 12 may employ various solutions, such as glyph substitution tables (GSUB) or an algorithm derived from the Arabicshaping.txt file in the Unicode Character Database, to provide such support. Furthermore, the printer 12 supports diacritic marks. One way to support diacritic marks is to have a font engine render the character and combining mark together. For instance, a font engine could combine the character and the non-spacing diacritic mark and then render the combined character. Another way to support diacritic marks is through the use of presentation forms. The character and the combining mark are converted into its presentation form. The presentation form is a pre-combined character that exists in its own code point in Unicode. Normalization C Algorithm aids the conversion to the presentation form and is detailed in the Unicode Standard. A font engine then renders the pre-combined presentation form, instead of the separate character and combining mark. If the presentation form is not available, the un-combined characters are printed side-by-side. A font engine may be used to combine characters when a presentation form is not available. Thus, the printer 12 is configured to accept the combining characters in the presentation forms and the characters plus combining marks.

(23) Additionally, the printer 12 is capable of supporting bi-directional text if Arabic or Hebrew languages are supported, which is in accordance with the Unicode Standard. The printer 12 can also support text written left-to-right on the same line as text written right-to-left (e.g., English and Hebrew). Bi-directional support is typically selectable. Thus, with the bi-directional support having user selectable support, the printer 12 will remain backwards compatible. The user should be able to select bi-directional text support through both a ZPL command and a front panel prompt on the printer 12.

(24) Currently, the {circumflex over ()}FO command sets the upper-left corner of the field area. When working with left to right oriented text in the {circumflex over ()}FD command, the field origin is the beginning of the text; however, when the {circumflex over ()}FD command contains right to left oriented text, the {circumflex over ()}FO command will set the upper-right corner of the field area. FIG. 5 demonstrates an exemplary {circumflex over ()}FO command with right to left and left to right oriented text. Both of the {circumflex over ()}FD commands have the same {circumflex over ()}FO command setting the field origin at the same location for both {circumflex over ()}FD commands. Since the first {circumflex over ()}FD command contains English, which is left to right oriented text, the field origin is the upper-left corner of the field area. The second command contains Hebrew text, which is right to left oriented text, so the field origin is set at the upper-right corner of the field area.

(25) Furthermore, the printer 12 has the ability to override the location of field origin using explicit commands rather than the printer 12 using the script to determine the location based on the primary directionality of the script. Primary directionality of the script is defined within the Unicode Standard.

(26) The printer 12 also supports word wrapping. When employing word wrapping, normative line breaking properties are followed. The most general way of word wrapping is to line break at spaces; however, in some languages, there are no spaces. If there are no spaces in the text, as in Japanese or Chinese, then the text should be broken when there is no more room in a line. There are certain characters that are prohibited from beginning a line of text, such as those shown in FIG. 6. These characters should be wrapped up to stay with the previous line. Similarly, there are also certain characters that should not end a line of text and should begin a new line of text, such as those shown in FIG. 7. These characters should be wrapped down to start the next line. Bi-directional text also presents issues with respect to line breaking. For example, since Hebrew is written from right to left, the Hebrew text that should be read first would move to the first line and the remainder would move to the second line.

(27) Word wrapping in the printer 12 will also work so that text can be displayed in any horizontal or vertical direction. Field block commands (e.g., {circumflex over ()}FB, {circumflex over ()}TB) may interact with the {circumflex over ()}FP command to accomplish text formatting in any horizontal or vertical direction. The {circumflex over ()}FP command will have the format {circumflex over ()}FPd,g,s and have three parameters: d, g, and s. The d will be the primary direction of the text and the s will be the secondary direction of text. The secondary direction will be ignored if the command is not interacting with a {circumflex over ()}FB command. The middle parameter g will remain as the parameter for additional inter-character gap. Table 1 shows the different command possibilities for {circumflex over ()}FP. The default for parameter d will be H (Horizontal) and the default for parameter s will be V (Vertical). The default for parameter s will change to R (Reverse) when either V or B (Bottom Up) is used for the parameter d.

(28) TABLE-US-00001 TABLE 1 Word Wrapping Interactions Command Output Primary Direction Secondary Direction 1 {circumflex over ()}FPH,g,V Left to Right Top to Bottom 2 {circumflex over ()}FPH,g,B Left to Right Bottom to Top 3 {circumflex over ()}FPV,g,H Top to Bottom Left to Right 4 {circumflex over ()}FPB,g,H Bottom to Top Left to Right 5 {circumflex over ()}FPR,g,V Right to Left Top to Bottom 6 {circumflex over ()}FPR,g,B Right to Left Bottom to Top 7 {circumflex over ()}FPV,g,R Top to Bottom Right to Left 8 {circumflex over ()}FPB,g,R Bottom to Top Right to Left

(29) Additionally, the printer 12 is capable of supporting multiple scripts on a single label that are oriented both vertically (e.g., Japanese) and horizontally (e.g., English). In this regard, a new command to ZPL, the text block command {circumflex over ()}TB, has been added. Currently this command supports complex horizontal text layout but is capable of being expanded to also support complex vertical text. In order to allow for this expansion an expandable command set within Zebra's current printer control command set was specified. This specification consists of an escape sequence that can be included within the printer data command ({circumflex over ()}FD) for the text block to add typographical commands. Each escape sequence starts with < and ends with >. For example, the << > command allows the printer 12 to print a less than character in a text block. At a later date, additional commands may be added, such as <RL> to define Right to Left line stacking progression in vertical text and <rotate> to define a rotation of the glyphs in the line progression. Furthermore, the use of an expandable set of escape sequences may facilitate compliance with the proposed CSS3 (cascading style sheets) standard for layout of complex vertical text. Additional examples of how such a command sequence could be used can be found in Unicode Technical Note #22.

(30) Another issue with the current word wrap command is that it overwrites the last line of text if there are not enough lines in the text box for all of the text to fit. The printer 12 requires that the word wrap command truncate and disregard the remaining text instead of overwriting the last line if there is not enough space. However, the user will have the option to know if the text box is truncating part of the text because the last three characters that are displayed on the last line of the text box will be replaced with a # sign to identify there is text that cannot fit inside the text box, as shown in FIG. 8. The option to validate the truncating of the text will have the default of no validation to remain backwards compatible.

(31) The notification of text being truncated is a useful feature when using variable data fields. Since the label is formatted without knowing the size of the data field, the user should know if there is data missing from the text box. Regardless of the validation option, the word wrap is configured to not overwrite the last line of text if there are not enough lines for all of the text to fit in the text box.

(32) The printer 12 is capable of supporting text rotation without losing any of the capabilities of the current solution Moreover, the printer 12 is capable of supporting large printer resident fonts that support sufficient scripts required for multinational companies that may want to print multiple language content labels. Fonts of this size typically exceed 20 megabytes.

(33) The printer 12 typically provides support for UTF-8 and UTF-16 (big endian and little endian), along with UCS-2. UCS-2 is similar to the Unicode encodings, but is actually defined by ISO 10646. UTF-8 has an optional byte order mark (B.O.M.). The rest of the encodings may or may not have a B.O.M. present to identify big endian or little endian. If there is no B.O.M., the default is big endian. UTF-16 includes a mechanism known as surrogates, where two separate 16-bit code units stand in for a single character beyond the Basic Multilingual Plane (BMP). Surrogates themselves are not characters; it takes two (one high and one low) to properly represent a character. The printer 12 is also capable of supporting UTF-32 and UCS-4; however, these encoding schemes require a full 32 bits for every character, requiring more space than a UTF-16 or UTF-8 encoded file, unless all of the characters are outside of the BMP. The printer 12 includes a {circumflex over ()}CI command that supports the switching between UTF-8, UTF-16BE and UTF-LE encoding. Furthermore, the printer 12 can interpret a Unicode BOM to induce the switching between UTF-8, UTF-16BE, and UTF-LE encoding.

(34) With the vast number of code points in the Unicode Standard, it is possible that a character without a glyph in the selected font or an unassigned code point may be selected. In the case that there is no glyph for the requested code point or character, an identifier, such as a symbol (e.g., ) could be displayed in place of the glyph. It is desirable to have the option that a last resort font be used to identify if the requested code point without a glyph is an illegal code point, unassigned code point, or informs the user to which character block the code point belongs.

(35) The printer 12 not only supports Unicode, but also ASCII and other legacy encoding schemes. Table 2 provides examples of common legacy encoding schemes used around the world.

(36) TABLE-US-00002 TABLE 2 Legacy Encoding Schemes Region/Language Encoding Schemes United States ASCII Latin CP 850 Japan JIS (ISO 2022-JP), Shift-JIS Korea UHangul, Johab, Wansung China/Taiwan Big 5, GB 2312, HZ
While mode changes of encoding schemes are required within a ZPL script, there can be no requirement to identify the encoding scheme used for individual text elements. This concept of encoding scheme mode changes can be compared to the current handling of character set changes in a ZPL script. If the entire label is going to be in one international character set, the {circumflex over ()}CI command sets the default character set for the entire ZPL script. However, if multiple character sets or encodings are being used in the script, several {circumflex over ()}CI commands will switch between the characters sets or encodings. After each {circumflex over ()}CI command the character set and encoding remain the same until a trigger, such as another CI command or a Unicode BOM, is given to switch character sets. Thus, the CI command can change both the character set and encoding scheme simultaneously

(37) Providing support for legacy and Unicode encoding schemes allows the customer to continue to send existing printer control scripts to the printer 12 that are saved in an ASCII-transparent encoding scheme without changing the script at the same time as new Unicode scripts are sent to the printer 12. The printer 12 is capable of parsing printer control commands that are being sent simultaneously in both ASCII transparent encoding schemes and in UTF-16 encoding schemes without requiring an encoding indicator before the printer control commands are sent to the printer by maintaining two different parsing states defined by three pieces of state information. The two parsing states indicate if ASCII transparent data or if non-ASCII transparent data (i.e. UTF-16) are being parsed. The three pieces of state information include the current parsing state, the last endianness for a UTF-16 data stream, and the last ASCII transparent encoding scheme, which is called ASCII Trans Type. The printer 12 will be initialized in the ASCII transparent encoding state, the endianness for UTF-16 data streams is set to big endian, and the ASCII transparent type is set to the default encoding scheme.

(38) As shown in FIG. 11A and FIG. 11B the parser takes in data, initializing and setting data structures needed to process incoming data (blocks 20-26). In blocks 28 and 30 the printer 12 identifies the data being sent to the printer by analyzing the bytes received, with the goal of determining if the last two bytes in the parser buffer are UTF-16 BOM. If a 16 bit BOM is identified, the printer 12 adjusts the parser state and endianness variables accordingly (blocks 42-48). If the printer 12 identifies a printer control command prefix followed immediately by a ASCII character in the range 0x30 to 0x7f, the parser state is set to ASCII transparent (blocks 32 and 50). If the buffer is not 2 bytes long (block 34) and the printer 12 identifies a UTF-8 BOM, the parser state is set to ASCII transparent and the ASCII transparency type is set to UTF-8 (blocks 36 and 52). The printer eliminates all bytes that are null (0x00) from the parser buffer in order to identify printer control commands that are ASCII based (block 38 to 40). If the command identified is the ZPL command {circumflex over ()}CI, the printer reads the balance of the command from the data buffer using a process dependent on the current parser state (ASCII transparency or Unicode 16 bit) and endianness. The printer then changes the parser state and ASCII transparency type and endianness per the direction indicated by the {circumflex over ()}CI command (blocks 54-58).

(39) If the command identified is a ZPL command that is a data carrier command, such as but not limited to {circumflex over ()}FD, {circumflex over ()}FV, {circumflex over ()}SN, {circumflex over ()}SF, the printer reads the next character from the data buffer. The size of the character read is dependent upon three pieces of information, the parser state, ASCII transparency type, and endianness. If the parser state is Unicode 16 bit, a character will be composed of 2 bytes. If the parser state is ASCII transparency and the ASCII transparency type is single byte encoding, a character is composed of 1 byte. If the parser state is ASCII transparency, and the ASCII transparency type is a multi-byte encoding, the size of the character is determined by the value of the first byte of the character as indicated by the encoding type used (blocks 60-64). When the character found is equal to the printer control command prefix, the printer terminates the data carrier command processing task (blocks 66-70).

(40) In addition to the standard encoding schemes, the printer 12 is also capable of supporting other characters sets, such as, for example, Zebra OEM character sets in the {circumflex over ()}CI ZPL II command as in ZPL II Programming Guide Volume One Rev. A and the various code pages utilized by the fonts in the current price lists. Furthermore, the printer 12 is capable of supporting ASCII command interactions, such as ASCII control characters assigned as shortcuts for ZPL commands that may conflict with Unicode characters. For example, ETX (0x03) is a shortcut for the {circumflex over ()}XZ command. However, the byte 0x03 is also the first byte for the code point combining dot below when encoded in a UTF-16 big endian encoding scheme. The printer 12 is capable of distinguishing the byte 0x03 as either an ETX and therefore, a shortcut for an {circumflex over ()}XZ command or as the first byte of a combining dot below character, dependent on the current encoding state.

(41) The printer 12 may also provide real-time clock support independent of the encoding scheme utilized. For example, the {circumflex over ()}FC command can remain only supporting ASCII characters as values for parameters, but the ASCII characters must function in any encoding scheme and mix in the data field with other non-ASCII characters.

(42) Furthermore, the printer 12 provides support for other character sets and encoding schemes in addition to Unicode, such as character sets and encoding schemes listed in Table 2. The printer 12 is also capable of supporting GB 18030-2000, which is a standard required by the People's Republic of China. The Chinese government issued a regulation in the year 2000 stating that operating systems for non-handheld computers must comply with the standard. Although printers are exempt from this regulation, any user driving label printing from a GB 18030 compliant device, such as a Chinese version of Windows, will require printer resident GB 18030 support. GB 18030 is a coded character set that encodes the characters as one, two or four bytes. It is a superset of GB2312 and GBK and incorporates all of Unicode's CJK Unified Ideographs Extension A. When providing support for GB 18030-2000, the printer 12 will also require a printer resident font that supports the GB 18030 characters set.

(43) Moreover, the printer 12 may also be configured to support Big5-HKSCS. The Hong Kong Supplementary Character Set is an extension of the Big5 character set and encoding and adds 4702 characters to the character set. The missing characters were Cantonese, scientific names, personal names, pinyin symbols, and other foreign characters, such as hiragana, katakana, and Russian. All code points of the Supplementary Character Set can be found within existing code space of Big5. These are commonly used characters in Hong Kong that were not supported in the original character set.

(44) The printer 12 is further capable of supporting different fonts for different locales. In the effort to assign characters to code points in Unicode, Han unification occurred. Unicode unified some similar Japanese, Korean, Simplified Chinese, and Traditional Chinese characters into a single code point even when they have a slightly different glyph. So, some characters can have up to four different glyphs depending if the character is in Simplified Chinese, Traditional Chinese, Japanese, or Korean text. Since Unicode defines the character and not the glyph, the appropriate font must be used to achieve desired glyph. If an inappropriate font is used, the characters are readable and recognizable, but not correct. Thus, different glyphs may be represented for the same character and have the same code point, but a correct font must be used to properly display each glyph.

(45) Furthermore, the printer 12 is capable of supporting multiple fonts in a single ZPL script. Customization of the glyph appearance is necessary for several reasons, such as Han Unification. Han Unification requires a locale specific font to display the appropriate characters. Multiple fonts may also be required when the user wants to display text in different styles. The example in FIG. 4 illustrates a label that was printed with several fonts. Since the Japanese characters on the label were not available in the font that was used to print the English characters, two fonts were required.

(46) Users are capable of creating custom characters that are assigned a code point in the Unicode private character space, such as using the Private Character Editor in Microsoft Windows. The Private Character Editor creates a smooth, scalable font that is given the extension .TTE and functions like a True Type Font. The Private Character Editor is used to create glyphs for uncommon characters or symbols that are not available in an existing font, for example, an Asian character found in a proper name or a company logo. The printer 12 may support the TTE fonts as downloadable printer resident fonts, in same manner that True Type fonts are supported. The printer 12 may also support linking of private character font to associated font, such that if the base font does not have a glyph for the required character, the printer looks to the linked private character font for the glyph. With the introduction of the TTE fonts and improved support for other fonts, the printer 12 also simplifies the process of loading TTF and TTE to the printer.

(47) According to another embodiment of the present invention, the printer 12 is capable of supporting barcodes that are encoding scheme independent. For example, the printer 12 is capable of encoding various types of barcodes, such as one-dimensional, Maxicode, Aztec, Datamatrix, PDF417, MicroPDF417, RSS, TLC-39, and 16K barcodes. However, not all barcodes are encoding scheme independent, such as the QR barcode. The QR barcode is capable of encoding Kanji characters, which must be encoded as Shift-JIS as defined by the QR code specification.

(48) The printer 12 is capable of intelligently converting Unicode encoded input data into Shift-JIS data in order to support QR barcodes. As described above, a QR barcode formatter requires Kanji data to be encoded via Shift-JIS. Data stream input encodings that are of particular relevance for the QR barcode are {circumflex over ()}CI15 (Shift-JIS) and {circumflex over ()}CI28-30 (Unicode). As shown in FIG. 12, the QR barcode is expecting Shift-JIS data and, if the user has selected {circumflex over ()}CI15 (i.e. non Unicode) (block 80), the printer 12 may send the input data directly into the barcode without changing anything (block 82). For {circumflex over ()}CI28-30, the data will be converted from Unicode to the proper data for the specified character mode. In this regard, the first step is to convert the data to UTF-8 (block 84), which ensures that numeric and alphanumeric data will be processed correctly in the absence of the Shift-JIS data table (JIS.DAT). If a Shift-JIS data table is not present (block 86), the UTF-8 converted data stream is sent to the QR code formatter (block 82) for rendering. However, if a Shift-JIS data table is available, the entire UTF-8 data stream is converted (block 88). That is, for numeric mode and alphanumeric mode data, the stream will be filtered for those characters and sent to the formatter as single byte data. 8-bit Byte mode is JIS X 0201, which can be found in Table 6 of the QR standard. Unicode data should be converted to this single byte encoding before formatting the barcode. Finally, Kanji mode is JIS X 0208, where the Unicode data will be converted back to Shift-JIS using the Shift-JIS data table in reverse before formatting the barcode.

(49) The printer 12 is also capable of supporting serialization according to another embodiment of the present invention. The ASN ZPL command, which represents Serialization Data, will only increment numbers and will interpret the data field in an encoding scheme independent fashion. The command will start with the last integer in the field data stream and have a maximum string length of 12 digits. Table 3 illustrates an example of two encodings of ASN 9/10. Both encodings should have the output of 9/10, 9/11, 9/12, etc.

(50) TABLE-US-00003 TABLE 3 {circumflex over ()}SN 9/10 9 / 1 0 UTF-8 39 2F 31 30 UTF-16 0039 002F 0031 0030
Table 4 shows an example of a ASN command that has non-ASCII characters in the field. This command is {circumflex over ()}SN 910 and will work similar to the previous example. The output for all encodings should be 910, 911, 912, etc.

(51) TABLE-US-00004 TABLE 4 {circumflex over ()}SN 9 10 9 1 0 UTF-8 39 E6 9C 88 31 30 E6 97 A5 UTF-16 0039 6708 0031 0030 65E5

(52) An exemplary technique for implementing serialization of encoding scheme independent data is outlined in FIG. 13 and Tables 5 and 6.

(53) TABLE-US-00005 TABLE 5 Combining Semantic Cluster Boundary Properties CR U+000D Carriage Return (CR) LF U+000A Line Feed (LF) Control General_Category = (Line Separator (Zl) | Paragraph Separator (Zp) | Control (Cc) | Format (Cf) && NOT (U+000D | U+000A | U+200C | U+200D) Extend General Category = Nonspacing_Mark (Mn) | Enclosing_Mark (Me) | Spacing_Mark (Mc) | U+200C | U+200D Link Grapheme_Link = TRUE L Hangul_Syllable_Type = L V Hangul_Syllable_Type = V T Hangul_Syllable_Type = T LV Hangul_Syllable_Type = LV LVT Hangul_Syllable_Type = LVT Any Any character (includes all of the above)

(54) TABLE-US-00006 TABLE 6 Combining Semantic Cluster Boundary Rules Break at the start and the end of text. SOT Any (1) Any EOT (2) CR LF (3) (Control|CR|LF) Any (4) Any (Control|CR|LF) (5) Do not break Hangul Syllable sequences L (L|V|LV|LVT) (6) (LV|V) (V|T) (7) (LVT|T) T (8) Do not break before extending characters Any Extend (9) Do not break after Link Characters Link Any (10) Otherwise, break everywhere. Any Any (11) [ = No Boundary (do not allow break here); = Boundary (allow break here)]
The first step is to convert the field data to UTF-8 (block 90). Next, the data stream is parsed into an array of independent combining semantic clusters (CSC) per the rules outlined in Tables 5 and 6 (block 92). A loop is initialized to examine the CSC array starting at the end of the array (blocks 94-100) in order to find an element in the CSC array that is composed of a single byte with a value of 0x30-0x39 inclusive (block 98). At this juncture, the balance of serialization can be completed using previous algorithms developed by Zebra Technologies for serialization with the simple substitution of the concept of the combining semantic cluster instead of a single byte (block 102).

(55) The {circumflex over ()}SF command is encoding scheme independent. Alphanumeric is defined as 0x30-0x39, 0x41-0x5A, and 0x61-0x7A. If there is any mismatched mask members, that mask member changes to %. The example in FIG. 9 has all ASCII characters in the data field. The output should be 12A, 12C, 12E, and 12G for all encodings of the ZPL script. The example in FIG. 10 has non-ASCII characters in the data field. These characters will be ignored using the % mask. The output for all encodings should be A, C, E, and G.

(56) The Unicode Standard defines the concept of grapheme clusters for identifying units of characters represented by multiple Unicode code points (e.g., non-spacing combining marks). When working with characters that are to be reversed or split vertically, certain clusters should not be broken such that a glyph that should not be by itself does not end up by itself. The example in FIG. 14 has several combining semantic clusters. The first combining semantic cluster is the combination of the first two code points in the sequence. Code point 093F is a spacing mark that combines with code point 092C. The code point 093F-Devangari Vowel Sign I is a dependent spacing vowel mark and is never found in isolation of the base character, whose vowel sound it modifies. Thus, the printer 12 may employ the concept of a Combining Semantic Cluster, which is a group of code points between Combining Semantic Cluster Boundaries. Tables 5 and 6 set out the Combining Semantic Cluster Boundary Properties and Rules, respectively.

(57) Once the definition of a Combining Semantic Cluster is complete, the functionality can be redefined and algorithms provided for the revised {circumflex over ()}FP and {circumflex over ()}SF commands. The {circumflex over ()}FP command allows vertical and reverse character printing. This will be handled in the vertical case by splitting the text at the Cluster Boundaries. It is equivalent to inserting a CR (carriage return) and LF (line feed) between all Combining Semantic Clusters. This will also work for right-to-left text and bidirectional text, as right-to-left text is ignored when printing top-to-bottom (see Unicode Technical Note #22 for details). In the reversal case, again the text is split at Cluster Boundaries and all the clusters are simply reordered. In addition, in order to prevent unwanted ligatures that may change the meaning, a Zero Width Non-Joiner (U+200C) should be inserted between each cluster.

(58) Regarding an encoding scheme independent implementation of the {circumflex over ()}SF command, the term character is replaced with Combining Semantic Cluster. Thus, a single % could mask an entire Combining Semantic Cluster, rather than a single code point. Moreover, the mask string and the target string are aligned at the first code-points in their respective backing stores, while the mask string and increment string are aligned at the last code-points in their respective backing stores. All masks should be developed with regard to the backing store rather than to visual order. Finally, code points involving Bi-directional Overriding (RLM, LRM, RLE, LRE, RLO, LRO, and POP) should be automatically skipped and do not require mask placeholders.

(59) With respect to the {circumflex over ()}SN command and similar to the {circumflex over ()}SF command, the antiquated concept of right most is replaced with the first number working backwards in the backing store to properly account for bidirectional text.

(60) The present invention has many advantages. For example, the printer reduces the amount of data required to be sent between the printer and the host, as the host can now transmit only the code points rather than the bitmap image, which also reduces the first label out time. The printer also enables more cost effective and proper support of the languages required in new and emerging markets, such as China or UAE. Many of the new and growing markets are not supported with a complete or proper thermal printing solution for their languages. For example, there does not appear to be a thermal printer that can support all of the Simplified Chinese characters required for printing a label in Chinese in an efficient and cost effective manner. Furthermore, the printer is capable of interpreting serialized scripts written in both Unicode and non-Unicode commands such that the printer is capable of supporting legacy encoding schemes.

(61) Many modifications and other embodiments of the invention set forth herein will come to mind to one skilled in the art to which this invention pertains having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.