I'm sure I am overlooking some basic fact about the <break> element here so wanted to post and hopefully get my confusion cleared up. I created the attached sample report that illustrates my problem. It is a LONG detail band that is longer than 1 page and has a break element roughly 20px above where the first page ends. I tried to compile it to see the break in action but I get the error:
net.sf.jasperreports.engine.design.JRValidationException: Report design not valid : <br /> 1. The detail section, the page and column headers and footers and the margins do not fit the page height.<br /> at net.sf.jasperreports.engine.design.JRAbstractCompiler.verifyDesign(JRAbstractCompiler.java:260)<br /> at net.sf.jasperreports.engine.design.JRAbstractCompiler.compileReport(JRAbstractCompiler.java:144)<br /> at net.sf.jasperreports.engine.JasperCompileManager.compileReport(JasperCompileManager.java:220)<br /> at net.sf.jasperreports.engine.JasperCompileManager.compileReport(JasperCompileManager.java:153)<br /> at com.test.ReportRunner.main(ReportRunner.java:21)
Shouldn't I be able to use the break element this way? Detail bands can span multiple pages normally, so wondering how i can design my report 'pages'. I really want to avoid using any work arounds as I really embraced the break element to avoid the usual group header-page workaround.
Attached is a very simple sample report that illustrates my issues. I'm using JasperReports 2.0.2.
[file name=pagebreak_sample-d2602f001bf5cf6ee2fa5b97718ebd5c.jrxml size=1704]http://www.jasperforge.org/components/com_joomlaboard/uploaded/files/pag...
Post Edited by iryzhikov at 06/05/2012 16:56
The break element is not meant to work that way.
What you need to achieve is described in this FAQ here:
You said you don't want to use tricks, but one of the reasons for the report validation to ignore the presence of break elements on large bands is that those breaks could have printWhenExpression that we cannot evaluate at that time. Also, the break element is a recent addition to the engine and it solves some issues, but it was not meant for splitting large bands. At least not for now. The whole engine would have to be refactored to support that and I'm afraid this will not come soon, if ever.
I created an empty document in iReport. I reduced for zero all the sections besides 'details'.Than I added 2 groups: page1group and page2group. For the second group (page2group)I checked the option "Start on a new page".
As there is no condition to start a group, I put nothing. I reduced the "details" section for the minimum.
Just to test if it works I added some static texts to both groups. But I was always limited to drag any of the groups to get it longer. iReport always checked the page (A4 in my case) size and didn't allow me to get it longer. As result - I got everything on the only page, of course. What did I wrong ?
Either I should replace al my static text elements by text field elements (dynamic) and indicate them as streched, and in this case iReport will add a new page if there is not enough space, either there is another solution that I don't know.
I now see what you mean. It appears that iReport does not allow us to enlarge a band after a certain limit was reached. I think this is not good and I'll let Giulio know about it.
You could also post this issue on the iReport forums as I think it is something that needs to be fixed.
Users should be allowed to make bands as large as they want and only in the end a validation should be performed, when the report is actually compiled and run.
If you manually edit the JRXML, you can achieve what we've said in previous messages.
<br /> writer.setPageEmpty(ignore_empty);<br /> document.newPage();<br /> writer.setPageEmpty(ignore_empty);<br /> document.newPage();<br /> document.add(new Paragraph("Hello World"Â«Â»));<br /> document.newPage();<br /> writer.setPageEmpty(ignore_empty);<br /> document.newPage();<br /> </td></tr></tbody></table><br /> By default, to start a new page([document.newPage()] iText checks the value of 'ignore_empty' variable, - true by default). If we set it to false, a new empty page will be created.<br /> I know that it is a little different. Nevertheless it works fine. JasperReports includes iText.jar. Why not use the same technics?<br /> <br /> Post edited by: Javix, at: 2007/12/14 11:18<br>Post edited by: Javix, at: 2007/12/14 11:20
<br /> net.sf.jasperreports.engine.design.JRValidationException: Report design not valid : <br /> 1. The detail section, the page and column headers and footers and the margins do not fit the page height.<br /> at net.sf.jasperreports.engine.design.JRAbstractCompiler.verifyDesign(JRAbstractCompiler.java:260)<br /> at net.sf.jasperreports.engine.design.JRAbstractCompiler.compileReport(JRAbstractCompiler.java:144)<br /> at net.sf.jasperreports.engine.JasperCompileManager.compileReport(JasperCompileManager.java:220)<br /> at net.sf.jasperreports.engine.JasperCompileManager.compileReport(JasperCompileManager.java:153)<br /> </td></tr></tbody></table><br /> So I don't see any solution for the problem. And you, Admin ?
I only suggest you carefully read the validation message and try do something about it. It is in your power to get yourself out of this misery.
If you took the approach of splitting the template in two dummy group headers, why do you still use a huge detail band? The detail band should be empty and with height zero. You put everything in the two group sections you just made.
1. Even in this case I'm still limited in page size(A4).
2. Even if when creating the second group I checked "Start on new page" check box, my second group never starts on the new page. I am asking myself what is that check box for if it does nothing???
3. Event if change the report page height manually in the jrxml file (1600 for ex.), it makes just my page longer but doesn't put a page break that I woulf like to.
Any suggestions, Admin ? Thank you in advance.
What are the odds that there will ever be a <page_break> element or something similar to achieve the multiple pages in the detail band? I am sure that thinking up this idea there are many concerns that I don't consider, but it seems like it would be a very valuable element to have. Most of my reports have been based on 'pages' as well as I am sure a lot of others. Is this on the plate at jasperforge at all?
There is a <break> element available in JR since version 1.3.0. Is just that you cannot use it to make bands that are larger than one page.
Why? Because the break element, just like any other element could be displayed based on a "print when" condition, and at design time we cannot evaluate those conditions, if present.
Another reason is that all band expressions are evaluated only once, so if you display the page number or page-level calculations in a band that stretches 5 pages, these values will not be accurate, as they would correspond to the first page of the range.
If you still think that the report validation should take into account <break> elements that do not have a "printWhenExpression", please log it as a RFE and we'll take care of it in a future release.
If you tried to post a new attachment, it appears it did not make it through.
Note that there was indeed a problem with the band height validations made in iReport and they are going to be fixed in the upcoming iR release.
However, you should be able to manually edit JRXML and achieved the desired effect. Try attach again the manually edited files so that I can tell you what is wrong with them.
If you talk about this RFE here:
then it seems you did not come back with an answer to our question there.
If it is about
then you might consider batch exporting several documents that have different page sizes, like shown in the /demo/samples/batchexport sample provided with the project.
We are now considering adding support for something like JasperBook, which would be a template to group several reports that have different page sizes. But it would only be a simpler way to use subreports or batch export.
I am not sure if you recall, but we exchanged several emails last November concerning my inability to log into the website to post follow up questions and as such I emailed you directly as per your instructions asking at that time for the feasibility of my RFE. There was no response to that email to this point is what I meant by 'no action on it'.
Not withstanding those technical issues, my mentality behind this RFE is the ability to have 1 report be visible in 1 file in your editor, and to have the ability to designate a report design that is clear and logically outlined. Using work-around's is never as preferable as using a straight forward solution and from an architectual perspective a cause for concern.
Don't get me wrong, I think JasperReports is an amazing technology, I am just trying to express ways that it does not seem to meet my needs and hopefully participate in it's evolution and growth.