Created attachment 58277 [details] comparison of border lines style LO ver 3.5.1RC2 & LO ver 3.3.4 rendered in 3.5 On a newly created table, Table properties>table format>borders>line>style The distance between the two lines is to small, it is hard to tell it is a double line border style. The distance between the two lines used to be greater ~ x2, in ver 3.3 and before. This is using the 'line width' of .05 which is the same line weight as the table. increasing the line width is not the solution, heavier lines for the border are not wanted, more distance between the lines is. Thank You Greg
Thanks for bugrepprt Please, attach odt file that demonstrates this problem
indeed, while the new way of setting borders is a bit more flexible, it cannot create some of the double borders that were possible with the old versions (but they should be displayed properly when loaded from existing documents). for example i can't get anything like the old double 1.10pt or 2.60pt borders. Cedric, why is this no longer possible, i.e. is there some good reason for that or is it an accident?
(In reply to comment #2) > indeed, while the new way of setting borders is a bit more flexible, > it cannot create some of the double borders that were possible > with the old versions (but they should be displayed properly > when loaded from existing documents). > > for example i can't get anything like the old double 1.10pt or > 2.60pt borders. > > Cedric, why is this no longer possible, i.e. is there some > good reason for that or is it an accident? The reason is simply that the new set of widths may not cover all the previous one... but indeed, just having the ability to read / paint those would help solving a pair of problems. I'ld say it's more of an accident here than a premeditated crime.
*** Bug 48622 has been marked as a duplicate of this bug. ***
Marking as NEEDINFO as we need the file to test.
Created attachment 97079 [details] Double-line table cell demo document Sample of a table with single cells formatted with thick double-line styles, showing obviously how wrong the rendering may get; created with LibreOffice 4.2.2.1 Writer on Windows 7 SP1 64-bit.
Created attachment 97080 [details] Double-line table cell demo document, PDF export Result of PDF export from attachment #97079 [details]; here the rendering is even more wrong, or at least differently wrong...
The "Platform" attribute of this bug is certainly not restricted to "Linux", same issues are in Windows version 4.2.2.1 (release). Regarding the consequences in the document: Neither the thickness of individual lines in double-line styles are correct, nor the distance between them. And when exporting to PDF, the results are even more confusing than in the ODT document, especially for thick lines (~4 pt width): The second line of the double-line pair of a cell border is often separated by half the cell height. So hardly being able to recognize the style in the dialog control is rather the less annoying part of this bug.
(In reply to LigH from comment #6) > Created attachment 97079 [details] > Double-line table cell demo document > > Sample of a table with single cells formatted with thick double-line styles, > showing obviously how wrong the rendering may get; created with LibreOffice > 4.2.2.1 Writer on Windows 7 SP1 64-bit. Obviously there is something wrong. Reproducible with the master. Set status to NEW. Best regards. JBF
The rendering of the test file is already broken at the start of the 43all bibisect repository, and the rendering changes at least 4 times (each broken in a different way) over the course of the repository. It seems likely to me that the effort of tracking down all these later changes is not going to aid the development of a fix. On that basis, setting Whiteboard:notBibisectable
(on reflection, the fact that the first bug is before the bibisect repo is probably the most significant part, so let's make that preBibisect instead)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.