|
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 |
Modern business needs warrant a seamless integration and interaction across any platform and infrastructure. Oracle Reports enables businesses to develop and deploy information to all levels within and outside of the organization. However, since any enterprise reporting tool is bound to use some platform-specific functionality like the system fonts or printer fonts, there exists a possibility that the look-and-feel of the report changes when the report is ported from one platform to another; for example, from the development platform (commonly Windows) to the deployment platform (commonly a UNIX-based platform).
This chapter covers those scenarios where the choice of platform may affect the look-and-feel of the report output. Each report output format (for example, PDF, HTMLCSS, and RTF) that is open to cross-platform issues is covered in a separate section. These sections provide step-by-step instructions that will ensure that your report output looks the same on all platforms. These guidelines are followed by troubleshooting information and FAQs. Since multibyte and Unicode reports involve some additional steps, separate sections are devoted to those topics. This chapter is applicable to Oracle9i Reports, Oracle Reports 10g Release 1 (9.0.4), and 10g Release 2 (10.1.2), except as specifically noted.
Before you proceed, it is strongly recommended that you are familiar with the concepts and terminology outlined in the following chapters:
This chapter includes the following sections:
|
Note: This chapter lists only those scenarios and guidelines that need additional work to ensure similar outputs across platforms. |
Oracle Reports is available on many platforms, including Windows, Linux, Sun Solaris, HP-UX, and IBM AIX. You can use Oracle Reports to develop and deploy reports on any of these platforms interchangeably. The most common scenario is that the report is developed on Windows, and is deployed on a UNIX-based environment, such as Linux (see Figure 7-1). This may result in a slight change in the look-and-feel of the deployed report. For example, when you are developing the report on Windows, you allocate enough space to each text object or field in your report. However, when you deploy and run the report on Linux, you may see that the text does not fit within the allocated space in the output. Such issues that are the direct result of change in platform are referred to as cross-platform issues. A possible cause of such issues is that the fonts available on the development platform are not available on the deployment platform. As a result, when the report is executed on the deployment platform, a substitute font needs to be used for formatting the report output. Since any two fonts are likely to have certain differences, the report output on the development and deployment platforms looks different.
Another likely scenario in which you may encounter cross-platform issues is when the platform on which the report is finally viewed (see Figure 7-1) does not have the proper fonts installed. Thus, even if the development and deployment platforms display the report output correctly, the platform on which the end-user views the report will not display the proper look-and-feel of the report.
Figure 7-1 Sample Cross-Platform Deployment Scenario
A font is a set of printable or displayable text characters in a specific style and size. Fonts are needed for displaying the report on the screen as well as for printing it. The metrics for these fonts are picked up by Oracle Reports while formatting the report; that is, while executing the report command. Based on the font metrics, the report is formatted and the output is produced.
The font metrics are provided by specific files that must be available on the system where you are running OracleAS Reports Services. On Windows, these font metrics are provided by True Type Font (TTF) files or True Type Collection (TTC) files. On UNIX platforms, the font metrics are taken from Adobe Font Metrics (AFM) files or TeX Font Metrics (TFM) files. The font availability and the metrics can vary based on the operating system used. This difference in fonts used and the rendering can affect the visual appearance of the generated outptut.
Example 1: Tahoma, a commonly used font in single-byte regions, is available on Windows but not on UNIX. For example, a reports developer has used Tahoma font while designing the report. The output of the report looks good on the development platform; that is, Windows. The report is then ported to the deployment platform (say Linux). When you submit a request to the Reports Server to execute this report, the Reports Server looks for Tahoma font metrics. It will be unable to find the metric file, since Tahoma is a Windows-specific font. Another font that closely resembles Tahoma will be used instead. This will affect the report output since a different font has been used.
Example 2: The development as well as deployment platform is Windows. So Reports Servers on both the development and deployment platforms are able to access Tahoma font since both run on Windows. However, suppose an end-user views the output on Linux. All reports output formats (HTML, HTMLCSS, RTF, and PDF) merely refer to the fonts and do not embed the fonts in the output unless you specifically use the font embedding feature in PDF. As a result, the client system will look for the Tahoma font to display the report output on client machine. Since Tahoma is not available on Linux, the user will encounter cross-platform issues while viewing the output.
As we have seen, many cross-platform issues are caused by the non-availability of fonts either on the production environment (where the Reports Server is running) or on the client system. These font availability issues must be resolved by a 3-step approach:
Development platform: Ensure that you develop the report keeping in mind the font availability on the deployment platform. All font files that are available on Windows (TTF files) may not be available on UNIX (AFM or TFM files). If you have the correct AFM or TFM font file available on the UNIX platform, you can continue to use it (AFM for PostScript printing and TFM for PCL). For fonts with AFM files not readily available on UNIX, or if you encounter any font issues in the report output such as text misalignment, you can convert and generate an AFM file from the Windows TTF file using freely available third party utilities, such as ttf2pt1. Do not attempt to convert to a TFM file, as this may not produce reliable results.
Deployment platform: Ensure that the fonts used in the report are available. For PDF output, use font aliasing to substitute the unavailable font with the closest available font. Global font aliasing can be used for all output formats. Same comment holds for all the subsequent sections where you have asked to provide examples.
Client platform: Ensure that you account for font unavailability on the client system. For example, in the case of PDF output, you can use Font Subsetting or Font Embedding, as decribed in Chapter 6, "Using PDF in Oracle Reports". In the case of HTML, HTMLCSS or RTF output formats it is not possible to embed the fonts, so it is best to design the report using fonts that are known to be available on all platforms.
Table 7-1 shows the cross platform deployment scenario where the destination format is HTMLCSS, RTF, or the Web.
Table 7-1 Cross Platform Deployment - Scenario 1
| Development Platform | Deployment Platform | Destination Format |
|---|---|---|
|
Windows |
UNIX |
HTMLCSS, RTF, or Web |
This section discusses designing and deploying a report for HTMLCSS, RTF, or Web output in the following subsections:
To prepare your report before you deploy it on a UNIX platform:
Create a new report. While creating your report ensure that you leave additional padding space for boilerplate and field objects. This is to ensure that the box's size accounts for any possible increase in the text width when the report is run on the deployment platform.
Use only those fonts in your report that:
Are available on UNIX. All font files that are available on Windows (TTF files) may not be available on UNIX (AFM or TFM files). If you have the correct AFM or TFM font file available on the UNIX platform, you can continue to use it (AFM for PostScript and TFM for PCL).
|
Note: AFM support is extended only to single-byte PostScript file generation, with the exception of Japanese encoding.The encoding schemes supported for the AFM files are:
|
Can scale well. For example, MS Sans Serif does not scale well to a different size, whereas Tahoma does. The reason is that the MS Sans Serif font is a raster font that does not scale well to any size and usually has rounding issues. On the other hand, Tahoma font is a TrueType font that is very similar in visual appearance to the MS Sans Serif font. Additionally, Tahoma is a vector font that can be scaled to any size and rotated to any angle.
For fonts with AFM files not readily available on UNIX, or if you encounter any font issues in the report output such as text misalignment, you can convert and generate an AFM file from the Windows TTF file using freely available third party utilities, such as ttf2pt1. Do not attempt to convert to a TFM file, as this may not produce reliable results.
To deploy your report on a UNIX platform when AFM font files are not available:
Locate the TTF files corresponding to the fonts used in your report. Convert these TTF files to AFM to ensure that you will have the AFM files for the fonts used in your report.
Use a True Type to Type 1 font converter utility to convert the TTF files to AFM files. For example, ttf2pt1.
Post-conversion, remove the .afm extension in the AFM file name. For example:
Copy the converted AFM files to the $ORACLE_HOME/guicommon/tk/admin/AFM directory.
Edit the screenprinter.ppd file with any text editor.
|
Note: If you have defined a default printer by including an entry inORACLE_HOME/guicommon/tk/admin/uiprint.txt, then you will have to make the appropriate entries in the printer's PPD file for a PostScript printer or in the HPD file for a PCL printer.
Beginning with Oracle Reports 10g Release 1 (9.0.4), a default printer surface that mimics the screen ( The PPD files are located at: ORACLE_HOME/guicommon/tk/admin/PPD The HPD files are located at: ORACLE_HOME/guicommon/tk/admin/HPD Refer to Section 3.10.1, "ScreenPrinter" for more information on the |
Ensure that the PPD/HPD file used contains an entry for each AFM or TFM file that you use in your report. PPD/HPD files are configuration files containing printer driver settings and the list of all the fonts supported by the printer.
Navigate to the to the Font Information section in the PPD file and add the necessary entries for the font files in the following format:
*FONTNAME:ENCODING:VERSION:LOCATION
For example:
*Font Arial: Standard "(Version 2.76)" Standard ROM *Font CourierNew: Standard "(Version 2.76)" Standard ROM
Ensure that the AFM file name exactly matches the font name specified in the PPD file as Oracle Reports searches for this file based on the font name in the PPD file.
Ensure that the fonts used in your report are not aliased.
For example, edit the uifont.ali file and comment the entries in the [Global] section, where Arial and Courier New are aliased to Helvetica and Courier, respectively.
[ Global ] # Put mappings for all surfaces here. # Mapping from MS Windows #Arial = helvetica #"Courier New" = courier
This ensures that Arial and Courier New are not aliased to any other font.
|
Note: Theuifont.ali is located in the $ORACLE_HOME /guicommon/tk/admin directory.
Use font aliasing only if you are unable to generate the AFM file for a particular font. You can then alias the missing font to the closest match. The fonts must be made available on the machine displaying the report output and not necessarily on the machine generating the report output. |
Run the report.
http://mywebserver.com:reports/rwservlet?server=myserver+report="c:\test.rdf"+a uthid=hr/hr@mydb+desformat=htmlcss+destype=cache
The HTMLCSS output of your report will look exactly the same as the one generated on Windows.
If you encounter deployment issues, review the following troubleshooting information:
If you do not get the correct fonts in the HTMLCSS output, set the environment variable DEBUG_SLFIND to a log file name, for example, debug.txt, and run the report. The font files that are looked up while parsing the PPD file as well as the fonts used will be written to the log file debug.txt. Specifically, check for the following:
The PPD file that you modified should be picked up. If it is not picked up it is a configuration issue. Refer to Chapter 4, "Managing Fonts in Oracle Reports".
The AFM files that you have copied to AFM directory should be picked up next.
See Chapter 5, "Printing on UNIX with Oracle Reports" for more information on DEBUG_SLFIND.
This section covers frequently asked questions (FAQs) pertaining to deploying a report to HTMLCSS, RTF or the Web.
Question
When I design a report on Windows with font styles such as italic and bold, then run the report on UNIX, I do not see the output as it appeared on Windows. Why?
Answer
On UNIX, report formatting is done using fonts' corresponding AFM files. By default, these AFM files are picked from the $ORACLE_HOME/guicommon/tk/admin/AFM directory, provided as part of the installation. If the font style used in report does not have a corresponding AFM file on UNIX, the closest matching AFM file is used. For example, if you design a report on Windows with Courier Italic font, then run the report on UNIX, you may see only plain Courier font in the output. This happens because there is no AFM file available for Courier Italic font in the $ORACLE_HOME/guicommon/tk/admin/AFM directory, so instead Courier is picked. To work around this issue, you can alias your font's style to the same style for some other font that has AFM available. For example, you could alias Courier Italic to Times Italic in the global section of uifont.ali. Moreover, on Windows, there are some fonts that have bold, italic, and bold italic versions; for example, Arial has arialbd.ttf (Arial bold), ariali.ttf (Arial italic), and arialbi.ttf (Arial bold italic). Therefore, if you are using any font that has bold, italic, and bold italic TTF files available, you can generate AFM files from these files using ttf2pt1 and use these AFM files on UNIX.
Question
My report was created in Windows and is deployed on HP-UX 11. Although the font style on HP-UX 11 is correct, the spacing between the lines is inconsistent and some text is unable to fit in the allocated space. How can I fix the spacing so that my text fits correctly?
Answer
Ensure that you have set up the corresponding AFM files for all the fonts used in your document. Refer to Section 7.2.1, "Designing Your Report" for more information.
Question
My report is designed on Windows. When it is deployed on a different platform, it displays garbled output. For example, some fields display, ***** instead of the actual content. Is this a spacing issue?
Answer
Oracle Reports cannot find the AFM files of the font that you have used in your report. You can verify this by opening the report's HTML source and searching for the font that you have used.
Oracle Reports then uses the closest matching font whose metrics are bigger than the original font. Therefore, when the characters cannot fit in the box, a **** is displayed in the field, instead of the actual output.
Ensure that:
You have set up the AFM files for all the fonts used in your report. Refer to Section 7.2.1, "Designing Your Report" for more information.
You have left approximately 10% extra padding space for fields and text boilerplates.
Question
When my report is run on UNIX, the HTML or the HTMLCSS output looks shrunk. However, the same report run on Windows looks fine. What can I do to ensure that my report looks the same on UNIX as it did on Windows?
Answer
If you see shrinkage or expansion in your HTMLCSS output and you are on Oracle9i Reports, then set the environment variable REPORTS_DEFAULT_PIXEL_SIZE to any value ranging from 72 through 200 in reports.sh and restart the Reports Server.
For example:
REPORTS_DEFAULT_PIXEL_SIZE =72 export REPORTS_DEFAULT_PIXEL_SIZE
There will not be any HTMLCSS output shrinkage/expansion in Oracle Reports 10g as a fixed resolution is picked up from screenprinter.ppd. This resolution is editable.
*DefaultResolution: 96dpi (recommended)
Question
Can I use the overstrike property when I deploy a report in Solaris?
Answer
A limitation of AFM files is that it does not support the overstrike property.
Question
My report contains right-aligned fields that displays both positive and negative numbers. For example, 12345.67, -12345.67. However, when the report is generated to HTMLCSS output, the alignment is not correct. How can I fix the alignment? Is this a platform-specific issue?
Answer
This is not exactly a platform-specific issue. When the spaces in the HTMLCSS output are replaced by this problem will be resolved. This is fixed in Oracle9i Reports Patch Release 1 and later releases. To ensure that you do not face this issue, you must upgrade to the latest release of Oracle Reports.
Table 7-3 shows the cross-platform deployment scenario where the destination format is single-byte PDF created using PDF font subsetting. For more information on PDF font features, refer to Chapter 6, "Using PDF in Oracle Reports".
Table 7-3 Cross Platform Deployment - Scenario 2
| Development Platform | Deployment Platform | Destination Format |
|---|---|---|
|
Windows |
UNIX |
PDF (single byte) |
This section discusses designing and deploying a report for single-byte PDF output in the following subsections:
To prepare your report before you deploy it on a UNIX platform:
Create a new report.
Use only those fonts in your report that:
Are available on UNIX. All font files that are available on Windows (TTF files) may not be available on UNIX (AFM or TFM files). If you have the correct AFM or TFM font file available on the UNIX platform, you can continue to use it (AFM for PostScript and TFM for PCL).
|
Note: AFM support is extended only to single-byte PostScript file generation, with the exception of Japanese encoding.The encoding schemes supported for the AFM files are:
|
Can scale well. For example, MS Sans Serif does not scale well to a different size, whereas Tahoma does. The reason is that the MS Sans Serif font is a raster font that does not scale well to any size and usually has rounding issues. On the other hand, Tahoma font is a TrueType font that is very similar in visual appearance to the MS Sans Serif font. Additionally, Tahoma is a vector font that can be scaled to any size and rotated to any angle.
For fonts with AFM files not readily available on UNIX, or if you encounter any font issues in the report output such as text misalignment, you can convert and generate an AFM file from the Windows TTF file using freely available third party utilities, such as ttf2pt1. Do not attempt to convert to a TFM file, as this may not produce reliable results.
To deploy your report on a UNIX platform using PDF font subsetting:
Locate the TTF files corresponding to the fonts used in your report. Convert these TTF files to AFM to ensure that you will have the AFM files for the fonts used in your report.
Use a True Type to Type 1 font converter utility to convert the TTF files to AFM files. For example, ttf2pt1.
Post-conversion, remove the .afm extension in the AFM file name. For example:
Copy the Windows TTF files that you have used in your report to the fonts directory on your UNIX machine. For example, $ORACLE_HOME/reports/fonts.
Add the path to the TTF files in the REPORTS_PATH environment variable. This ensures that the font files can be referenced by Reports Runtime.
Edit the screenprinter.ppd file with any text editor.
|
Note: If you have defined a default printer by including an entry inORACLE_HOME/guicommon/tk/admin/uiprint.txt, then you will have to make the appropriate entries in the printer's PPD file for a PostScript printer or in the HPD file for a PCL printer.
Beginning with Oracle Reports 10g Release 1 (9.0.4), a default printer surface that mimics the screen ( The PPD files are located at: ORACLE_HOME/guicommon/tk/admin/PPD The HPD files are located at: ORACLE_HOME/guicommon/tk/admin/HPD Refer to Section 3.10.1, "ScreenPrinter" for more information on the |
Ensure that the PPD/HPD file used contains an entry for each AFM or TFM file that you use in your report. PPD/HPD files are configuration files containing printer driver settings and the list of all the fonts supported by the printer.
Navigate to the to the Font Information section in the PPD file and add the necessary entries for the font files in the following format:
*FONTNAME:ENCODING:VERSION:LOCATION
For example:
*Font Arial: Standard "(Version 2.76)" Standard ROM *Font CourierNew: Standard "(Version 2.76)" Standard ROM
Ensure that the AFM file name exactly matches the font name specified in the PPD file as Oracle Reports searches for this file based on the font name in the PPD file.
Copy the converted AFM files to the $ORACLE_HOME/guicommon/tk/admin/AFM directory.
Ensure that the uiprint.txt has the entry for the appropriate PPD file:
printer name:PostScript:2:test:ppd file
For example:
printer1:PostScript:2:test:hpljet42.ppd
Edit the hpljet42.ppd file with any text editor.
|
Note: Create a backup of thehpljet42.ppd file before you proceed to edit it. This file is located in:
$ORACLE_HOME/guicommon/tk/admin/PPD |
Ensure that the PPD/HPD file used contains an entry for each AFM or TFM file that you use in your report.
Navigate to the Font Information section and add the necessary entries for the new AFM files in the following format:
*FONTNAME:ENCODING:VERSION:LOCATION
For example:
*Font Arial: Standard "(Version 2.76)" Standard ROM *Font CourierNew: Standard "(Version 2.76)" Standard ROM
Ensure that the AFM file name is the same as the font name given in the PPD file. Oracle Reports searches for this file based on the font name in the PPD file.
Ensure that the fonts used in your report are not aliased.
For example, edit the uifont.ali and comment the entries in the [Global] section where Arial and Courier New are aliased, by default, to Helvetica and Courier respectively.
[ Global ] # Put mappings for all surfaces here. # Mapping from MS Windows #Arial = helvetica #"Courier New" = courier
|
Note: Theuifont.ali is located in the $ORACLE_HOME /guicommon/tk/admin directory.
Use font aliasing only if you are unable to generate the AFM file for a particular font. You can then alias the missing font to the closest match. The fonts must be made available on the machine displaying the PDF output and not necessarily on the machine generating the PDF file. |
Add the appropriate entries in the [PDF:Subset] section to subset the fonts used in your report.
For example:
[ PDF:Subset ] "arial" = "arial.ttf" "courier new" = "cour.ttf"
For PDF file portability, you can use either font subsetting or font embedding. File portability ensures that the PDF report does not depend on the machine where it is viewed to have the fonts installed.
Run the report to PDF and view it. The PDF should contain the fonts used in your report. For example, Arial and Courier New fonts.
To verify the fonts used, do the following:
In Acrobat Reader 6.0, choose File >Document Properties > Fonts.
In Acrobat Reader 3.0 and above, choose File >Document Info > Fonts.
The Original Font column displays the Arial and Tahoma fonts. The PDF document should not contain any font alignment issues.
If you encounter deployment issues, review the following troubleshooting information:
If you do not get the correct fonts in the PDF output, set the environment variable DEBUG_SLFIND to a log file name (for example, debug.txt) and run the report. The font files that are looked up while parsing the PPD file as well as the fonts used will be written to the specified file. Specifically, check for the following:
The PPD file that you modified should be picked up. If it is not picked up it is a configuration issue. Refer to Chapter 4, "Managing Fonts in Oracle Reports".
The AFM files that you have copied to AFM directory should be picked up next.
See Chapter 5, "Printing on UNIX with Oracle Reports" for more information on DEBUG_SLFIND.
This section contains frequently asked questions (FAQs) pertaining to deploying a report to single-byte PDF output.
Question
My PDF report page count varies when it is deployed in Windows and UNIX platforms. What must I do to fix it?
Answer
Your report uses the default printer for formatting. Ensure that the same resolution and the same fonts used are made available to both the printers. One way of achieving this would be to generate AFM files from Windows TTF font files and then copy the Windows TTF files and AFM files to UNIX in the appropriate folders. Also set the same resolution as Windows in PPD/HPD files. Follow the process specified in the prior steps.
Question
The page count of my report varies when run on different installations of UNIX. How can I ensure that the page count of my report is the same regardless of the installation?
Answer
In UNIX, Oracle Reports uses the PPD/HPD file of the default printer in the installation for formatting. The resolution and list of fonts will be picked up from this PPD/HPD files. Beginning with Oracle Reports 10g Release 1 (9.0.4), if there is no default printer setup in the installation, then screenprinter.ppd will be used. This PPD file emulates the screen. Earlier versions of Oracle Reports used the DISPLAY environment variable instead. Ensure that the two installations use the same AFM/TFM files and font files, so that the number of pages of PDF output will be the same.
Table 7-5 shows the cross platform deployment scenario where the destination format is multibyte PDF created using PDF font subsetting. For more information on PDF font features, refer to Chapter 6, "Using PDF in Oracle Reports".
Table 7-5 Cross Platform Deployment - Scenario 4
| Development Platform | Deployment Platform | Destination Format |
|---|---|---|
|
Windows |
UNIX |
PDF (multibyte) |
This section discusses designing and deploying a report for multibyte PDF output in the following subsections:
To prepare your report before you deploy it on a UNIX platform:
Create a new report with a TrueType multibyte font. For example, Simplified Arabic font with the AR8ISO8859P6 character set.
Use only those fonts in your report that:
Are available on UNIX. All font files that are available on Windows (TTF files) may not be available on UNIX (AFM or TFM files). If you have the correct AFM or TFM font file available on the UNIX platform, you can continue to use it (AFM for PostScript and TFM for PCL).
|
Note: AFM support is extended only to single-byte PostScript file generation, with the exception of Japanese encoding.The encoding schemes supported for the AFM files are:
|
Can scale well. For example, MS Sans Serif does not scale well to a different size, whereas Tahoma does. The reason is that the MS Sans Serif font is a raster font that does not scale well to any size and usually has rounding issues. On the other hand, Tahoma font is a TrueType font that is very similar in visual appearance to the MS Sans Serif font. Additionally, Tahoma is a vector font that can be scaled to any size and rotated to any angle.
For fonts with AFM files not readily available on UNIX, or if you encounter any font issues in the report output such as text misalignment, you can convert and generate an AFM file from the Windows TTF file using freely available third party utilities, such as ttf2pt1. Do not attempt to convert to a TFM file, as this may not produce reliable results.
To deploy your report on a UNIX platform:
Locate the TTF files corresponding to the fonts used in your report. Convert these TTF files to AFM to ensure that you will have the AFM files for the fonts used in your report.
Use a True Type to Type 1 font converter utility to convert the TTF files to AFM files. For example, ttf2pt1.
Post-conversion, remove the .afm extension in the AFM file name. For example:
Copy the Windows TTF file used in your report to the fonts directory on your UNIX machine. For example, $ORACLE_HOME/fonts.
Add the path to the TTF file in the REPORTS_PATH environment variable.
Copy the AFM file to the $ORACLE_HOME/guicommon/tk/admin/AFM directory.
Edit the screenprinter.ppd file with any text editor.
|
Note: If you have defined a default printer by including an entry inORACLE_HOME/guicommon/tk/admin/uiprint.txt, then you will have to make the appropriate entries in the printer's PPD file for a PostScript printer or in the HPD file for a PCL printer.
Beginning with Oracle Reports 10g Release 1 (9.0.4), a default printer surface that mimics the screen ( The PPD files are located at: ORACLE_HOME/guicommon/tk/admin/PPD The HPD files are located at: ORACLE_HOME/guicommon/tk/admin/HPD Refer to Section 3.10.1, "ScreenPrinter" for more information on the |
Ensure that the PPD/HPD file used contains an entry for each AFM or TFM file that you use in your report. PPD/HPD files are configuration files containing printer driver settings and the list of all the fonts supported by the printer.
Navigate to the to the Font Information section in the PPD file and add the necessary entries for the font files in the following format:
*FONTNAME:ENCODING:VERSION:LOCATION
For example:
*Font Arial: Standard "(Version 2.76)" Standard ROM *Font CourierNew: Standard "(Version 2.76)" Standard ROM
Ensure that the AFM file name exactly matches the font name specified in the PPD file as Oracle Reports searches for this file based on the font name in the PPD file.
Ensure that the uiprint.txt has the entry for the appropriate PPD file: printername: PostScript:2:test:ppd_file.
For example:
printer1:PostScript:2:test:hpljet42.ppd
Edit the hpljet42.ppd file with any text editor.
|
Note: Create a backup of thehpljet42.ppd before you proceed to edit it. This file is located in:
|
Ensure that the PPD/HPD file used contains an entry for each AFM or TFM file that you use in your report.
Navigate to the Font Information section and add the necessary entries for the new AFM files in the following order:
*FONTNAME:ENCODING:VERSION:LOCATION
For example:
*Font SimplifiedArabic: Standard "(001.01)" Standard ROM
Ensure that the fonts used in your report are not aliased.
Edit uifont.ali and comment the entries, if any, where Simplified Arabic font is aliased to some other font. For example: "SimplifiedArabic"="Arial".
|
Note: Theuifont.ali is located in the $ORACLE_HOME/guicommon/tk/admin directory.
Use font aliasing only if you are unable to generate the AFM file for a particular font. You can then alias the missing font to the closest match. The fonts must be made available on the machine displaying the PDF output and not necessarily on the machine generating the PDF file. |
In the [PDF:Subset] section, add the appropriate entries to subset the fonts.
For example:
[ PDF:Subset ]"SimplifiedArabic" = "simpo.ttf"
For PDF file portability, you can use either font subsetting or font embedding. File portability ensures that the PDF report does not depend on the machine where it is viewed to have the fonts installed.
Run the report to PDF and view it.
http://mywebserver.com:reports/rwservlet?server=myserver+report= "c:\test.rdf"+authid=hr/hr@mydb+desformat=PDF+destype=cache
The PDF should contain the font that you have used in your report. For example, the David font.
To verify the fonts used, do the following:
In Acrobat Reader 6.0, choose File >Document Properties > Fonts.
In Acrobat Reader 3.0 and above, choose File >Document Info > Fonts.
The Original Font column should display the David font.
If you encounter deployment issues, review the following troubleshooting information:
If you do not get the correct fonts in the PDF output, set the environment variable DEBUG_SLFIND to a log file name, for example, debug.txt, and run the report. The font files that are looked up while parsing the PPD file as well as the fonts used will be written to the log file debug.txt. Specifically, check for the following:
The PPD file that you modified should be picked up. If it is not picked up it is a configuration issue. Refer to Chapter 4, "Managing Fonts in Oracle Reports".
The AFM files that you have copied to AFM directory should be picked up next.
See Chapter 5, "Printing on UNIX with Oracle Reports" for more information on DEBUG_SLFIND.
This section contains frequently asked questions (FAQs) pertaining to deploying a report to multibyte PDF output.
Question
What are the cross-platform issues for the PDF output when using CID multibyte fonts?
Answer
To enable multibyte language support in PDF reports with CID multibyte fonts, you need to make sure that the Asian font package is installed for your Acrobat Reader on the machine where you are going to view these PDF files. The Asian font package is available at the Adobe Web site.
Question
Why is the formatting of my report not correct when using multibyte fonts on UNIX, or why do I see misaligned text in the report?
Answer
If you have used ttf2pt1 to create the AFM file, ttf2pt1 has a limitation in that it creates AFM files with metrics information for only the first 256 characters of the font. The first 256 characters are for Latin-1 characters. So, if your font contains more than 256 characters, metrics information will not be available for the additional characters. Oracle Reports uses default metrics information contained in the AFM file when it encounters characters in the report that are not in the AFM file. These default metrics may not match the exact metrics of the characters used in the report. For this reason, formatting will not be correct. To avoid this situation when you are using characters beyond the first 256 characters of the font, you can use fixed width fonts where all the characters have the same width. For example, Miriam Fixed is a fixed width font for Hebrew and can be used to avoid formatting issues.
Table 7-7 shows the cross-platform deployment scenario where the destination format is Unicode PDF created using PDF font subsetting. For more information on PDF font features, refer to Chapter 6, "Using PDF in Oracle Reports".
Table 7-7 Cross Platform Deployment - Scenario 5
| Development Platform | Deployment Platform | Destination Format |
|---|---|---|
|
Windows |
UNIX |
PDF (Unicode) |
This section discusses designing and deploying a report for Unicode PDF output in the following subsections:
To prepare your report before you deploy it on a UNIX platform:
Create a new report using a Unicode font. For example, Arial Unicode MS font.
Use only those fonts in your report that:
Cover the entire Unicode range that your report uses.
Are available on UNIX. All font files that are available on Windows (TTF files) may not be available on UNIX (AFM or TFM files). If you have the correct AFM or TFM font file available on the UNIX platform, you can continue to use it (AFM for PostScript and TFM for PCL).
|
Note: AFM support is extended only to single-byte PostScript file generation, with the exception of Japanese encoding.The encoding schemes supported for the AFM files are:
|
Can scale well. For example, MS Sans Serif does not scale well to a different size, whereas Tahoma does. The reason is that the MS Sans Serif font is a raster font that does not scale well to any size and usually has rounding issues. On the other hand, Tahoma font is a TrueType font that is very similar in visual appearance to the MS Sans Serif font. Additionally, Tahoma is a vector font that can be scaled to any size and rotated to any angle.
For fonts with AFM files not readily available on UNIX, or if you encounter any font issues in the report output such as text misalignment, you can convert and generate an AFM file from the Windows TTF file using freely available third party utilities, such as ttf2pt1. Do not attempt to convert to a TFM file, as this may not produce reliable results.
To deploy your report on a UNIX platform:
Locate the TTF files corresponding to the fonts used in your report. Convert these TTF files to AFM to ensure that you will have the AFM files for the fonts used in your report.
Use a True Type to Type 1 font converter utility to convert the TTF files to AFM files. For example, ttf2pt1.
Post-conversion, remove the .afm extension in the AFM file name. For example:
Copy the Windows TTF file used in your report to the fonts directory on your UNIX machine. For example, $ORACLE_HOME/fonts.
Add the path to the TTF file in the REPORTS_PATH environment variable. For example, arialuni.ttf.
Copy the AFM file to the $ORACLE_HOME/guicommon/tk/admin/AFM directory. For example, ArialUnicodeMS.
Edit the screenprinter.ppd file with any text editor.
|
Note: If you have defined a default printer by including an entry inORACLE_HOME/guicommon/tk/admin/uiprint.txt, then you will have to make the appropriate entries in the printer's PPD file for a PostScript printer or in the HPD file for a PCL printer.
Beginning with Oracle Reports 10g Release 1 (9.0.4), a default printer surface that mimics the screen ( The PPD files are located at: ORACLE_HOME/guicommon/tk/admin/PPD The HPD files are located at: ORACLE_HOME/guicommon/tk/admin/HPD Refer to Section 3.10.1, "ScreenPrinter" for more information on the |
Ensure that the PPD/HPD file used contains an entry for each AFM or TFM file that you use in your report. PPD/HPD files are configuration files containing printer driver settings and the list of all the fonts supported by the printer.
Navigate to the to the Font Information section in the PPD file and add the necessary entries for the font files in the following format:
*FONTNAME:ENCODING:VERSION:LOCATION
For example:
*Font Arial: Standard "(Version 2.76)" Standard ROM *Font CourierNew: Standard "(Version 2.76)" Standard ROM
Ensure that the AFM file name exactly matches the font name specified in the PPD file as Oracle Reports searches for this file based on the font name in the PPD file.
Ensure that the uiprint.txt has the entry for the appropriate PPD file.
printer name:PostScript:2:test:ppd file
In this example:
printer1:PostScript:2:test:hpljet42.ppd
Edit the hpljet42.ppd file with any text editor.
|
Note: Create a backup of thehpljet42.ppd before you proceed to edit it. This file is located in:
|
Ensure that the PPD/HPD file used contains an entry for each AFM or TFM file that you use in your report.
Navigate to the Font Information section and add the necessary entries for the new AFM files in the following order:
*FONTNAME:ENCODING:VERSION:LOCATION
For example:
*Font ArialUnicodeMS: Standard "(Version 2.76)" Standard ROM
In the [PDF:Subset] section, add the following entries to subset the fonts used in your report.
For example:
[ PDF:Subset ]"ArialUnicodeMS" = "arialuni.ttf"
Use the PDF subsetting feature to generate multibyte PDF output from your reports and to ensure your PDF report is portable. Thus, there is not dependency on the machine deploying the report to have the fonts installed.
Run the report to PDF and view it.
http://mywebserver.com:reports/rwservlet?server=myserver+report= "c:\test.rdf"+authid=hr/hr@mydb+desformat=PDF+destype=cache
The PDF should contain the unicode font used in your report. For example, Arial.
If you encounter deployment issues, review the following troubleshooting information:
If you do not get the correct fonts in the PDF output, set the environment variable DEBUG_SLFIND to a log file name (for example, debug.txt) and run the report. The font files that are looked up while parsing the PPD file as well as the fonts used will be written to the log file debug.txt. Specifically, check for the following:
The PPD file that you modified should be picked up. If it is not picked up it is a configuration issue. Refer to Chapter 4, "Managing Fonts in Oracle Reports".
The AFM files that you have copied to AFM directory should be picked up next.
See Chapter 5, "Printing on UNIX with Oracle Reports" for more information on DEBUG_SLFIND.
This section contains frequently asked questions (FAQs) pertaining to deploying a report to Unicode PDF output.
Question
Why is the formatting of my report not correct when using Unicode on UNIX, or why do I see misaligned text in the report?
Answer
If you have used ttf2pt1 to create the AFM file, ttf2pt1 has a limitation in that it creates AFM files with metrics information for only the first 256 characters of the font. So, if you are using multiple languages in the report with a Unicode font like Arial Unicode MS, when you create the AFM file for UNIX, there will not be metrics information for the characters beyond the first 256 characters. Oracle Reports uses default metrics information contained in the AFM file when it encounters characters in the report that are not in the AFM file. These default metrics may not match the exact metrics of the characters used in the report. For this reason, formatting will not be correct. To avoid formatting issues when you are using characters beyond the first 256 characters of the font, you can use fixed width fonts where all the characters have the same width.
Table 7-9 shows the cross-platform deployment scenario where the destination format is PostScript.
Table 7-9 Cross Platform Deployment - Scenario 3
| Development Platform | Deployment Platform | Destination Format |
|---|---|---|
|
Windows |
UNIX |
PostScript |
This section discusses designing and deploying a report for PostScript output in the following subsections:
To prepare your report before you deploy it on a UNIX platform:
Create a new report.
Use only those fonts in your report that:
Are available on UNIX. All font files that are available on Windows (TTF files) may not be available on UNIX (AFM or TFM files). If you have the correct AFM or TFM font file available on the UNIX platform, you can continue to use it (AFM for PostScript and TFM for PCL).
|
Note: AFM support is extended only to single-byte PostScript file generation, with the exception of Japanese encoding.The encoding schemes supported for the AFM files are:
|
Can scale well. For example, MS Sans Serif does not scale well to a different size, whereas Tahoma does. This is because MS Sans Serif is a raster font that does not scale well to any size and usually has rounding issues. On the other hand, Tahoma is a TrueType font that is very similar in visual appearance to MS Sans Serif. Additionally, Tahoma is a vector font that can be scaled to any size and rotated to any angle.
Do not include Unicode characters. Oracle Reports does not support Unicode character sets in Post Script output on the UNIX platform. As an alternative, you can use either of the following:
Oracle Reports PDF output (desformat=pdf), which supports multibyte character sets, as discussed in Section 5.5.1, "Multibyte Character Set Printing".
Oracle Reports utilities IX and PASTA for font embedding in PostScript output when Oracle Reports is installed and used with Oracle Applications, as discussed in Section 5.5.2, "Overview of IX and PASTA".
To have the PostScript output look same on the design platform (Windows) and deployment platform (Unix), the paper size should be same on both the platforms. On Windows, if you want to change the default paper size from Letter to any other size (for example, A4), perform the following steps:
Choose Settings > Control Panel > Printers.
Right-click the default printer and select Properties.
Click Printing Preferences in the General tab.
Click Advanced in the Paper/Quality tab.
Select the Paper Size and click OK.
Click OK until the main dialog box displays to set the default paper size.
For fonts with AFM files not readily available on UNIX, or if you encounter any font issues in the report output such as text misalignment, you can convert and generate an AFM file from the Windows TTF file using freely available third party utilities, such as ttf2pt1. Do not attempt to convert to a TFM file, as this may not produce reliable results.
To deploy your report on a UNIX platform:
Locate the TTF files corresponding to the fonts used in your report. Convert these TTF files to AFM to ensure that you will have the AFM files for the fonts used in your report.
Use a True Type to Type 1 font converter utility to convert the TTF files to AFM files. For example, ttf2pt1.
Post-conversion, remove the .afm extension in the AFM file name. For example:
Copy the Windows TTF file used in your report to the fonts directory on your UNIX machine. For example, $ORACLE_HOME/reports/fonts.
Add the path to the TTF file in the REPORTS_PATH environment variable. For example, arial.ttf.
Copy the AFM file to the $ORACLE_HOME/guicommon/tk/admin/AFM directory.
Ensure that the TK_PRINTER environment variable or the PRINTER environment variable is set to the default printer name. For example, printer1.
Ensure that uiprint.txt has the entry for the appropriate PPD file in the format, printer name: PostScript:2:test:ppd file. In this example:
printer1:PostScript:2:test:hpljet42.ppd
Edit the file hpljet42.ppd using any text editor. Specifically, edit the DefaultPageSize, DefaultPageRegion, and DefaultPaperDimension to change the default paper from Letter to A4, in the following way:
….. *DefaultPageSize: A4 ….. *DefaultPageRegion: A4 ….. *DefaultPaperDimension: A4 ….
|
Note: Create a backup of thehpljet42.ppd before you edit it. This file is located in:
|
Ensure that the PPD file used contains an entry for each AFM file that you use in your report.
Navigate to the Font Information section and add the necessary entries for the new AFM files in the following order:
*FONTNAME:ENCODING:VERSION:LOCATION
For example:
*Font Arial: Standard "(Version 2.76)" Standard ROM
Run the report to printer and verify that it is printed to A4 Paper.
http://mywebserver.com:reports/rwservlet?server=myserver+report="c:\test.rdf"+a uthid=hr/hr@mydb+desformat=postscript+destype=cache
This section contains frequently asked questions (FAQs) pertaining to deploying a report to PostScript output.
Question
Does Oracle Reports support Unicode PostScript file generation?
Answer
Currently, Oracle Reports supports Unicode character sets in PostScript output only on the Windows platform. On UNIX platforms, you can use either of the following:
Oracle Reports PDF output (desformat=pdf), which supports multibyte character sets, as discussed in Section 5.5.1, "Multibyte Character Set Printing".
Oracle Reports utilities IX and PASTA for font embedding in PostScript output when Oracle Reports is installed and used with Oracle Applications, as discussed in Section 5.5.2, "Overview of IX and PASTA".
Question
Does Oracle Reports embed the font in the PostScript output file?
Answer
Oracle Reports does not embed the font in the PostScript output file. It writes the font name and the metrics that were calculated using AFM files. Therefore, for the report to appear without any font alignment issues, ensure that the necessary fonts are installed on the printer.
Question
The page count of my report varies when run on different installations of UNIX. How can I ensure that the page count of my report is the same regardless of the installation?
Answer
In UNIX, Oracle Reports uses the PPD/HPD file of the default printer in the installation for formatting. The resolution and list of fonts will be picked up from this PPD/HPD files. Beginning with Oracle Reports 10g Release 1 (9.0.4), if there is no default printer setup in the installation, then screenprinter.ppd will be used. This PPD file emulates the screen. Earlier versions of Oracle Reports used the DISPLAY environment variable instead. Ensure that the two installations use the same AFM/TFM files and font files, so that the number of pages of PDF output will be the same.
