Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 331541 - page breaks on table occur if the table is not visible
Summary: page breaks on table occur if the table is not visible
Status: RESOLVED WONTFIX
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: BIRT (show other bugs)
Version: 2.6.1   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 3.7.0   Edit
Assignee: Gang Liu CLA
QA Contact: Xiaoying Gu CLA
URL:
Whiteboard:
Keywords:
: 351361 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-12-01 09:02 EST by Jason Weathersby CLA
Modified: 2017-07-07 09:43 EDT (History)
10 users (show)

See Also:


Attachments
example report (35.87 KB, application/octet-stream)
2010-12-01 09:03 EST, Jason Weathersby CLA
no flags Details
A report showing the effects of visibility problems (73.24 KB, text/plain)
2011-07-15 06:28 EDT, Aca Andersson CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jason Weathersby CLA 2010-12-01 09:02:45 EST
see attached report and look at the visibility expression for both tables.
Comment 1 Jason Weathersby CLA 2010-12-01 09:03:17 EST
Created attachment 184258 [details]
example report
Comment 2 Xiaoying Gu CLA 2010-12-05 22:10:20 EST
this is expected that All output format has the same pagination.
Comment 3 Jason Weathersby CLA 2010-12-06 10:10:16 EST
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.
Comment 4 Xiaoying Gu CLA 2010-12-07 04:27:35 EST
>> 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 ?
Comment 5 Jason Weathersby CLA 2010-12-07 10:01:56 EST
No, because parameters are handled at generation time.  The master page background image should be changeable at render time.
Comment 6 Jason Weathersby CLA 2010-12-07 10:06:36 EST
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.
Comment 7 Wenfeng Li CLA 2010-12-10 19:22:03 EST
reopen to continue discussion.
Comment 8 Gang Liu CLA 2011-05-16 05:02:19 EDT
this is expected that All output format has the same pagination.
set to won't fix
Comment 9 Xiaoying Gu CLA 2011-07-06 23:05:24 EDT
*** Bug 351361 has been marked as a duplicate of this bug. ***
Comment 10 Aca Andersson CLA 2011-07-15 06:28:26 EDT
Created attachment 199736 [details]
A report showing the effects of visibility problems
Comment 11 Aca Andersson CLA 2011-07-15 06:32:36 EDT
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.
Comment 12 Wei Yan CLA 2011-07-15 18:03:36 EDT
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.
Comment 13 Parag CLA 2011-12-09 10:00:13 EST
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)?
Comment 14 Chris Hernandez CLA 2012-08-17 09:18:46 EDT
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?
Comment 15 Cullen Bond CLA 2016-06-09 12:58:37 EDT
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.
Comment 16 nlight dev CLA 2017-07-07 09:43:59 EDT
Also vote for re-evaluation of the status, this issue causes around 600 pages to be blank out of 1700 total.