Consultor Eletrônico



Kbase P3937: Can the PROGRESS 4GL output reports using multiple fonts?
Autor   Progress Software Corporation - Progress
Acesso   Público
Publicação   16/03/2009
Status: Verified

GOAL:

Can the PROGRESS 4GL output reports using multiple fonts?

GOAL:

Is it possible to use multiple fonts with an ABL report?

FACT(s) (Environment):

All Supported Operating Systems
Progress 9.x
OpenEdge 10.x

FIX:

There is no standard feature in the OpenEdge ABL for creating reports that consist of multiple fonts. Many programmers desire this feature for adding a more polished look to their reports.

One alternative is to use the Progress Report Builder, which uses 3GL to create a WYSIWYG ("What you see is what you get") output. Report Builder can do this because it interfaces directly with the MS-Windows API (application programming interface); standard 4GL cannot work with the API in the same way, mainly because the API is written in 3GL and requires sophisticated interaction which is not possible using a ABL.

When Report Builder cannot be part of the solution (for one, it is not feasible for DOS character-mode or Unix users) then a 4GL programmer's options are limited. In MS-Windows, he or she can write a dynamic linked library (DLL) which accomplishes the same kind of interaction with the API as Report Builder.
This would be the most appropriate and direct solution, again since the API itself is written in 3GL, however it requires 3GL knowledge as well as an understanding of the API.

However, be aware that Report Builder, (Design + Runtime) is no longer be distributed as part of the OpenEdge 10 product suite. The Report Builder Design module is no longer be included in OpenEdge 10 but, for purposes of backwards compatibility, the Report Builder Runtime Engine is still be present. Please refer to the reference below for further details.


Due to the number of API calls involved in printing (they number in the hundreds), Progress Technical Support is unable to assist programmers who seek to write a DLL that interfaces with the API to make printer calls. Programmers are referred to Progress Corporate Consulting or to their local Progress User Group for the customized help that would be required in this area.

Another approach to the problem of printing 4GL reports with multiple fonts would be to send control codes to the target printer during report output, setting it to use different fonts. While this is theoretically possible the approach has serious drawbacks:

Different printers generally require different control codes to do the same thing. A printer manufactured, say, by Epson (your case) would almost certainly require a different control sequence for "14-point Times Roman" than a HP.
If an application were to be portable to all possible user configurations, it would require that a programmer anticipate every printer that might exist at a site, then write conditional code to query for the printers and execute accordingly. This would be a daunting task.

1- Printers can respond to control codes in unexpected ways. For instance, upon receipt of a control code sequence placing it in "underline" mode, a printer might automatically start a new line or skip multiple spaces. There is no way to detect this behavior at runtime in the ABL, so again the programmer would be left with the task of testing all likely printer configurations and attempting to work around them.

2- Even if a programmer was to achieve perfect fine-tuning for one specific printer, as soon as a different printer were to be used (even one of the same make and model) there would be a likelihood that the new printer would not be configured exactly the same and so would generate different-looking reports due to font availability, font size, line spacing, etc.

3- The limitations described in (1) through (3) would compound the difficulties of maintaining such source code.

For MS-Windows programmers, there is a third-party DLL which will allow reports to be generated completely in *one* of the fonts defined in the .INI file: vpxPrint.d.ll. Since this DLL is written in 3GL, it is capable of interaction with the MS-Windows API, making it possible to use a non-default font. For more information about vpxprint, refer to the below reference.



There is an existing enhancement request to add multiple-font support to 4GL report output, however due to the difficulties described above it is not likely that this feature will be added in the foreseeable future..