Bug 215231 - Variable totalPage doesn't work on PDF
Summary: Variable totalPage doesn't work on PDF
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: BIRT (show other bugs)
Version: 2.2.1   Edit
Hardware: PC Windows Vista
: P5 normal with 6 votes (vote)
Target Milestone: Future   Edit
Assignee: Gary Xue CLA
QA Contact: Xiaodan Wang CLA
URL:
Whiteboard:
Keywords: plan
Depends on:
Blocks:
 
Reported: 2008-01-14 11:16 EST by Adam Domanski CLA
Modified: 2014-07-16 04:55 EDT (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Domanski CLA 2008-01-14 11:16:25 EST
Build ID: Eclipse 3.3.0 I20070621-1340

Steps To Reproduce:
I've created report with data expanded on 2 pages. I need total pages count in report footer in following form "Page $m of $n", but I cannot choose auto-text "Page $m of $n", because there will be some gaps in output. So I just created html text field with following values: "Page <value-of>pageNumber</value-of> of <value-of>totalPage</value-of>".

I get following wrong results:

on page 1: "Page 1 of 1"
on page 2: "Page 2 of 2"



More information:
To check what is going on, I temporarily added auto-text with total-page and it worked as expected:

on page 1: "2"
on page 2: "2"

My BIRT version ID: 2.2.1.v20070718

I checked source code of BIRT and debug it. I found that code that populates total page count in located in PDFPageLM.resolveTotalPage() method and works only with auto-text.
Comment 1 Wei Yan CLA 2008-03-23 23:21:41 EDT
suggest defer to future release.
Comment 2 Gang Liu CLA 2008-12-22 00:29:12 EST
Currently we support totalPage in autoText item. Need we support totalPage variable in script?
If we need support it in PDF, we should layout twice.
Comment 3 Gary Xue CLA 2008-12-22 13:19:22 EST
Deferring this issue, as the requested feature requires that generation-time scripts have access to render-type information (page number etc). Gang's suggested 2-pass rendering solution will kill performance. 

We should instead focus on improving the usability of autotext element in 2.5. There are several enhancements already logged for that.
Comment 4 Joe Bordes CLA 2011-01-28 18:04:40 EST
Just ran into this problem while trying to show a text block only on the last page of the PDF. Would be nice if a solution was proposed in some way.
Comment 5 Joe Bordes CLA 2011-01-28 18:05:41 EST
This is the forum thread where I expose the problem:
http://www.birt-exchange.org/org/forum/index.php/topic/21423-conditional-visibility-block-on-last-page/
Comment 6 Thomas Zimmermann CLA 2013-08-27 06:09:45 EDT
Just some additional Info.
I am using BIRT 4.2.2.

In my Master Page of a PDF Report I have something like this:

<VIEWTIME-VALUE-OF>"Page" + pageNumber + " of " + totalPage</VIEWTIME-VALUE-OF>

This almost works, but not always. If I have an element with Page Break behaviour of "Before: Always", it works and shows "Page 1 of 2".
But if I don't have this element, every page shows "Page 1 of 1", "Page 2 of 2" as already described.

This may be an appropriate workaround for someone.
Comment 7 Henning von Bargen CLA 2014-07-16 04:55:42 EDT
A 2-pass run would kill performance,
but shouldn't it be possible to do it similar to Oracle Reports?

That is: 

First, do some pre-calculation for the layout objects:

If a container contains a forward-reference like total-number-of-pages, mark this as "do-it-later".
If the container is variable-sized (width and height not fixed), go to the parent container, mark it as "do-it-later" and go on recursively, until a fixed-sized parent container is found.
If a fixed parent is not found, the report should fail with an appropriate error message. 

Rendering pass 1:
Do the normal rendering. But if a container is marked as "do-it-later", just create a placeholder (think of it as an empty rectangle) for it (we know that it is fixed-sized!) and ignore its contents.

Now the total number of pages and so on are known.

Rendering pass 2:
Render only the "do-it-later" layout objects, that is, replace the corresponding placeholder with the actual content.
How this is done depends on the emitter. For PDF, XObjects could be used. For XML-like output formats like Word and HTML, it's just a matter of string search/replace.

The design UI should warn the user if a forward-reference is not directly contained in a fixed-sized grid/table cell.