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
Version modified due to <http://wiki.documentfoundation.org/BugReport>?
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.
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:
fixed in libreoffice-3-4:
*** Bug 44708 has been marked as a duplicate of this bug. ***