10g (9.0.4)
Part Number B10314-01
 Contents |
 Index |
| Oracle Application Server Reports Services Publishing Reports to the Web 10g (9.0.4) Part Number B10314-01 |
|
This chapter provides information about fonts in Oracle Reports. In particular, it covers:
In Oracle Reports, fonts come into play:
Reports Builder provides a list of fonts that are available on the system in the font picker box.
Text description of the illustration font_pick.gif
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.MapsCS. For more information on Tk2Motif.MapsCS, refer to Font Configuration Files.
During report formatting, fonts associated with the layout objects are first checked against the font alias file, uifont.ali, (refer to 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 looked up 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:
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:
screenprinter.ppd.
Figure 4-2 illustrates the process of determining the available fonts for generating report output.
Text description of the illustration font_unixfont.gif
The following steps describe how Oracle Reports generates a list of the available fonts for generating output (e.g., for the screen, printer, or file):
uiprint.txt for all the printers that are listed for the application. If no printers are defined or available, Oracle Reports uses ScreenPrinter.
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.
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 Korean 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, etc. If more than one font has the same parameters, Oracle Reports picks the first one and uses it instead of the original font.
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.
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:
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.
"*Font Mkai-Medium: Standard "(001.004)" Standard ROM"
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 (e.g., 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 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 via 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 is set to UTF8, then you should create an entry like this one:
.....UTF8 = "Arial Unicode MS".....
Refer to 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:
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.
t1ascii.
.pfa files to the directory where the fonts need to be installed following the instructions for our platform.
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, make sure 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.
Text description of the illustration font_xlsfonts.gif
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 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 Font Aliasing for more information. |
The process for adding fonts is different on Windows and UNIX:
*Font new_font_name Standard '(00.1001)" Standard ROM *Font ...
ORACLE_HOME/guicommon9/tk90/admin/AFM. Ensure that the AFM file name is the same as the new_font_name given in the PPD file because Oracle Reports searches for this file based on the font name in the PPD file.
For example, if the PPD file contains *Font CodedreineunBold: Standard '(00.1001)" Standard ROM, then the AFM file name should be named CodedreineunBold without any extension.
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 Font Aliasing.
In order to use a new font in Oracle Reports, you need to have the HPD (printer definition files) 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.
Codedreineun then include a new line such as:
FONT= Codedreineun /tfm=9nb17035.tfm
ORACLE_HOME/guicommon9/tk90/admin/TFM
For adding a new font on Windows, refer to your operating system documentation on adding a new font. If the new font has a character set that is compatible with Reports Builder, the new font will appear in the font picker.
The listing below 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.
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/guicommon9/tk90/admin/PPD.
This file contains mapping information for fonts which can be substituted for other fonts at runtime. Refer to Font Aliasing for more information.
Oracle Reports has added three new sections to the uifont.ali file:
[PDF] - Used for font aliasing and multi-byte language support
[PDF:Subset] - Used for TrueType font subsetting and multi-byte language support
[PDF:Embed] - Used for Type1 font embedding
Some general rules for the uifont.ali file are:
Font embedding uses the font name and embeds using the Type 1 font file names (both the *FM and PFB files are required in this order).
Refer to Font Aliasing for more information.
PostScript Printer Definition (PPD) files and AFM (Adobe Font Metrics) 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.
*% 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 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, which give Oracle Reports 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:
PCL5 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.
FontMapsCs 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 the NLS_LANG should be 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.
Oracle Reports will first look for the variable in TK90_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 TK90_PPD, then in ORACLE_PPD, and then in ORACLE_HOME/guicommon9/tk90/admin/PPD.
For example, looking for uiprint.txt, Oracle Reports will first look at the environment variable TK90_UNKNOWN, then look at ORACLE_UNKNOWN, and then in the default directory.
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 MS Windows to Motif one would use font aliasing to map the MS Arial to a font available on Motif, such as Helvetica.
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 like Courier. The Style, Weight, Width, and CharSet may either be a numeric value or a predefined identifier/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:
Font name = Filename.ttf Face.Size.Style.Weight.Width.CharSet = Filename.ttf.
The following is a list of recognized 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 |
| Weight name | Numeric equivalent |
|---|---|
|
Ultralight |
1 |
|
Extralight |
2 |
|
Light |
3 |
|
Demilight |
4 |
|
Medium |
5 |
|
Demibold |
6 |
| 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 (CID Fonts) from the Asian font pack from Adobe. For example, in your Japanese report you have aliased a multi-byte 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 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 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\common90 (Windows) ORACLE_HOME/guicommon9/tk90/admin (UNIX)
The alias file consists of various sections which contains font mapping instructions for a particular area. 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.
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\common90 (Windows) directory and in the ORACLE_HOME/guicommon9/tk90/admin (UNIX) directory. The uifont.ali file is text readable, i.e., 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 the |
fontchk90 is used to verify whether the uifont.ali file is correct and 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:
fontchk90 [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/guicommon9/tk90/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.
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.
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.
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)
| 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.
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.
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.
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 example above, 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....
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, Reports Builder did not generate the code to the output file. Check for the HPD and TFM file.
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.
TK_DEBUG_POSTSCRIPT will affect PostScript output. It can be set to any combination of these strings:
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.
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.
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 Metalink, (http://metalink.oracle.com). The ARU number is 2638552.
NLS_LANG is 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.
AFM version that is supported is 2.0
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.
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.
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.
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 changing Horizontal Elasticity to Expand or Variable.
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 on 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.
When you click on 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.
How to choose bitmap fonts sizes of less than 8 point in Reports Builder.
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.
The report output font size is different in Windows and UNIX.
A simple report designed on Windows NT 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 Solaris using uifont.ali.
xlsfont command or any other UNIX font utility.
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.
When printing, fonts are replaced by non True Type fonts. In the Paper Design view, the fonts are fine.
Check the printer settings (advanced) and make sure that it doesn't say:
True Type Font: Substitute with Device Font
UNIX
While running Oracle Reports on X-windows emulators, fonts installed on UNIX do not appear in the font lookup box.
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. Oracle Reports provides Unicode support. If you use Unicode, you are able to display multiple languages, both single-byte languages such as those spoken in Western Europe, Eastern Europe, 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=JAPAN_JAPANESE.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 NLS_LANG variable must be set to one of the following:
NLS_LANG=JAPAN_JAPANESE.UTF8 NLS_LANG=GERMAN_GERMANY.UTF8
Oracle Reports relies on the operating system for the font and input method for different languages. To enter and display text in a particular language, you must be running a version of the operating system that supports that language. Font support is limited but not restricted to the operating system font. Windows NT release 4.0 and later versions provide True Type Big Fonts. These fonts contain all the characters necessary to display or print multilingual text. If you try to type, display, or print multilingual text and see unexpected characters, then you are probably not using a Big Font. Big Fonts provided by Microsoft under Windows NT release 4.0 and later, are as follows:
Third-party Unicode fonts are also available.
To enable Unicode support, set the NLS_LANG environment variable as follows:
NLS_LANG=character_set.UTF8
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, .pfb) contain character information while the metric (.afm - Adobe Font Metric or .pfm - Printer Font Metric) files 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 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:
Microsoft introduced TrueType into Windows with version 3.1 in early 1992. They created a core set of fonts:
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.
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.
|
 Copyright © 2003 Oracle Corporation. All Rights Reserved. | | Ad Choices. |
|