By Colin Nicholls
This article is based on some work I did in trying to answer a question from Alejandro Sosa on the Universal Thread. Alex was having some trouble getting title labels to right-align correctly with right-aligned field/expressions. His report was complex and migrated from an older version of FoxPro, so I created a simple test report to highlight what was happening.
In Visual FoxPro 9.0, there is a new report engine that uses GDI+ to render output. The older, backward-compatible report engine is still supported, however. You can switch between the two engines on the fly using the SET REPORTBEHAVIOR command.
Review: Monospaced fonts vs. Proportional fonts
Monospaced fonts use a constant width for all characters at a given font size. Proportional fonts use varying character widths as appropriate to make a font more readable. In this article you can see the difference quite easily: The paragraph text is proportional, and the code snippets are all in monospace.
In REPORTBEHAVIOR=90, all text labels will render with greater lengths that you would expect from looking at a report layout in the Report Desiginer. This is because GDI+ text rendering uses more space. Labels suffer from this because the layout records their exact starting position, as opposed to field/expressions which allow the aligment calculation to be performed by the engine, using GDI+.
Read on for details.
The test data
I wanted to compare right-alignment with both character string and numeric values, so I created two columns in my test cursor:
CREATE CURSOR x ( ftitle C(10), fnumb N(8,2) ) INSERT INTO x VALUES ( 'Bagels', 32.45 ) INSERT INTO x VALUES ( 'Cucumber', 5.23)
The test report
Here's a picture of the test report open in the designer, with the Label controls selected to show their exact positions. I have used red lines to highlight the alignment axes.
The field/expression controls for the FTITLE and FNUMB fields have both been configured as Right-Aligned - the character field had to be set manually; the numeric field is right-aligned by default. You can see that I have visually aligned the labels to line up with each end of the field/expression controls. I then duplicated the layout controls for each of five different fonts. Tahoma and Candara are proportional fonts, and Courier New, Bitstream Vera Sans Mono and Consolas are monospaced.
Here is what the report looks like in the Report Preview with REPORTBEHAVIOR = 80:
And the printed result:
Assuming the red guide lines are an accurate reference, it seems that best results can be seen with Courier New and Vera Sans Mono. Consolas and the proportional fonts seem to overrun their expected positions slightly. The tolerance for acceptable output would have to be pretty tight for any of these fonts to be a major problem, however.
Here is what the report looks like in the Report Preview with REPORTBEHAVIOR = 90:
And the printed result:
It's easy to see from the comparison that REPORTBEHAVIOR=90, all text labels overrun their expected length, not just the monospaced fonts. The effect is definitely more pronounced in the monospace fonts, however.
Why does this happen for labels and not field/expressions?
With REPORTBEHAVIOR=90, the new report engine uses GDI+ to render output, and text string rendering requires more space than plain old GDI. I've written about why GDI+ requires additional room for text strings before.
The Report Designer uses GDI - not GDI+ - to render the report layout components, including all the text strings that you see. So if you visually right-align a label report element, the report designer records the leftmost co-ordinates of the element (the text start position) in the layout. The length of the string under GDI+ rendering will most likely be greater than what you would think, based on what you see in the Designer.
There's no getting around the fact that you have to take this effect into account when you are designing label controls in your reports.
Now, you will have observed that this problem doesn't occur for field/expression controls. They are all right-aligned correctly because the Report Designer doesn't specify an exact starting position for the text string, but rather specifies the box within which the text must be rendered. So the alignment calculation takes place in the report engine, with GDI+ taking the text size into account.
Thanks to Alex Sosa for an interesting question!