Splitting behavior for bands when declared height is larger than remaining space

Hi,

 

I've been using JasperReports as the reporting engine for a large ERP application. I've been very impressed with the overall quality of JasperReports. However, this one issue results in several of my reports with large bands leaving huge amounts of whitespace at the bottom of each page.

 

Implementing the suggested work-around (formerly at http://jasperforge.org/sf/wiki/do/viewage/projects.jasperreports/wiki/FAQ) , creating multiple bands for the large bands, gets quite confusing with a grouped report...

 

Does anyone have any information as to when this issue might be addressed?

 

Would the issue be addressed more quickly if my employer payed JasperSoft for support?

 

 

Hi,

 

I have committed to SVN two new features that would help solve this:

 

1. We have added support for multi-band sections. For now, only the detail and the group header and footer are multi-band sections. With this, there is no longer the need to use dummy groups to split large sections into multiple bands. Several bands can be declared into the mentioned report sections.

 

2. The isSplitAllowed attribute was deprecated and replaced by an attribute called splitType, at band level. Possible values for this attribute are:

- Stretch : band breaks only when it stretches, never within declared height (default behavior);

- Prevent : band is prevented from breaking on first break attempt (equivalent to former isSplitAllowed=false);

- Immediate : the band can break anywhere, if at least one element has been printed on current page. If no element has been printed yet, whole band renders on next page.

 

I think what you want to achiev, C-Box is now possible with splitType=Immediate.

 

Note that the net.sf.jasperreports.band.split.type config property can be used per report or globally, to alter the default split behavior of bands which do not have the attribute set.

 

If you have the chance, please test the latest version from SVN and send us your feedback. This will be part of the next release.

 

I hope this helps.

Teodor

 

Hi Teodor & Lucian,

 

I'm currently completing the change from 2.0.5 to 3.5.3 and found some time to test the new split type...

for the first few cases it seems to be a great solution. I have more content at first page altough I have large bands defined and just set splitType to immediate.

 

Great work!

Thanks a lot!

Regards from sunny Germany

C-Box

Works like a charm!

 

C-Box

Ups... I just played around a little bit and found a case where it doesn't behave like expected....

 

I do have a groupfooter where I placed 5 elements below each other....

three of them (in the middle) are removed in certain cases (done via printwhenexpression) so all of them have positiontype "float" that there isn't any space between them if some fields are removed.

I set "immediate" as SplitType but although there is enough space at first page the last field is rendered at page 2 instead 1.....

See the JRXML i do attach.

Just run it with JREmptyDataSource(10) and set prompted parameter to "false".

I colorized the pageheader and footer to see how much space actually is left.

 

Do I missunderstood the SplitType behaviour or is it still kind of buggy???

 

regards

C-Box

Hi, C-Box

 

I'm afraid this is not quite a bug, but rather the way we made it work.

You see, the removal of empty space due to isRemoveWhenBlank and the stretch of the elements due to the stretchType are operations that are performed LATE during the band layout algorithm.

 

By the time the empty space is collapsed, the engine already decided that the band will split just above the "total value:" element. Only after the split was decided, the empty space is removed and the band is collapsed. But its remainder will still show up on the next page, because content will not be moved back from one page to the previous.

 

Changing this is complicated and with so many implications that we are not even going to try it. At least not soon. Introducing the new splitType attribute was not meant to solve this particular scenario.

 

Actually, in such cases when space is supposed to collapse, individual pieces of content should be isolated in separate bands. If you would have split the group footer in 5 bands, you would have achieved the proper effect, because the bands that do not show up will be collapsed properly.

 

If you think the explanation is enough, feel free to close back this bug. Otherwise, it will stay open for sometime.

 

Thank you,

Teodor

 

Hi Teodor,

 

thanks for your explanation.

 

the problem with splitting the band into multiple bands would now cause that the whole block isn't kept together if there isn't enough space for all of them. (what is intended, as that fields are the sums of invoice, orders and so on that sould be printed at one block to easily control them by end-users without moving between pages)

 

I guess the engine now "thinks always positive"... so if there are 5 elements in design, the whole space is needed and the calculation if the band fit's at current page is done by summing up the elements heights.

 

Even not having debugged that algorithm I could imagine, that the engine could "think negative" for elements that have "RemoveLineWhenBlank" set to true.

So all elements that has this attribute set to true are considered as NOT really filled and the remaining space-calculation ignores these heights.

 

Are I'm dreaming too much!??!!?

thanks for thinking about

C-Box

Hi,

 

Although it is not a nice workaround, you could actually try make collapseable elements as small as possible. Try use height=1 for all of them. They will expand anyway.

 

As I said, the algorithm around element layout is probably the most complex in the entire library, end we prefer not to mess with it unless absolutely necessary.

 

Thanks,

Teodor

Hmm I tried your suggestion but setting 1 as height prevents printing the elements at all. (don't understood your hint "They will expand anyway") is this a special property that has to be set?

 

Could the problem perhaps solved with a custom component let's call "ExtendedFrame" that precalculates the needed size in the way I mentioned before with the "negative thinking" towards elements that have RemoveLineWhenBlank????? So that I could place these elements into a such a new component that has a different calculation logic than normal frames for instance have?

 

Good night

C-Box

Well, I thought the elements are text fields and they could stretch with overflow. But indeed, in your sample, they are static texts, so they don't stretch. You could make them text fields, even if they display fixed text. However, if you plan to use evaluationTime, it would still not work.

 

Thanks,

Teodor

No I didn't thought about Evaluation Time but more at the calculation that is done within a custom component method "prepare" (eg. FillList.java --> public FillPrepareResult prepare(int availableHeight)) as far as I can see, there is the left availableHeight given when such a List is rendered and I could imagine, when creating such a "CollapsableFrame" Component could prevent the pagebreaks that causes now the second page.

 

What do you think, could that be feasible?

 

regards from currently very rainy Germany

C-Box

Hi,

 

I don't know. Might be feasible. I suggest you try make a component by using the existing code for frames. But inside the custom frame, you change the layout algorithm.

 

Anyway, it would not be trivial, but it is a possible way to get around this limitation of the engine.

I'm saying this because it is highly unlikely we are going to change the band behavior soon, because it might have unexpected consequences for people already using the product.

 

So we might close this tracker and maybe continue our discussion on a patch tracker were you provide the new component when you have it?

 

Thank you,

Teodor

Changed Priority from Urgent to Immediate

Changed Resolution from Fixed to Open

Changed Status from Closed to New

Changed Assigned User from @lucianc to -

---

Hello i have a problem. So on first page only goes 1 group, and then on the 2nd page goes second group and continues on third with third group. Can someone give me a solution with this, im losing my mind.This detail band is in subreport, and subreport is in main report in Group Header.I have expression on group header in main report.

Here is page_1

and page_2

Changed Resolution from Open to Fixed

Changed Status from New to Closed

Changed Assigned User from - to @teodord

---

These are nice pictures, Vjeko, but we cannot help you because we don't have the report templates you used to generate them.Impossible to tell what is wrong with them if we don't have them.And if you do provide them, please create a new tracker and leave this one closed, as it was.Thank you,Teodor