Skip Headers

Oracle® Application Server Reports Services Publishing Reports to the Web 10g Release 2 (10.1.2) B14048-02 |
| Library | Product | Contents | Index

Previous | Next |

# 18 Implementing Globalization and Bidirectional Support

When you design reports to be deployed to different countries, you must consider such things as character sets and text reading order. OracleAS Reports Services includes the support you need to address any issues related to these considerations: Globalization support for character sets and bidirectional support for text reading order.

Globalization support makes it possible to design applications that can be deployed in several different languages. Oracle supports most European, Middle Eastern, and Asian languages. globalization support enables you to:

- Use international character sets (including multibyte character sets)

- Display data according to the appropriate language and territory conventions

- Extract strings that appear in your interface and translate them

Bidirectional support enables you to display data in either a left-to-right or right-to-left orientation, depending on the requirements of your audience.

This chapter provides a look at globalization upport architecture, including globalization upport settings relevant to Reports; explains how to specify character sets in a JSP; and offers information on bidirectional, Unicode, and translation support. It includes the following main sections:

- Globalization Support Architecture

- Globalization Support Environment Variables

- Specifying a Character Set in a JSP or XML File

- Bidirectional Support

- Unicode

- Translating Applications

- Troubleshooting Globalization Issues

## 18.1 Globalization Support Architecture

Globalization support architecture consists of two parts:

- Language-Independent Functions

- Language-Dependent Data

### 18.1.1 Language-Independent Functions

Language-independent functions handle manipulation of data in an appropriate manner, depending on the language and territory of the runtime operator. Data is automatically formatted according to local date and time conventions.

### 18.1.2 Language-Dependent Data

With language-dependent data, you can isolate your data. This enables your application to deal only with translating strings that are unique to your application.

Because the language-dependent data is separate from the code, the operation of globalization upport functions is governed by the data supplied at runtime. New languages can be added and language-specific application characteristics can be altered without requiring code changes. This architecture also enables language-dependent features to be specified for each session.

## 18.2 Globalization Support Environment Variables

Globalization support environment variables are automatically set to default values during Oracle Application Server installation.

Note: With the environment switching feature, you are not limited to the default environment set at the time of installation, and you can configure multiple evironments, including language settings, for a single Reports Server. For more information, refer to Section 3.2.2, "Dynamic Environment Switching".

Table 18-1 lists and describes globalization support-related environment variables that are particularly relevant to OracleAS Reports Services.

Note: For more information on all globalization support environment variables, see the Oracle Application Server Globalization Guide on the Oracle Technology Network, (`http://www.oracle.com/technology/index.html`).

Table 18-1 OracleAS Reports ServicesEnvironment Variables for Globalization Support

Variable | Description
--- | ---
`NLS_LANG` | Relevant to OracleAS Reports Services. The language settings used by OracleAS Reports Services.
`DEVELOPER_NLS_LANG` | The language for Reports Builder. If not set, then `NLS_LANG` default values are used.
`USER_NLS_LANG` | The language for Reports Runtime. If not set, then `NLS_LANG` default values are used.

### 18.2.1 NLS_LANG Environment Variable

The `NLS_LANG` environment variable specifies the language, territory, and character set settings to be used by OracleAS Reports Services. Specifically:

- The language for messages displayed to the user

- The default format masks used for `DATE` and `NUMBER` data types

- The sorting sequence

- The character set

  Note: This environment variable is set automatically when you install Oracle Application Server. Refer to Defining the NLS_LANG Environment Variable for more information about changing the environment variable after installing Oracle Application Server.

The syntax for `NLS_LANG` is:

    NLS_LANG=language_territory.charset

The values are defined as follows:

- `language`

  Specifies the language and its conventions for displaying messages (including error messages) as well as day and month names. If language is not specified, then the value defaults to American.

- `territory`

  Specifies the territory and its conventions for default date format, decimal character used for numbers, currency symbol, and calculation of week and day numbers. If territory is not specified, then the value defaults to America.

- `charset`

  Specifies the character set in which data is displayed. This should be a character set that matches your language and platform. This option also specifies the character set used for displaying messages.

  Note: When you use features like OracleAS Portal Security, Portal Destination, and Job Status Repository, the JDBC database connections made by OracleAS Reports Services may override the initial `NLS_LANG` setting. This change may in turn affect the behavior of the running report, such as alisaing PDF output in Asian languages. On UNIX platforms, you can work around this issue by using the environment switching functionality to dynamically set the environment for reports, as described in Section 3.2.2, "Dynamic Environment Switching".

