| Summary: | [Improve Page Break Management] Invalid pageNumber at repeated group header in PDF output | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Johann Wilfling <wj313> |
| Component: | BIRT | Assignee: | Wei Yan <wyan> |
| Status: | VERIFIED WONTFIX | QA Contact: | mindan xu <mindan.xu> |
| Severity: | normal | ||
| Priority: | P3 | CC: | bluesoldier, hustlg, tp.paterson, wenfeng.fwd, whe, wyan |
| Version: | 2.1.0 | Keywords: | plan |
| Target Milestone: | 2.5.0 RC1 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | Obsolete | ||
|
Description
Johann Wilfling
as we has support the page-number as the auto-text, so can we remove the page-number in the onCreate/onRender time? (The page-number can only be accessed in onPageBreak). (In reply to comment #1) > as we has support the page-number as the auto-text, so can we remove the > page-number in the onCreate/onRender time? (The page-number can only be > accessed in onPageBreak). onPageBreak() is only triggered for when page is break because of a page break setting in the design, correct? page break due to master page size limit will not triggered onPageBreak(), or will it? I agree that we might need to remove the pageNumber from the onCreate() script, because the page number could change depends on the final output format of the report. The pageNumber in the onCreate() script will not be correct for certain output format. on the other hand, in onRender(), the page number should be supported? Can we review this as part of the overall scripting API enhancement? Does this mean we should make a variable of a element in script configurable? For example, when editting script for "OnCreate" method, "pageNumber" is invisible in the help context of "this". And it comes to be visible when editting script for "OnRender"/"OnPageBreak"? suggest to remove the pagenumber property from "this" in onCreate/onPageBreak, and have it at onRender(). I think onPageBreak() can not have the correct page number neither during report creation time, because it only accounts for logical page break, it doesn't account for paper-size trigged new pages. Engine team controls the script Engine decide if they could support this. Suggest to also remove the pageNumber property in OnRender script. Because at render time, the pageNumber is also uncertain. For example, layout engine starts to render a image. First the onRender script is executed, current page number is n. But this image may be put into n+1 page due to the page size limitation. Is it correct that when onRender() is executed, the current page is n? I think it is correct to have the value of this.pageNumber to be n. I think it is ok that some or all of the "this" will be render to page n+1, but if it starts at "n", this.pagenumber can be "n". Table report item is another example that when onRender is triggered, its pagenumber is n, but a table could span from page n to m. Changing on behalf of Renuka suggest to allow pageNumber in onRender but not onCreate and onPrepare events. add the "plan" key word for release planning. defer to RC1 due to resource limitation. The page number is the system defined page variable, it can only be used in the onRender and onPageScript or auto-text element. see #159857 Mark as verified first. |