Created attachment 143753 [details]
Open attached file. The text portion has a green background color and a padding. And it has a grey border. Notice, that at the top and right side of the border a green line is visible. That line should not be there. The green color should end at the inner border edge. You might want to draw a pixel wide under the border to avoid gaps coming from rounding errors. But drawing the padding color beyond the outer edge of the border is too far.
Created attachment 143754 [details]
LO 18.104.22.168.alpha0+ Build ID: fa881095bc62c3646406c82a98d8503377288a54
CPU threads: 2; OS: Windows 6.1; UI render: default;
TinderBox: Win-x86@42, Branch:master, Time: 2018-07-22_03:27:00
Locale: fr-FR (fr_FR); Calc: CL
Also reproducible in
Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 4.10; Render: default;
Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86
Locale: ca-ES (ca_ES.UTF-8)
In previous versions, the grey padding wasn't even present...
Dear Regina Henschel,
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!
I've tested the bug per the QA Administrator's request.
It's still an issue on version 6.4.5
It also affects printing. Depending on your printer's interpolation settings, the green line will be visible on paper.
I've also tested with version 7 RC3, same issue with Skia enabled.
Created attachment 163995 [details]
Paragraph border seams
I've tested with black area text color and white border color. This shows that not only is the outer border padding affected, but paragraphs themselves have seems.
To reproduce the attached document, select 5 paragraphs set area color to black, and enable all four borders with border color to white. Border width was set to 7 points.
Paragraph borders broke in version 3.4 which is why I'll add the keyword "regression" based on the QA Administrator's notice.
I had originally posted this issue in bug 38635 which was closed as "fixed" despite my objections. It was claimed at the time that it was a Cairo bug. However, I've tested this issue with LO 7 using Skia and the problem is still there.
This bug is the reason I'm keeping a portable OpenOffice for printing documents with paragraph borders.
Created attachment 163996 [details]
Paragraph border seams screenshot (worst case zooming)
Shows paragraph border seams. Zooming was set to the worst case scenario, but the bug shows in both PDF export and printing.
The correct display would be a black box with 5 numbers surrounded by white space without any seams.
This seems to have begun at the below commit.
Adding Cc: to Miklos Vajna ; Could you possibly take a look at this one?
cc4b90354dddc4b2aaaa918819c57de0e703ce7d is the first bad commit
Author: Matthew Francis <firstname.lastname@example.org>
Date: Wed May 27 18:51:40 2015 +0800
Bibisect: This commit covers the following irrelevant source commit(s)
Author: Miklos Vajna <email@example.com>
AuthorDate: Tue Feb 3 18:20:43 2015 +0100
Commit: Miklos Vajna <firstname.lastname@example.org>
CommitDate: Tue Feb 3 19:36:36 2015 +0100
xmloff: write character borders in the extension namespace for now
Before this commit the grey border was missing, after this commit the border is present but with green lines around (repo bibisect-50max$ ).
Created attachment 164410 [details]
Char borders not using loext.
Thanks for the bisect. Actually that just shows we ignored char borders from the extension namespace before. Let me attach a version of that document which has the char borders not in the loext namespace, then the problem is there with bibisect-50max.git oldest as well. So this is a bug in the char borders feature, not a regression.
Adjusting keywords accordingly.