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 20:53  |
 Brad Mising name
Messages: 21
Registered: September 2009 |
Junior Member |
|
|
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 #1012597 is a reply to message #1012586] |
Thu, 21 February 2013 21:27  |
|
How variable is this section that needs the page numbering? Is it just a table listing? Are the rows fixed in height? Can you set a fixed page break interval to allow you to know how many records will be on a page? If so, you might be able to compute the number of pages that it will take up and display your number based on that, instead of the method of finding the pages in the generation phase and displaying what was found in the presentation phase. Let me know.
Michael
Developer Evangelist, Silanis
|
|
| |
| Re: Pagination, Run Task, Render Task, and Writing to Disk [message #1012612 is a reply to message #1012599] |
Thu, 21 February 2013 22:11 |
|
I don't think there's going to be a good way to do this, without writing to the disk or without writing your own memory based document writer. You could control when the document gets written or when you simply render the report from an existing document.
Please log a bug in the bugzilla for the ability to use separate tasks without writing to disk and put the bug info in here, for future reference.
Michael
Developer Evangelist, Silanis
[Updated on: Fri, 22 February 2013 18:22] Report message to a moderator |
|
| | | | |
| Re: Pagination, Run Task, Render Task, and Writing to Disk [message #1027996 is a reply to message #1012679] |
Wed, 27 March 2013 17:43 |
Henning von Bargen
Messages: 23
Registered: May 2011 |
Junior Member |
|
|
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: Sat Sep 14 01:04:24 GMT 2024
Powered by FUDForum. Page generated in 0.04470 seconds |
] 
Search
Help
Register
Login
Home
