Empty TextFields with RemoveLineWhenBlank=true will be considered to detemine when a page will break

[KayelGee]

It seems that a page break is calculated before empty lines are removed.

Steps to reproduce:

• Create a Detail Band and set Layout to "Vertical Layout"
• Add a Textfiled with a Value that shows a position
• Add multiple Textfields with Value "" , RemoveLineWhenBlank=true and positionType=Float
• Add a StaticText with some Text in the Column Footer to better see where the Detail ends
• Preview with a Data Source that returns enough positions to overflow the page
• The first positions will look fine
• The last position on each page will have additional empty unused space

[teodord]

When you have tall bands with collapsing content, split them into multiple smaller bands that can display conditionally based on printWhenExpression.
In complex layouts, this might mean use of subreports.
The behaviour you described is unlikely to be changed.

[KayelGee]

I don't see how that can be the intended behaviour.

Once I split lines between multiple bands I lose the ability to have a consistent grid layout. Having subreports already makes this even harder, as a change to one column means I have to go into every subreport and make the same change. This could be solved by having a dummy line just for the layout at the beginning that doesn't print, but that wouldn't work currently.

[KayelGee]

Also with subreports even if the subreport doesn't return data(and the subreport is configured to not print anything when no data is present), it will still print a blank line(for the page break) unless I put the subreport in a band with a printWhenExpression. Which in turn means that whatever the query is inside the subreport, I need to add it to the main reports query just to check if it returns data just so I can have a printWhenExpression.

English isn't my first language, so if I'm explaining something badly please tell me.

[teodord]

I did not say you HAVE TO use subreports. I said "In complex layouts, this might mean use of subreports."
I was only trying to give you a sense of what a complete solution might look like without actually seeing your report design.
The simple test case you described in words, does not require use of subreports.

I do not exclude the fact that the program can be improved to work the way you expect, but I can assure you we are talking about an area of our program which is quite complex and the way it works today is the best we were able to come up with.
Feel free to check the source code and come up with improvements.

Thanks,
Teodor

[KayelGee]

I'm sorry if I came off wrong.
I just wanted to point out the flaws in the solutions. It's my only pain point with jasperreports.

Can you point me in a general direction on where to start to get an understanding of the current implementation?

[teodord]

Most of the behavior described in this tracker is implemented in this class:
https://github.com/Jaspersoft/jasperreports/blob/master/core/src/main/java/net/sf/jasperreports/engine/fill/JRFillElementContainer.java
Elements in a container are prepared, moved, collapsed, stretched and the order of operations is given. Before doing these operations, the elements are sorted based on their Y position and are processed from top to bottom.

When we suggest splitting a tall band into multiple smaller bands, it is about helping the program understand where the content can be cut, so that the existing algorithm produces minimum side effects.