A frame with no-fill background has a white background. To reproduce: Insert a frame, arrang it to the back, give it a (e.g. blue) background color. Insert a second frame (partly) above the first. Check its background is no-fill. The no-fill frame will display as a frame with white background. Expected: No-fill background is transparent. Only when selecting white as BG it should be white.
Created attachment 43689 [details] See Comment 1 [Reproducible] with "LibreOffice 3.3.1 RC2 – WIN7 Home Premium (64bit) German UI [OOO330m19 (build 8 / tag 3.3.1.2)]" A rectangle without filling shows 100% transparency as expected. A frame without filling unexpectedly shows 100% white background.
[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
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
reproduced in 3.5.5 and 3.6.0 on Fedora 64 bit option "No fill" result in filling with color of page (not white color)
It is not explicitly stated that the frame described in this bug is that created via Insert > Frame... although I imagine it is. Refer my comment https://bugs.freedesktop.org/show_bug.cgi?id=62505#c2 about the anchor point influencing the background colour for this type of frame.
I can confirm that this is still an issue in 4.1.1.2. This behavior is even more apparent if you anchor the inserted frame to a frame with a gradient as a background. It will simply set the inner frame's background to the same gradient and display it on a smaller scale. There is a work around, though. Give the inserted frame a background color and set the transparency to 100%. After that, it should behave as you would expect "No Fill" to. I'm not sure if this transparency causes any additional processing for print/view/export. As a side note, 100% transparent frames are also my work-around for dealing with the effects of bug 61306 ("No Fill" frames inside transparent-filled-frames causing line artifacting.)
*** Bug 68001 has been marked as a duplicate of this bug. ***
*** Bug 62505 has been marked as a duplicate of this bug. ***
I just marked another report as a dupe of this one. The interesting thing about that report is that the no-fill frame inherited its background from a table's cell's background color. No-Fill frames seem to behave very differently based on where they are anchored. Here is a list of how a no-fill frame behaves when anchored to a... 1 Page with no set background The page background is ultimately white, so the inserted frame sets its background color to white, obscuring objects arranged behind it. 2 Page with set color background The frame takes background color of the page. This frame will obscure any objects behind it. 3 Page with graphic background The inserted frame does some magic and changes its background to be a cutout of the page's background image. This means it will *appear* to be transparent until you arrange the frame on top of another object. Then it shows straight through to the page's background. 4 Another frame with no set background The inserted frame takes background color (white if that frame didn't inherit a background from its anchor point). This frame will obscure objects/page background behind it. 5 Another frame with set color background The inserted frame takes background color. This frame will obscure objects/page background behind it. 6 Another frame with 100% transparent background The inserted frame takes background color from its anchor point, which was transparent, and works like we would expect. Both frames now work like we would expect a no-fill frame to, and show through to objects in the background. 7 Another frame with graphic background The inserted frame behaves kind of like it does when anchored to a page with a graphic background. It changes its background to be cutout of anchor point's background. Again, this means it will *appear* to be transparent until you put it on top of another object. It does something REALLY funky when the no fill frame that runs outside the parent graphic frame. Since it's just inheriting the background frame's graphic, it will tile that graphic instead of showing through to the actual page's background. 8 Frame with gradient background The inserted frame changes background to be the same as anchor point's background. At the least, it should be set to behave like if it were anchored to a frame with a graphic background, with pseudo-transparency. But it does something even worse--it sets its background to the same style of gradient but reproduces it on the scale of the inside frame. 9 Table with no background The frame takes background color (white if default). This frame will obscure objects/page background behind it. 10 Table with set color background The frame takes background color. This frame will obscure objects/page background behind it. 11 Table with graphic background The frame behaves like it does when anchored to a frame with a graphic background. It changes its background to be cutout of anchor point's background. Again, this means it will *appear* to be transparent until it runs out of the table. It then does the same funky thing a no fill frame does when anchored to another frame with a graphic background and tiles the graphic, obscuring any objects/page background behind it. 12 Paragraph with background set to color (the case of this bug report!) The frame uses the anchor point's background color. The paragraph style overrides any other container style (page/frame/table), so the no fill frame will have a background of the paragraph style, even if it's in a container with another background. This will obscure any objects behind the no-fill frame. 13 Paragraph with graphic background The frame uses the anchor point's background color, which is a graphic. I'm not sure when you would ever use a graphic as a background for a paragraph, but that's another story. Just like with the paragraph with a colored background, the inserted frame will override any container backgrounds. It will act like a no fill frame inserted into a frame or table with a background, and begin to tile the image when it's stretched. It too will obscure any objects behind the frame. 14 Character style with any background The inserted frame falls back to the paragraph style, not using the character style's background. It doesn't inherit the character's style, even when anchored to character. I'm sure there are more cases of things that frames can be anchored to/inherit its background from, but these were the only examples I could think of. I could even create a sample document with examples if needed.
*** Bug 60525 has been marked as a duplicate of this bug. ***
I'm having this exact problem with Libre Office 4.3.0.4
Thanks for additional testing. Sorry, but 'version' is where bug appeared. Not a current version. If bug no more exist then we just close bugreport. Changing back to 3.3.0 Thanks again for interesting in this bug.
*** Bug 82005 has been marked as a duplicate of this bug. ***
Bug persists in LibreOffice 4.3.1.2
While in 4.2 and 4.3 on right click there is Frame-Background, in 4.4 master there is Frame-Transparency. Looking at https://bugs.freedesktop.org/attachment.cgi?id=43689, in 4.3 "No background filling" didn't have Transparency option. In 4.4, there is Transparency option and it can be set. Couldn't reproduce and seems solved to me. Found while looking at Bug 84294.
(In reply to Timur from comment #18) > While in 4.2 and 4.3 on right click there is Frame-Background, in 4.4 master > there is Frame-Transparency. > Looking at https://bugs.freedesktop.org/attachment.cgi?id=43689, in 4.3 "No > background filling" didn't have Transparency option. In 4.4, there is > Transparency option and it can be set. > Couldn't reproduce and seems solved to me. Found while looking at Bug 84294. I just tested in the latest 440 master nightly as of 2014-11-06_00:36:43 and I am still able reproduce this bug. Even though the area transparency settings have been expanded and moved to another tab, the setting this bug is concerned with is the fill property of "None." This property still makes the frame simply inherit the fill color of the anchor point instead of being truly transparent. I opened the same sample document in the nightly and it behaves the same way all other versions of OpenOffice and LibreOffice have behaved. The frames with an area fill setting of "None" still inherit the background color of white. The only difference is that the new interface didn't implement the constraint to automatically grey out the transparency setting when No-Fill is selected. So, one can now actually set 100% transparency on a No-Fill frame... IMO, a fill setting of "None" should simply toggle transparency to "Solid 100%" transparency. Also, moving to "Solid 100%" transparency should simply set the frame to be a no-filled frame. Changing to anything other than a "Solid 100%" should move fill from "None" to something else. For compatibility with the current behavior, perhaps there should be another fill type of "Inherited" that inherits background from the anchor point. Basically, it's hard to "fix" this issue without destroying compatibility. A quick search found this OpenOffice bug from 2004 that was closed for this very reason: https://issues.apache.org/ooo/show_bug.cgi?id=32724 There is also an open bug report from 2003 here: https://issues.apache.org/ooo/show_bug.cgi?id=20209 In those bug reports, this issue is characterized as a "historical design flaw." It has not been addressed by the current 4.4.0 master, unless something changed in the past week.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.