Community
Participate
Working Groups
Created attachment 198732 [details] TextItemHtml.rptdesign HTML content type text items in a grid have a different indent compared to plain text items, when rendering the report with Word doc emitter. BTW: Why html-content type has an extra cell is explained in Bug 204261.
Created attachment 198733 [details] TextItemHtmlCompare.gif
See the attached image TextItemHtmlCompare.gif for the different indent of the first letter in Word and PDF. Also applies for BIRT versions 2.6 and 2.5.
The indent of inner tables in Word documents seem to have the same problem like the text item in comment 1. Additionally the right side border is missing. Problably because the right side of the inner table moves out of sight. See the following attachments: PDF_vs_DOC.gif (comparison screenshot: Word- versus PDF-output) test_report.zip (contains test_report.rptdesign, preview.pdf, test_report.doc) BTW: The example is not a real subreport (or subtable), it's just a table inside another table.
Created attachment 199504 [details] PDF_vs_DOC.gif: comparison screenshot: Word- versus PDF-output
Created attachment 199505 [details] test_report.zip: test_report.rptdesign, preview.pdf, test_report.doc
I wanted to report a new bug, but it seems that this bug already describes the problem. Nevertheless, I add my description, too: Birt 3.7 (Word): Undesirable margin and truncated content in nested grids if cell padding is 0 If the first cell of a nested grid has the setting "left padding = 0" (or: inherited) then the cell content gets an undesired margin and the cell content is truncated. Before Birt 2.6.2 there was a similar behavior but with the fix of the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=331333 (with Birt 2.6.2) the cell margins were correct. Comparing the generated Word documents using Birt 2.6.2 and Birt 3.7: there is missing cell margin information in the word document ("w:tcMar") if the cell padding is 0. In Birt 3.7 the class AbstractWordXmlWriter contains conditions in the method "writeCellPadding" where margin information for a cell is only written if padding <> 0. I assume that Word uses a default value for the cell margin (e.g. the margin of the parent table: 0,19 cm) if there is no explicit cell margin information. Then the content of the cell (e.g. icon or description text) doesn't have enough space and is truncated. These conditions may cause problems in all components that are "transformed into" nested Word tables. In my case: 1) grid in grid 2) dynamic text in table.
I'm seeing the exact same behavior Gerald was describing in both 3.7.0 and 3.7.1. Anything in my report that is inside a table or a list or a grid is indented slightly when I output it to Word. I don't see the problem when I output to PDF. I noticed the same behavior when I was using BIRT 2.5, but once I upgraded to 2.6.2 the problem went away. Now that I am trying to upgrade again to 3.7.0 or 3.7.1 the problem is back. I did some poking around in the CVS code, and I think Gerald is right about the writeCellPadding method of the AbstractWordXmlWriter class being the problem. That method does not exist in the CVS version tagged BIRT_2_5_2_Release. In the version tagged BIRT_2_6_2_Release, the method is there and it is setting the margin information no matter what the cell padding is. But in the version tagged BIRT_3_7_0_Release, there is a new if condition in the method that prevents the margin information from being written if the cell padding is 0. It looks like if this method is backed up to the 2.6.2 version, it will fix this bug. Is there any chance of this fix making it in the 3.7.2 release?
Please increase the importance for this bug and fix it in 3.7.2! This bug causes BIRT Word output to be unusable!
The original issue mentioned in TextItemHtml.rptdesign has been fixed in 3.7.1 release. We will close this one. The issue in attachment 199505 [details] is different one. Please file a separate bug and we will look into it. Thanks.
I created the new bug 370096 for this.
(In reply to comment #10) > I created the new bug 370096 for this. Thanks, I will mark this bug as fixed. Keep tracking in bug 370096
