Word export - print on first page only

I am trying to put footer text on just the first page of a report. When viewing in the web viewer or exporint to PDF this works. But the Word export shows he footer text on multiple pages.
 
I'm using this:
 
for on render of the dynamic text element: if(pageNumber > 1) { this.text = ""; }
 
Any ideas on how to make this really show up only on the first page in Word?

Find more posts tagged with

Comments

JFreeman

What version of BIRT are you using?
What emitter are you using for word output?
Are you generating a .doc or .docx?
What version of Word are you using to open the generated output?
 
Using BIRT 4.4.2 with the default doc/docx emitters and Word 2010, the script setup you have described works successfully for me to prevent a dynamic text element on the master page footer from display text on any page except for page 1.

gavrielkay

I'm using BIRT 4.3.2 and I've tried both the .doc and .docx export from the web viewer. The results are the same for both file types. I'm using Word 2013 to open the documents.

JFreeman

I just tested in 4.3.2 exporting to .doc and .docx using the web viewer and the footer is only displayed on the first page in both Word 2010 and 2013.
 
I've attached the sample report I used for my testing, can you run this report in your environment and let me know the result?

gavrielkay

Sadly I can't send my report definition since it's for work, but basically I've got a huge grid with all sorts of other grids and tables inside it. The layout screen goes way beyond the default page window that the designer tool shows. When viewed by the web viewer, it's one very long scrolling page of output, which is to be expected. And when exported to PDF, the output does respect the actual page numbers and despite the layout being crazy, only the first page of PDF output has the footer text. But on the two Word export formats I get the footer text on each page.
 
I have some other reports that have multiple pages desgined into the report and the Word export half works for those. The problem is if the Word formatting causes the page breaks to fall in different places than the hard coded ones. Anything from the first hard coded page - even if margins etc make it spill over to more than one Word page - will have the footer. Anything after the first defined page won't have the footer.
 
So the PDF export is 'smart' enough to use the final rendered pagination to determine whether to display the footer text, but the Word export appears to use the pagination from the resulting web page which does not necessarily reflect the final Word document pagination at all.
 
I'm not sure if I need a report definition fix or if this is a bug in BIRT. I will try to get the latest BIRT version and see if this is something fixed already.

gavrielkay

I tried this with BIRT 4.4.2 and got the same result. 
 
The determination of whether to display the footer text in the Word export formats appears to be based on the pagination of the HTML format whereas for the PDF export the determination is based on the pagination of the PDF document - which I think is correct behavior.
 
I also tried doing this with a report variable which I would check in the onRender event. I used this logic:
 
if(showFooter) {
 showFooter = false;
} else {
 footer.text = "";
}
 
So the first time the logic is encountered should display the footer and then set it to not display again. This again worked for the PDF but not the Word export. Something is clearly different in processing between the two exports.

JFreeman

You are correct in that there are differences in how the exports work for PDF vs Word as the emitter has to work differently for a proper Word output.
 
What it looks like is happening has to do with the way your report is setup. When your report goes beyond the bounds of the page size, it is having to post process add the additional content onto new pages in the Word output which is what appears to be causing the issue because the pageNumber is set during factory side when the report is running and then when the report is rendered it is having to add the extra pages to fit it into the Word output.
 
When this happens, the pageNumber variable is not updated because it is a factory side variable that is already done processing. This means the content it is recognizing as page 1 content is having to be split onto 2+ pages in Word during rendering but the pageNumber variable will still reflect page 1 for this content as it was set in the factory and will not be updated during rendering.
 
If possible, I believe the best solution is going to be to adjust your reports layout so that it fits within your desired page output size by default. This will mean all the page breaks are occurring naturally during rendering, will align with the page breaks occurring during run on the factory side and additional page breaks will not have to be added during rendering to account for the page size of the report not aligning with the page size of Word.

gavrielkay

There's no way to know ahead of time how much data will fit on each page though. I would like all the tables to flow one after another without random short and long pages through the report...