[#7231] - blank space problem

Bug report
Feedback Requested
Project: Severity:
Component: Reproducibility:
Assigned to:

Sometimes, when using subreports with collection data, jasper prints unnecessary white space to PDF report. Every component has isRemoveLineWhenBlank property set to true. Even the subreport component in parent component has this property set ti true along with printWhenExpression. Screenshot and jrxml files are enclosured.

File bugreportassets.7z27.1 KB
vladislav.vodicka's picture
Joined: Aug 17 2015 - 1:35am
Last seen: 6 years 11 months ago


  • Priority:Normal» High
  • Status:New» Feedback Requested

I am also having the same issue in Jaspersoft 6.1 especially when i have included a subreport to the main report. Has this issue been fixed yet?




Indeed, JR does not handle large frames very well. I would say it handles them in an unintuitive way. They work like any other element that is able to stretch, such as text field elements, is just that this is not immediately apparent when the frame is big.
What happens in your case is that you have a tall frame with lots of different sections in it that display conditionally, based on some printWhenExpressions.

The problem is that the frame "overflows with white space", as we call it. There is some white space you left as gaps in between elements or at the bottom of the frame and the engine tries to preserve that space. Cannot simply collapse it or "forget about it".
It does not fit on the current page so that white space "renders" on the next page. But just like other elements, the frame does not have the ability to shrink and become smaller than its declared height in design mode.
So the big frame will render as big as in design mode on the next page, although it only needs to show some little remaining white space from previous page.
This is certainly hard to understand for most users.

But the general idea is that frames should be made small, to prevent such problem with un-collapsible space.
In the latest JR release, we introduced this possibility to make the frame at design time smaller than its content. Something like subreports or table component or crosstabs.
You can make the frame small although inside it has a lot of stuff. The advantage is that with a small design time height, the frame will always grow as much as needed.
One solution would be for you to upgrade JR Lib and modify your template and make the frame small, leaving its current content intact. It will be possible with latest release. It was not possible before.

Another solution is to break the frame in smaller pieces. Instead of using prinWhenExpression at element level to show/hide the different portions of the frame, you split them into separate bands. Note that the detail section of a report can be made of multiple bands, each band having a printWhenExpression. You would still need to put the elements in a frame, because I see you want to have border around the whole thing. But if you go with multiple bands, then for some bands you would only use left and right border for the frame, because top and bottom borders should not be rendered, so that the overall frame does not look cut into pieces.


Maybe the above explanations apply to your report design as well. If you don't think so, then you need to upload here you files so that we can see what the problem is in your case.


  • Assigned:nobody» teodord


Anything new on this one?



This feature is not on lists, which do not compress their white space on the report, nor can you make a frame around a list smaller than the list. It would be a welcomed feature to make a smaller space on the main report for a list, while the actual list layout in the separate list view is still shown expanded.

I tried several approaches to get around this issue with lists but none of them worked well. The only real success was to make all fields in the list 2px tall (since the fields expand when report is run), which allowed me to make the list height about one text line tall (small enough to prevent creation of empty white space on the main report). This was not a satisfactory solution, since it is not practical to edit a report where all field heights are 2px high.