>1.
>
>There is nothing "strange" about the fact that Arial 10 prints correctly while Arial 9 does not in your report. You have "stretch with overflow" turned on in the Arial 10 column. If you turn off "stretch" the Arial 10 will not print properly in SET REPORTB 80 either (or in VFP 8).

You're right, "stretch with overflow" was inadvertently on in the Arial 10 column and yes, turning it off produces overflow in that column under ReportBehavior 80 as well as 90. 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. "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.

>2.
>
>In a later build, the values in the Arial 8 column will print correctly, although they do not in yours. This makes sense, because the algorithm figuring out how many digits can fit in this field *has* been improved since the public beta build.

Good.

>3.
>
>Why doesn't the Arial 9 column fit while it does in SET REPORTB 80? A couple of reasons:
>
>a) GDI+ takes a little more room than GDI as we've discussed, and as you'll find in the release notes. In this case, for Arial 9, your field was 1 inch wide and 1.05 inch did it for me (use the builder). Of course stretch worked too, if you prefer that <s>.
>
>b) You've used a picture clause that indicates you want a certain number of chars to fit. New-style output (and I believe this is also in release notes) pays attention to this picture clause for numbers to determine whether the number actually fits.

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. To print all values in a column as asterisks simply because the largest possible value won't fit doesn't make sense. I really hope that's not what's going on here, although the release notes seem to imply it may be.

>If the number you are outputting really can ever be as big as "999,999,999.99" (your picture clause), your field should be wider. Otherwise there is a chance that the displayed number will be cut off. If the data can never be that wide, then you should reduce the picture clause appropriately.

As you note below, this is currency data so hypothetically the values could get much larger than even that picture allows. In actual practice the values do not approach the upper limit of a currency field, but they can have nine digits to the left of the decimal, which is why a "999,999,999.99" picture clause is used.

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. If the report field cannot accommodate a particular value as formatted then that value should print as asterisks indicating oveflow. All values that do fit should print correctly, though. In other words, the picture should determine the format of the printed number and the width of the report field should determine the largest formatted value that can print without overflow.

>Although this change makes sense for safety reasons, it is also related to the way the width the field can display is calculated in the report up-front in new-style output, I believe. See point # 4.

You're probably referring to the section of the release notes entitled "Use of picture templates in determining what will fit in a report layout object." The example given deals with a smaller field (4 digits) being formatted with a larger picture (999,999,999). It's not clear to me how these changes will impact a larger field, such as a currency field, being formatted with a smaller picture.

>c) Your field is also of currency type. That means something special from the engine's point of view, and this was the same in VFP 8 and SET REPORTB 8. Currency values actually have four decimal places. I think that the engine is still trying to calculate room for those 4 places when it does its up-front calc of how much room is needed for this field, and this is one of the things that is still under review. I *don't* think that this is significant in your specific example, just wanted to mention it.

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. In other words, it should disregard the space that would be needed for the other two decimal positions because those decimal positions are not going to be printed.

>3.
>
>Right alignment along with currency values do present some additional issues, and these are also items currently under review.

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

>4.
>
>Why do the calculated fields in the footer print correctly in Arial 9 while they don't in the non-calculated fields?
>
>Not 100% sure, and I will try to get you a more exact answer on this. But I think it's because the up-front calculation of "how many characters can fit in that space" is probably done a bit differently. Once there is a calculation there, the Engine may not recognize that the value is of currency type, or even numeric type.

What it comes down to is that if a field of a certain width, say 1.00", using a certain font, say Arial 8, is wide enough to print a particular value, say 275,000.00, in the footer band of a report, then a field of the same width using the same font should also be wide enough to print an equal or smaller value in the detail band.

I appreciate your thoroughness here. Perhaps most of this has already been resolved in a later build, anyway. I would like to continue the discussion about using the picture clause to determine what fits, though, either here or privately. It's late and I'm not sure I fully understand it, but right now it seems to me this change could break a lot of existing reports.