rlib-devel

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

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

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

I may get time to look into it later this weekend but I've got
a lot of other fires to fix first.

Cheers and happy coding,

William.

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

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

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.

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

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

Hello,
Just an update. I added the check for the size of an image to the
get_output_size routine, added a logo to the page footer, and now
am seeing a double compensation for the size of the footer.

On Sun, 2005-06-12 at 11:51, William K. Volkman wrote:
<snip>
> 
> On Sun, 2005-06-12 at 09:17, Bob Doan wrote:
> > 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.

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

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

An image on a line or an Image outside of a line?

One of the "features" in rlib is to have an IMAGE outside of a line, but
the catch is it doesn't account for Horizontal space.

On Sun, 2005-06-12 at 13:32 -0600, William K. Volkman wrote:
> Hello,
> Just an update. I added the check for the size of an image to the
> get_output_size routine, added a logo to the page footer, and now
> am seeing a double compensation for the size of the footer.
> 
> On Sun, 2005-06-12 at 11:51, William K. Volkman wrote:
> <snip>
> > 
> > On Sun, 2005-06-12 at 09:17, Bob Doan wrote:
> > > 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.
> 
-- 
Bob Doan <bd...@si...>

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

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

Hello,
On Sun, 2005-06-12 at 16:16, Bob Doan wrote:
> An image on a line or an Image outside of a line?

Humm.. an image on the line causes an under compensation, the
detail rows land in the page footer.  An image outside the line
shows the overcompensation.  Note this is not plain CVS,
in reportgen.c get_output_size I added:
              } else if(rd->type == RLIB_REPORT_PRESENTATION_DATA_IMAGE)
{
                      struct rlib_report_image *ri = rd->data;
                      struct rlib_value rval4, *rval_height=&rval4;
                      rlib_execute_pcode(r, &rval4, ri->height_code,
NULL);
                      if(!RLIB_VALUE_IS_NUMBER(rval_height)) {
                              r_error("RLIB ENCOUNTERED AN ERROR
OBTAINING THE HEIGHT FOR A IMAGE\n");
                      } else {
                              gfloat height =
RLIB_FXP_TO_NORMAL_LONG_LONG(RLIB_VALUE_GET_AS_NUMBER(rval_height));
                              rlib_value_free(rval_height);
                              total += RLIB_GET_LINE(height);
                      }
                }


> One of the "features" in rlib is to have an IMAGE outside of a line, but
> the catch is it doesn't account for Horizontal space.
> 
> On Sun, 2005-06-12 at 13:32 -0600, William K. Volkman wrote:
> > Hello,
> > Just an update. I added the check for the size of an image to the
> > get_output_size routine, added a logo to the page footer, and now
> > am seeing a double compensation for the size of the footer.
> > 
> > On Sun, 2005-06-12 at 11:51, William K. Volkman wrote:
> > <snip>
> > > 
> > > On Sun, 2005-06-12 at 09:17, Bob Doan wrote:
> > > > 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).

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

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

Did you fix the problem with the Image?  I'm kinda confused here ;)

- bob

On Sun, 2005-06-12 at 13:32 -0600, William K. Volkman wrote:
> Hello,
> Just an update. I added the check for the size of an image to the
> get_output_size routine, added a logo to the page footer, and now
> am seeing a double compensation for the size of the footer.
> 
> On Sun, 2005-06-12 at 11:51, William K. Volkman wrote:
> <snip>
> > 
> > On Sun, 2005-06-12 at 09:17, Bob Doan wrote:
> > > 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.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
> a projector? How fast can you ride your desk chair down the office luge track?
> If you want to score the big prize, get to know the little guy.  
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Rlib-devel mailing list
> Rli...@li...
> https://lists.sourceforge.net/lists/listinfo/rlib-devel

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

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

Hello Bob,
	I continued to use the patch I had made to get_output_size
which took into account the size of horizontal lines, I added to
that to have it also account for Images.  The reason I continued
with my patch was it fixes my reports for now.  The implication
from your response below was there was another way to solve
the problem.  Since you are the architect you best would know
how to implement a fix (which I'm eagerly waiting to test :-).
One thing that I wanted to point out with my update was that
somewhere there appears to be a double accounting of the space
taken for the page footer.  This showed up with the Image being
outside of a Line object.

Does that clarify things?

Cheers,
William.
 
On Mon, 2005-06-13 at 11:26, Bob Doan wrote:
> Did you fix the problem with the Image?  I'm kinda confused here ;)
> 
> - bob
> 
> On Sun, 2005-06-12 at 13:32 -0600, William K. Volkman wrote:
> > Hello,
> > Just an update. I added the check for the size of an image to the
> > get_output_size routine, added a logo to the page footer, and now
> > am seeing a double compensation for the size of the footer.
> > 
> > On Sun, 2005-06-12 at 11:51, William K. Volkman wrote:
> > <snip>
> > > 
> > > On Sun, 2005-06-12 at 09:17, Bob Doan wrote:
> > > > 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.
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
> > a projector? How fast can you ride your desk chair down the office luge track?
> > If you want to score the big prize, get to know the little guy.  
> > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> > _______________________________________________
> > Rlib-devel mailing list
> > Rli...@li...
> > https://lists.sourceforge.net/lists/listinfo/rlib-devel