Bug 42442 - PRINTING and PDFEXPORT of particular business cards shows unwanted horizontal and vertical line artifacts for frame borders
Summary: PRINTING and PDFEXPORT of particular business cards shows unwanted horizontal...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: x86 (IA32) All
: medium major
Assignee: Not Assigned
Whiteboard: target:5.4
Keywords: filter:pdf
: 47637 55894 (view as bug list)
Depends on:
Blocks: PDF-Export Labels-BusinessCards
  Show dependency treegraph
Reported: 2011-10-31 09:25 UTC by Istvan Varga
Modified: 2022-01-12 14:32 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:

Original document (546.27 KB, application/vnd.oasis.opendocument.text)
2011-10-31 09:25 UTC, Istvan Varga
PDF exported from original document (580.25 KB, application/pdf)
2011-10-31 09:27 UTC, Istvan Varga
Bug seen on dark backgrund in LO 4.3.3 (37.78 KB, application/pdf)
2015-09-02 15:43 UTC, alf
Corresponding LO-document *.odt of attached PDF (18.85 KB, application/vnd.oasis.opendocument.text)
2015-09-02 15:48 UTC, alf
Same document in LO as seen in 'gv' (84.05 KB, image/png)
2015-09-02 20:06 UTC, alf

Note You need to log in before you can comment on or make changes to this bug.
Description Istvan Varga 2011-10-31 09:25:25 UTC
Created attachment 52959 [details]
Original document

Magnify the exported PDF. You'll see unwanted horizontal and vertical thin lines around the name for example that shouldn't be there.
Comment 1 Istvan Varga 2011-10-31 09:27:35 UTC
Created attachment 52960 [details]
PDF exported from original document

Use high magnification, like 800% to see this bug.
Comment 2 Rainer Bielefeld Retired 2011-10-31 11:41:07 UTC
[Reproducible] with reporter's sampe and "LibreOffice 3.4.4RC1  - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:401)]". Frame borders around "VARGA ISTVÁN" are shown as blue lines with Zoom > 800% in blue color, horizontal line fragments prolongated. with more zoom (2000%) also other frame lines fragments become visible for other frames although there are no border lines activated.

