Consultor Eletrônico

Solution ID: P3937

GOAL:

Can the PROGRESS 4GL output reports using multiple fonts?

FIX:

There is no standard feature in the PROGRESS 4GL 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 4GL.

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.

[ 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 (as of yet, Progress Technical Support has not encountered anyone who has had success doing it) the approach has serious drawbacks:

(1) Different printers generally require different control codes to do the same thing. A printer manufactured, say, by Hewlett Packard would almost certainly require a different control sequence for "14-point Times Roman" than a Minolta.
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.

(2) 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 4GL, so again the
programmer would be left with the task of testing all likely printer configurations and attempting to work around them.

(3) Even if a programmer were 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.

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

For MS-Windows programmers, there is a DLL provided by Progress which will allow reports to be generated completely in *one* of the fonts defined in the .INI file: ProPrint.dll. 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. ProPrint.dll does not, however, allow for more than one font to be used, so it is not a true workaround to the problem described in this solution.

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.