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
Created attachment 48374 [details] Screenshot showing the small line on the edges
Created attachment 48375 [details] Printout as PDF showing the problem
*** Bug 43995 has been marked as a duplicate of this bug. ***
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
[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
Still happens with LOdev 3.5.0
I also came across this bug in LO 3.5RC3, with frames, exactly as Nathan described.
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
<http://wiki.documentfoundation.org/BugReport_Details#Version>
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:
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.
why does this stupid version always change itself
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.
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:
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
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.
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.
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 on attachment 61466 [details] adds some assertions for debugging only this patch is not intended to be integrated, removing "patch" flag.
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.
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.
(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.
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.
Should be a 3.6 MAB not a 4.1 (not a regression or something new to LibreOffice 4.1) Changing
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.
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.
Still present in Version: 4.1.3.1 Build ID: b42498da0e3f91b17e51b55c8295ec4f8f22087 - Sophie
Restricted my LibreOffice hacking area
Moving to mab4.1 (Bug 60270) because: - 4.0 reached EOL (End Of Life) - bug confirmed in later version
Changed importance to reflect the new policy - Sophie
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 :)
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
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.
thanks for screenshot. so situation improved but not 100% fixed yet.
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.
Changed importance to critical. A word processor must be able to print correctly.
This is not critical - please don't mess around with severity/priority
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.
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/
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.
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.
Per email - please stop messing around with the severity/priority. Moving back - last time I'll ask
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.
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
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.
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.
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.
@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.