Bug 38635 - Gaps and jaggies in borders, affecting normal view and printing
Summary: Gaps and jaggies in borders, affecting normal view and printing
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.0 release
Hardware: x86 (IA32) All
: highest normal
Assignee: Not Assigned
URL:
Whiteboard: target:3.6.0 target:3.5.3
Keywords: regression
: 43995 (view as bug list)
Depends on:
Blocks: 44768 mab4.2
  Show dependency treegraph
 
Reported: 2011-06-24 02:28 UTC by Larsen
Modified: 2023-05-20 18:42 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Example document (9.79 KB, application/vnd.oasis.opendocument.text)
2011-06-24 02:28 UTC, Larsen
Details
Screenshot showing the small line on the edges (4.09 KB, image/png)
2011-06-24 02:28 UTC, Larsen
Details
Printout as PDF showing the problem (2.77 KB, application/pdf)
2011-06-24 02:29 UTC, Larsen
Details
Gaps in paragraph borders still a problem & how to identify (140.45 KB, application/zip)
2012-05-03 06:36 UTC, Panos Stokas
Details
adds some assertions for debugging only (3.52 KB, text/plain)
2012-05-11 12:56 UTC, Michael Stahl (allotropia)
Details
worst case which also appears in print, while OpenOffice looks good (30.95 KB, application/zip)
2013-02-12 09:13 UTC, Panos Stokas
Details
Screenshot showing the edges in LO 4.2.4.2 (2.51 KB, image/png)
2014-05-12 20:57 UTC, Larsen
Details
LibreOffice text borders getting worse with new versions (55.84 KB, image/png)
2014-05-15 07:04 UTC, Panos Stokas
Details
BorderPrint.pdf (13.65 KB, application/pdf)
2014-05-15 15:54 UTC, Joel Madero
Details
zip of screen clips -- Writer normal view and of export PDF of test docs (44.59 KB, application/x-zip-compressed)
2014-05-15 18:02 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Larsen 2011-06-24 02:28:18 UTC
Created attachment 48373 [details]
Example document

I have a paragraph that is surrounded by a border (see attached doc). When I zoom in onto the edges, I can see a very tiny line (see screenshot).

Now, when I print the document that line is very thick so the borders are not closed at the edges (see PDF, looks the same on a printout).

OS is Win XP SP3 German
Comment 1 Larsen 2011-06-24 02:28:57 UTC
Created attachment 48374 [details]
Screenshot showing the small line on the edges
Comment 2 Larsen 2011-06-24 02:29:42 UTC
Created attachment 48375 [details]
Printout as PDF showing the problem
Comment 3 Nathan Wells 2011-12-20 19:42:09 UTC
*** Bug 43995 has been marked as a duplicate of this bug. ***
Comment 4 Nathan Wells 2011-12-20 19:45:02 UTC
I am also having this problem.

Steps to reproduce:
1. Create a frame in LibreOffice Writer
2. Add a border
3. Print the page

