|
Oracle® Application Server Reports Services Publishing Reports to the Web
10g Release 2 (10.1.2) B14048-02 |
|
 Previous |
 Next |
|
Oracle® Application Server Reports Services Publishing Reports to the Web
10g Release 2 (10.1.2) B14048-02 |
|
|
Previous |
Next |
This chapter provides information about fonts in Oracle Reports. In particular, it covers the following sections:
In Oracle Reports, fonts come into play:
In Reports Builder, at build time
In the report's output, at runtime
In the user interface of Reports Builder
Reports Builder provides a list of fonts that are available on the system in the font picker box.
On Windows, the font list is derived from the fonts that are installed on the system along with the fonts available on the current default printer. A small printer icon before the font name identifies printer fonts. True Type fonts are associated with a TTF icon.
On UNIX, the font list is derived by querying the X-server display on which the application is running for the available fonts. The command is similar to the UNIX xlsfonts command, which lists all of the available fonts for the X-server display. From this font list, Reports Builder generates a list of usable fonts with the valid style, weight, width, size, and encoding characteristics to match the character set. The character set is driven by the NLS_LANG environment variable. Reports Builder includes only those fonts with an encoding of iso8859-1, unless specified differently in the toolkit resource file, Tk2Motif*fontMapCs. For more information on Tk2Motif*fontMapCs, refer to Section 4.3, "Font Configuration Files".
During report formatting, fonts associated with the layout objects are first checked against the font alias file, uifont.ali, (refer to Section 4.3, "Font Configuration Files"). If an entry in the font alias file is found, the mapped font is used instead of the original one. The mapped font is then searched for in the list of fonts available on the system or printer. If a particular font is not found, Oracle Reports will look for the nearest matching font under the same character set which can be used instead.
On Windows, the font lookup mechanism is simple due to the availability of printer drivers, which have the capability of uploading fonts from the system as needed. Any output from Oracle Reports running on Windows will contain fonts from either one of the following:
The system
The printer
For this reason, Oracle Reports considers both the printer and the system fonts when looking for the available fonts.
On UNIX, the fonts available for generating output are either one of the following:
the fonts available on the printer, specifically the fonts defined in the PPD or TFM files
if no printer is specified, the fonts available in ScreenPrinter, screenprinter.ppd.
Figure 4-2 illustrates the process of determining the available fonts for generating report output.
The following steps describe how Oracle Reports generates a list of the available fonts for generating output (for example, for the screen, printer, or file):
Oracle Reports looks in the printer configuration file uiprint.txt for all the printers that are listed for the application. If no printers are defined or available, Oracle Reports uses ScreenPrinter.
Get their type, version and printer definition file.
Check for the existence of these printers in the system.
If the printers are present, the printer definition files are loaded and the information in these files is read along with the information related to the fonts available for the printer. If these printers are not found, then Oracle Reports uses ScreenPrinter.
The AFM files, which are named the same as the font names given in the PPD files, are searched.
If found, Oracle Reports then reads this file for all the valid keywords, checks for their correctness and, in case of any discrepancy, default values are used for those keywords.
If the AFM file is not found, Oracle Reports marks the font as unusable.
|
Note: Similarly for PCL printers, the HP printer definition file (glue file) is loaded and all the fonts defined in the file are also loaded. While looking for a font, Oracle Reports searches for an entry in the HPD file with the font name and accordingly takes the font if the TFM file for this font is also found. Otherwise, Oracle Reports matches this font to the closest available one. |
Once the list of available fonts is generated, the mapped font is searched for in this list of fonts and, again, the AFM files are read for the purpose of calculating the text size and weight.
Substituting fonts
If a particular font is needed but not found in the PPD file or if an AFM file is not found, Oracle Reports will look for the nearest matching font according to its matching rules. For example, suppose a report is originally designed with a Simplified Chinese font SimSun and in the uifont.ali file no mapping for this font is found. Oracle Reports will look for the font SimSun in the list of available fonts generated by the Font lookup algorithm. If this font name is not in that list, Oracle Reports tries to look for the closest matching font from the list of fonts given in the printer definition file.
For the SimSun font, the character set is 850. If it cannot find any matching font for this character set, Oracle Reports searches for a font that has a character set for the environment in which the application is running. After a set of fonts with a similar character set is found, Oracle Reports picks the closest match to the requested font based on the font weight, style, and so on. If more than one font has the same parameters, Oracle Reports picks the first one and uses it instead of the original font.
Font matching rules
When attempting to match a font, Oracle Reports will try to find the closest match according to the following criteria for fonts with the same character set:
fontface > fontsize > fontstyle > fontweight > fontwidth
If Oracle Reports can't match the font face, it will try to match the font size; if it can't match the size, it will try to match the font style; and so on.
If a font matches the font size but nothing else and another font matches the style, weight, and width but not the font size, then Oracle Reports will pick the font with the same font size.
It should be noted that irrespective of any font in the output file, the final printed output will depend solely on the fonts installed in the printer.
Example: Suppose that a report has layout objects associated with one of two fonts, Helvetica font of size 8, style Plain, and weight Medium, and Courier font. If the user is running this report on a PostScript-1 printer and generating HTML output, the fonts are chosen as follows:
While formatting, Oracle Reports checks uifont.ali for any mappings of either specified font. Suppose that uifont.ali contains this entry in the [Printer:PostScript1] section:
Helvetica.8.Plain.Medium.. = "Mkai-Medium"..
Oracle Reports will now search for the Mkai-Medium font instead of the Helvetica font.
Oracle Reports looks for the mapped font in the printer definition (PPD) file. Suppose that the PPD file contains the following entry in the *Font Information section:
"*Font Mkai-Medium: Standard "(001.004)" Standard ROM"
Oracle Reports now checks for the associated AFM file (named Mkai-Medium) in the AFM directory. If an AFM file with this name is not found, it will look for another font that has size 8, style Plain, and weight Medium under the same character set as the original font.
Because a report may have to run in many different environments, Oracle Reports always tries to approximate a font for the original font when the original is unavailable. This algorithm is not entirely foolproof. When you create a report, you must be aware of the fonts defined and you should always consider whether those same fonts will be available on the platform where users will run the report. If the font that you have defined is not available in the runtime environment, Oracle Reports substitutes another font that is available on the machine. This process can lead to unexpected and undesirable results, such as strange characters in the report output (for example, Wingding characters) and incorrect formatting of objects.
If you are encountering these kinds of problems, you should use font aliasing to control the font substitutions made by Oracle Reports. Refer to Section 4.4, "Font Aliasing".
Oracle Reports follows the above described mechanisms for all output file generation except PDF, which has the PDF font sub setting/embedding capabilities.
|
See Also: Chapter 6, "Using PDF in Oracle Reports" for more information on the PDF features and enhancements in OracleAS Reports Services.For more information on PDF in general, consult the Adobe PDF documentation. |
For printing, Oracle Reports generates output based upon the printer driver, in case of Windows, or the printer, in the case of UNIX. On Windows, the output generation is handled by the printer driver. The fonts in this case can either be from the system or from the printer. For fonts which are not available on the printer, the printer will get the fonts from the system through Windows APIs.
Text in the user interface of Reports Builder, like the window title, menu items, message boxes, and data model object names, use fonts taken from the system resource files for the current language. These system resource files are supplied with Oracle Reports installation. In Oracle Reports, you can map these fonts in the [rwbuilder] section of uifont.ali. If found, the mapped font is used instead of the original font. Otherwise, Oracle Reports uses the original font.
On UNIX, these fonts are defined in Tk2Motif.rgb under Tk2Motif*fontList. If the font is not defined, then the default font (fixed for default character set) is used instead. The default system font need not be the one defined in Tk2Motif.rgb. If the defined font does not match the character set on which the application is running, some other available font will be used following the font lookup algorithm discussed in the previous section.
On Windows, in order to maintain the look and feel of the windows, Oracle Reports makes extensive use of the system font, which is obtained from the Windows system parameters. For non-Unicode environments, the font is obtained from the icon objects. You can change it by modifying the fonts through Display Property > Appearance. Select Icon from the drop down box and select the desired font name and size. For Japanese Unicode systems, the font is MS Gothic. For Korean, it's MS Sans Serif. For simplified, traditional, and Hong Kong it's Arial. For other languages, it's Lucida Sans Unicode.
You can also change the Windows tool tip font by changing the icon font as described above. This change is not completely reflected across Reports Builder because some tool tip fonts are taken from the resource file.
In Oracle Reports, fonts for the Web Source view are selected by making an entry in the alias file under the [rwbuilder] section. The entry required for this change should only be aliased to the character set and not to any specific font. For example, if you want to use Arial Unicode MS when NLS_LANG is set to UTF8, then you should create an entry like this one:
…..UTF8 = "Arial Unicode MS"…..
Refer to Section 4.4, "Font Aliasing" for more information.
The supported styles are: Plain, Italic, Oblique, Underline, Outline, Shadow, Inverted, Overstrike, and Blink.
The supported weights are: Ultralight, Extralight, Light, Demilight, Medium, Demibold, Bold, Extrabold, and Ultrabold.
You should not use fonts with a weight of Regular because this weight is not supported and may cause Reports Builder to display undesirable results.
In Oracle Reports, fonts can be added for use:
At build time (in Reports Builder)
At runtime (in the output)
In the user interface
To build a report in a certain font, the font must be available in Reports Builder from the font picker when you are designing the report. In order for the fonts to appear in the font picker, the fonts should be added to the system or the display on which Reports Builder is running. Please review your operating system documentation for adding fonts before attempting this procedure.
To add Type1 fonts on UNIX:
Get the font-related files from the vendor. These include the PFB, PFA, and the AFM files.
Convert the PFB binary file to PFA ASCII font using one of the available convertors. Typically, you can get such converters as shareware, for example, t1ascii.
Copy the PFA files to the directory where the fonts need to be installed following the instructions for our platform.
Verify the installation of the fonts by entering the xlsfonts -u command. This command lists all the fonts that are available for that system.
If you are using a UNIX emulator like reflection X, the fonts installed on the system may not appear in the xlsfonts command. The reason for this behavior is that it is taking fonts from the font path or the font server, which is configured for this emulator. If using a font server, ensure that, after installing the font, you add the font directory to the font server configuration file and restart the font server. In the emulator, specify the font path to this font server wherever the fonts are installed. If you are still not able to see the fonts in xlsfonts, ensure that the new font directory is the first element of the catalogue in the configuration file.
Start Reports Builder on the display that points to the font server on which these fonts are installed or to the display where the fonts are installed.
For generating output in Oracle Reports, only the fonts that are specified in the printer definition file are used. To use a newly added font in your output, you should first add it to Reports Builder so that you can assign the font to layout objects when designing the report. Refer to Section 4.2.1, "Adding Fonts to Reports Builder" for further information.
|
Note: If you use fonts in Reports Builder that are not available on your runtime platform, you should alias those fonts on the runtime platform. Refer to Section 4.4, "Font Aliasing" for more information. |
The process for adding fonts is different on Windows and UNIX:
Copy the AFM file for the new font to ORACLE_HOME/guicommon/tk/admin/AFM.
Add the entry for this new font to the *Font information section in the printer definition (PPD) file:
*Font new_font_name Standard '(00.1001)" Standard ROM
*Font ...
Ensure that the new_font_name given in the PPD file is the same as the AFM file, because Oracle Reports searches for this file based on the font name in the PPD file. Also make sure that the AFM file name does not include the .afm extension.
For example, if the AFM file name is CodedreineunBold, then the PPD file should contain *Font CodedreineunBold: Standard "(00.1001)" Standard ROM.
If necessary, make changes in the alias file for mapping to this font.
If the layout objects are associated with the same font name as the new font, then mapping is not required. If the fonts for the layout objects are different and the new fonts are desired in the output file instead of the original ones, then you must map the original fonts to the new ones.
For example, if the layout objects' font is Helvetica and you want newly installed fonts in the output, then you could add the following to the [Printer:PostScript1] section:
Helvetica = CodedreineunBold
Please note the section will be different if you are using a different PostScript level in your uiprint.txt. Refer to Section 4.4, "Font Aliasing".
In order to use a new font in Oracle Reports, you need to have the HPD (printer definition) and TFM files for your printer. The HPD file can be copied from an existing one. You need to be sure that the file is suitable for your printer; fonts referenced in this file should be available on your printer. If the TFM files (fonts) are not available on Oracle Reports installation, you need to contact your font/printer supplier. The new TFM files must be added to the HPD file under a unique font name.
In the HPD, you will have to add the new font entry. For example if the new font is Codedreineun then include a new line such as:
FONT= Codedreineun /tfm=9nb17035.tfm
Copy the associated TFM file into the TFM directory:
ORACLE_HOME/guicommon/tk/admin/TFM
Modify the alias file, if necessary, as described in Section 4.2.2.1, "Adding fonts on UNIX" for the PostScript printers. The section in which the mapping is done should be [PCL].
This section describes all of the files associated with font configuration for Oracle Reports:
The printer configuration file contains a list of printers installed for the application along with the type of the printer, its version, and the printer definition file. The list of available fonts for runtime is taken from the printer definition file. If no printer is present, Oracle Reports chooses a PostScript printer as the default and default.ppd file as the printer definition file.
Example:
Printer: Printer_driver:Driver_specifying_language_and_level:Printer_ description:Printer_definition_file:
Each line contains five fields separated by colons.
If you are using PCL printing, then this entry should contain the name of an HPD file.
screenprinter.ppd is used when a printer is not available on UNIX. screenprinter.ppd is in ORACLE_HOME/guicommon/tk/admin/PPD.
This file contains mapping information for fonts which can be substituted for other fonts at runtime. Refer to Section 4.4, "Font Aliasing" for more information.
Oracle Reports has added three new sections to the uifont.ali file:
[PDF] - Used for font aliasing and multibyte language support
[PDF:Subset] - Used for TrueType font subsetting and multibyte language support
[PDF:Embed] - Used for Type1 font embedding
|
Caution: Do not alter the sections as Oracle Reports parses theuifont.ali file looking for keywords. The sections can be in any order.
|
Some general rules for the uifont.ali file are:
Use double quotes around any font or character set names containing two or more words, or spaces.
Use # in the first column for comments.
Comment out lines instead of deleting them to be able to use them in the future.
Font aliasing is a font name-to-font name or character set-to-CID font (from Adobe) only.
Font subsetting is for TrueType fonts only.
Font subsetting uses the font name and subsets using the TrueType font file name.
Font embedding is for Type1 fonts only. These fonts have two files. One for metrics, containing either .afm or .pfm file extension and the binary containing the .pfb file extension.
Font embedding uses the font name and embeds using the Type 1 font file names (both the AFM and PFB files are required in this order).
Refer to Section 4.4, "Font Aliasing" for more information.
PPD and AFM files (UNIX only)
PostScript Printer Definition (PPD) files and Adobe Font Metrics (AFM) files are supplied by Adobe and by printer vendors. These files contain information about the printer. Along with other parameters, these files are read for the information about the available fonts for the printer, which Oracle Reports will use. For all the fonts listed in the PPD file, Oracle Reports searches for the corresponding AFM file according to the font name and loads all of the fonts for which there is an available AFM.
From the fonts perspective, you should modify these files when you add new fonts for the printer and want these changes reflected in Oracle Reports.
Example:
*% Font Information ===================== *DefaultFont: Error *Font AvantGarde-Demi: Standard "(001.001)" Standard *Font AvantGarde-DemiOblique: Standard "(001.001)" Standard *Font Courier: Standard "(001.004)" Standard *Font Courier-Bold: Standard "(001.004)" Standard
The AFM files contain information such as the font attributes (style, weight, width, encoding scheme), whether the font is fixed pitch or proportional, and how large each character is.
After looking for the font names from the PPD files, Oracle Reports searches for the AFM files with the same name as the font according to the search criteria described in Section 4.3.1, "File Searching". For example, if Oracle Reports finds AvantGarde-Demi: Standard in the PPD file, it will search for an AFM file named AvantGarde-Demi in the AFM directory.
Please note that the AFM files are not font files; they are metrics files that provide Oracle Reports with information on how to properly format the character for the printer. If you have an AFM file, but the font is not available on the printer, then Oracle Reports cannot generate the font.
Since the AFM files are NOT fonts themselves, if you wish to have more PostScript printer fonts available, you need to:
Purchase the fonts and have them installed on the printer.
Obtain revised AFM and PPD files from the font/printer vendor.
Obtain matching X Server display fonts (if necessary).
HPD and TFM files
PCL uses HPD and TFM files. The HPD files contain a list of fonts available for the printer and each font refers to a TFM file. The HPD file is an ASCII file, which can be edited, but the TFM file is a binary file, which cannot be edited. Even though TFM files are binary and uneditable, you can perform string operations to read some specific keywords from these files. Oracle Reports recognizes the font name that is in the TFM files and not the one specified in the HPD file. The font vendor should provide TFM files and new fonts should be added to the HPD file for your printer when installed.
This file contains resource settings for all Oracle Motif tools based on Oracle Toolkit. For font specific resource settings, Tk2Motif*fontMapCs and Tk2Motif*fontList are used.
Tk2Motif*fontMapCs governs the base character set of fonts that the application will use, which are on the X-window display.
If Tk2Motif*fontMapCs: iso8859-2=EE8ISO8859P2, then NLS_LANG should be set to EE8ISO8859P2 and only fonts with encoding as iso8859-2 will be used for the application. If the system does not find any fonts with the above encoding, it will fail with a REP-3000 error.
Tk2Motif*fontList specifies the default system font that will be used by the application. The following means that the Helvetica font with medium weight and normal width of size 12 will be used:
Tk2Motif*fontList: -*-helvetica-medium-r-normal-*-120*
The syntax for the above entries can be found in Tk2Motif.rgb file as comments.
The criteria for searching files is dependent upon the type of file and the various environment variables defined.
Table 4-1 File Information
| File Name | Type | Description |
|---|---|---|
|
|
UNKNOWN |
Printer configuration file |
|
|
FONTALIAS |
Font aliasing file |
|
PPD |
PPD |
PostScript printer definition file |
|
AFM |
AFM |
Adobe font metrics file |
|
HPD |
HPD |
HP glue file |
|
TFM |
TFM |
HP glue file |
Oracle Reports will first look for the variable in TK_type, then in the ORACLE_type, and then in the global directory. For instance, the PPD files are searched for in the directory specified by TK_PPD, then in ORACLE_PPD, and then in ORACLE_HOME/guicommon/tk/admin/PPD.
For example, looking for uiprint.txt, Oracle Reports will first look at the environment variable TK_UNKNOWN, then look at ORACLE_UNKNOWN, and then in the default directory.
Environment Variables:
REPORTS_NO_DUMMY_PRINTER: If this variable is defined to any value, Oracle Reports will use screen fonts instead of the printer fonts.
Font aliasing is a mechanism in Oracle Reports that allows a font or its associated attributes like style, weight, width, size and character set to be mapped to another desired font or its associated attributes. Its primary use is when applications are ported from one platform to another and the font associated with some or all of the objects in the layout on the source platform do not exist on the target platform. In such cases font aliasing will be helpful as the nonexistent fonts can be mapped to another available one producing the required results. For example, when moving from Windows to Motif one would use font aliasing to map the Windows Arial to a font available on Motif, such as Helvetica.
This section includes the following topics:
The file that contains mapping specifications is uifont.ali. To include any new or changed mapping rules, you must edit this file.
The general format is:
"Original_font"="Font_to_be_aliased"
where Original_font is the font name or its other attributes that will be mapped to the font name or attributes of Font_to_be_aliased.
The fonts along with their attributes can be described as:
Face.Size.Style.Weight.Width.CharSet= Face.Size.Style.Weight.Width.CharSet
The Face must be the name (string/identifier) of a font face, such as Courier. The Style, Weight, Width, and CharSet may either be a numeric value or a predefined identifier or string. For example, both Plain and 0 are valid Style values and refer to the same style. The Size dimension must be an explicit size, in points.
These attributes take effect for font aliasing, font subsetting, and font embedding.
For example, in the case of font subsetting it is:
Fontname=filename.ttf Face.Size.Style.Weight.Width.CharSet=filename.ttf
The following is a list of recognized names and their numeric equivalents:
Table 4-2 Style Names and Their Numeric Equivalents
| Style Name | Numeric Equivalent |
|---|---|
|
Plain |
0 |
|
Italic |
1 |
|
Oblique |
2 |
|
Underline |
4 |
|
Outline |
8 |
|
Shadow |
16 |
|
Inverted |
32 |
|
Blink |
64 |
Table 4-3 Weights and Their Numeric Equivalents
| Weight Name | Numeric Equivalent |
|---|---|
|
Ultralight |
1 |
|
Extralight |
2 |
|
Light |
3 |
|
Demilight |
4 |
|
Medium |
5 |
|
Demibold |
6 |
Table 4-4 Widths and Their Numeric Equivalents
| Width Name | Numeric Equivalent |
|---|---|
|
Ultradense |
1 |
|
Extradense |
2 |
|
Dense |
3 |
|
Semidense |
4 |
|
Normal |
5 |
|
Expand |
7 |
|
Extraexpand |
8 |
|
Ultraexpand |
9 |
Styles may be combined; you can use the plus sign (+) to delimit parts of a style. For example:
Arial..Italic+Overstrike = Helvetica.12.Italic.Bold
This mapping indicates that any Arial that has both Italic and Overstrike styles will be mapped to a 12-point, bold, italic Helvetica font.
For multibyte language support, you must alias a character set with a CID font (Section 4.6.7, "CID Fonts") from the Asian font pack from Adobe. For example, in your Japanese report you have aliased a multibyte Shift-JIS characterset be aliased to HeiseiKakuGo-W5-Acro CID font with the following entry: .....JA16SJIS = "HeiseiKakuGo-W5-Acro"
All strings are case-insensitive in mapping. Font faces are likely to be case-sensitive on lookup, depending on the platform and surface. As a result, take care with the names used. For example, if the font name arial is used on the left-hand side (the original font), all layout objects with fonts such as arial or Arial are mapped to the aliased font.
For font aliasing, Oracle Reports searches for entries under the related section in the alias file that matches the original font attributes given in the report. Refer to Section 4.4.3, "Font Alias File Sections" for more information about the sections of the font alias file. If an exact match is found, Oracle Reports maps the original font on the left to the target font on the right.
For example:
Arial.8.Italic.Medium.Normal.WE8ISO8859P1 = Helvetica.12.Plain.Light.Normal.WE8ISO8859P1
If an Arial font with all of the attributes listed on the left is found, it will be mapped to a Helvetica font with all of the attributes listed on the right.
Any field can have a blank entry, which means it will be matched regardless. For instance:
Arial..... = Helvetica.12.Plain.Light.Normal.WE8ISO8859P1
In this case, all of the Arial fonts, irrespective of size and other attributes, are mapped to Helvetica with size 12, style Plain, weight Light, having Normal width under character set WE8ISO8859P1.
Another way to specify an aliasing rule is:
Arial = "OCR B"
This method will preserve the other attributes of the present font but will change the font name to OCR B. You need to be certain in such cases about the availability of mapped fonts with the attributes of other fonts. For example, in this rule the Arial font with style Italic might be mapped to the OCR B font with Plain style because the OCR B font does not have the Italic style present.
After a mapped font is read from the alias file (uifont.ali), Oracle Reports looks for the font following the font lookup procedure, which is described in Section 4.1.2.1, "Font lookup". If the mapped font is found on the system, then Oracle Reports uses this font. Otherwise, it looks for the original font in the system.
Font attributes are searched for with the font face, size, style, weight, and width under the specified character set.
In Oracle Reports, fonts for the Web Source view and PL/SQL editor can be mapped by providing a mapping specification in the [rwbuilder] section. This feature is mainly intended for supporting Unicode fonts in these editors.
The uifont.ali file can be found in the following locations for Oracle Reports:
ORACLE_HOME\tools\common (Windows) ORACLE_HOME/guicommon/tk/admin (UNIX)
The alias file consists of various sections which contains font mapping instructions for a particular area, as shown in Table 4-5. Since Oracle Reports looks in specific sections for specific purposes, it is crucial that you place your mapping entries in the appropriate section for what you are trying to accomplish.
Table 4-5 Font Mapping File Sections
| Section Name | Description |
|---|---|
|
|
Applies everywhere. |
|
|
Only applies to printer output. |
|
|
Applies to PostScript Level 1 printers. |
|
|
Applies to PostScript Level 2 printers. |
|
|
Applies to PCL 5 printers. |
|
|
Only applies to the display (the screen). |
|
|
Applies only to the Motif display. |
|
|
Applies only to character-mode display. |
|
|
Used for font aliasing (from Oracle Reports 6i) and multibyte language support (from Oracle Reports). |
|
|
(Oracle Reports only) Used for Type 1 font embedding. |
|
|
(Oracle Reports only) |
|
|
(Oracle Reports only) Fonts for the Web source and PL/SQL editor can be mapped in this section. |
|
|
A section for a specific printer, such as:
|
Order of precedence
When aliasing a particular font, only one section is read based upon the context in which the font is used. Hence, if three sections apply, only one is read. For example, suppose you have three sections: [Printer], [Printer:PostScript], and [Printer:PostScript:2op813a]. When generating output, if the printer is 2op813a, only the mapping rules in section [Printer:PostScript:2op813a] are read. For printers other than 2op813a, Oracle Reports would use the [Printer:PostScript] section.
The more specific sections of the alias file take precedence over the more general sections. For example, a specific printer section, such as [Printer:PostScript1:2op813a] would take precedence over the [Printer:PostScript1] section, which would take precedence over the [Printer] section, which would take precedence over the [Global] section.
The uifont.ali file is the configuration file controlling all of the Oracle Reports PDF font enhancements. It can be found in the ORACLE_HOME\tools\common (Windows) directory and in the ORACLE_HOME/guicommon/tk/admin (UNIX) directory. The uifont.ali file is text readable; that is, you can edit it with a standard text editor. Exercise caution when editing the file. The uifont.ali file should be saved as a text file with no formatting or special characters that may corrupt the file.
|
See Also: Chapter 6, "Using PDF in Oracle Reports" for more information on the various sections in theuifont.ali file.
|
To verify whether the uifont.ali file is correct, you can run the font check utility, which can be found in the ORACLE_HOME/bin directory. It is always advisable to run this utility on the modified uifont.ali file to catch any errors:
On Windows:
fnchk.exe filename
On UNIX:
mfontchk filename
where filename is the name of the uifont.ali file. If you don't specify any file name, it will check the default file based on the environment variables.
If the alias file has errors, the utility returns an error message along with the file on which the error was found. For example:
Parsing font alias file "/home/oracle/guicommon/tk/admin/uifont.ali" Ms san serif Error at line 85: Invalid font specification Parse of font alias file failed
The above error indicates that there is a syntax error in uifont.ali in the mapping rule for MS San Serif font on line 85.
To help resolve font issues that may occur in your applications, this section provides the following troubleshooting information:
Checking Whether the Desired Font Is Used in a PostScript File
PostScript files have a list of fonts, which is created after reading the PPD file. If you examine the PostScript file, you can check the fonts by looking for the following tags:
DocumentNeededResource has the list of fonts referenced in the PPD file.
DocumentSuppliedResource has the list of fonts for which the PostScript driver was able to find the AFM file.
%%Page paragraph before the field's %IncludeResource:font has the font name which will be used for the field.
For PCL output files, you can check whether a particular font was used or not. Depending on this information the font settings in Oracle Reports or the printer can be modified.
Example:
The test results below are based on a Lexmark Optra printer. The fonts and their numbers as well as the control commands are examples and may vary with other printers.
Font information The Lexmark has a small menu with the option of printing all available fonts (PCL Emulation Fonts). This includes both resident fonts (defaults) and Flash fonts (installed on the printer separately)
Table 4-6 Sample Font Information
| Font Name | Style | Weight | Example Output |
|---|---|---|---|
|
R0 Courier |
0 |
0 |
... <ESC>(<symset><ESC>(s0p<pitch>h0s0b4099T... |
|
R39 Courier Bold |
0 |
3 |
... <ESC>(<symset><ESC>(s0p<pitch>h0s3b4099T... |
|
R40 Courier Italic |
1 |
0 |
... <ESC>(<symset><ESC>(s0p<pitch>h1s0b4099T... |
|
R55 Century Schoolbook Roman |
0 |
0 |
... <ESC>(<symset><ESC>(s1p<point>v0s0b24703T ... |
Table 4-7 Sample Flash Font Information
| Font Name | Symbol Set | Style | Weight | Example Output |
|---|---|---|---|---|
|
F2 OCR-A |
0O |
0 |
0 |
... <ESC>(0O<ESC>(s0p<pitch>h0s0b4200T ... |
|
F3 OCR-B |
1O |
0 |
3 |
... <ESC>(1O<ESC>(s0p<pitch>h0s0b4206T ... |
In these examples, there are many more fonts and each font has its own code. OCRB for example has code 4206. This number is important later on.
Creating Output
When having problems getting the correct font, simplify the report and thereby the output. This can be done by creating a straightforward report using select sysdate from dual as the query and limiting the number of fonts. This will avoid long runs and create much smaller output files.
Reading the Output File
The resulting PCL-file is a binary file but is reasonably readable in the VI editor. The first small part and the end part is binary, but the middle part is readable and contains data that can be interpreted.
Verifying the Output File
The only interesting information is in the readable, middle part of the file. Find the text (this is the text displayed in the reports output) and check out the part preceding the text.
It looks like this:
....;SD1,14,2,0,3,10.34,5,0,6,0,7,4099;LB here is your text
In the preceding example, the font is selected with code 4099. For the Lexmark printer, this is selecting Courier.
In one example, the font OCR-B (code 4206) was needed. The font did not come out until that specific code was generated just before the selected text. It looks like this:
....;SD1,14,2,0,3,8.57,5,0,6,0,7,4206;LBThis is OCRB font....
Correcting Printed Font
If the output file contains the correct code, but the font does not appear on the printer, the printer probably does not have the font available. This will also occur if the code in the output file (deduced from TFM file) is not the same as the one the printer is expecting. On the Lexmark printer, the font was replaced by the default font on the printer.
If the output file does not contain the code for the font, Oracle Reports did not generate the code to the output file. Check for the HPD and TFM files.
Checking Environment Variables
DEBUG_SLFIND can help you ascertain which of these files was used. With reference to the fonts, you can find the list of AFM/TFM files the application looked at after reading the printer definition file and which font files it read after the aliasing. In this manner, you can also determine whether a font is mapped or not. Usually the order of file reading will be as follows.
First read the printer definition file.
Read all the associated font files for the font supplied by this printer definition file.
Read in the alias file.
If there is a mapping of file then read in font information files for those fonts and finally again read the AFM file for the fonts that are used in generating the output.
TK_DEBUG_POSTSCRIPT will affect PostScript output. It can be set to any combination of these strings:
Functions list each toolkit function called in comments in the PostScript output.
Long produces long, slow, intelligible PostScript.
Memory displays memory usage at the bottom of each page.
Any of the options can appear in the environment variable, abbreviated down to one letter. You can set it to any combination of these, separated by "/". This variable is case insensitive. For example, Func/L/Mem would give you all three options.
Note that the output that results from using this variable will not be supported by Oracle for customer use. It exists for diagnostics purposes only.
Repairing Fonts Not Appearing Correctly in Web Source View
Text in the user interface of Reports Builder, such as the window title, uses fonts taken from the system resource files for the current language. These system resource files are supplied with the Oracle Reports installation. In Oracle Reports, you can map these fonts in the [rwbuilder] section of uifont.ali. If found, the mapped font is used instead of the original font; if not, Oracle Reports uses the original font.
|
Note: The mapped font needs to be a fixed-width font. |
In the Web Source view of the Report Editor, the following languages may appear garbled: Arabic, Central European languages, Cyrillic, Greek, Hebrew, Japanese, Thai, and Turkish. To work around this issue, you can set the font names for Reports Builder in uifont.ali as follows:
[rwbuilder] .....AR8MSWIN1256="Courier New" .....CL8MSWIN1251="Courier New" .....EE8MSWIN1250="Courier New" .....EL8MSWIN1253="Courier New" .....IW8MSWIN1255="Courier New" .....JA16SJIS="MS Gothic" .....TH8TISASCII="Andale Duospace WT" .....TR8MSWIN1254="Courier New"
You can download a copy of the Andale Duospace WT (fixed width) font from Oracle Metalink (http://metalink.oracle.com). The ARU number is 2766564.
Understanding Limitations
On Windows:
For Unicode, 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.
Wingdings fonts may not appear when NLS_LANG is set to UTF8.
The only Wingdings fonts available when using UTF8 are the characters between ASC 32 and 127. ASC 252 would display a blank because it is not supported by UTF8.
Any of the following font sets would provide a reasonable work around.
Webdings - chr(97)
Wingdings2 - chr(80)
Wingdings2 - chr(87)
On UNIX:
AFM support is only for single byte PostScript file generation except for the Japanese encoding. The encoding schemes supported for the AFM files are AdobeStandardEncoding, ExtJIS12-88-CFEncoding, FontSpecific, HRoman, ISOLatinHebrew, JIS12-88-CFEncoding, and JIS12e-88-CFEncoding.
AFM version that is supported is 2.0.
X11 does not support the underline font attribute. Output to file should work according to steps given below.
In JDK, a bug causes the bold Korean font to appear incorrectly. OracleAS Reports Services uses the JRE and therefore all bold Korean strings in graphs within reports show up incorrectly.
PostScript printing will not load the fonts to the printer. So for the desired fonts to appear in the printed output, it is necessary that those fonts should be installed on the printer.
For PCL output, only TFM font formats are supported.
The display system on UNIX (for example, X11) is totally independent of any application or printer. There is no direct connection between printing and displaying. There can be a font displayed on your screen that is not printed.
Display and printer fonts are somewhat similar but have more differences than similarities.
X fonts (display fonts) are bitmap display glyphs, which are displayed on an X terminal by an X Server.
Printer fonts are PostScript fonts (mathematical descriptions of fonts, not bitmaps) that are present in a PostScript printer and are generated by a PostScript Interpreter on that printer.
Font size changes after applying a template.
Creating a template with font set to Times New Roman size 10 (for all fields) and making the report use this template, makes the Paper Design view of the Report Editor display a different font size.
The reason for this behavior is that defaulting couldn't fit the layout into the desired area.
First it reduced the size of text fields and then reduced the size of the fonts. This is much better than wrapping the fields and keeping the template font size.
Also, for templates, the font chosen may be different to that in the template since it matches first on the character set. So if the template font doesn't support the current character set, the font will change to one that does. This is mostly visible if you have an English template, which you use in a Hebrew/Arabic environment.
Resolving Common Problems
Problem: Letters are truncated from the right margin on printed label reports.
You have printed a mailing label report on a Windows machine and notice that the last letter, or last few letters, on each line are being truncated. The letters are not missing when you preview the report. You have tried changing the page formatting and font settings, but this has failed to resolve the problem.
Solution: If the report displays correctly using a DESTYPE of Preview, this is not a problem with the printer driver. The problem may be occurring due to the frame properties.
If a frame around the layout objects has a Horizontal Elasticity setting of Fixed and the data exceeds the frame size, it can cause this truncation of data.
Try testing the results after setting the Horizontal Elasticity property to Expand or Variable.
Problem: When generating to file as HTMLCSS, a column is dropped off in the output.
You are generating a report to an HTMLCSS file format and it appears to be fine in the Paper Design view of the Report Editor. When you click the newly created file it comes up in your browser, but the last column is missing from the report output.
If you re-run the report again, it still looks fine in the Paper Design view and the column is there as it should be. Clicking on the file again appears to have the column dropped off and missing from the report output. PDF appears fine in Paper Design view and the Adobe Acrobat reader.
Solution:
Quit Oracle Reports and any other open applications.
Choose Windows Control Panel > Display > Settings.
Set your fonts to be Small Fonts, click Apply button and then click OK to reconfigure your Windows font settings.
Reboot your computer in order for the new font settings to take effect.
You can now go back into Windows Control Panel > Display > Settings to verify that you have small fonts as a default for your system.
When you click the HTMLCSS file, your browser shows the report correctly with all of the columns intact.
When viewing HTMLCSS files with your browser, it is recommended to have Small Fonts as the default setting for your Windows system.
If you have Large Fonts as your default, your HTMLCSS file may not display correctly.
Problem: How to choose bitmap fonts sizes of less than 8 point in Reports Builder.
Solution: There are times when a font size of 6 or less is required for reporting purposes. Keeping in mind that font mapping and sizing is actually a product of operating system font files and driver/printer specifications, it is possible to change many fonts to minimal sizes such as 6 or less.
Oracle Reports typically allows fonts to be downsized to a size of 8. This is accomplished by opening a report in Reports Builder, going to the Layout Model view, and selecting the report objects that you wish to change. Once the object is selected, go to the font size list next to the font picker and select your font size.
Typically, your size will be limited to a range from 8 to 72 for True Type fonts, less for other fonts.
You can enter a size smaller or larger than the sizes in the list. To do this, again select the object, place your cursor in the font size field, press Delete to remove the current size number, enter the font size you desire, and then press the TAB key. The change takes effect immediately.
Once again, keep in mind that not all font sizes are possible. Also, some combinations of fonts and attributes are not practical. Simply having the ability to choose a font size does not mean that the font will be legible when printed. Fonts that involve small sizes, combined with bold, italic, or other attributes, may also present legibility problems when printed or displayed due to the limitations of the printer driver, printer, font metrics, language, code sets, NLS_LANG, and, of course, human eyesight.
Problem: The report output font size is different in Windows and UNIX.
A simple report designed on Windows uses the Arial and a font size of 8. This report was ported to Sun Solaris and was found to have a different font size in the output on Solaris. In the UNIX environment, the report is uses the Helvetica font and a font size of 9. The Arial font has been mapped to the equivalent font, Helvetica, on UNIX using uifont.ali.
Solution:
First look for the font size available for Helvetica on the UNIX system by either using the xlsfont command or any other UNIX font utility.
You should map variable sized fonts on Windows to variable sized fonts on UNIX. For example, modify the mapping for MS Windows Arial.8 = Helvetica.8 (assuming that size 8 is available for Helvetica on the UNIX system) and ensure that uifont.ali is in the correct directory (see font mapping).
It's probable that the Helvetica font installed on your machine is bit mapped (rasterized) and so it doesn't automatically scale to any arbitrary size. If so, you need to install a scalable Type 1 font, which should allow you to choose any point size.
There may always be differences between fonts on different systems even if the fonts installed are the same because the font configuration files may be different on these systems.
Problem: When printing, fonts are replaced by non True Type fonts. In the Paper Design view, the fonts are fine.
Solution: Check the printer settings (advanced) and ensure that it doesn't say:
True Type Font: Substitute with Device Font
UNIX
Problem: While running Oracle Reports on X-windows emulators, fonts installed on UNIX do not appear in the font lookup box.
Solution: On X-windows emulators, where the font path is usually a font directory on the local machine, the fonts that were installed on will not be available and only the fonts in the local font directory will be used by the Oracle Reports font lookup box. In such cases, you should start a font server on a remote machine where the fonts were installed and point the font path entry to this font server. For starting the font server and setting the font path entry, consult the system manual and X-windows emulator help.
For finding the font path or font server that is currently being used, use the UNIX command xset -.
This section discusses the fonts and character sets relevant to Oracle Reports:
The character set component of the NLS 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.
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 generate with the NLS environment variable (NLS_LANG) set to that particular character set.
If you design and generate 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 generate character set, then question marks appear in place of the unrecognized characters. Portable Document Format (PDF) supports multibyte character sets. There might be situations where you create an 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 Oracle Reports checks to see if the character set associated with the font matches the character set specified by the language environment variable (NLS_LANG). If the two do not match, Oracle Reports 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).
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. For information about using Unicode in your multilingual applications, refer to Section 18.5, "Unicode".
PostScript font formats Adobe Type 1 fonts are stored in two common formats: .pfa (PostScript Font ASCII) and .pfb (PostScript Font Binary). These contain descriptions of the character shapes, with each character being generated by a small program that calls on other small programs to compute common parts of the characters in the font. In both cases, the character descriptions are encrypted. Before such a font can be used, it must be rendered into dots in a bitmap, either by the PostScript interpreter, or by a specialized rendering engine, such as Adobe Type Manager, which is used to generate low-resolution screen fonts on Apple Macintosh and on Microsoft Windows systems.
The Type 1 binary files (.pfa and .pfb) contain character information, while the metric files (.afm (Adobe Font Metric) and .pfm (Printer Font Metric)) contain the metric information to form the character. These metrics files are ASCII files with a well-defined easy-to-parse structure.
The personal computer brought about a need for scalable font technology, thought to be an important part of any future operating system. TrueType is this scalable font technology that enables you to view the same output without the jagged aliasing caused by scaling that is apparent when bitmapped fonts are used.
This technology involves two parts:
The Rasterizer
TrueType fonts
The Rasterizer is an application that is included in both Windows and Macintosh operating systems. It acts as an interpreter and translates the font information into a form that the video display can render.
The TrueType fonts themselves contain information that describes the outline of each character in the typeface. Higher quality fonts also contain hinting codes. Hinting is a process that makes a font that has been scaled down to a small size look its best. Instead of simply relying on the vector outline, the hinting codes ensure that the characters line up well with the pixels so that the font looks as smooth and legible as possible.
Adobe wanted both Apple and Microsoft to license its PostScript code, which was capable of handling this role, but both companies were concerned about having a third party control key parts of their operating systems. Apple and Microsoft agreed to a cross-licensing and product development deal, with Microsoft creating a PostScript-style graphics engine and Apple creating a font system. Apple developed what was to become TrueType, which proved superior to other competing technologies on performance and rendering quality. Apple and Microsoft announced their strategic alliance against Adobe, where Apple would do the font system, Microsoft the printing engine. Apple released TrueType in March 1991 and the first TrueType fonts:
Times Roman
Helvetica
Courier
Microsoft introduced TrueType into Windows with version 3.1 in early 1992. They created a core set of fonts:
Times New Roman
Arial
Courier
Both Apple's and Microsoft's TrueType fonts showed that scalable fonts could generate bitmaps virtually as though each size had been designed by hand.
A TrueType Collection (TTC) is an efficient way of sharing common font data, such as character information and glyphs. This data sharing results in an optmized file size as the common glyphs are stored in a single file structure, instead of within each font. The end result is a single file that is a combination of two or more fonts. For example, certain Japanese fonts in a font family may share a common set of kanji characters. They can be included in a TTC file.
For example, the TTC file, msgothic.ttc, is a collection file consisting of three fonts. They are MS Gothic, MS PGothic, and MS UI Gothic.
Barcode fonts can be quite confusing. Some industries have chosen a specific barcode type. If this is what you need, then using the appropriate barcode font should work. For example, if you are interested in putting barcode on retail packages or books, the choice of a barcode is simple. Retail packages in North America use the UPC-A bar code. European retail articles use the EAN barcode .
All book ISBN numbers use the Bookland barcode (an EAN 13 bar code with a 5 digit supplement). Fonts are one way to obtain barcode, but not the only way. Oracle Reports offers another solution for producing barcodes using a Java barcode bean. The Java barcode bean is capable of creating barcodes based on the most popular barcode types.
Character IDentifier (CID) fonts are a format of composite (multibyte) Type1 fonts used to better address the requirements of Far East markets. Adobe developed the CID-keyed font file format to support large character set fonts for use with PostScript. It is the ideal format for Chinese, Japanese, or Korean fonts and can also be used for roman fonts with very large character sets. CID-keyed refers to the character identifier (CID) numbers used to index and access the characters in the font. A CID (character identifier) font consists of a large font file containing all the character outlines and a small CMap file that contains a list of characters, encodings, and character identifiers. The combination of the font file and the CMap file yields a font that is a specific character set and encoding information. Each CID font can support many character set and encoding combinations.
