[Rlib-devel] Re: Buglet in detail layout on first page

[William K. V. <wk...@us...>]

On Fri, 2005-06-10 at 19:58, William K. Volkman wrote:
> 	I just noticed an off-by-one issue with detail rows on
> the first page of a report.  It is overwriting the first part
> of the page footer before breaking.

Actually it is an off-by-break-header/footer-size problem.
One thing I've found is that the horizontal rule sizes aren't
being calculated until late in the game.

resolution.c:rlib_hr_resolve_pcode does this: rhl->size = 0;
and set's up size_code

reportgen.c:get_output_size uses this: RLIB_GET_LINE(rhl->size);

reportgen.c:rlib_make_report calls rlib_layout_init_part_page
which is going to call get_outputs_size (which calls get_output_size)
to determine the part->bottom_size however it does this before
any calls to rlib_layout_report_output (which calls
rlib_layout_report_outputs_across_pages, who then calls
rlib_layout_report_output_array, who will finally perform:

rlib_execute_as_float(r, rhl->size_code, &f)
rhl->size = f;

The next path that gets confused is (the break is on rhl->size being
0):

#0  get_output_size (r=0x8049d60, roa=0x8079f80) at reportgen.c:220
#1  0x40042e88 in get_outputs_size (r=0x8049d60, e=0x807a9d8, page=0) at
reportgen.c:233
#2  0x400543d7 in rlib_handle_break_headers (r=0x8049d60,
part=0x807b880, report=0x80729a0) at breaks.c:133
#3  0x40043baa in rlib_layout_report (r=0x8049d60, part=0x807b880,
report=0x80729a0, left_margin_offset=0, top_margin_offset=0) at
reportgen.c:559
#4  0x400440d2 in rlib_layout_part_td (r=0x8049d60, part=0x807b880,
part_deviations=0x804a7a0, page_number=1, position_top=0,
rrp=0xbfffcef8) at reportgen.c:668
#5  0x40044331 in rlib_layout_part_tr (r=0x8049d60, part=0x807b880) at
reportgen.c:715
#6  0x400446ec in rlib_make_report (r=0x8049d60) at reportgen.c:800

Then:
#0  get_output_size (r=0x8049d60, roa=0x8078570) at reportgen.c:220
#1  0x40042f68 in will_outputs_fit (r=0x8049d60, part=0x807b880,
report=0x80729a0, e=0x8078400, page=1) at reportgen.c:260
#2  0x40043056 in rlib_end_page_if_line_wont_fit (r=0x8049d60,
part=0x807b880, report=0x80729a0, e=0x8078400) at reportgen.c:278
#3  0x4005473e in rlib_break_all_below_in_reverse_order (r=0x8049d60,
part=0x807b880, report=0x80729a0, e=0x807a960) at breaks.c:204
#4  0x40054870 in rlib_handle_break_footers (r=0x8049d60,
part=0x807b880, report=0x80729a0) at breaks.c:264
#5  0x40043c52 in rlib_layout_report (r=0x8049d60, part=0x807b880,
report=0x80729a0, left_margin_offset=0, top_margin_offset=0) at
reportgen.c:587
#6  0x400440d2 in rlib_layout_part_td (r=0x8049d60, part=0x807b880,
part_deviations=0x804a7a0, page_number=1, position_top=0,
rrp=0xbfffcef8) at reportgen.c:668
#7  0x40044331 in rlib_layout_part_tr (r=0x8049d60, part=0x807b880) at
reportgen.c:715
#8  0x400446ec in rlib_make_report (r=0x8049d60) at reportgen.c:800

One solution would be to hack the get_output_size code to execute the
pcode for obtaining the size.  This however raises questions:

1.  Should we always evaluate the pcode or only if rhl->size is 0?
(if not then perhaps resolution should setup rhl->size)
2.  Should the check for the size of the text line take into account
the is_not_suppressed check?

Experimental patch attached, it fixes my reports, YMMV.

Cheers,
William.