The following two files attached shows an abnormal and breakage of table rendering under LO 3.4 rc2 Both files were generated by a macro. File 33.odt was generated by LO 3.3.2 and is OK, renders in both LO 3.3 and LO 3.4 File 34.odt was generated under LO3.4-RC2 and is not OK, with black thick lines polluting the file. Under LO3.4 the lines are seen from left to right and under LO3.3 the lines are in-between the columns.
Created attachment 47251 [details] File generated by macro in LO 3.3
Created attachment 47252 [details] File generated by macro in LO 3.4, shows thick lines
[Reproducible] with "LibreOffice 3.4.0RC2 – WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:12)]" and reporter's sample documents. Only 1 Bug/Report, so here we should handle the table rendering problem. When I copy paste compete table from 34.odt to an other empty LibO WRITER text document, it loks like in 34.odt. When I paste it to an empty OOo 3.1.1 document, it looks like a normal table with thick vertical borders between the cells. The new document will not look different from OOo 3.1.1 when I open it with LibO 3.4. Currently we here have a problem "LibO3.4 has more problems with invalid ODF table code than LibO 3.3", so this does not seem to be a blocker until we do not have information that more users might suffer from this problem. @Olivier Hallot Can you please file a second report for the problem that Macro table result in LibO3.4 is different from the one in LibO3.3? I think that is the more serious one, and I believe the macro would be useful! @Cédric Please feel free to reassign if it's not your area!
Created attachment 47258 [details] file with macro This is a file with a simplified macro in its Standard library. The macro adds a table in the header and the footer of all used page styles. It looks like the issue is intermittent. If you run the macro several times, the issue appears and vanishes, randomly AFAIK. The issue appears more often if you run the macro step by step. The original macro was packed as an extension in system area, with access by menus and has dialogs. The original macro does present the issue consistently.
(In reply to comment #3) (snip) > When I paste it to an empty OOo 3.1.1 > document, it looks like a normal table with thick vertical borders between the > cells. Yes: If you look at the table properties / borders you will see weird line thickness and dashes in cell inner borders.
Created attachment 47712 [details] Table properties indicating abnormal borders Table properties screen indicating abnormal borders: The red lines indicates where it is wrong. Borders are to be invisible. Border thickness of 9pt is really wrong. Middle cell border not to exist Border style messed.
RC2 is bit by bit identical with release version, so separate items in the version picker are useless. Changes have been discussed with Michael Meeks.
in the 3.3 generated doc: fo:padding="0cm" fo:border="none" in the 3.4 generated doc: fo:border-left="215494.75pt dotted #000000" i.e. 7602cm, which seems quite whacky indeed. Looks to me that there must be some initial problem under 3.4 with the generation of the document Can we take it that "run the macro, get tables which work" is a sufficient victory condition. The real bug looks like it appears in generation of the document. i.e. just write-off the rendering of the crazy borders in the existing document, and not create them
hmm, TableBorder is a struct that contains LineBorder. Casting it to a LineBorder2 isn't going to give a valid LineBorder. Would need (presumably) to invent a TableBorder2 to transport LineBorder2 collections around.
Created attachment 49617 [details] Seeing as its a LineBorder member in TableBorder, we need it like so I reckon
caolanm->dtardon: You poked around this area as well. Agree/Disagree ?
committed as http://cgit.freedesktop.org/libreoffice/writer/commit/?id=a7058d28e5d36778b9f16308632ffb4c9608479c AFAICT if we want BorderLine2's here we need a TableBorder2 to transport them around, and would need hackery like http://cgit.freedesktop.org/libreoffice/libs-core/commit/?id=0d209ac289dd5c79da6950b4c01b0cec9b7fbe6d at a TableBorder/TableBorder2 level to handle old-style and new-style ones.
(In reply to comment #11) > caolanm->dtardon: You poked around this area as well. Agree/Disagree ? Agree.
Is this related to Bug 38542 - FORMATTING TABLE double borders incompatibility with old LibO / OOo Versions
fix here doesn't fix that, though it is clearly also a table border issue, so related in that sense.