When it comes to printing non-latin languages such as Chinese or Hebrew using industrial Zebra printers and ZPL, things quickly get tricky. There are several ways of dealing with the issue.
In this article, we briefly describe the generally available solutions, and offers an insight in the way T2S handles the matter in its labeling solutions.
Zebra printers can be operated using a proprietary language called ZPL (Zebra Programming Language). ZPL is a page description language that is excellent for printing labels, especially if they contain numbering sequences like counters, or barcodes. Also, it is emulated in printers by other manufacturers, which effectively makes it some sort of industry standard.
If you have ever tried to print non-latin characters on a Zebra printer using ZPL, you have probably ended up with a label covered with gibberish, or with nothing at all.
True enough, Zebra printers built for specific markets (such as Asia) will often have pre-loaded fonts that include regionally relevant characters.
But if you don’t have one of those, what are your choices?
There is always the option of loading a font for the specific language you are planning to use. Tools such as the Zebra font downloader allow you to properly encode the font so it can be understood by the printer.
And what if you are looking at using multiple languages?
Fonts that support a broader subset of Unicode are usually quite large and the standard memory available on a Zebra printer is often not sufficient to store them. Adding memory to a Zebra printer is an option, but if you have a large pool of printers, it quickly becomes difficult. Because of the cost, but also because of maintenance: printers need to be preloaded with large files; setting them up and occasionally updating them generates additional overhead.
So how can you keep your overhead and costs down, while still taking advantage of the full range of languages on your Zebra printer?
When we faced the same challenge in one of our globally used labeling solutions, One2Label and One2Label Automation, we came up with an approach that allowed us to keep using dynamically generated ZPL without having to worry about the language being used.
Our labeling solutions use a rendering component that examines the content of the print request, which is submitted as a simplified XML format we nicknamed Silfi (Simplified layout format interface). If that content is found to contain characters that are not supported in the built-in fonts of the Zebra printer (let’s call them “exotic” for lack of a better word), the renderer turns them into bitmaps on-the-fly.
Using bitmaps on-the-fly
These bitmaps are correctly positioned and sent as ZPL inline graphics (^GF commands for the connoisseurs). The renderer can be set up to selectively convert “exotic” content, but also to convert all content. This way, possible differences between the font used to generate the bitmap and the built-in fonts can be eliminated.
An example of dynamically composed ZPL where the English text is clearly visible in the ZPL code, while the equivalent Chinese text has been dynamically converted to a bitmap (^GF).
Why not convert the entire label to a bitmap instead?
For a number of reasons. The most important one is that, for a bitmap, a white pixel has the same “weight” as a black pixel. In other terms, each and every pixel is present in the bitmap. Arguably, white pixels are less important as they do not get printed. Selectively converting content allows us to minimize the non-printable pixels to encode, so data sent to the printer is smaller, and therefore faster.
We use the same technique of injecting bitmaps created on-the-fly to avoid having to preload pictograms, and to print barcodes in symbologies not natively or adequately supported in ZPL.
Free Trial One2label Automation
Try out One2Label Automation and discover the possibilities. Enter your contact details to request a free trial.
Mediclabel for Confexion & JOYinCARE 
Webinar EDI and SSCC labels