Bugzilla – Full Text Bug Listing
| Summary: | [Improve Page Break Management] Multiple autotexts cause unwanted indentation in PDF | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Jan Doerrenhaus <jan.doerrenhaus> |
| Component: | BIRT | Assignee: | Yu Chen <yChen> |
| Status: | VERIFIED FIXED | QA Contact: | Xiaodan Wang <xwang> |
| Severity: | normal | ||
| Priority: | P3 | CC: | bluesoldier, wenfeng.fwd, wyan, xwang |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | 2.6.0 RC2 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | Autoed,G | ||
| Bug Depends on: | |||
| Bug Blocks: | 236190 | ||
|
Description
Jan Doerrenhaus
Before PDF layout is complete, we are not able to get the total page number. So we use a template, whose width is 4 em, and assume the total page number will never exceed that width. When the PDF layout is finished, we will fill the template with the total page number. So, in this case, when the cell is set to right text alignment, it is the template which is actually right aligned. However, 4em width is too large for the total page number, that causes ~1 inch gap. I see. So is there any way to fix this? One possible way to resolve this problem is: Every page has an independent template. The template contains all the auto texts in that page. when the whole report layout is finished, we layout all the templates for each page. We need more time to implement the feature. (In reply to comment #3) > One possible way to resolve this problem is: > Every page has an independent template. The template contains all the auto > texts in that page. when the whole report layout is finished, we layout all the > templates for each page. > We need more time to implement the feature. What is the performance impact to this alg? Is there a way to let report designer to specify the template size? while it is default to 4em, it can be reduced to remove the gap? The report designer can specify the template size by adjusting the dimension of the auto text item. If the report designer can guess the total page number in advance, that will help to reduce the gap. (In reply to comment #5) > The report designer can specify the template size by adjusting the dimension of > the auto text item. If the report designer can guess the total page number in > advance, that will help to reduce the gap. Is the total number right adjusted in the allocated space? If so, there should be no gap between the page border and the number, correct? Yes. But in most cases, the report designer may not be able to know the total page number at design time. (In reply to comment #7) > Yes. > But in most cases, the report designer may not be able to know the total page > number at design time. If it is right adjusted, there should be no gap between the number and the border regardless how many page there are, correct? There could be gap like "page N/ totalpagenum" correct? If so, maybe we can have a grid right adjusted, but totalpagenum in the grid cell left adjusted? (In reply to comment #8) > If it is right adjusted, there should be no gap between the number and the > border regardless how many page there are, correct? > There could be gap like "page N/ totalpagenum" correct? Sorry, I misunderstand comment #6. Yes. We can make the totalpagenum in the template right-aligned to avoid the gap between totalpagenum and the right border, but there will be a gap before totalpagenum. > If so, maybe we can have a grid right adjusted, but totalpagenum in the grid > cell left adjusted? Currently, the template is right-aligned, and the totalpagenum in the template is left-aligned. It is quite alike your suggested solution. Because the template width is larger than the width of the text area containing totalpagenum, the gap is still here. If the designer specifies the AutoText item width, the template width equals the AutoText width. Otherwise, it uses 4em by default. The width of the totalpagenum text is calculated in layout time. So the closer the two "width" are, the smaller gap we will get. We fixed the auto text alignment issue. Now, when the user align the total page to right, the text can be aligned properly, and there may be margin before the total page text; Also, if the user align the total page to left. there may be margin after the total page text. I think the result is acceptable. please try our new build. To remove the margin completely, 2 pass layout is needed. which will bring performance impact. (In reply to comment #10) > To remove the margin completely, 2 pass layout is needed. which will bring > performance impact. Which margin is this one? What is the reason it needs to pass layout? Verified in build (2.3.1.v20080903-0630). I was wondering. The main problem is actually, that we have boxes for each element. |Page|1|of| 1| What if we had just one element? What if there were an element where you could enter your own text, which would then replace the first occurrance with a predefined sign, say, an asterisk, with the current page and the second occurrance with the total page count? | Page 1 of 1| You could still do the thing with leaving 4em space for the total page count, but the margin would be in front of or behind the entire page number display, not in front of or behind single elements of it. The key problem is that the total page number can only be got after the whole report is finished layout. Once we get the number, we are able to calculate the auto text length. So no matter we place all the auto texts in one element or distribute them in several elements, to remove the margin completely, we must do 2 stage layout. 1. layout the page body content to retrieve the total page number. 2. layout the page headers/footers which contain total page info. Currently, PDF emitter outputs PDF file page by page. Then we must cache all the page bodies to wait the associate headers/footers are finished layout. When a report is huge, this is not acceptable. > The key problem is that the total page number can only be got after the whole
> report is finished layout. Once we get the number, we are able to calculate the
> auto text length.
I understand that. My point is:
If we have "Page", "<current page>", "of" and "<total page count>" in separate elements, there will always be a gap either between "of" and the total page count, or after the entire thing.
If all of those 4 parts would be combined in one element, using right alignment, the gap would be before the entire text, like " Page 1 of 1" instead of "Page 1 of 1"
(In reply to comment #14) > The key problem is that the total page number can only be got after the whole > report is finished layout. Once we get the number, we are able to calculate the > auto text length. > So no matter we place all the auto texts in one element or distribute them in > several elements, to remove the margin completely, we must do 2 stage layout. > 1. layout the page body content to retrieve the total page number. > 2. layout the page headers/footers which contain total page info. > Currently, PDF emitter outputs PDF file page by page. Then we must cache all > the page bodies to wait the associate headers/footers are finished layout. > When a report is huge, this is not acceptable. Is there a native PDF "page N of T" control that the emitter can leverage, so that the total page number is calculated by the PDF reader and not by BIRT engine? Also, at the end of the PDF output before writing the total page count to the template, can we adjust the width of the template? defer to 2.5.1 to resolve with the support page variable in runAndRender task. defer to 2.6.0. For run task and render task execution flow, is there a way to display "page N of M" as one element to remove the gaps already with 2.5.2+? If so, we have a solution for run then render deployment scenrio. For run task and render task execution flow, if the user specifies IPDFRenderOption.RESERVE_DOCUMENT_PAGE_NUMBERS to ture, we will use the total page number stored in report document in render task. In this case, we can avoid using pdf template and the gaps can be removed. Fixed. The default value of IPDFRenderOption.RESERVE_DOCUMENT_PAGE_NUMBERS is changed to true. We did this change because for fixed layout, the page number is always consistent with that in report document. If the user only wants to export a part of the whole report, since the user knows from which page he selects to start the export, we need not to recount the total exported page numbers. And for auto layout, this change may cause wrong page number/total page. But auto layout is not the default layout preference. We think it is acceptable to keep the document page number in auto layout. But in RunAndRenderTask, since we do not have the total page number in advance, the gap can not be avoid. Verified in build (2.6.0.v20100525-0630). |