Home » Archived » BIRT » Pagination, Run Task, Render Task, and Writing to Disk(Do I really need to do all this just to get pagination working??)
| Pagination, Run Task, Render Task, and Writing to Disk [message #1012586] |
Thu, 21 February 2013 15:53  |
Eclipse User |
|
|
|
We have a generic, deployed ReportGenerator app which executes the RunAndRender task on report design files and XML input data to generate reports. This has been used for a long time now for a wide range of reports. All good.
I have a requirement in the latest report design to generate paginated numbering within a subsection of the document (so managed with report vars and onPageEnd script event). These don't display when export from Report Designer directly to PDF, as expected, but only when exported to the Web Viewer first; the Run step, followed by export to PDF, the Render step.
Running it through the ReportGenerator app, it also fails to render the pagination data, which seems to be because of the use of RunAndRender single task. Solution as noted in multiple places is to run the separate Run task and Render task.
I can potentially modify the aged ReportGenerator app to perform this 2-step approach. But it seems this will write it to disk, then the Render will read from disk. What is best practise for this to avoid disk writing?
Also, I've seen some mention that if the design and inputs are unchanged between calls then the Run Task will not update the rptDocument as it would be the same. Is this correct and how is this managed?
Thanks
Brad
BIRT 2.6.2 (upgrade path constrained)
|
|
| | | | | | | |
| Re: Pagination, Run Task, Render Task, and Writing to Disk [message #1027996 is a reply to message #1012679] |
Wed, 27 March 2013 13:43  |
| Eclipse User |
|
|
|
We are using the following workaround in our application:
Note: This approach only works since we are not using the WebViewer, instead we developed our own BIRT server (which is not very difficult, by the way).
We have custom Java classes for describing where and how the page numbers should display in the resulting PDF:
* position on the page (a rect)
* justification (left, right or centered)
* font: name, point size, bold, italics
* format string (eg. "Page {0} of {1}"
* resetAtTOCLevel (an Integer)
In the BIRT report, we test if the target format is PDF.
If this is the case:
* We hide the page number layout items
* We write the layout instructions for the PostProcessor as objects into the reportContext.
After the RunAndRenderTask is finished,
the BIRT server checks the reportContext (great feature, by the way!) to see if the PostProcessor should be called.
It then calls the PostProcessor with the layout instruction objects and the PDF file.
The PostProcessor first renames the PDF, then uses an iText Stamper to add page numbering texts and writes the PDF with the original name.
For "grouped" page numbers, the BIRT report can tell the PostProcessor to reset the page number whenever a TOC (outline) entry of level N appears.
This way, we can e.g. create work lists for different departments with one report.
By using a list or table group within BIRT (TOC entries are generated per default),
BIRT then creates a report with pages 1-2 for dept A, page 3 for dept B, pages 4-6 for dept C (as an example).
There are TOC entries for each dept: dept A: Page 1, dept B: page 3, dept C: page 4.
The PostProcessor uses this to create page numbering texts like this:
Page 1: "Dept A, page 1 of 2"
Page 2: "Dept A, page 2 of 2"
Page 3: "Dept B, page 1 of 1"
Page 4: "Dept C, page 1 of 3"
Page 5: "Dept C, page 2 of 3"
Page 6: "Dept C, page 3 of 3"
This is somewhat ugly as BIRT doesn't offer this and we have to re-parse the PDF, but the additional time needed for this is minimal.
The time needed for developing this was not so minimal.
I'd like to see something like this integrated in the BIRT PDF emitter.
If someone is willing to give it a try, I'd talk with my boss to donate the code.
|
|
|
Goto Forum:
Current Time: Sun Mar 16 06:49:24 EDT 2025
Powered by FUDForum. Page generated in 0.03613 seconds |
Home