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.

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)

LibreOffice 6.0.3.2: better but still not optimal, a few gaps persist.

Created attachment 142954 [details]
Double-line table cells, PDF export from LOW 6.0.3.2

Created attachment 170522 [details]
DLTCell_40_41_42_43_72.pdf: How it looks in various versions using Linux bibisects

(In reply to LigH from comment #14)
> LibreOffice 6.0.3.2: better but still not optimal, a few gaps persist.

Comment 6's attachment 97079 [details] still looks the same in 7.2+.
Then again, using Linux bibisects all the way back to 4.0, 4.1, and 4.2 it also looks approximately the same. I've never seen anything like the result in comment 7 - it looks like it came from a different test file.

I'm not sure what it is "supposed" to look like. Certainly the double lines are not too close together as the title states - so based on the title alone this bug could be marked as WORKSFORME.

I think it is best just to close this bug. Comment 14 indicates that it looks "better", and I don't see any significant differences at all over time. It looks fine enough to me.