Bug 118937 - Border around text portion has padding color artifacts
Summary: Border around text portion has padding color artifacts
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
5.0 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, implementationError
Depends on:
Blocks: Borders
  Show dependency treegraph
Reported: 2018-07-25 16:13 UTC by Regina Henschel
Modified: 2021-07-31 08:23 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:

Testdocument (11.48 KB, application/vnd.oasis.opendocument.text)
2018-07-25 16:13 UTC, Regina Henschel
Screenshot (65.47 KB, image/png)
2018-07-25 16:14 UTC, Regina Henschel
Paragraph border seams (8.90 KB, application/vnd.oasis.opendocument.text)
2020-08-06 06:10 UTC, Panos Stokas
Paragraph border seams screenshot (worst case zooming) (15.25 KB, image/png)
2020-08-06 06:13 UTC, Panos Stokas
Char borders not using loext. (11.43 KB, application/vnd.oasis.opendocument.text)
2020-08-18 14:00 UTC, Miklos Vajna
how it looks in 7.3 (86.93 KB, image/png)
2021-07-31 08:23 UTC, BogdanB

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2018-07-25 16:13:51 UTC
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.
Comment 1 Regina Henschel 2018-07-25 16:14:15 UTC
Created attachment 143754 [details]
Comment 2 Jacques Guilleron 2018-07-26 13:52:35 UTC
HI Regina,

Reproduced with
LO 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
Comment 3 Xisco Faulí 2018-07-27 09:25:49 UTC
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...
Comment 4 QA Administrators 2019-08-03 03:06:18 UTC Comment hidden (obsolete)
Comment 5 Panos Stokas 2020-08-04 05:59:14 UTC
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.
Comment 6 Panos Stokas 2020-08-04 15:24:26 UTC
I've also tested with version 7 RC3, same issue with Skia enabled.
Comment 7 Panos Stokas 2020-08-06 06:10:47 UTC
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.
Comment 8 Panos Stokas 2020-08-06 06:13:39 UTC
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.
Comment 9 raal 2020-08-15 20:25:32 UTC
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
commit cc4b90354dddc4b2aaaa918819c57de0e703ce7d
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Wed May 27 18:51:40 2015 +0800

    Bibisect: This commit covers the following irrelevant source commit(s)
    commit f1f6b6db730ae67a427c7974b59a5e19ab571984
    Author:     Miklos Vajna <vmiklos@collabora.co.uk>
    AuthorDate: Tue Feb 3 18:20:43 2015 +0100
    Commit:     Miklos Vajna <vmiklos@collabora.co.uk>
    CommitDate: Tue Feb 3 19:36:36 2015 +0100
        xmloff: write character borders in the extension namespace for now
        Change-Id: Ia112cf626126149ea9cf09c5d6ff812d5d5ffec5

Before this commit the grey border was missing, after this commit the border is present but with green lines around (repo bibisect-50max$ ).
Comment 10 Miklos Vajna 2020-08-18 14:00:34 UTC
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.
Comment 11 Miklos Vajna 2020-08-18 14:00:52 UTC
Adjusting keywords accordingly.
Comment 12 BogdanB 2021-07-31 08:23:33 UTC
Created attachment 173987 [details]
how it looks in 7.3

Retested in Version: / LibreOffice Community
Build ID: 5aa74aa1e6fac571f99146ebcb6adc9feb1459ad
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-07-28_19:35:14
Calc: threaded