[#5010] - Band Element splitType = "Prevent" introduces blank pages

Category:
Bug report
Priority:
Urgent
Status:
Confirmed
Project: Severity:
Critical
Resolution:
Open
Component: Reproducibility:
Always
Assigned to:
31

<p>Band Element splitType = &quot;Prevent&quot; introduces blank page.</p>
<p>When a detail row doesn&#39;t fit one page, Jasper Report generates a blank page immediately before displaying the content for the long row.</p>
<p>I have already mentioned the root cause of the problem in issue 4975. I am repeating it here below:</p>
<p>The behavior of Jasper is such that (when splitType=true for a band) if an element or row is going to flow into the next page, it prints it on the next page instead of the same page. This is normal behavior if the row or element is not the first element of the dataset. However, this creates a problem if the element or row that is going to overflow is the first element of the dataset or the first element of a group.</p>
<p>When the first element or row of the dataset or the group is too huge to fit in a single page, jasper leaves the current page and prints it on the next page creating a blank page (on the first page of the report or first page of the group respectively)</p>

dgonsalves's picture
Joined: Nov 15 2010 - 12:10am
Last seen: 6 years 10 months ago

19 Comments:

#1

Hi,

Thank you for posting this separately.
You probably agree now this has nothing to do with the keepTogether group feature, as you don't have any group in your attached sample.

Currently, the engine does not verify if the page is already a new page, when preventing the band from splitting.
This is not a trivial issue to solve and for now I can only acknowledge the issue.

Thanks,
Teodor

#2

Hi,

Thanks for acknowledging this.

As I have already mentioned, this seems to be a generic issue when Jasper trys to prevent anything from splitting.

I am attaching two more examples which might be useful in analyzing the issue.

Two jrxmls (splitTypeIssueSecondPage and splitTypeIssueWithGroup)and one common datasource which can be used for both in csv format (sampledatasetforjasper.csv).

1) In the First example 'splitTypeIssueSecondPage.jrxml' the blank page is introduced even on the second page. This is because the overflowing element is the first element on the second page.

2) In the second example 'splitTypeIssueWithGroup.jrxml' again a blank page is introduced on the second page. In this case, it is because we have created a group with the attribute 'isStartNewPage = true'. So, the second group which is going to be printed on the new page, Jasper finds that it is going to overflow, then it leaves the current page and goes to the next page. Thus a blank page is again created on the second page.

After seeing all these scenarios, I feel the actual ideal behaviour of Jasper should be as follows:

I am assuming what you have already mentioned regarding verifying that the page is a new page is the same as what I am saying below. Anyways I am saying it just incase it is something different.

- When a report has been configured to prevent a band or group from splitting, if an over-flowing element is encountered, Jasper should first check if there is an existing element or group on the current Page.

- Only if there is already an existing element or group on the current page, it should leave the existing page and print on the next page.

- If there is no existing element or group on the current page, it should print on the same page.

I hope this helps:)

I understand if this is a complex issue to solve quickly but, its my request to please take this on priority. Currently my application is creating a report of hundreds of pages and because of this issue it has become unusable.

Many thanks in advance.

#3

Hi Teodord,

Can you please provide any update on this issue or an approximate target date for this fix.

Our reporting application is in an un-usable state for more than a month since this defect was identified.

Many thanks and Regards

#4

Hello,

I would really appreciate some reply on this.

I tried the latest release and the issue still exists.

Thanks and Regards

#5

Hi,

Can someone please update on this issue?

Thanks,
Dominic

#6

Hello,
We apologize because we opened a call related duplicate 0005746
to this same question.
I'm currently in version 4.7.0 and still occurs.
Some suggestion for contouring?

Thanks,
Alan S

#7

Hi Teodord,

Any news about the problem?
I'm trying the same problem in version 4.7.

Thanks,
Fernanda

#8

The problem also existed in 3.5.1 and up,
would be nice to get it finally fixed.

Reports don't look nice with blank pages inside

#9

Hi,

I also stumbled over this bug, and as it appeared in a critical application, I tried to find a quick fix that didn't involve changing the content structure of the report. With a bit of toying around and lots of debugging in eclipse, I came up with a small change in JRVerticalFiller that seems to cure the problem for me. What I did is basically:
- Add a private integer property in JRVerticalFiller that carries the current detail band number
- In fillDetail im incrementing this detail band number after each iteration over the detail bands
- After the loop in fillDetail I'm substracting the band count from the band number again (don't know if this is necessary)
- In fillColumnBand in the check for willOverflow I'm only calling fillColumnBreak if both isSplitPrevent() returns true and the detail band number is greater than zero

I'm not really familiar with the inner workings of the jasperreport engine, so I'm pretty sure there are side effects outside my simple scenarios where the change might break things completely and utterly, but it works for me and for dgonsalves' exmaples, so perhaps it can be a starting point for somebody else.

Im attaching a diff against net/sf/jasperreports/engine/fill/JRVerticalFiller.java from version 4.6.0.

AttachmentSize
jrverticalfiller.diff952 bytes
#10
  • Status:Acknowledged» Confirmed
#11

Hi.
Here is another possible patch for this bug.
We found this fix after many hours debugging in eclipse too.

Although we didn't checked for any possible regressions we think it deserves reviewing by the core team.

AttachmentSize
fix-blank-page.diff692 bytes
#12

Hi lucianc.

We're encountering the same issues in our reports. Do you have any updates on an official fix?

Thanks
FF

#13

Awesome! This saved my day, thanks a lot for posting the fix!

#14

The way the tag Band Element works was impressive. I think this tag helps o deal with blank spaces better than ever and it enables the developers to have better alignments in the pages. Thanks for sharing the documents on various tags for Band Element.
http://www.poweredwebsite.com/

#15

Hi, I can report the same issue. Using 5.6.0 Version.

#16

Does anyone know if the solutions by fangebault or bitpoet are going to be added to the project? I'm using 5.6.0 and they are not there.

The only other option as far as I can tell, is to checkout the project, change the JRVerticalFiller class manually, as well as the JRFiller.createFiller() method ... compile and use. I don't see any way to, for example, extend the JRFiller class and only implement the createFiller() method.

But I really don't want to maintain a modified Jasper library in my project. Is there an easier/better way to this?

#17

It's awful bug. When you have many rows with big height document become to long and with a lot of empty space, because each big row transferred to the next page, and only after that is splitted.
When it will be fixed? 5 years open - JasperSoft ignore us?

#18
  • Severity:Block» Critical

I also encountered this awful bug! Is there any news???
<dependency>
<groupId>net.sf.jasperreports</groupId>
<artifactId>jasperreports</artifactId>
<version>6.2.0</version>
</dependency>

#19

The problem has not been fixed yet!

Feedback