INVOICE

[Former Member]

Hi

consultant have implemented smartform for invoices. They try to create invoice for foreign client (POLAND -> FRANCE) but at option Issue output to - Print preview French buyers don't have French special characters only character is #.

Where could be problem? It is Unicode system.

Regards

Damian

[jiteshmehta]

Dear Damian

To display Special characters in Smartforms ...

goto text editor of the perticular text node.

in the text editor, Click INSERT - Characters - Displayable Characters.

a new window will open showing all characters...if ur required character is not

present, click on non-dispalyble character button , it displays all the characters

and their respective numbers...select ur required character .

if that doesn't solve your problem refer

OSS Note: 776507

___________________

Symptom

Documents printed via SAPscript or SmartForms do not print with correct special characters, e.g. ### prints instead of Japanese or Russian characters. What to do?

Other terms

SAPscript, SmartForms, printing, device types, OTF

Reason and Prerequisites

Help required to choose proper fonts in a SAPscript or SmartForm

Solution

When using SAPscript or SmartForms to print (or email or fax) a form from a business application, many factors influence the outcome of the actual text within the form. All these factors must be checked in order to ensure a correct printout:

1) The language version of the form used to produce the printout.

Example: If you want to print a French invoice, you need to have a FR version of your SAPscript or SmartForms invoice form RVINVOICE01. And the application program must specify the corresponding language key (FR) when calling the SAPscript or SmartForms API.

2) The font selections specified in the form (possibly also in a SAPscript style or SmartStyle used in a form).

Example: In a SAPscript form or a SmartStyle you need to specify HELVE if you want to print German text in Helvetica (or similar) font. If you want to print Japanese text, HELVE is not a valid choice but you need to specify a Japanese font like JPMINCHO in your Japanese form.

3) The output character set of the device type

Every printer in transaction SPAD has a "device type" assigned. Device types used by the spooler for printing support only one single specific output character set. All text from the form has to be converted (using SAP's built-in character conversion mechanism) to this output character set.

A character set can typically support either a single language (e.g. Shift-JIS which supports only Japanese) or a set of languages (e.g. ISO 8859-1, which supports Western-European languages). It is possible that a given language (such as German) can be supported by several output character sets, e.g. you may use either ISO 8895-1 (Latin-1) or ISO 8859-2 (Latin-2) to represent German text. This is so because both character sets contain the special characters used in German.

Example: HPLJ4000 is a HP LaserJet device type supporting the ISO 8859-1 (Latin-1) character set. ISO 8859-1 can be used to represent e.g. Dutch, English, French, German, Spanish, Swedish but NOT Russian or Japanese.

As a consequence, it is ok to use HPLJ4000 to print English, German French etc. but not for Japanese or Russian.

4) The set of available printer fonts for a given device type

When formatting a document, SAPscript and SmartForms perform an automatic mapping of the font definitions in the form (e.g. "HELVE 14 point bold") and the available printer fonts of the device type. A replacement printer font is chosen, should the specified font selection not be available in the device type. Now this replacement can be problematic if a language-specific font, such as Chinese CNSONG, is specified in a form and it gets replaced by a font which does not support this language, e.g. COURIER.

To solve this problem, font families in SE73 have language attribute assigned, e.g. some fonts are characterized as being suitable only for certain languages. And when a replacement has to be chosen because the original font from the form is not available in the device type, a replacement font is chosen which has the same language attributes.

If no fonts for the language in question exist in the device type, the resulting font will not be able to print the special characters and you will see "wrong" output characters in the printout.

[Former Member]

Hi Damien,

Non-unicode system can also be a reason for your issue, but if you can elaborate more regarding this the situation will become slightly clear...

Hope this view would help you in some extent...

Hrishi