Current behavior: Frame border has gaps in corners (like the corners aren't joined)

Expected behavior: The border should be connected without gaps.

Also confirmed in Windows 7 x64 LibreOffice 3.4.4 build 402; Ubuntu 11.10  LibreOffice 3.4.4 build 402; and LO 3.4.4 (build 402) running Kubuntu 11.10
Comment 5 Björn Michaelsen 2011-12-23 12:28:36 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 6 Larsen 2011-12-24 02:39:18 UTC
Still happens with LOdev 3.5.0
Comment 7 Jan Jurkus 2012-02-08 03:57:23 UTC
I also came across this bug in LO 3.5RC3, with frames, exactly as Nathan described.
Comment 8 Michael Stahl (allotropia) 2012-03-23 14:35:04 UTC
indeed, the border has very visible gaps in the PDF
that OOo 3.4beta didn't produce; broken in LO 3.4.3 and master
Comment 9 Rainer Bielefeld Retired 2012-04-05 10:49:47 UTC
<http://wiki.documentfoundation.org/BugReport_Details#Version>
Comment 10 Not Assigned 2012-04-16 07:19:39 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=502c93143ef29989692ca3e63e3e6abc255fd53f

fdo#38635: fix border printing:
Comment 11 Michael Stahl (allotropia) 2012-04-16 08:29:22 UTC
with the fix in comment #10 the huge gap on printing is removed, but sometimes a very small gap remains, which probably means the start/end points of the borders are a little bit off and requires further investigation.
so not setting to FIXED yet.
Comment 12 Michael Stahl (allotropia) 2012-04-16 08:31:30 UTC
why does this stupid version always change itself
Comment 13 Not Assigned 2012-04-17 01:22:45 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f20c1f3081c98cfb03940318e4ba7ec33f624aec&g=libreoffice-3-5

fdo#38635: fix border printing:


It will be available in LibreOffice 3.5.3.
Comment 14 Not Assigned 2012-04-17 13:44:19 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b08e9f3023e9ea1ca0926334becac939ca8fdfac

fdo#38635: sw: fix border corner gaps:
Comment 15 Michael Stahl (allotropia) 2012-04-17 13:45:16 UTC
so with the first fix, the start and end points of the lines
have these coordinates while printing; the problem is that they
are 1.5 or 2.5 twips apart; the drawing layer computes a
clipping region from these positions and the width of the border,
and there doesn't seem to be anything wrong with that part.

new start.X 2007,500000, start.Y 2422,000000, end.X 2007,500000, end.Y 4114,000000 els -20,000000 ers 20,000000 ele -20,000000 ere 20,000000
new start.X 7779,500000, start.Y 2422,000000, end.X 7779,500000, end.Y 4114,000000 els 20,000000 ers -20,000000 ele 20,000000 ere -20,000000
new start.X 2009,000000, start.Y 2420,500000, end.X 7777,000000, end.Y 2420,500000 els 20,000000 ers -20,000000 ele 20,000000 ere -20,000000
new start.X 2009,000000, start.Y 4116,500000, end.X 7777,000000, end.Y 4116,500000 els -20,000000 ers 20,000000 ele -20,000000 ere 20,000000

adding calls to lcl_AlignHeight/Width improves this a bit,
the top and left coordinates now match:

new start.X 2007,500000, start.Y 2420,500000, end.X 2007,500000, end.Y 4115,500000 els -20,000000 ers 20,000000 ele -20,000000 ere 20,000000
new start.X 7779,500000, start.Y 2420,500000, end.X 7779,500000, end.Y 4115,500000 els 20,000000 ers -20,000000 ele 20,000000 ere -20,000000
new start.X 2007,500000, start.Y 2420,500000, end.X 7778,500000, end.Y 2420,500000 els 20,000000 ers -20,000000 ele 20,000000 ere -20,000000
new start.X 2007,500000, start.Y 4116,500000, end.X 7778,500000, end.Y 4116,500000 els -20,000000 ers 20,000000 ele -20,000000 ere 20,000000

additionally computing the constant coordinate always from the
outer edge instead of from the left edge makes everything match:

new start.X 2007,500000, start.Y 2420,500000, end.X 2007,500000, end.Y 4115,500000 els -20,000000 ers 20,000000 ele -20,000000 ere 20,000000
new start.X 7778,500000, start.Y 2420,500000, end.X 7778,500000, end.Y 4115,500000 els 20,000000 ers -20,000000 ele 20,000000 ere -20,000000
new start.X 2007,500000, start.Y 2420,500000, end.X 7778,500000, end.Y 2420,500000 els 20,000000 ers -20,000000 ele 20,000000 ere -20,000000
new start.X 2007,500000, start.Y 4115,500000, end.X 7778,500000, end.Y 4115,500000 els -20,000000 ers 20,000000 ele -20,000000 ere 20,000000
Comment 16 Not Assigned 2012-04-18 02:41:46 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=fe2a1f6bcb72b17d050355377b68e986f17cf1ff&g=libreoffice-3-5

fdo#38635: sw: fix border corner gaps:


It will be available in LibreOffice 3.5.3.
Comment 17 Panos Stokas 2012-05-03 06:36:00 UTC
Created attachment 60970 [details]
Gaps in paragraph borders still a problem & how to identify

The issue has improved but it still exists. In the attached archive you'll find 3 screenshots displaying how:

1. It is very difficult to discern the gaps with the naked eye
2. However the PDF export amplifies the contrast in the gaps
3. In reality the issue is not to the PDF exporter but the border rendering instead

A simple method to identify the problem: magnify the document at maximum level, get a screenshot and pass it through a strong  a Gamma filter. The gaps will now be very visible.

The original and PDF documents are included as well.
Comment 18 Michael Stahl (allotropia) 2012-05-11 12:56:05 UTC
Created attachment 61466 [details]
adds some assertions for debugging only

this patch adds some assertions to writer that show that the start/end positions of the border lines are equal (hence my suspicion that any remaining problem is in drawing layer/VCL/anti-aliasing).

unfortunately this patch cannot be committed because in case of table cells the borders can be merged and then the assertions trigger spuriously.
Comment 19 Michael Stahl (allotropia) 2012-06-29 14:52:39 UTC
Comment on attachment 61466 [details]
adds some assertions for debugging only

this patch is not intended to be integrated, removing "patch" flag.
Comment 20 Panos Stokas 2013-02-12 09:13:21 UTC
Created attachment 74668 [details]
worst case which also appears in print, while OpenOffice looks good

I am posting additional information as this bug is also affecting documents printed from LibreOffice. The attached archive contains the original document as well as a screenshot from OpenOffice. OpenOffice renders the borders correctly.

Finally it contains the document in large magnification as it was sent to a PDF printer. This may be of special interest to the coders who are looking at this bug. Printing the document on a laser or inkjet printer does exhibit this problem although in no such detail.

Considering that this is seriously affecting the appearance of documents printed from LibreOffice and that there is no workaround against this bug (I do not consider switching to OpenOffice as a workaround) I will also raise the severity of this.
Comment 21 Michael Meeks 2013-02-12 13:24:10 UTC
Panos - I'm wondering why this is a 4.1 MAB ? is this problem specific to 4.1 ? if not it should be filed against the oldest MAB tracker for which this is a problem.

In general, in place of re-opening an existing bug (is that what happened?), it's often good to file a new one that refers to this one.
Comment 22 Panos Stokas 2013-02-12 20:49:28 UTC
(In reply to comment #21)
> Panos - I'm wondering why this is a 4.1 MAB ? is this problem specific to
> 4.1 ? if not it should be filed against the oldest MAB tracker for which
> this is a problem.

I set this to 4.1 to draw attention to this bug as printing is a most basic function of office software concept and I am highly bothered when I have to resort to OpenOffice to print documents that I've created with LibreOffice.

If you feel that this was a mistake, please delete the MAB entry and I'll add it in an older one.


> In general, in place of re-opening an existing bug (is that what happened?),
> it's often good to file a new one that refers to this one.

I'll keep it in mind. I thought the bug had received additional attention when it was reopened a few months ago.
Comment 23 Panos Stokas 2013-02-14 08:08:32 UTC
I've renamed the bug to reflect its more serious magnitude. It doesn't only affect PDF printing, it affects all printing (as I have witnessed it) as well as editing.
Comment 24 Joel Madero 2013-02-15 20:43:51 UTC
Should be a 3.6 MAB not a 4.1 (not a regression or something new to LibreOffice 4.1) Changing
Comment 25 tommy27 2013-08-16 13:13:20 UTC
I confirm issue using LibO 4.0.4 and 4.1.0 finale releases on Win7 64bit.
moving this bur report to the mab4.0 list since 3.6.x is EOL.
Comment 26 Thorsten Behrens (allotropia) 2013-09-12 16:14:59 UTC
Apologies for not having gotten around fixing this bug yet; unfortunately in future I'll have even less time at my disposal for this, so I'm freeing up ownership for other volunteers to take over.
Comment 27 sophie 2013-11-05 10:05:25 UTC
Still present in Version: 4.1.3.1
Build ID: b42498da0e3f91b17e51b55c8295ec4f8f22087 - Sophie
Comment 28 Cédric Bosdonnat 2014-01-20 08:57:52 UTC
Restricted my LibreOffice hacking area
Comment 29 Stéphane Guillou (stragu) 2014-02-12 08:02:38 UTC
Moving to mab4.1 (Bug 60270) because:
- 4.0 reached EOL (End Of Life)
- bug confirmed in later version
Comment 30 sophie 2014-02-12 09:32:34 UTC
Changed importance to reflect the new policy - Sophie
Comment 31 Michael Stahl (allotropia) 2014-04-25 11:43:54 UTC
Comment on attachment 74668 [details]
worst case which also appears in print, while OpenOffice looks good

this document contains a white 0.05pt border on the top and bottom of the paragraphs, and drawing a diagonal with such a thin border you get just
a 1-pixel step in the middle of the end, and since the border is white it's
impossible to see any white gap between horiziontal and vertical border line.

hence this particular document is not the worst case but the best case :)
Comment 32 tommy27 2014-05-10 11:58:57 UTC
please retest against current 4.2.4.2 release.
if bug persists, please move it to the mab4.2 list since 4.1.x reached end of life
Comment 33 Larsen 2014-05-12 20:57:39 UTC
Created attachment 98943 [details]
Screenshot showing the edges in LO 4.2.4.2

The line in the PDF is still visible, but only when zooming in quite a lot. Looks ok to me now.

In Writer, it looks a little bit different as the edges of the lines are not bevelled anymore. See screenshot.
Comment 34 tommy27 2014-05-13 02:52:48 UTC
thanks for screenshot. so situation improved but not 100% fixed yet.
Comment 35 Panos Stokas 2014-05-15 07:04:37 UTC
Created attachment 99062 [details]
LibreOffice text borders getting worse with new versions

Actually the situation is now getting much worse. Look at the attached image (which also contains the corrected borders from OpenOffice 4.1) and look at my older screenshots where I had to increase gamma to show the problem in actual screenshots. Of course the problem was still very obvious in many high-res printing cases, but now it's gotten so bad that it's actually good news. I really don't think that a new version will actually be released out of beta before this is finally fixed.
Comment 36 Panos Stokas 2014-05-15 07:11:41 UTC
Changed importance to critical.

A word processor must be able to print correctly.
Comment 37 Joel Madero 2014-05-15 15:42:49 UTC
This is not critical - please don't mess around with severity/priority
Comment 38 Joel Madero 2014-05-15 15:49:30 UTC
Also - providing just images are not useful at all in recreating the problem. When you make attachments you should attach a zip/tar.gz which includes the original file, as well as any images that you think are necessary to show your problem.
Comment 39 Joel Madero 2014-05-15 15:54:40 UTC
Created attachment 99102 [details]
BorderPrint.pdf

Sorry for the noise - I just downloaded the original document (the one that the bug was based on) and did a print to file and the border looks fine (see attached pdf). 

I am closing this bug as FIXED as it originally was. 

If there are similar problems with a NEW document please report a separate bug - feel free to CC me on it and I will try to test. Please include the document itself plus a pdf that shows the export. Also include exact steps on how to reproduce (are you exporting as pdf or printing to file?) Please do not reopen this bug as the original test case is perfect from what I can tell.

Also, before reporting a new bug you might want to test against a daily build to see what kind of results you get: http://dev-builds.libreoffice.org/daily/master/
Comment 40 Panos Stokas 2014-05-15 16:36:56 UTC
I am reopening the bug and also increase the severity as it is obviously not fixed but it is getting worse as per screenshots at https://bugs.freedesktop.org/attachment.cgi?id=99062


Steps to reproduce:

1. Use the latest nightly version.
2. Open the "border gaps.odt" file from https://bugs.freedesktop.org/attachment.cgi?id=60970
3. Zoom the document.

Please don't mess with the severity. This is obviously getting critical as any document that is using text borders will be looking terrible on print.
Comment 41 Panos Stokas 2014-05-15 16:42:40 UTC
I am also asking Joel Madero to be more careful with his own investigation, as the sample which he provided has a clear gap in all four corners. It may not be visible to him, but it is visible to me.

But as I said, the problem has gotten much worse with the latest nightlies.
Comment 42 Joel Madero 2014-05-15 16:43:49 UTC
Per email - please stop messing around with the severity/priority. Moving back - last time I'll ask
Comment 43 V Stuart Foote 2014-05-15 17:46:35 UTC
Actually, both test documents (from attachment 60970 [details] - border gaps.zip, and 48373 - test.odt ) print and render as PDF export correctly using recent LibreOffice 4.3.0alpha1+ build on Windows.

However, the paragraph border as rendered on screen in a writer session shows with block line ends rather than cleanly mitered, so that is not yet correct.  And I believe that is a regression in the on screen display of the document.

It does print and export correctly.

Priority and placement on MAB 4.2 is correct at highest/normal.
Comment 44 V Stuart Foote 2014-05-15 18:02:05 UTC
Created attachment 99111 [details]
zip of screen clips -- Writer normal view and of export PDF of test docs

print and PDF export of paragraph borders are being correctly rendered, but the on screen normal view has regressed
Comment 45 Joel Madero 2014-05-15 18:50:48 UTC
I am bibisecting that now - I believe that should be a new bug report (I'll report once I'm done bibisecting).

With your test case and explanation - again closing this as FIXED.

For anyone else watching this bug - there is expected to be a very slight gap (1px) between the sides. Additionally - viewing is a separate issue (although might have been triggered by these commits) so it belongs in a new report.
Comment 46 Kohei Yoshida 2014-05-15 19:01:41 UTC
No need to bibisect.  I'm the one who "broke" that, though that was in exchange for solving something else.  That's normally how everything goes in this code base.
Comment 47 Panos Stokas 2014-05-15 21:08:19 UTC
The border_gaps_normalView_PDF-export.PNG and test_normalView_PDF-export.PNG screenshots at https://bugs.freedesktop.org/attachment.cgi?id=99111 still have gaps in LibreOffice.

It doesn't matter if can't see them in your monitor without zooming, these are visible in print (and in some cases may be very annoying). Even my inkjet printer at home shows them.

But as I've been warned against reopening this bug, I am done here.
Comment 48 V Stuart Foote 2014-05-15 23:13:08 UTC
@Panos, *,

No believe that very faint border that IS noticeable in PDF and PostScript vector renderings is a Cairo vector primitive. These are stroke attributes of the Cairo LINE_JOIN_MITER--they are not a bug, just a limit of the vector description of the stroke and fill that makes up each path.

I think the issues Kohei was referring to was with bug 75260 fixing double line borders in calc (cells) and writer (tables and paragraph border). That issue remains open. And beleive Kohei will revisit the single line paragraph borders.

Lets leave this resolved fixed to keep it simple for Kohei, although one could make the case for tracking the regression here.