Refer to the Oracle Application Server Globalization Guide for more information on the commonly used language, territory, and character values for `NLS_LANG`.

Your `NLS_LANG` setting should take into account regional differences between countries that use (basically) the same language. For example, if you want to run in French (as used in France), then you set the `NLS_LANG` environment variable:

    NLS_LANG=FRENCH_FRANCE.WE8ISO8859P1

If you want to run in French, but this time as used in Switzerland, you would set the `NLS_LANG` environment variable:

    NLS_LANG=FRENCH_SWITZERLAND.WE8ISO8859P1

Note: The language for the `rwservlet` pages such as`showjobs,showenv`, online Help, and error messages are delivered from the middle tier machine's locale (or `LANG` on UNIX) and not `NLS_LANG`. For example, if you have set your middle tier locale to French and `NLS_LANG=JAPANESE_JAPAN.JA16SJIS`, the `showjobs` or error messages will be displayed in French, not in Japanese.

#### 18.2.1.1 Defining the NLS_LANG Environment Variable

You define the `NLS_LANG` environment variable in the same way you define other environment variables on your Windows or UNIX operating system.

##### 18.2.1.1.1 Windows

To define the `NLS_LANG` environment variable on Windows, do the following:

1. Open the Windows registry.

   Note: Back up your registry before you edit it.

2. Expand the HKEY_LOCAL_MACHINE node, then expand the SOFTWARE node.

3. Expand the Oracle node, then click your OracleAS Reports Services HOME node to display the Oracle environment variables in the right panel of the Registry Editor.

4. Double-click the `NLS_LANG` environment variable.

5. Type the new value for `NLS_LANG` in the Value data text box.

6. Click OK.

##### 18.2.1.1.2 UNIX

To define the `NLS_LANG` environment variable on the UNIX platform, set it in the shell script `reports.sh`, located in your `ORACLE_HOME``/bin` directory.

#### 18.2.1.2 Character Sets

The character set component of the globalization support environment variables specifies the character set in which data is represented in your environment. When data is transferred from a system using one character set to a system using another character set, it is processed and displayed correctly on the second system, even though some characters might be represented by different binary values in the character sets.

##### 18.2.1.2.1 Character Set Design Considerations

If you are designing a multilingual application, or even a single-language application that runs with multiple character sets, you need to determine the character set most widely used at runtime and then set the `NLS_LANG` environment variable to that particular character set.

If you design an application in one character set and run it in another character set, performance can suffer. Furthermore, if the runtime character set does not contain all the characters in the design-time character set, then question marks appear in place of the unrecognized characters.

##### 18.2.1.2.2 Font Aliasing Considerations

There may be situations where you create a multilingual application with a specific font but find that a different font is being used when you run that application. You would most likely encounter this when using an English font (such as MS Sans Serif or Arial) in environments other than Western European. This occurs because OracleAS Reports Services checks to see if the character set associated with the font matches the character set specified by the language environment variable. If the two do not match, OracleAS Reports Services automatically substitutes the font with another font whose associated character set matches the character set specified by the language environment variable. This automatic substitution assures that the data being returned from the database gets displayed correctly in the application.

Note: If you enter local characters using an English font, then Windows does an implicit association with another font.

