Community
Participate
Working Groups
Created attachment 92802 [details] Report Created with BIRT 2.2.2 I just updated to BIRT 2.2.2. Now PDF Reports created with the Report Designer are shrinked to fit a single page. For my prupose most Reports are created as multipage PDF with dynamic Grids and Tables. Pagination was conotrolled with Page Break propertie Auto, Avoid, Always. Now only always seems to work. I Attach PDF's created with BIRT 2.2.1.1 and BIRT 2.2.2 Franzi
Created attachment 92803 [details] Report created with BIRT 2.2.1.1
Looks like a bug in the pagination handling. Franzi, can you attach the report design XML file?
Need to decide if this bug requires a 2.2.2.1 build if there is no work around.
*** This bug has been marked as a duplicate of bug 223119 ***
wait for the user's design.
Created attachment 92868 [details] Report with PDF Pagination Problems Because my original Report depends on custom data sources and a rather large libary I created a new reported that shows the same problems.
Created attachment 92869 [details] PDF created with BIRT Designer 2.2.2
Created attachment 92870 [details] Report created with Webviewer "Actual Size"
Hello, I added a newly created Report that shows the same problems. My original report depends on a ratehr large libary and a custom DataSet so I did it this way. The Report can be created via the BIRT Deisgner and is shruink to fit the Page. When creating the Report in Webviewer first, I can choose from different Options when exporting to PDF. But none of them show the Behaviour I want. Either the Report is shrunk or cut at the end of the Page. With BIRT 2.2.1.1 the Report would have had Page Breaks as needed to fit the PDF Pages. Thanks a lot Franzi
Can't this be fixed in a stable 2.2.2.1 Release? This is really critical for my application. I can't update to Version 2.2.2 of birt if this is not fixed. And Version 2.2.1 has a bug on crosstabs that's why an update is needed? Thanks a lot Franzi
(In reply to comment #10) > Can't this be fixed in a stable 2.2.2.1 Release? Wei, can we attach a patch viewer to this bugzila that works for 2.2.2?
*** Bug 223311 has been marked as a duplicate of this bug. ***
I've found a suggested temporary patch here: http://www.birt-exchange.com/modules/vbulletin/showthread.php?p=31072 If this work, could someone attach a precompiled patched viewservlets.jar?
*** Bug 223119 has been marked as a duplicate of this bug. ***
Add __pageoverflow URL parameter to support the following PDF overflow modes: 1) __pageoverflow = 0 -------- Auto 2) __pageoverflow = 1 -------- Actual size 3) __pageoverflow = 2 -------- Fit to page
Jerry, 1) __pageoverflow = 0 -------- Auto 2) __pageoverflow = 1 -------- Actual size 3) __pageoverflow = 2 -------- Fit to page What is the behavior of Auto setting? Is it the same as Actual Size or is it the setting the will expand the PDF page to include the overflow contents? What is the default value for the setting? Please also attach a viewer patch for 2.2.2 to this bugzilla?
In BIRT 2.2.1, there are two output modes are supported: - Actual size. The report content will be outputted in actual size. If the report content size is larger than the specified master page size, the report content will truncated. - Fit to page. The report content will be scaling to fit to the master page size. In both modes, the report export will always honor the HTML pagination, so the number of the pages in PDF/PS will be the same as in HTML. The two issue mentioned (content truncation and too small to read in PDF) could be addressed by increasing the master page size. It’s the report developers responsibility to make sure they have set the proper master page size, and the right pagination, so the output in PDF will look good. To address the issue raised in the bug, we plan to add a third option in report export. With this option, the PDF page size will be automatically expanded when the page content exceeds the specified master page size. The report content will be output with actual size. Still no re-pagination is required for PDF export in this mode, and the number of pages in PDF will be the same as in HTML.
Bugzilla feedbacks from many users suggest that there is a need of keeping the page size as master page and do not clip the contents. In short, we shall provide following following options: 1. scale the content to fit the page. 2. expand the PDF page to fit the content (just like HTML page) 3. keep the PDF page size as the master page size, but overflow the content to next PDF page. The first two cases the page count in PDF = page count in HTML. In the 3rd case, there will be more PDF page than HTML pages, but user seems do not think this is an issue. I suggest we use 1. auto = keep the PDF page size as the master page size, but overflow the content to next PDF page. and have this as default. 2. Actual size = expand the PDF page to fit the content (just like HTML page) 3. fit to page = scale the content to fit the page. In theory we can also provide a 4th option of 4. Keep the PDF page size as the master page size, clip the overflow contents. Not sure there is usage of such an option, however. Maybe wait until there is a need for it?
ok. We will add the following options in the BIRT viwer export page: 1. auto = keep the PDF page size as the master page size, but overflow the content to next PDF page. and have this as default. 2. Actual size = expand the PDF page to fit the content (just like HTML page). 3. fit to page = scale the content to fit the page. The "actual size" option is essentially the same as the "auto" option as I suggested in comment #17. Currently (BIRT 2.2.1) the "actual size" option will output the content in actual size, and truncate the content if the content exceeds the page size. When expanding the PDF page size, I suggest not to honor the master page width/height ratio otherwise, there will be a lot of white space because the report content is unlikely to have the same width/height ratio.
(In reply to comment #16) > Jerry, > 1) __pageoverflow = 0 -------- Auto > 2) __pageoverflow = 1 -------- Actual size > 3) __pageoverflow = 2 -------- Fit to page > What is the behavior of Auto setting? Is it the same as Actual Size or is it > the setting the will expand the PDF page to include the overflow contents? > What is the default value for the setting? > Please also attach a viewer patch for 2.2.2 to this bugzilla? For auto setting, it will keep HTML pagination and set PAGE_OVERFLOW to OUTPUT_TO_MULTIPLE_PAGES which will keep the actual size of the content and the page(If the content exceeds the page size, divide it into multiple pages). The default setting is auto. I will make a patch for 2.2.2 later.
Created attachment 96405 [details] Patch for BIRT 2.2.2 build For BIRT 2.2.2 build, we provide this patch to roll back behavior to 2.2.1. Please update the same files in patch zip file.
Fixed it.
It's possible to have a bin patch that don't require to download and recompile the Viewer?
(In reply to comment #21) > Created an attachment (id=96405) [details] > Patch for BIRT 2.2.2 build > > For BIRT 2.2.2 build, we provide this patch to roll back behavior to 2.2.1. > > Please update the same files in patch zip file. > Hi, i'm a little bit confused about functionality. I adopted the delivered patch in my 2.2.2 version. But there is not the same behaviour like in Version 2.2.1. I try to explain: I have the same situation like Franzi described in comment 9. Before applying the patch the situation was as follows: with the URL Parameter __format=pdf the Output was fitted to one page (not readible). When exporting to PDF via Web Viewer with option actual Size the content was truncated. After applying the patch i have the following situation: with the URL Parameter __format=pdf the content is divided over multiple pages in PDF. That's OK. But when i export to PDF via Web Viewer then the content is still truncated after the first PDF page. (this was not the case in 2.2.1) Have i missed something? Andreas
sorry, my mistake, I had don't understood how to apply the patch (into viewservlets.jar)
Applying the patch PDF works better but it seems that the URL __pageoverflow parameter don't work. changing it from 0 to 1 or 2 doesn't change the PDF pagination.
Please update the JSPs in patch. And clear pre-compile JSPs. (In reply to comment #24) > (In reply to comment #21) > > Created an attachment (id=96405) [details] [details] > > Patch for BIRT 2.2.2 build > > > > For BIRT 2.2.2 build, we provide this patch to roll back behavior to 2.2.1. > > > > Please update the same files in patch zip file. > > > Hi, i'm a little bit confused about functionality. > I adopted the delivered patch in my 2.2.2 version. > But there is not the same behaviour like in Version 2.2.1. > I try to explain: > I have the same situation like Franzi described in comment 9. > Before applying the patch the situation was as follows: > with the URL Parameter __format=pdf the Output was fitted to one page (not > readible). > When exporting to PDF via Web Viewer with option actual Size the content was > truncated. > After applying the patch i have the following situation: > with the URL Parameter __format=pdf the content is divided over multiple pages > in PDF. That's OK. > But when i export to PDF via Web Viewer then the content is still truncated > after the first PDF page. (this was not the case in 2.2.1) > Have i missed something? > Andreas
Sorry, in 2.2.2, we don't support "__pageoverflow" URL paraemter. It is supported in 2.3.0 build. (In reply to comment #26) > Applying the patch PDF works better but it seems that the URL __pageoverflow > parameter don't work. > changing it from 0 to 1 or 2 doesn't change the PDF pagination.
Sorry, Please update the JS files in patch. And clear browser cache. (In reply to comment #27) > Please update the JSPs in patch. > And clear pre-compile JSPs. > (In reply to comment #24) > > (In reply to comment #21) > > > Created an attachment (id=96405) [details] [details] [details] > > > Patch for BIRT 2.2.2 build > > > > > > For BIRT 2.2.2 build, we provide this patch to roll back behavior to 2.2.1. > > > > > > Please update the same files in patch zip file. > > > > > Hi, i'm a little bit confused about functionality. > > I adopted the delivered patch in my 2.2.2 version. > > But there is not the same behaviour like in Version 2.2.1. > > I try to explain: > > I have the same situation like Franzi described in comment 9. > > Before applying the patch the situation was as follows: > > with the URL Parameter __format=pdf the Output was fitted to one page (not > > readible). > > When exporting to PDF via Web Viewer with option actual Size the content was > > truncated. > > After applying the patch i have the following situation: > > with the URL Parameter __format=pdf the content is divided over multiple pages > > in PDF. That's OK. > > But when i export to PDF via Web Viewer then the content is still truncated > > after the first PDF page. (this was not the case in 2.2.1) > > Have i missed something? > > Andreas
(In reply to comment #29) > Sorry, Please update the JS files in patch. > And clear browser cache. Hi, i have adopted the JS-Files and cleared my Cache. That's not the reason. Any other hints? Andreas
I don't know if it's caused by the missing __pageoverlow parameter but the report with the patched 2.2.2 doesn't well autofit in all the pages. I've attached the same report output produced by the 2.2.1 and the 2.2.2-patched. I've already cleared the browser cache. As you can see in 2.2.2-patched sometimes page break occours before the end of the page.
Created attachment 96782 [details] Well fitted 2.2.1 report This report shows how 2.2.1 could auto-fit tables with a good page break
Created attachment 96786 [details] Bad fitted patched 2.2.2 report Here you can see how the patched 2.2.2 sometimes doesn't fill pages
(In reply to comment #30) > (In reply to comment #29) > > Sorry, Please update the JS files in patch. > > And clear browser cache. > Hi, > i have adopted the JS-Files and cleared my Cache. > That's not the reason. > Any other hints? > Andreas Hi Andreas, You are right. There is an issue when render document as PDF. Please check the new patch for 2.2.2 build. Thanks.
Created attachment 96814 [details] Patch 20080421 for BIRT 2.2.2
(In reply to comment #35) > Created an attachment (id=96814) [details] > Patch 20080421 for BIRT 2.2.2 > Hi Jerry, the only difference between the two patches is the ReportEngineService.class file. Because i recompiled using the source files i see no difference between the patches. Am i wrong? Andreas
Created attachment 96951 [details] Patch 20080422 for BIRT 2.2.2 build Please try this one. I also included the latest source code.
Created attachment 96981 [details] Fit sample with 20080422 patch Tried with the latest 20080422 patch but it doesn't change anything. I attach another sample report where you can see how page break change in every page. Hoping it could help.
(In reply to comment #38) > Created an attachment (id=96981) [details] > Fit sample with 20080422 patch > Tried with the latest 20080422 patch but it doesn't change anything. I attach > another sample report where you can see how page break change in every page. > Hoping it could help. Hi Simone, This patch doesn't focus on your issue. I guess your issue is due to engine PDF output mechanisms changes. For this case, we will treat HTML pagination as false and engine will calculate the page break. So maybe PDF output is different between these two milestones. Engine doesn't ensure this output consistent in every milestone. But from 2.3.0 RC0, engine has introduced "PAGE_OVERFLOW" option and it will focus on this case. But in 2.2.2, we don't support it. Thanks.
*** Bug 228647 has been marked as a duplicate of this bug. ***
(In reply to comment #37) > Created an attachment (id=96951) [details] > Patch 20080422 for BIRT 2.2.2 build > > Please try this one. I also included the latest source code. > Hi Jerry, Many thanks, that does the trick! Andreas
*** Bug 233624 has been marked as a duplicate of this bug. ***
*** Bug 238341 has been marked as a duplicate of this bug. ***
