Why don’t Unicode characters print correctly from SAP?

SAP applications have been around for a long time, and printed business documents have been around even longer. Over the years, various technologies and standards have evolved to enable printing in SAP environments. Yet printing problems remain, especially in large implementations that span many countries and languages.

The Unicode standard is a universal way for encoding and presenting all written characters from any language in the world. By contrast, the older code page-based approach to international character handling was only able to present a small subset of the possible symbols.

There is, for example, a separate code page for Western Europe (ISO-8859-1 or CP1252), Eastern Europe, Cyrillic, etc. Aside from these so-called “single-byte” code pages (which can present a maximum of 255 characters), there are also double-byte code pages for Asian characters (e.g., GB2312) that can depict over 60,000 symbols.

Unicode, on the other hand, provides different encodings for the display of all characters — the so-called Unicode Transformation Formats. UTF-16 is used internally by the SAP environment, so each character uses two bytes of data. For presentation of Unicode in data streams like print data, XML, and HTML files, UTF-8 is often used. Among other things, it is a more efficient way to depict ASCII symbol and European special characters. 

Great… there are multiple ways of handling printed characters. So what does this have to do with printing problems from SAP applications? 

SAP and Unicode

SAP first officially introduced Unicode support in SAP R/3 Version 4.7C. In doing so, they could offer an elegant solution to handle the input and data storage of the many characters used in international languages. But when it comes to printing documents with Unicode — especially with Asian characters — problems can still arise. Two of the most vexing problems relate to device support and output drivers.

The problem is, most devices are not designed to print these double-byte characters. If you send a document with Japanese characters to the average printer, for example, the SAP print driver will substitute any unsupported symbols with the symbol “#”.

In addition, SAP only supplies a few device types (drivers) for special printers that support Asian or Cyrillic characters. Usually these drivers only support certain code pages. Among other things, this means that you have to create more than one device type for each physical printer.

There are, of course, printers that support Asian fonts. However, these few printers are only commonly available in the Asian region. They usually only support print output involving double-byte code pages. Not many printers can handle native Unicode in UTF-8 form. Aside from the issue of Unicode support, there is also the problem of whether these printers have incorporated SAP-specific fonts like Andale. 

This problem presents a major challenge for the user. If you want to send Unicode directly from SAP, you’re limited to a small number of output devices and/or hardware vendors. You’re tied to a narrow range of printer models and manufacturers, which makes it difficult to use more cost-effective or better-optioned devices from other sources. Even upgrading current printers with special modules to support Unicode printing is problematic, since it locks you into both the module vendor and the provider of the associated devices.

Output Drivers

There are also some points to consider from the SAP side of the equation. For any Unicode-capable printers you want to deploy, there must also be a corresponding device type definition available for the various SAP releases. Otherwise, these printers will be of little use. The same applies to printers in which you’ve installed DIMM (hardware) modules to enable Unicode print support. If there are no longer any device type definitions available for your given SAP ERP system, then the investment in DIMMs is worthless. 

In addition to resource availability, there is also the issue of administrative effort needed to install, configure, test, and distribute the device drivers in the SAP landscape. This is not a trivial task, given the number of variables involved.

Solution

SAP offers several of its own solutions to this dilemma. For starters, you can use the device type SAPWIN and print the Unicode output via Windows. Obviously, this makes one reliant on the print facilities of the Windows OS. For newer SAP versions, it is possible to use SAP UPE (Unicode Printing Enhancement, available as of SAP NetWeaver 7.02) or SAP Interactive forms by Adobe (SAP ADS, available since SAP NetWeaver 2004). Either of these can make Unicode printing possible. However, the problem of supporting different device types in SAP still exists. Furthermore, these solutions are not available for all SAP versions still in use. SAP ADS is not as prevalent as SAPScript and SmartForms, which may or may not be a consideration.

LRS offers a technically elegant solution to the problem of Unicode printing, one designed with platform independence and future supportability in mind. The LRS Transforms component makes it possible to generate Unicode characters in a software process instead of hardware. This lets you support SAP and Unicode printing on any number of output devices from various manufacturers. Special hardware and SAP upgrades become unnecessary. 

There is also another advantage to this solution: you only need a single output device type: SAPGOFU. This special device type does more than greatly simplify printer administration in your SAP environment. It also greatly reduces the burden on your SAP server needed to generate print jobs. The LRS Transform module transfers the print workload to the VPSX server. Result? Better optimization of SAP system resources and lower administration effort related to printing.

So when it comes to printing from your SAP applications, you have options. Some are better than others, however. If you’re weighing the pros and cons of each approach, feel free to contact LRS for advice. We’ll be glad to help.