Created attachment 52960 [details]
PDF exported from original document

Use high magnification, like 800% to see this bug.

[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.

@Cédric:
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.

(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...

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...

<http://wiki.documentfoundation.org/BugReport_Details#Version>

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-3.3.3.1, 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.

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.

*** Bug 47637 has been marked as a duplicate of this bug. ***

*** Bug 55894 has been marked as a duplicate of this bug. ***

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!
https://issues.apache.org/ooo/show_bug.cgi?id=83388

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.

Still...
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 4.1.0.4 under both Linux and MS Windows and has affected every version of libreoffice/openoffice going back to 2007.

(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

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.

This bug has not been fixed.
Version: 4.2.8.2
Build ID: 420m0(Build:2)
Xubuntu Linux

We think this is inherited from OOo

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.

Created attachment 118352 [details]
Bug seen on dark backgrund in LO 4.3.3

Created attachment 118353 [details]
Corresponding LO-document *.odt of attached PDF

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".

This appears to be fixed as of Version: 4.4.2.2
Build ID: 40m0(Build:2)
Locale: en_US

Xubuntu Linux 15.04

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, ...).

Created attachment 118358 [details]
Same document in LO 4.4.5.2 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.

(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.

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: 
https://bugs.documentfoundation.org/attachment.cgi?id=95338
in LO 4.4+ and copy/paste the outside frame to a new document, the entire behavior changes.

Still broken in Version: 5.1.6.2
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

This is fixed when exporting to PDF, also tested Windows

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

Version: 6.4.0.0.alpha1+
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

Fixed as far as I can tell, both in print & pdf. 

Using: 
Version: 7.2.2.2 / 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.

Yes, seems fixed even in LO 5.4.0, I close. 
Duplicates should also be checked and reopened if not fixed.