Skip to Content
Author's profile photo Aidan Black

PDF Conversion in Multiple Languages

PDF conversion can be complicated when trying to create PDFs from sapscript and smartforms in various languages.

For some languages the internal Adobe fonts do not support the characters as needed. In this case you need to install a true type font in the SAP system and this font is embedded into the PDF file and is used for the characters. The disadvantage to this is that it increases the size of the created PDF because the complete font needs to be embedded into the PDF file.

There are two methods for creating PDFs from SAP. 

The first method is the old non-Unicode method where the PDF file is created via non-Unicode device types like SAPWIN, CNSAPWIN, I2HP4, I7SPOST etc. In this case, the PDF must be created by a sapscript form or smartform with the correct language key and the fonts used in the smartform need to to support the language characters. Also the device type used must be a suiitable device type for the required language.

An example of this is if you want to create a PDF for a form with Russian(Cyrillic) characters. The form must have a language key RU. The fonts used in the form must be Russian fonts like COURCYR, TIMECYR and HELVCYR. True type fonts that support Russian characters must be uploaded into the SAP system under font familes COURCYR, TIMECYR and HELVCYR. This is done via report RSTXPDF2. Finally a device type that supports Cyrillic characters like SAPWIN or SAPWIN5 must be used to create the PDF data. This information applies for Unicode systems also if you use a non-Unicode device type.

In Unicode systems only, the Unicode PDF conversion method is possible. The PDF in this case must be create via unicode device types like SWINCF or PDFUC. With this method, the language key of the form is no longer important. The characters are mapped to a suitable font based on the unicode range that they belong to. For languages which have chararacters that are not supported by Adobe’s internal fonts, it is again necessary to upload true type fonts to the SAP system. For the Unicode PDF conversion menthod via  PDFUC or SWINCF, the fonts can be uploaded via report RSTPDF2UC.There is more information about this topic in SAP note #999712 and the PDF_Font_Installation_Guide document contained in the note attachments.

For both methods above, when creating PDFs with CJK Asian languages, no true type fonts are needed. The internal Adobe fonts support these languages. Also, any true type font for these languages is much too large to embed into a PDF file.

For PDF conversion of sapscript and smartforms, this can be done by the application creating the OTF spool data and then a function moule like CONVERT_OTF is used to create the PDF from the OTF data. In this case, it is the device type, form language key and fonts used to create the OTF data that is important.

It is also possible to call the sapscript funtion module OPEN_FORM with parameter DEVICE=MAIL. In this case the PDF conversion is done via SAPCONNECT. It is similar if the application calls the smartform function module with the parameter CONTROL_PARAMETERS-DEVICE = ‘MAIL’. When the PDF is created via SAPCONNECT, for the device type used, it is the setting in SAPCONNECT(transaction SCOT) that is important.

SCOT -> Settings -> Device Types for Format Conversion

Here a device type can be maintained for the various languages and it is this device type that is used to create the PDF file.

I hope you find this useful.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Trond Stroemme
      Trond Stroemme
      One way of resolving these output issues are using a universal unicode device type, typically with an output management system like HP output managemet (formerly known as dazel) or possibly similar systems. This also avoids having to install a myriad of fonts etc on local printers - a real boon if you operate a global SAP system and have to cater for several local character sets and languages. And, remember, some of those pesky font files are covered by intellectual property rights - meaning they're not for free...
      Author's profile photo Bruno Esperança
      Bruno Esperança

      Thanks so much for this.