Consultor Eletrônico

Status: Unverified

FACT(s) (Environment):

Windows
Progress 9.x
OpenEdge 10.x

SYMPTOM(s):

SESSION:GET-PRINTERS returns wrong character when using -cpinternal UTF-8

Printers with extended character names are displayed incorrectly when returned with GET-PRINTERS method.

Using UTF-8 for -cpinternal.

Using another single byte code page for -cpstream (e.g. 1252).

CAUSE:


This is expected behavior. When reading and writing to/from the registry and ini files, Progress does not perform any code page conversions between cpinternal and cpstream. The reason for this is because in the past it was assumed that the ini files and registry will be modified using Windows tools (using the Windows code page).
Therefore in the registry, printer names can be defined with extended characters, but these characters will be defined using the the operating systems local single byte code page (e.g. 1252) when the printer was defined. This means that these characters will have code point values between 128 - 255. If a UTF-8 (-cpinternal) client session then executes GET-PRINTERS, since Progress does not convert when reading from the registry, because the session is started with the UTF-8 code page Progress assumes the registry values must be in this code page. Since it is not defined in UTF-8 and the fact that there aren't any characters in UTF-8 in the position 128 - 255, you get an incorrect printer name (corrupted characters) returned.

FIX:

To avoid this problem only define printer names using the ASCII characters in positions 0-127.

Alternatively use CODEPAGE-CONVERT to convert from the O.S. code page to UTF-8. For example:

CODEPAGE-CONVERT(SESSION:GET-PRINTERS(),"UTF-8","1252").