Kbase 16020: Can the PROGRESS 4gl output reports using multiple fonts ?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/10/1998 |
|
Can the PROGRESS 4gl output reports using multiple fonts ?
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 knowledgebase.
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.
SEE ALSO:
---------
Kbase 6364, "Using PUT to send CONTROL codes to a printer
4GL or RESULTS"
Kbase 13563, "SAMPLE - ProPrint.DLL and _osprint ( OSPRINT )"
Kbase 13502, "Return codes from ProPrint.dll"
Kbase 14085, "osprint and output to printer - which font do
we use?"
Kbase 15682, "OSPRINT does not print in Landscape mode"
Progress Software Technical Support Note # 16020