| Summary: | page breaks on table occur if the table is not visible | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Jason Weathersby <jasonweathersby> | ||||||
| Component: | BIRT | Assignee: | Gang Liu <hustlg> | ||||||
| Status: | RESOLVED WONTFIX | QA Contact: | Xiaoying Gu <bluesoldier> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | andras_szopko, bluesoldier, carola.andersson, Chris_Hernandez, dan.leahu, paragrt, pzaverchand, staticspark, wenfeng.fwd, wyan | ||||||
| Version: | 2.6.1 | ||||||||
| Target Milestone: | 3.7.0 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jason Weathersby
Created attachment 184258 [details]
example report
this is expected that All output format has the same pagination. Is this is not going to be fixed, we need to look at another way to achieve the same thing. Some master page content( like watermarks) should be changeable at render time. >> Some master page content( like watermarks) should be changeable at render time. Is this duplicated as bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=330380 ? No, because parameters are handled at generation time. The master page background image should be changeable at render time. I also do not like that blank pages are generated when using a visibilty expression based on output format. If you do not specify a specific output blank pages are not created. This still seems like a bug to me. reopen to continue discussion. this is expected that All output format has the same pagination. set to won't fix *** Bug 351361 has been marked as a duplicate of this bug. *** Created attachment 199736 [details]
A report showing the effects of visibility problems
I switched from RunAndRenderTaks to using RunTask and RenderTask to enable the use of getPageCount(). This method is however wrong when I have expressions to the Visibility property. Both the method pageCount and the total page shown on the end pdf report has the same erroneous number. See attachments for example on this visibility problem. In Run then render mode, the pagination is executed in run task. As it don't know the final output format, so all elements will be count into the pagination unless it is hidden for all formats. While in the run and render mode, we have know the final output format, only the visible elements joins the pagination. It means the run/render may have different pagination with runAndRender. Why is pagination being done at generate time? Pagination sounds like a view-time/render-time function. Is that the crux of the issue here? And does it affect all Actuate product lines?(Actuate 11, Actuate BIRT and OpenSource BIRT)? are there any recommendations from BIRT developers on how to get around this? We have an issue with generating a dynamic table of contents based on page-numbers and this breaks everything for us. Right now our work around involves taking a report parameter, but it's not ideal and is this recommended? I would like this bug to be re-evaluated. If pagination occurs before Render output has been designated this causes issues. We have many reports using the html text, when it is used the Web will take the entire chunk of html into one page. The rptdocument will also take the chunk into one page as well and then render it into a pdf causing duplicate pages, page numbers and duplication of printed html. Can we move the priority of fixing this issue and change the status from WontFix please. Also vote for re-evaluation of the status, this issue causes around 600 pages to be blank out of 1700 total. |