| Category: | Feature request |
Priority: | Normal |
Status: | Acknowledged |
| Project: | Severity: | Minor |
Resolution: | Open |
|
| Component: | Reproducibility: | Not Attempted |
Assigned to: |
We are encountering the situation more and more frequently that we need to be able to print more column headers that can be fitted on A4 format. It would be great if column headers could support spanning multiple pages. So instead of not printing the columns which are outside the page width the remaining columns are printed on the next page, just as rows do. Basically a similar approach as Excel has.
The cross tab report already supports this kind of multi-page spanning, but it would be great if normal headers could do this as well. This would make it possible to print tables with many columns still on A4 format.
10 Comments:
Hi,
What should happen with columns that are cut in the middle by the right page margin?
Should they appear on both pages, like being cut with a scissors?
Or should we move the whole column to next page?
What if columns do not aligh with other content? Would we have a jagged edge at the right side of the first page and at the left side of the next page (like a puzzle)?
Thanks,
Teodor
Hi Teodor,
cutting the columns like a scissor would definitely not be a good option for us, since this would make the report unreadable. The whole column should move to the next page. If I am not mistaken, JasperReports already takes this approach, if the column only fits on the page partly, it is not printed at all right? My proposal would be the print it on the next page.
What other content are you thinking about? A subreport? I would assume the same approach can be taken there if the subreport also has a columnheader: all subreport column headers which don't fit completely on this page are moved to the next. I think it should be up to the designer of the report to make sure that the "fit columns on next page" behaviour is applicable for his report.
kind regards,
Christiaan
Hi,
I think I was not very clear when I asked about cutting.
In case of documents made of only simple columns, it is easy.
But what about tables with several levels of column header grouping?
Let's say we have a column header spanning 3 columns. In case the page cut occurs somewhere in between these 3 columns, what should happen with the wrapping column header? Should it be cut?
Or should all 3 columns move to the next page so that their common header stay in one piece?
Note that in a report template such as this, there is no necessarily a concept of column, unless you are using the new table component, added in JR 3.7.2.
I suggest you try the new table component, because this might actually be a feature of the table component after all.
Let me know what you think.
Thank you,
Teodor
I will definitely check out the new table components and see if we can migrate our existing reports to it.
Since the existing reports have no notion of the concept column, I would like to suggest to make the rule as simple as possible. If the field does not fit entirely on the current page, it will be moved the next page. So this is independent of fields in "parent" grouping or other fields in the same band. This would already help us a lot.
thanks,
Christiaan
"But what about tables with several levels of column header grouping?
Let's say we have a column header spanning 3 columns. In case the page cut occurs somewhere in between these 3 columns, what should happen with the wrapping column header? Should it be cut?"
In this case, maybe the columns of the header that fit in the page should be printed there and the others would be printed in another page. About the wrapping column header, it would be cut.
If we did something like:
"Or should all 3 columns move to the next page so that their common header stay in one piece?"
there's always a risk that the header's columns don't fit in the fresh new page, and then we would be forced to use the first approach.
A question: when should "complementary" pages be printed? 1) just after their "left" pages? 2) or should they be printed after all "left" pages were printed. In this case, could anything be done to help the user to join the pieces together?
At an implementation point of view, maybe (1) is the best option.
My preference would be option 1), so after their "left" pages
This issue is almost 2 years old and many users seem to like it. It seems like a normal reporting requirement, many of our users ask for it. When can we expect an implementation of it? What can we do to speed things up?
I would really need this functionality,
and my preference would also be (1). This would help us a lot.