----
But the point of the test was really the difference between ReportBehavior 80 and 90 as concerns data in the detail band vs data in the footer band.
----

Then you should not have added your bit of diagnosis about how the issue was specific to smaller size fonts, since size 10 worked -- and I would not have had to explain this <s>.

---
"Stretch with overflow" is off in the Arial 9 and Arial 8 columns and there is no overflow in the detail band of these columns with ReportBehavior 80, but there is overflow in the detail band with ReportBehavior 90.
----

Yes, I do understand this. To spell this out:

In the case of Arial 9 there appears to be .052 inch difference in tolerance between what GDI+ requires (for your picture template) and what GDI requires.

In the case of Arial 8, with the algorithm improved, this fits in GDI+'s rendering.

---
Surely the calculation, and hence the decision whether to print asterisks or the actual number, is based on the value of the data at print time and not on the largest possible value the picture clause allows.
----

I hate it when people say "Surely" . This just is not true.

Once again: size determinations are made up-front. They *will* be made on the basis of the picture clause, *not* on the basis of pre-calculating all your report expressions up front.

And, yes, I understand that (a) this is a difference of behavior; it will be doc'd and (b) expressions with a calculation behave slightly differently -- I will try to find out exactly why and post an explanation here; this should be in the docs as well if it is relevant.

----
To print all values in a column as asterisks simply because the largest possible value won't fit doesn't make sense.
----

Actually, it does make sense from many perspectives, but thank you for your opinion <s>.

----
As you note below, this is currency data so hypothetically the values could get much larger than even that picture allows
----

If a number can "hypothetically" get larger than its space then you should leave room for your data in the expression, or set the picture clause that matches the data that will actually fit in that expression. See below for more of an explanation.

----
The "999,999,999.99" picture clause says I want the values printed in triplets separated by commas to the left of the decimal, with two positions to the right of the decimal.
----


I understand what the picture clause says. But if you want three positions to be able to appear to the left of the leftmost comma, you will have to make room for it -- and in my test this will take .052" more room in GDI+ rending than in GDI.

You can change your picture clause by eliminating the leftmost 9, which will work fine in the current 1" size. And you should *only* need to do this for Arial 9, Arial 8 would be fine with the full clause.

I hope that this is not too much of a sacrifice for you to make for all the advantages we have gained from GDI+ rendering <s>.

If you feel you cannot live without the full complement of 9's in your picture clause, then this says to me that you really do have data that requires the full picture clause. In that case you should widen the the field to 1.052" so your actual data (not hypothetical) will actually fit. End of story.

The engine is *not* going to check to see what the highest value of your actual data is before the report run. It uses your instructions in the picture clause to do that and it expects your instructions to give appropriate information.

-----
Yes, the values are of currency data type, but on reports only two decimals should be printed, which is why the picture only allows for two. I would hope the report engine takes this into account when calculating whether a value will fit in the space provided.
-----

It does now. In earlier versions, believe it or not, there were some issues with this. That is one reason why actually using a picture clause that is actually appropriate is a good idea <s>.

----
Not sure I understand that. All numeric values are right aligned by default. Is something changing?
----

I said nothing to even remotely suggest that numeric values being right aligned would change!

I said that right alignment behavior was under review. The rendering of strings (whether numerically based or not) that is rendered differently from the default for the context is handled differently under GDI+ so different work has to be done by the new rendering engine than before. The intended results are the same.

FWIW "right" vs "left" aligned doesn't exist in GDI+, it would be "far alignment as defined in each context (RTL or LTR). This is one of the differences.

>L<