Created attachment 48258 [details] 180% screenshot of table rules in 3.3.2 I have a document with hundreds of tables. I designed the table rules with the corporate style. I've attached a screenshot of one of the tables, before and after 3.3.4. When I loaded the file into LibreOffice 3.3.4, the table rules exploded, as shown in the second attachment. (Both attachments are taken with the document at 180%.) Here's how the upper-left corner cell is defined in the odt/content.xml file: style:border-line-width-left="0.0139in 0.0139in 0.0139in" style:border-line-width-top="0.0139in 0.0139in 0.0139in" fo:padding="0.0201in" fo:border-left="0.0417in double #0000ff" fo:border-right="none" fo:border-top="0.0417in double #0000ff" fo:border-bottom="0.0007in solid #0000ff" Here's how is looks in 3.3.4: style:border-line-width-left="0.0417in 0.0417in 0.0417in" style:border-line-width-top="0.0417in 0.0417in 0.0417in" fo:padding="0.0201in" fo:border-left="3pt double #0000ff" fo:border-right="none" fo:border-top="3pt double #0000ff" fo:border-bottom="0.05pt solid #0000ff" As you can see, the border-line-width-left and top are getting tripled! (B.T.W. 0.0139in = 1pt; 0.0417in = 3pt)
Created attachment 48259 [details] 180% screenshot of table rules in 3.3.4
Yo, anyone home?
Created attachment 48504 [details] table with 3pt double rules that don't display properly in 3.4
More on this one. LibreOffice 3.3.3 and 3.4 display the same table rules radically differently for the same file (attached). 3.3.3 draws the lines correctly. 3.4 draws the lines way too fat, which obscures part of the content.
Still a problem in 3.4.2rc1
P.S. The tables were created in OpenOffice, not Microsoft, so it's a problem with changing OO versions, not conversion from Microsoft.
[Reproducible] with "LibreOffice 3.4.1 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:103)]". In master situation becomes even worse! Situation is a little confusing because there seem to be also bugs in older versions ( see "Bug 39227 - TABLES border formatting preserved" comment 6). But facts are: a) Double borders are shown different in LibO 3.3.3 (OOo) ans LibO 3.4 aa) white space between lines and inner lines will be shown too thick b) Saving with LibO 3.4 and Reopening with LibO 3.3.3 does not heal problems from 3.4, Tables will be destroyed, look even worse than looked with 3.4 (with thin single border) and can no longer be used in 3.3.3 without intensive rework. For more details please see screenshots from my Testkit. This problem makes 3.4 unusable for all users using tables with double lines. Dataloss problem, so CRITICAL @Steve Kelem: Version modified due to <http://wiki.documentfoundation.org/BugReport>? @Cédric: Please feel free to reassign if it’s not your area
Created attachment 49327 [details] Test kit, see Comment 7
It causes data loss. It is relatively common thing. So I increase the priority.
Cedric has vacation next few weeks. Lubos, any chance that you could look at it?
.
Is this related to Bug 37693 - Abnormal Table Rendering ?
No, bug 37693 has to do with rendering tables whose borders were generated in xml, something about incompatible parameters. This bug has to do with tables created in OpenOffice prior to 3.4 being rendered improperly in 3.4.
Has anyone signed on to this bug?
(In reply to comment #13) > No, bug 37693 has to do with rendering tables whose borders were generated in > xml, something about incompatible parameters. > > This bug has to do with tables created in OpenOffice prior to 3.4 being > rendered improperly in 3.4. Abnormal table rendering you can also see in new documents created with LO 3.4.3.
Glad that someone filed this bug before. This bug makes older files nearly unusable.
Created attachment 55271 [details] doc viewed in LO ver 3.3
Created attachment 55272 [details] doc viewed in LO ver 3.4 & greater
Created attachment 55448 [details] document containing table with single line borders It's not just double borders that are affected. I have many documents containing tables with single minimal width (0.05pt) borders that no longer render correctly. A stripped down example is attached. In OOo 3.3.0 and LO 3.3.2 this renders correctly, with borders around all cells (see first screenshot). In LO 3.4.x and LO 3.5.0, most of the borders are missing (see second screenshot). For me, this makes LO completely unusable.
Created attachment 55449 [details] document viewed in OOo 3.3.0
Created attachment 55450 [details] document viewed in LO 3.5.0 beta
(In reply to comment #19) > Created attachment 55448 [details] > document containing table with single line borders > > It's not just double borders that are affected. I have many documents > containing tables with single minimal width (0.05pt) borders that no longer > render correctly. A stripped down example is attached. In OOo 3.3.0 and LO > 3.3.2 this renders correctly, with borders around all cells (see first > screenshot). In LO 3.4.x and LO 3.5.0, most of the borders are missing (see > second screenshot). > > For me, this makes LO completely unusable. Another issue, viewing hidden cell borders has changed also.Using Lo 3.5 RC1 and the LO 3.4.x series. These two features seem to control the visibility of cell borders, the behavior has been changed. 1. menu > view > text boundaries 2. menu > table > table boundaries AFAIKT, 'table boundaries' is not working (does not show or hide cell boundaries) on my docs. Seems like someone has been busy changing table features, without an eye towards backward compatibility.
Created attachment 56150 [details] put "double" cell borders on a diet in the first attachment, the cell borders are of type "double", and the ODF import filter effectively triples their width. patch should fix that.
Created attachment 56151 [details] prevents wrong overriding of the style:border-line-width attributes another problem when importing the first attachment: the width from fo:border overrides widths in style:border-line-width, which are more specific for "double" style borders and thus should be preferred.
additional note about the second patch: i'd really like to detect the fact that we have read the other attribute by adding some booleans in the import filter instead of checking that the width is not zero, but that seems to require too much refactoring to do it now... so this heuristic will have to do. now, the document inside the zip file attached in comment#8 looks much better, which is mostly good but in one case not: the 6.55 pt double border has attributes like this: style:border-line-width="0.002cm 0.088cm 0.141cm" but it is displayed with 3 equal width inside, gap, outside lines. looking at it in OOo 3.3 it is rather ugly, but still the fact that it looks prettier in LO 3.4 is a regression :)
Created attachment 56161 [details] add a custom double border style this patch seems to fix the problem described in previous comment. i'm really not sure if this is the right approach, apparently everything that doesn't match one of the pre-defined styles is deliberately ignored; is there a reason for that? anyway, saving the document again, i get the same attribute values, and the rendering looks rather more like in older versions, except not the same: the thin inner lines are painted too long, also outside the table cell borders.
Michael, thanks for the patches. they are OK for me. I just pushed them to master and cherry-picked to -3-5. 2 more reviews to get them into -3-5-0.
Have these patches also fixed the problem with minimal width single borders (see comment 19)? If not, I will open a new bug for this.
the bugdoc attached in comment #19 mainly has the problem that the border line is only 1 twip wide, and is not painted for some reason. this problem is handled with bug 42750.
OK, thanks Michael, that saves me a job. Can I suggest changing the title of bug 42750 to make it more obvious what it is now tracking.
*** Bug 42570 has been marked as a duplicate of this bug. ***
fixed in libreoffice-3-5: http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=7cda0a56bf3f9d09740871d85f0557cf0b4a7a76 http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=858d8a4a2312139545e910cc0854c45f5d65a296 http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=f05b865607a832cdc1b9b4bfdfd07bcfdc7431cc fixed in libreoffice-3-4: http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4&id=fcdf6cde90c7f9f941a5664d4b0866adcfab5db9 http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4&id=8e184c376ce77b3c27d7a2722b15b8f36de71ea5 http://cgit.freedesktop.org/libreoffice/libs-core/commit/?h=libreoffice-3-4&id=ed41167d5ffae11efdd9cb43b2d88a8147e6d13f
*** Bug 44708 has been marked as a duplicate of this bug. ***