8.9 Troubleshooting Font Issues

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.


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 8-6 Sample Font Information

Font Name Style Weight Example Output

R0 Courier



... <ESC>(<symset><ESC>(s0p<pitch>h0s0b4099T...

R39 Courier Bold



... <ESC>(<symset><ESC>(s0p<pitch>h0s3b4099T...

R40 Courier Italic



... <ESC>(<symset><ESC>(s0p<pitch>h1s0b4099T...

R55 Century Schoolbook Roman



... <ESC>(<symset><ESC>(s1p<point>v0s0b24703T ...

Table 8-7 Sample Flash Font Information

Font Name Symbol Set Style Weight Example Output





... <ESC>(0O<ESC>(s0p<pitch>h0s0b4200T ...





... <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.


Set the environment variable DEBUG_SLFIND to any file name and run the report. The debug information is written in that particular file.

Usage: # setenv DEBUG_SLFIND mydebug.txt

For more information, see Appendix B, "Environment Variables".

Repairing Fonts Not Appearing Correctly in Web Source View

Text in the user interface of Oracle 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.


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 Oracle Reports Builder in uifont.ali as follows:

.....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)


  • 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. Oracle 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.


  1. Close Oracle Reports Builder and other open applications.

  2. Choose Windows Control Panel > Display > Settings.

  3. Set your fonts to be Small Fonts, click Apply button and then click OK to reconfigure your Windows font settings.

  4. Reboot your computer in order for the new font settings to take effect.

  5. 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 Oracle 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 Oracle 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.


  1. 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.

  2. 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.

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


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 -.