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

[Bob D. <bd...@si...>]

Hym... This doesn't seem quite right because theoretically you could set
the size of a HR to 0 to suppress it.

As of this moment resolution.c would be the correct place to set it.

But:

Another serious problem here is if people have expectations to change
the height of things (font sizes, height, ect) dynamically.

like 

<HorizontalLine size="iif(r.detailcnt%2,5,100)" bgcolor="'white'"/>

Same is true for images and lines.

As of this moment things like this just won't work (And overwrites will
occur)

Perhaps the more correct thing to do execute hight changing properties
before we check to see if "it will fit"

I could tackle this one if you don't feel comfortable doing it.  Let me
know.

- bob

On Sat, 2005-06-11 at 19:13 -0600, William K. Volkman wrote:
> 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.
> 
> 
> 
> 
> 
-- 
Bob Doan <bd...@si...>