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

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

Hello Bob,

On Sun, 2005-06-12 at 09:17, Bob Doan wrote:
> Hym... This doesn't seem quite right because theoretically you could set
> the size of a HR to 0 to suppress it.

Yes, there appears to be two ways to suppress the horizontal line,
the xml attribute suppress and then just changing the height to 0.

> 
> As of this moment resolution.c would be the correct place to set it.
> 
Agreed, provided the intention was that these things are to be static.

> Another serious problem here is if people have expectations to change
> the height of things (font sizes, height, ect) dynamically.
> <HorizontalLine size="iif(r.detailcnt%2,5,100)" bgcolor="'white'"/>

This was the gist of my question, it appears that at some point a change
was made to enable these to be more dynamic however the change was not
carried all the way through.

> Same is true for images and lines.

I noted that lines have a suppress code which prompted one of my
questions, the fontSize attribute isn't dynamic at least.  Images
can't be suppressed however their height and width could change,
the current get_output_size routine doesn't even consider their
presence so would need that added.

> 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"

Which is one reason why I put made the change to get_output_size,
it is called as part of the "will fit" check (see second stack
trace from GDB below).

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

I don't think that I'm familiar enough with the architecture to be in
a position to judge the "best" way to handle this.  If you want to
tackle it that is fine by me.  The change I made basically works in
the static case albeit not in the most efficient manner and didn't
add support for images (which is one change that I would make, logo
goes in the page footer).

Take care,
William.

> 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.