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.
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
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 22.214.171.124 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 126.96.36.199 (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
> 188.8.131.52 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)
Migrating Whiteboard tags to Keywords: (preBibisect)
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
LibreOffice 184.108.40.206: better but still not optimal, a few gaps persist.
Created attachment 142954 [details]
Double-line table cells, PDF export from LOW 220.127.116.11