Unicode Printing until now
Over the last few years, I have focused on Printing and Output Management as a topic within SAP Consulting. The starting point for that was the question as to how to print after a Unicode conversion has taken place; after conversion the documents will have different languages and code pages.
Until now, the answer involved four different alternatives:
A) Printing with Unicode Device Types (like HPUTF8)
In this case, SAP creates the print data without any font embedding. That means, the printer is responsible for including all the fonts required on its system (e.g. by adding them via DIMM chips).
B) SWINCF (Windows-based solution)
The second solution is to use SAPWIN as a technology. With SWINCF, the Windows system (either on the front-end or on the server) is responsible for adding the necessary subsets of fonts to the data stream.
C) External Conversion (e.g. by Output Management Systems)
Independently of the interface you are using (print data like PCL, pre-formatted data like SAPGOFU or raw data with RDI/UCPLAIN) this is an elegant way to print Unicode documents on every printer.
There are several good conversion routines that are used by the standard output management systems like SAP Document Presentment by OpenText (StreamServe), LRS VPSX or others.
D) Printing with SAP Interactive Forms by Adobe
The ADS is able to render documents and do font subsetting out-of-the-box.
Each alternative has its own justification, but there was no direct solution by using the pure SAP standard. Each alternative has its own limitations (the most important ones in my eyes for our customer are: A: printer-dependency, B: relying on Windows for formatting and monitoring, C: not free of charge, D: need to convert to SAP IFbA means a lot of effort for existing SAPscript forms / Smart Forms).
Unicode Printing Enhancement (UPE)
In 2012, SAP started a development based on a co-operation with the German SAP User Group (DSAG). This Customer Engagement Initiative focused on solving this issue by developing a pure SAP solution.
The requirements for this development were:
- Generic solution to print Unicode documents in the most common languages on PCL- and Postscript-based printers for ABAP Lists, SAPscript and SAP Smart Forms.
- High level of compatibility and minimized influence on performance
- Inclusion of internal PDF conversion
- Embedding of only the characters that are needed in the print data stream (font sub-setting)
- SAP will license fonts and deliver a holistic solution.
How to use UPE?
That was quite a bit of theory – but now let’s have a look how you can start with UPE. Assuming you fulfill the technical requirements (see Note 1812076), there is a new button available in the device configuration in transaction SPAD.
Yes – you enable UPE at printer level to ensure a non-disruptive change in your landscape. As soon as you activate UPE, you have to select a Unicode Reference Device Type (URDT) – for details check the chapter below.
If you do not print Chinese, Korean, Japanese or Taiwan, it doesn’t matter which URDT you choose.
After these two simple steps, your printer is now UPE-enabled as soon as you have saved the printer. You can check the available languages now with the button “Supported Languages”.
If your printer is using UPE, the following will happen: As soon as there is a character in the document that does not exist in the code page of the printer device type, the SAP spool will – by means of the URDT – extract precisely that part of the TrueType font and include it in the print data.
The big advantage in this case is the full functionality (using all of the languages) out-of-the-box by only adding the needed characters instead of a full font.
And if you convert your documents to PDF in SAP, the same methodology is used as described above.
No additional configuration is needed, as all of the fonts are included in SAP with the NW stacks mentioned in Note 1812076.
Unicode Reference Device Type (URDT)
For most of the languages the URDT has no effect. But if you want to print in Chinese, Korean, Japanese or Taiwanese, you have to take the following into consideration.
The URDT is not a real device type. Instead, it is more or less the flavor your output should look like. A simple rule (the CJK topic could cover a whole blog entry itself) is to choose the URDT for “your” country, e.g. the Chinese one for printers in China. All the non-CJK-Countries will be the same for all the different URDTs.
The real reason behind that differentiation is that Chinese, Taiwanese, Korean and Japanese share some code points in Unicode but use slightly different glyphs. In reality, a native Japanese would be able to read a text with a Chinese flavor, but he or she would recognize that a different character has been used.
To visualize the issue, there is a list available in Wikipedia that shows some example of differences. (http://en.wikipedia.org/wiki/Han_Unification#Examples_of_language_dependent_characters)
What is delivered?
With the support packages mentioned below, there is the needed integration in SPAD delivered as well as the fonts themselves and the addition to the internal PDF converter.
In addition to this standard scope, there is also a report delivered ‘RSPOUPE_URDT_TOOL’ that enables you to modify URDTs, e.g. to add an individual font or to customize the fonts used e.g. for list printing.
Starting with NW 7.40 SP03 and including downports up to NW 7.02 SAP will deliver this solution in the following Support Package Levels:
- NW7.02 – SP14
- NW7.30 – SP10
- NW7.31 – SP09
Note: Kernel 721 is a requirement!
Details in Note 1812076.
To be very honest, not every language that is supported by Unicode (such as Mongolian) is supported by UPE. But here is a list of languages that are supported by this new solution:
- Latin 1 (e.g. English, French, German, Spanish…)
- Latin 2 (e.g. Czech, Polish,…)
- Cyrillic (e.g. Russian, Ukranian)
- Simplified Chinese
- Traditional Chinese
- Baltic (Estonian, Latvian, Lithunian)