There might be cases, however, where you do not want this substitution to take place. You can avoid this substitution by mapping all desired fonts to the `WE8ISO8859P1` character set in the font alias file (`uifont.ali`). For example, if you are unable to use the Arial font in your application, you can add the following line to your font alias file (located at `ORACLE_HOME``\TOOLS\COMMON\`):

    ARIAL.....=ARIAL.....WE8ISO8859P1

This example specifies that any Arial font should be mapped to the same value, but with the `WE8ISO8859P1` character set.

For more information about font aliasing and `uifont.ali`, see Section 6.1.2.1, "Font Aliasing".

#### 18.2.1.3 Language and Territory

While the character set ensures that the individual characters needed for each language are available, support for national conventions provides correct localized display of data items.

The specified language determines the default conventions for the following characteristics:

- Language for OracleAS Reports Services messages and message from the Oracle Database.

- Language for day and month names and their abbreviations (specified in the SQL functions `TO_CHAR` and `TO_DATE`).

- Symbol equivalents for AM, PM, AD, and BC.

- Default sorting sequence for character data when `ORDER BY` is specified (`GROUP BY` uses a binary sort unless `ORDER BY` is specified).

- Writing direction (both right to left and left to right).

For example, if the language is set to French, then the following messages in English are converted to French:

    English:
    ORA-00942: table or view does not exist
    REP-0110: Unable to open file.

    French:
    ORA-0092: table ou vue inexistante
    REP-0110: Impossible d'ouvrir le fichier

The specified territory determines the conventions for the following default date and numeric formatting characteristics:

- Date format

- Decimal character and group separator

- Local currency symbol

- ISO currency symbol

- Week start day

- Credit and debit symbol

- ISO week flag

- List separator

For example, if the territory is set to France, then the numbers are formatted using a comma as the decimal character.

### 18.2.2 DEVELOPER_NLS_LANG and USER_NLS_LANG Environment Variables

If you must use two sets of resource and message files at the same time, then two other language environment variables are available. These can be used after Oracle Application Server installation is completed.

- `DEVELOPER_NLS_LANG`

- `USER_NLS_LANG`

The syntax for `DEVELOPER_NLS_LANG` and `USER_NLS_LANG` is the same as for the `NLS_LANG` environment variable. That is:

    DEVELOPER_NLS_LANG=language_territory.charset
    USER_NLS_LANG=language_territory.charset

If these environment variables are not specifically set, then `NLS_LANG` default values will be used. Use the `DEVELOPER_NLS_LANG` and `USER_NLS_LANG` environment variables in lieu of the `NLS_LANG` environment variable in the following situations:

- You prefer to use Reports Builder in a particular language (for example, English), but you are developing an application for another language. `DEVELOPER_NLS_LANG` and `USER_NLS_LANG` environment variables allow you to use different language settings for the Reports Builder and Reports Runtime.

- You are creating an application to run in a language for which a local language version of Reports Builder is not currently available.

## 18.3 Specifying a Character Set in a JSP or XML File

If you are running the Web layout of your JSP report, then you may need to add a character set to your JSP file using the following syntax (the following example specifies a Japanese character set):

    <%@ page contentType="text/html;charset=Shift_JIS" %>
    <META http-equiv="Content-Type" content="text/html;charset=Shift_JIS">

Note: To set the character set in a paper layout report that you plan to use to generate XML, you must include a character set for the report's XML Prolog Value property:
    <?xml version="1.0" encoding="&Encoding" ?>
`&Encoding` is then replaced at runtime with the appropriate setting. For more information, refer to the Oracle Application Server Globalization Guide.

The values expressed for the character set should call a character set that is compatible with the one specified for OracleAS Reports Services. The values for character sets used on the Web (IANA-defined character sets) are different from the values expressed in the `NLS_LANG` environment variable. Table 18-2 lists commonly used IANA-defined character sets for the `charset` parameter:

Note: IANA charset values are not case-sensitive. You can enter them in uppercase or lowercase.

Table 18-2 Valid Values for the IANA-Defined Character Sets

Languages | Valid IANA-Defined Character Sets
--- | ---
AMERICAN | ISO-8859-1, ISO-8859-15, windows-1252, US-ASCII, UTF-8
ARABIC | ISO-8859-6, windows-1256, UTF-8
ASSAMESE | UTF-8
BANGLA | UTF-8
BENGALI | UTF-8
BRAZILIAN PORTUGESE | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
BULGARIAN | ISO-8859-5, windows-1251, KOI8-R, UTF8
CANADIAN FRENCH | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
CATALAN | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
CROATIAN | ISO-8859-2, windows-1250, UTF-8
CZECH | ISO-8859-2, windows-1250, UTF-8
DANISH | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
DUTCH | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
EGYPTIAN | ISO-8859-6, windows-1256, UTF-8
ENGLISH | ISO-8859-1, ISO-8859-15, windows-1252, US-ASCII, UTF-8
ESTONIAN | ISO-8859-4, ISO-8859-13, windows-1257, UTF-8
FINNISH | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
FRENCH | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
GERMAN DIN | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
GERMAN | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
GREEK | ISO-8859-7, windows-1253, UTF-8
GUJARATI | UTF-8
HEBREW | ISO-8859-8-I, windows-1255, UTF-8
HINDI | UTF-8
HUNGARIAN | ISO-8859-2, windows-1250, UTF8
ICELANDIC | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
INDONESIAN | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
ITALIAN | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
JAPANESE | EUC-JP, Shift_JIS, UTF-8
KANNADA | UTF-8
KOREAN | EUC-KR, UTF-8
LATIN AMERICAN SPANISH | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
LATVIAN | ISO-8859-4, ISO-8859-13, windows-1257, UTF-8
LITHUANIAN | ISO-8859-4, ISO-8859-13, windows-1257, UTF-8
MALAY | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
MALAYALAM | UTF-8
MARATHI | UTF-8
MEXICAN SPANISH | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
NORWEGIAN | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
ORIYA | UTF-8
POLISH | ISO-8859-2, windows-1250, UTF8
PORTUGESE | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
PUNJABI | UTF-8
ROMANIAN | ISO-8859-2, windows-1250, UTF-8
RUSSIAN | ISO-8859-5, windows-1251, KOI8-R, UTF-8
SIMPLIFIED CHINESE | GBK, GB18030, UTF-8
SLOVAK | ISO-8859-2, windows-1250, UTF-8
SLOVENIAN | ISO-8859-2, windows-1250, UTF-8
SPANISH | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
SWEDISH | ISO-8859-1, ISO-8859-15, windows-1252, UTF-8
TAMIL | UTF-8
TELUGU | UTF-8
THAI | TIS-620, UTF-8
TRADITIONAL CHINESE | Big5, Big5-HKSCS, UTF-8
TURKISH | ISO-8859-9, windows-1254, UTF-8
UKRANIAN | ISO-8859-5, windows-1251, KOI8-U, UTF-8
VIETNAMESE | windows-1258, UTF-8

## 18.4 Bidirectional Support

Bidirectional support enables you to design applications in those languages whose natural writing direction is right to left, such as Middle Eastern and North African languages. Bidirectional support enables you to control:

- Layout direction, which includes displaying items with labels at the right of the item and correct placement of check boxes and radio buttons.

- Reading order, which includes text direction (for example, right to left or left to right) .

- Alignment, which includes switching point-of-origin from upper left to upper right.

When you are designing bidirectional applications, you might want to use the globalization support environment variables `DEVELOPER_NLS_LANG` and `USER_NLS_LANG` rather than inheriting the `NLS_LANG` settings. For example, if you want to use an American interface while developing an Arabic application in a Windows environment, then set these environment variables as follows:

    DEVELOPER_NLS_LANG=AMERICAN_AMERICA.AR8MSWIN1256
    USER_NLS_LANG=ARABIC_UNITED ARAB EMIRATES.AR8MSWIN1256

Note that, in this example, the `DEVELOPER_NLS_LANG` environment variable uses an Arabic character set. For more information, refer to Section 18.2, "Globalization Support Environment Variables".

On Windows, when you generate PDF output with font subsetting enabled for languages that read right to left (such as Hebrew and Arabic), Oracle Reports 10g Release 2 (10.1.2) introduces an enhancement that ensures text will be accurately right-aligned (refer to Section 6.4, "Generating a Bidirectional (BiDi) PDF File").

On UNIX, you may continue to see misalignment of right-aligned text in PDF output for languages that read right to left. To work around this issue, use fixed width fonts instead of variable width fonts. For example, Miriam Fixed True Type font (Hebrew) is a fixed width font available on Windows 2000, and can be used for font subsetting on UNIX platforms to correct any font alignment issues with Hebrew fonts. For more information about resolving font issues across different platforms, see Chapter 7, "Resolving Cross-Platform Porting Issues".

## 18.5 Unicode

Unicode is a global character set that allows multilingual text to be displayed in a single application. This enables multinational corporations to develop a single multilingual application and deploy it worldwide.

Global markets require a character set that:

- Allows a single implementation of a product for all languages, yet is simple enough to be implemented everywhere.

- Contains all major living scripts.

- Supports multilingual users and organizations.

- Enables worldwide interchange of data through the Internet.

This section discusses the following aspects of Unicode in Oracle Reports:

- Unicode Support

- Unicode Font Support

- Enabling Unicode Support

### 18.5.1 Unicode Support

OracleAS Reports Services provides Unicode support. On UNIX platforms, Unicode support has certain limitations; for example:

- Unicode is not supported in PostScript output format on UNIX.

- In other bitmap output formats, such as PDF and RTF, you may observe font issues such as character misalignment on UNIX.

For information on how to resolve such issues, refer to Section 7.1.2, "Fixing Font-Related Issues".

If you use Unicode, you are able to display multiple languages, both single-byte languages such as Western European, Eastern European, Bidirectional Middle Eastern, and multibyte Asian languages such as Chinese, Japanese, and Korean (CJK) in the same application.

Use of a single character set that encompasses all languages eliminates the need to have various character sets for various languages. For example, to display a multibyte language such as Japanese, the `NLS_LANG` environment variable must be set to the following:

    NLS_LANG=JAPANESE_JAPAN.JA16SJIS

To display a single-byte language such as German, `NLS_LANG` must be set to the following:

    NLS_LANG=GERMAN_GERMANY.WE8ISO8859P1

The obvious disadvantage of this scheme is that applications can only display characters from one character set at a time. Mixed character set data is not possible.

With the Unicode character set, you can set the character set portion of `NLS_LANG` to `UTF8` instead of a specific language character set. This allows characters from different languages and character sets to be displayed simultaneously. For example, to display Japanese and German together on the screen, the character set portion of the `NLS_LANG` environment variable must be set to `UTF8`, along with the appropriate `language_territory` setting. For example:

    NLS_LANG=JAPANESE_JAPAN.UTF8
    NLS_LANG=GERMAN_GERMANY.UTF8
    NLS_LANG=AMERICAN_AMERICA.UTF8

Unicode capability gives the application developer and end user the ability to display multilingual text in a report. This includes text from a database containing Unicode characters, multilingual boilerplate text, text in graphical user interface (GUI) objects, text input from the keyboard, and text from the clipboard.

Note: If you develop applications for the Web, then you can use Unicode because of the Unicode support provided by Java through the browser.

### 18.5.2 Unicode Font Support

To enter text in a particular language, you must be running a version of the operating system that supports that language. Also, depending on the output format type, OracleAS Reports Services relies on the operating system for the font for different languages, as described in Chapter 4, "Managing Fonts in Oracle Reports".

Windows provides True Type Big Fonts. These fonts contain the characters necessary to display or print text from more than one language. For example, if you try to type, display, or print Western European, Central European, and Arabic text on a field and see unexpected characters, then you are probably not using a Big Font. Big Fonts for single-byte languages provided by Microsoft Windows are Arial, Courier New, and Times New Roman. For more information, go to Microsoft's Web site: `http://www.microsoft.com/typography/fonts/default.aspx`.

Oracle provides two Unicode fonts for Western European, Central European, Cyrillic, Greek, Turkish, Hebrew, Arabic, Baltic, Vietnamese, Thai, Simplified Chinese, Japanese, Korean, and Traditional Chinese:

- Albany WT fonts (proportional width) are available in Oracle Application Server 10g Release 2 (10.1.2) MRUA CD.

- Andale Duospace WT fonts (fixed width) can be downloaded from Oracle Metalink (`http://metalink.oracle.com`). The ARU number is 2638552.

Third-party Unicode fonts are also available.

### 18.5.3 Enabling Unicode Support

To enable Unicode support, set the `NLS_LANG` environment variable as follows:

    NLS_LANG=language_territory.UTF8

Refer to Section 18.2, "Globalization Support Environment Variables" for more information about environment variables.

## 18.6 Translating Applications

In any OracleAS Reports Services application, you see many types of messages, including:

- Error messages from the database

- Runtime error messages produced by OracleAS Reports Services

- Messages and boilerplate text defined as part of the application

If the `NLS_LANG` environment variable is set correctly and the appropriate message files are available, then translation of messages for the first two items is done for you. To translate messages and boilerplate text defined as part of the application, you can use the Oracle translation tool, TranslationHub, and you might also find it useful to use PL/SQL Libraries for strings of code.

Note: You'll find information about using TranslationHub on your Oracle Developer Suite documentation CD and on the Oracle Technology Network (`http://www.oracle.com/technology/index.html`).

Manual translation is required for constant text within a PL/SQL block because that text is not clearly delimited, but is often built up from variables and pieces of strings. To translate these strings, you can use PL/SQL libraries to implement a flexible message structure.

You can use attachable PL/SQL libraries to implement a flexible message function for messages that are displayed programmatically by the `SRW.MESSAGE` built-in procedure, or by assigning a message to a display item from a trigger or procedure. The library can be stored on the host and dynamically attached at runtime. At runtime, based on a search path, you can pull in the attached library. For example, a library might hold only the Italian messages:

    FUNCTION nls_appl_mesg(index_no NUMBER)
    RETURN CHAR
    IS
       msg CHAR(80);
    BEGIN
       IF index_no = 1001 THEN
          msg := 'L''impiegato che Voi cercate non esiste...';
       ELSIF index_no = 1002 THEN
          msg := 'Lo stipendio non puo essere minore di zero.';
       ELSIF  ...
       .
       .
       ELSE
          msg := 'ERRORE: Indice messaggio inesistente.';
       END IF;
       RETURN msg;
    END;

A routine like this could be used anywhere a character expression would normally be valid. For example, to display text with the appropriately translated application message, you might include the following code:

    SRW.MESSAGE(1001,nls_appl_mesg(1001));

Note: For a description of the `SRW` built-in package, including the `SRW.MESSAGE` built-in procedure, see the Oracle Reports online Help.

To change the application to another language, simply replace the PL/SQL library containing the `nls_appl_mes` function with a library of the same name containing the `nls_appl_mesg` function with translated text.

## 18.7 Troubleshooting Globalization Issues

To help resolve globalization issues that may occur in your multilingual applications, this section provides the following troubleshooting information:

- Embedding a Character Set in a JSP file Dynamically

- Setting Globalization Support Environment Variables

- Repairing Garbled Fonts When Using the WE8ISO8859P15 Character Set

- Opening or Running an Encoded JSP Report

- Resolving ERR-063001 xxx.dtd null

- Running Oracle Reports in a Japanese Environment on HP-UX

Embedding a Character Set in a JSP file Dynamically

In Oracle Reports, Web report templates are configured for Western European character encoding by default. However, for other languages, you can specify the character encoding for every JSP file by using both the charset attribute of the `<Meta>` tag and the `<%@page%>` page directive.

To dynamically associate the appropriate character encoding with the JSP file, you can make the following modifications:

1. Edit the `rw*.html` files and the `blank_template.jsp` file:

   1. Modify the page directive to read

          <%@ page contentType="text/html;charset=yourIANAencoding" %>

      where:

      `yourIANAencoding` is the IANA-defined character set name that corresponds to the `NLS_CHARACTERSET` portion of the `NLS_LANG` variable.

   2. Modify the `<Meta>` tag inside the `<Head>` tag to read:

          <meta http-equiv="Content-Type"
          content="text/html;charset=yourIANAencoding" />

      Note: The template files; that is, `rw*.html`, and `blank_template.jsp`, are located in the `ORACLE_HOME``/reports/templates/` directory.

2. Edit the `template.xsl` (`ORACLE_HOME``/reports/templates/`) file:

   1. Modify the `<xsl:output>` tag to read:

          <xsl:output
               method="jsp"
               indent="yes"
               encoding="yourIANAencoding"
             />

      where

      `yourIANAencoding` is the IANA-defined character set name that corresponds to the `NLS_CHARACTERSET` portion of the `NLS_LANG` variable.

   2. Add the page directive to the file:

          <%@ page contentType="text/html;charset=yourIANAencoding" %>

   3. Add or modify the `<META>` tag inside the `<HEAD>` tag:

          <meta http-equiv="Content-Type"
          content="text/html;charset=yourIANAencoding" />

      where

      `yourIANAencoding` is the IANA-defined character set name that corresponds to the `NLS_CHARACTERSET` portion of the `NLS_LANG` variable.

Setting Globalization Support Environment Variables

The `Tk2Motif.rgb` file contains resource settings for the Motif version of the Oracle Toolkit. For example, it specifies the font mapping between the character set used by Oracle Reports, specified in `NLS_CHARACTERSET`, and X fonts.

Oracle Reports looks for this file in the directory `ORACLE_HOME``/guicommon/tk/admin/language`, where `language` is derived from the language setting in `NLS_LANG`.

If the file does not exist, then Oracle Reports looks for the default version in `ORACLE_HOME``/guicommon/tk/admin`. This version is configured for `WEISO8859P1`, the Western European character set.

If your `NLS_LANG` or `NLS_CHARACTERSET` specifies a character set that is not normally used for the language you have set in `NLS_LANG`, then Oracle Reports generates an error.

For example, if you have set `NLS_LANG=AMERICAN_AMERICA.JA16EUC`, then Oracle Reports locates `Tk2Motif.rgb` in the directory `ORACLE_HOME``/guicommon/tk/admin/`. The language setting in `NLS_LANG` is `AMERICAN`, and there is no language subdirectory associated with `AMERICAN`, so Oracle Reports uses the default file. Since this version is designed for `WE8ISO8859P1`, and your `NLS_LANG` character set is `JA16EUC`, Oracle Reports generates the error `REP-3000`.

To work around this problem, set the value of the environment variable `TK_UNKNOWN` to the location of your character set-specific `Tk2Motif.rgb` file.

For example, if `NLS_LANG=AMERICAN_AMERICA.JA16EUC`, then set `TK_UNKNOWN`=`ORACLE_HOME``/guicommon/tk/admin/JA`. Even though your language is set to `AMERICAN`, Oracle Reports will use the `Tk2Motif.rgb` file in the `JA` language subdirectory.

Repairing Garbled Fonts When Using the WE8ISO8859P15 Character Set

You may see garbled output when you run a multibyte report on UNIX with `we8iso8859p15` character set.

To work around this issue, you must do the following:

1. Make an entry for the fonts used in your default printer's `.ppd` file. This file is located in the following directory:

       $ORACLE_HOME/guicommon/tk/admin

   Note: The entries are for the fonts that appears garbled in the report output.

2. Set the encoding scheme in the font's AFM file to `FontSpecific` if it is `AdobeStandardEncoding`. Thus, the following entry in the AFM file:

       EncodingScheme AdobeStandardEncoding

   must change to:

       EncodingScheme FontSpecific

Opening or Running an Encoded JSP Report

If your JSP report's character encoding (for example, `EUC-JP`) differs from the character set portion of the `NLS_LANG` environment variable (for example, `JA16SJIS`), then you will get the following errors:

- when running the JSP file:

      REP-6106 or 6104 with javax.servlet.jsp.JspException  (multibyte)
      REP-0495 Unable to tokenize the query (singlebyte)

- when opening the JSP file using Reports Builder:

      REP-0069 Internal Error or REP-6106

To work around this issue, you must ensure that your JSP report's character encoding matches the IANA-defined character set corresponding to Oracle Reports' character set portion of the `NLS_LANG` variable.

For example:

JSP Report encoding:

    <%@ page contentType="text/html;charset=EUC-JP" %>
    <META http-equiv="Content-Type" content="text/html;charset=EUC-JP">

This JSP file needs to be encoded in the character set (`EUC-JP`).

Oracle Reports encoding:

    NLS_LANG=JAPANESE_JAPAN.JA16EUC

In this example, the JSP report's encoding (`EUC-JP`) matches Oracle Reports' character set portion of `NLS_LANG`; that is, `JA16EUC`.

Resolving ERR-063001 xxx.dtd null

When you create a report against an XML data source, you must ensure that the encoding of both the XML file (data source) as well as the DTD matches the encoding of Oracle Reports.

When you create an XML report against a table -- for example, a Japanese table-- the group element name is in the table's language that is Japanese. To match the data source, you should set the group's element name in the DTD to Japanese. The XML and DTD files can be in any encoding that supports Japanese, for example, `Shift_JIS`, `EUC-JP`, or `UTF-8`. However, when the encoding of the XML data source as well as the DTD differs from Oracle Reports, you will see the following error:

    ERR-063001 xxx.dtd null

Note: This error is not displayed if you use an XML schema to define the rules.

To work around this issue, you must ensure that both the data source XML files as well as the DTD file for an XML report is encoded in the character set portion of Reports Runtime `NLS_LANG`.

For example, if your `NLS_LANG=JAPANESE_JAPAN.JA16SJIS`, then both your data source XML file as well as your DTD file should be encoded in `Shift_JIS`.

Running Oracle Reports in a Japanese Environment on HP-UX

If you want to use Oracle Reports in the HP-UX Japanese environment with `NLS_LANG=JAPANESE_JAPAN.JA16SJIS`, you will need to modify the appropriate `Tk2Motif.rgb` file before using Oracle Reports because this file contains EUC encoded Japanese resources.

Convert the `Tk2Motif.rgb` file to Shift-JIS encoding, or remove the last seven entries from this file. Otherwise, Oracle Reports may fail.

Note: The `Tk2Motif.rgb` file for the Japanese environment is: `$ORACLE_HOME/guicommon/tk/admin/JA/Tk2Motif.rgb`