I can not see such lines in Printouts, neither FreePDF nor Samsung CLX-3185 Laser printer, so I modified Subject line for now.

Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Comment 3 Istvan Varga 2011-10-31 13:46:49 UTC
(In reply to comment #2)

> I can not see such lines in Printouts, neither FreePDF nor Samsung CLX-3185
> Laser printer, so I modified Subject line for now.

I'm using Canon ip4600 and they are clearly visible using high quality mode either in case of printing document directly or printing the exported PDF. Choosing draft mode or printing to my HP LaserJet lines are not visible but it's because the lower resolution. So bug's title has to have "Printing" also...
Comment 4 Istvan Varga 2012-02-14 13:03:55 UTC
Unwanted lines aren't acceptabe in any circumstances so what about a priority elevation? And why it is new for 3 months now? I'm really sorry to bother you, just asking...
Comment 5 Rainer Bielefeld Retired 2012-02-14 13:25:34 UTC
Comment 6 Istvan Varga 2012-02-17 04:16:17 UTC
Reproducible under Linux with the same document.
PDFEXPORT and PRINTING both have this isuue.

Tried two versions:

LibreOffice 3.3.4 
OOO330m19 (Build:401)
tag libreoffice-, Ubuntu package 1:3.3.4-0ubuntu1

and the most recent I could reach

LibreOffice 3.5.0rc3 
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735

So I changed Platform to All.
Comment 7 Michael Stahl (allotropia) 2012-05-22 02:49:06 UTC
the lines are also there in OOo 3.4beta, the PDF from that looks the same.
also the lines are in PDF from OOo 3.0.1 but a bit thinner.
so doesn't look like a regression to me.
Comment 8 Michael Stahl (allotropia) 2012-05-22 06:58:18 UTC
*** Bug 47637 has been marked as a duplicate of this bug. ***
Comment 9 Michael Stahl (allotropia) 2012-10-31 20:53:17 UTC
*** Bug 55894 has been marked as a duplicate of this bug. ***
Comment 10 tmacalp 2013-08-07 05:31:02 UTC
I believe this behavior stems from a bug that has been around for MANY years.  It was actually inherited from OpenOffice and is even more important now than before since it now affects all printing, now that the default printing engine has moved from postscript over to pdf.

I believe bug 61306 and all of the other bugs mentioned above as "duplicates" present more accurate descriptions of the actual issue, as it is MUCH broader than simple business cards.  It will show/print/export the same lines in MANY documents, especially those containing nested frames with transparent backgrounds.

Here is it reported in OpenOffice back in 2007!

OO's conclusion seemed to be that the problem was complicated and would probably vanish when they moved to the new fancy pdf-mode printing system. It didn't.  Ironically, it still affects pdf export AND pdf printing(the new default), but without an easy work-around(env variable/ps printing) to at least fix printing.  I don't know of a work around for exporting pdfs.

I don't know the inner workings of LO's pdf export module, but it appears to split the document up into a number of rendered tiles/components.  These tiles seem to be ever so slightly misaligned.  If you open the rendered pdf in inkscape, you can actually drag each of these tiles around and zoom in to see that the lines are just areas where the tiles either don't touch, or slightly overlap.

As mentioned in other (more accurate bug reports), here are easy steps to reproduce where you can even see without requiring exporting/printing:

* Open Writer and create a new document
* Insert a frame and resize it to be rather large.
* Change the frame's background color to green(or any dark color), 25% transparent.
* Inside that frame, insert another frame with default options. (disable the inside frame's borders to see it more clearly)
* Note the visible horizontal line artifacts.

On Linux systems, you can make LibreOffice stop displaying these glitches (while in LO) by setting the environment variable: SAL_DISABLE_NATIVE_ALPHA=TRUE.  This severely hampers performance, though.  That setting in combination with switching back to postscript printing at least allows printing to function properly.

If you PRINT the document with the pdf print engine(default) or EXPORT the document as a pdf, you can clearly see the line defects.

I can confirm that this is still an issue in LibreOffice under both Linux and MS Windows and has affected every version of libreoffice/openoffice going back to 2007.
Comment 11 crxssi 2013-08-08 13:53:05 UTC
(In reply to comment #10)
> I believe this behavior stems from a bug that has been around for MANY
> years.  [...]
> Here is it reported in OpenOffice back in 2007!
> https://issues.apache.org/ooo/show_bug.cgi?id=83388

Yep, that was my bug I reported on OO.  Thank goodness I did, since it is how I got the SAL_DISABLE_NATIVE_ALPHA=TRUE workaround that we are still using today.  As it is, they (OO) seem to just be mostly ignoring the issue... and yet it won't go away.

See also: Bug 61189
Comment 12 James Cloos 2014-05-28 20:19:56 UTC
Higher resolution of the coordinates in the exported pdf and ps should avoid artifacts like this.

The attched pdf has coordinates rounded to decipoints, which evidently is insufficient to place borders flush against each other when rendered at typical printer resolution.

(One might expect that it would be enough, since decipoint precision is 720 dpi precision, but this example shows otherwise.)

Centipoint — or millipoint if necessary ­— resolution should avoid the artifacts at higher dpis.  At the cost of larger, slower files.  Potentially noticeably so.
Comment 13 QA Administrators 2015-06-08 14:42:43 UTC Comment hidden (obsolete)
Comment 14 Lance Haverkamp 2015-06-08 19:43:45 UTC
This bug has not been fixed.
Build ID: 420m0(Build:2)
Xubuntu Linux

We think this is inherited from OOo
Comment 15 alf 2015-09-02 15:40:45 UTC
Bug still persists in LibreOffice 4.3.3-2 in Debian Jessie.

It gets most evident, if you create documents with dark background. In that cases exported PDFs show clearly borders of the boxes/margins/frames you have used in your documents. They appear lighter than the background, this might be the reason why it is rarely observed in standard documents.

I also observed that these lines disappear, when you include a *.png image with transparency included in you document. However this is not a solution, as other artefacts show up with transparent images included.

I selected print as "PDF/A-1a" which removes transparency during export. So one personal guess from me is that these lines result from some transparency used to make the lines visible on dark background?

I'll upload the sample PDF  Suedamerika-Cover-5-.pdf.

This is really annoying, as especially book covers use dark background and PDF to submit to printeries.
Comment 16 alf 2015-09-02 15:43:49 UTC
Created attachment 118352 [details]
Bug seen on dark backgrund in LO 4.3.3
Comment 17 alf 2015-09-02 15:48:05 UTC
Created attachment 118353 [details]
Corresponding LO-document *.odt of attached PDF
Comment 18 alf 2015-09-02 16:04:06 UTC
Forgot to mention:

the printing company als mentioned that "the boxes were not correctly interlaced/nested" in the PDF document - whatever that means, in German it is "verschachtelt".
Comment 19 Lance Haverkamp 2015-09-02 17:39:05 UTC
This appears to be fixed as of Version:
Build ID: 40m0(Build:2)
Locale: en_US

Xubuntu Linux 15.04
Comment 20 alf 2015-09-02 19:38:23 UTC
I cannot confirm that.
Installed v4.4.5.2 from Jessie-backports and opened the *.odt File as already uploaded here.

Exporting to PDF/A-1a results in almost the same light lines. Probably the horizontal lines dissapeared, but verticals persist. Adding a transparent image as *.png and exporting to PDF results in rubbish (half content missing/white, ...).
Comment 21 alf 2015-09-02 20:06:55 UTC
Created attachment 118358 [details]
Same document in LO as seen in 'gv'

It has improved, but not fixed. The visability to a large extent depends on magnification and alignment to pixels on the display. Here I attache a screenshot of the resulting PDF in gv with magnification of 32x in the window.

On another computer it is already visible on a full-HD screen without magnification in Evince.
Comment 22 Dom F 2015-09-08 11:23:51 UTC
(In reply to alf from comment #17)
> Created attachment 118353 [details]
> Corresponding LO-document *.odt of attached PDF

WORKAROUND for this document, found using my own document:

Set all frames' transparency explicitly to 100%

Click on frame text, hit ESC to select frame itself, use context menu (e.g. right click) to select "Frame...", go to "Transparency" tab, click "Transparency:" radio button and enter "100%" in the field to the right then click "OK"

When you've done this for all 3 frames in above document then do print preview you will see that all strange lines have disappeared.

Tested with LibreOffice 5.0.1.

It helps to save files in FODT format so you can look through the XML to see what's happening. I did this and concluded that there were no actual borders being set. I tried editing frame positions (in the XML) to simpler values (e.g. svg:x from 0.01284in to 0.1in) to help rendering but that had no effect.

Hope this helps people who are stuck and just want to get their documents going.
Not sure how much this is going to help LO devs find the exact issue though.
Comment 23 tmacalp 2015-12-29 22:03:52 UTC
I believe LO 4.4 mostly fixed this issue...  Unfortunately, it doesn't fix old documents.  If I select everything in the original test document and paste it to a new document before exporting my pdf, I can't reproduce the line artifacts.

I've found this to be VERY true with other similar issues involving nested frame transparency.  For example, if you open my test document: 
in LO 4.4+ and copy/paste the outside frame to a new document, the entire behavior changes.
Comment 24 QA Administrators 2017-10-30 08:29:48 UTC Comment hidden (obsolete)
Comment 25 Lance Haverkamp 2017-10-31 03:43:29 UTC
Still broken in Version:
Build ID: 1:5.1.6~rc2-0ubuntu1~xenial2
CPU Threads: 4; OS Version: Linux 4.10; UI Render: default; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 26 QA Administrators 2019-10-19 02:41:53 UTC Comment hidden (obsolete)
Comment 27 eisa01 2019-11-09 21:02:38 UTC
This is fixed when exporting to PDF, also tested Windows

I can't test printing, so leaving open for now

Build ID: 25c390e17a7f1c018b5eed1ef7dfd568b76f4a84
CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 28 QA Administrators 2021-11-09 04:38:12 UTC Comment hidden (obsolete)
Comment 29 Lance Haverkamp 2021-11-10 01:06:36 UTC
Fixed as far as I can tell, both in print & pdf. 

Version: / LibreOffice Community
Build ID: 20(Build:2)
CPU threads: 4; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb)
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
On OpenSUSE Tumbleweed.
Comment 30 Timur 2022-01-12 14:26:05 UTC Comment hidden (me-too)
Comment 31 Timur 2022-01-12 14:26:24 UTC
Yes, seems fixed even in LO 5.4.0, I close. 
Duplicates should also be checked and reopened if not fixed.