In Writer, there are horizontal artifact lines emanating from frames when they are placed on a transparent frame which is on a page with a colored background. The artifact lines are the same color as the page background. To reproduce: * Open Writer and create a new document * Format-> Page change background to green * Insert-> Frame and place a frame on the page * Select that frame and change the background fill to white with 25% transparency * Inside that frame, insert another frame * Note the artifacting lines. I am attaching a sample document which causes the lines and a screenshot of what it looks like on my monitor. Tested as occurring on all of these: Version Host Display LO 4.0.0 RHEL 6 Linux Mandriva Linux 2009.1 LO 4.0.0 RHEL 6 Linux Fedora Linux 17 LO 4.0.0 Mandriva Linux 2009.1 Mandriva Linux 2009.1 LO 3.6.5.2 Arch Linux (2/2013) Mandriva Linux 2009.1 OO 3.2.0 Mandriva Linux 2009.1 Mandriva Linux 2009.1
Created attachment 75356 [details] Sample document that causes artifacts Sample writer document that causes artifacts to appear on Linux/X11 under certain frame transparency conditions.
Created attachment 75357 [details] Screenshot of issue Screenshot of issue
Thank you for reporthing this bug, I can conform this bug running LibreOffice 4.0.1.1 rc on Mac osx 10.6.8. extra explain I can see the problem, it accurs wen 2 frames are on each other. Wen you move the frame of the other frame the stripe wil be gone.
Additional information: There is also vertical line artifacting, although it is far less prominent. Even worse- these horizontal and vertical artifacts are also appearing on our printouts (not just on the screen)
I can confirm this using LibreOffice 3.4.3 and Windows XP and LibreOffice 3.6.5.2 on an up-to-date Arch Linux install. I reproduced the problem by creating a frame within a frame within a frame. I made the outside frame have a green background and the middle frame white and 10% transparent so it'd be very visible. I left the sub-sub-frame One workaround that I noticed was that you can make the offending sub-frames HAVE a background color, but be 100% transparent and the line problem goes away. Unfortunately, I'm guessing that specifying transparency probably calls for extra unnecessary/wasteful processing. I exported a pdf from the glitchy document and it came out without the flaw. But when I printed the document from both MS Windows and from Linux, the line artifacts WERE printed. This problem does seem to affect all platforms.
(In reply to comment #4) > Additional information: There is also vertical line artifacting, although > it is far less prominent. Even worse- these horizontal and vertical > artifacts are also appearing on our printouts (not just on the screen) I neglected to mention that the lines also appear in exported PDF's too. Too see, just open the sample document and export it. Next problem is that if you print using PDF engine ( properties-> Device-> Printer Language type = PDF ) the foreground frame will be way too dark. Doesn't look like the screen at all. Almost as if it accidentally uses black for the transparent frames instead of white. This might be worthy of another bug report- it is quite severely broken. I am attaching a scan of a printout of the sample document. There is a workaround to fix the screen display under Linux, if you "export SAL_DISABLE_NATIVE_ALPHA=TRUE" before launching LO, it will disable using the RENDER extension. (Of course this will also greatly slow down screen rendering under certain conditions). This change will also fix printing, but only printing with PS (postscript), if you print using properties-> Device-> Printer Language type = PDF, it will show the same lines (and the way too dark foreground frame).
Created attachment 76030 [details] scan of printed sample document using pdf printing engine/language in LO
You're absolutely right. PDF export WAS affected as well! What is interesting is that if you then take that PDF generated from the example provided and open it with inkscape, you can zoom in and see that the and see a little bit of what is happening. The white transparent frame is split into lots of smaller transparent rectangle objects at frame boundaries. You can actually drag these pieces of transparent white around. The problem seems to be that they don't ever actually touch. So the panel's placement/size appears to be being calculated incorrectly when the pdf is being rendered. Since the boxes are truly transparent, lines would also be generated if the panels overlapped at all. That also explains why I missed them the first time. I didn't use/export the attached example document. I recreated the document myself, using my own frames within frames. My original transparent frame box was white and only 10% transparent to better show the dark green lines when I printed. When I opened the PDF, the miscalculation went the OTHER way and the transparent tiles slightly overlapped to show very slight white lines instead of the dark lines I was expecting.
Created attachment 76051 [details] Screenshot of opening generated pdf in inkscape I've attached a screenshot of what I see opening the generated PDF in Inkscape. It comes into Inkscape as you see in the top of the image. And it is the same way I see the PDF rendered in Adobe Reader. I then copied everything below and shifted some of the panels around. As you can see where they overlap, they are actually real transparent objects that are not attached to text or each other.
Tested in LO 4.1. No change in behavior (still a problem)
I see the same behavior in 4.2.0.4 (In reply to comment #5) > One workaround that I noticed was that you can make the offending sub-frames > HAVE a background color, but be 100% transparent and the line problem goes > away. Unfortunately, I'm guessing that specifying transparency probably > calls for extra unnecessary/wasteful processing. This appears to work to remove the artifacts. Thank you. I also have now noticed that similar artifacts appear around images that are placed in a transparent frame on a colored page. Images do not have background color transparency options, so this workaround unfortunately cannot be used in this case.
(In reply to comment #11) > I also have now noticed that similar artifacts appear around images that are > placed in a transparent frame on a colored page. Images do not have > background color transparency options, so this workaround unfortunately > cannot be used in this case. Update on the images: Artifacts seem to be partially dependent on image anchoring. This presents a workaround: Artifacts were present when the images were anchored "to paragraph", but seem to go away when the images are anchored "as character".
Created attachment 95338 [details] More examples of the same bug with various frames/graphics I've created a new example document that shows some of the cases that will cause these lines. The document simply contains one big frame (background black, transparency 50%) with various objects in it. When these objects draw themselves, they corrupt the big half-tranparent frame, creating ugly 1px wide gaps. 1. "No Fill" border-less frame anchored to paragraph Creates 1px wide gaps around perimeter of frame and extending horizontally through parent frame. 2. 100% transparent border-less frame anchored to paragraph WORKS AS EXPECTED: Doesn't show any border, just the text in the frame. 3. White background, 0% transparency, border-less frame anchored to paragraph Creates 1px wide gaps around perimeter of frame and extending horizontally through parent frame. 4. "No Fill" border-less frame anchored "as character" Doesn't create the gap, but also doesn't handle the background transparency properly. It STACKS the transparency of the parent, essentially making the background twice as black. This is different from the "No Fill" behavior of frames anchored in other ways. 5. JPG image (image with no transparency), anchored to paragraph Creates 1px wide gaps around perimeter of frame and extending horizontally through parent frame. 6. PNG image (image with transparency), anchored to paragraph WORKS AS EXPECTED: Doesn't show any border, just the picture! 7. "No Fill" border-less frame anchored to paragraph (of a transparent frame) on top of another "No Fill" border-less frame anchored to same paragraph. Acts like #4 described above. Doesn't create the gap, but also doesn't handle the background transparency properly. It STACKS the transparency of the parent, essentially making the background twice as black. 8. "No Fill" border-less frame anchored to paragraph (of a transparent frame) on top of another "No Fill" border-less frame, but this time anchored TO that frame. Creates 1px wide gaps around perimeter of frame and extending horizontally through parent frame. But the lines do not extend into the big outer frame. I then used File->Export to have LibreOffice render an image of what I saw. It rendered with all of the buggy lines. I inserted this picture on the second page of the example document. I also exported a pdf and even printed the document. I saw the buggy lines in all cases.
It appears that 4.4.x will finally fix this specific issue! Unfortunately, it also appears to introduce an odd new behavior for frames with a "None" fill type. Opening my last example document in 4.4.0.1 shows some interesting changes. 1. 4.4.0 converted all of the "None" filled frames to White/100% transparency. 2. When I change the fill on those frames back to "None" and change the transparency back to 0%, the frame now completely inherit the background of their anchor points. 3. 4.4.0 then stacks each "None" filled frame's inherited background on top of the parent frame's transparency, making each nested frame half as transparent. Before 4.4.0, "None" filled frames would not stack their backgrounds and would try fake being the same background color. Also, opening the first attachment in 4.4.0.1 rc triggers bug 87369, which causes the green frame's background color to be changed to white on file load. These observations probably warrant other bug reports, but this original bug can probably be closed. Please reopen if I'm wrong.
If the specific commit is not known, then it's Worksforme rather then Fixed.
I won't reopen this report (I've been yelled at before!), but it appears this is more complicated than I thought. First, LO shows completely different behavior depending on if you're opening an existing document or if you're creating a new one. If you're opening an existing document, such as my last example document ( https://bugs.documentfoundation.org/attachment.cgi?id=95338 ), LO 4.4+ will revert to something closer to the previous pre-4.4 behavior. The horizontal artifacts will disappear as described, but only if anti-aliasing is enabled. In this state, even though the lines are still visible, the lines are much less noticeable. I'm guessing either the gap is thinner or the panes are slightly transparent? If, instead, you create the same frames in LO 4.4+ or just copy/paste the frames from the example doc to a new document, you'll see the new behavior/bugs I described above in comment 14.