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.
I tested LO 4.4.0.3 a bit and can confirm that the behavior for no-fill frames is relatively the same as originally reported. No-fill frames still just inherit the background from their anchor point. One change that's new in 4.4 is that a no-fill frame that's nested in (and anchored to) a slightly transparent frame will now stack its transparency with the background frame. In 4.3, the nested no-fill frame would still inherit the background frame's color/transparency, but would drop one layer to blend in and try to match the background frame. But that might be another bug. Another change in 4.4 is that with older documents, no-fill frames are being converted to white/100% transparent on file open. This will make a lot of test documents appear to work properly. This might be related to bug 87369. I created an attachment for another bug report that demonstrates some weird no-fill frame inconsistencies: https://bugs.documentfoundation.org/attachment.cgi?id=95338 If testing the above attachment in 4.4, find all frames labeled no-fill and turn their area settings to type "None" and 0% transparency.
This thread confirms the problems I'm finding with items created in DRAW not displaying properly when placed in a Writer frame, but work ok when pasted directly on the page. My default setting for frames was Area fill= None, Transparency= None, and the defects only appeared after reloading a file. I found that Text boxes and lines (arrows etc) displayed ok but that shapes (circles, rectangles) all "disappeared". The workaround I found (and mentioned in this thread) was to set Area Fill= Colour e.g. white, Transparency = Solid, 100%, which precludes using any frame background colour. I'm using LO 4.4.0.3 on Win7, and as a new user I find issues like this very frustrating and reduce product confidence.
Why this bug still not fixed? I have troubles when I want to apply style to cells. This bug overrides background color in cells to white color.
Now testing LO 5.1 (Linux AMD64), I still see this bug.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Tested with Version: 7.1.0.0.alpha0+ (x64) Build ID: c5b985bc9bd8d56fb012260cb1685a617261e7fc CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL The error still exists. Despite showing a white background, in file the frame has the style attributes fo:background="transparent" and draw:fill="none". It Word opens the odt file, the frame is transparent.
Reproduced as in Description with: Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: bb54d6d8241a06a6772052b77b67d6a4f686426c CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-11_20:14:38 Calc: threaded
This bug still exists in version 7.2.6.2.
Still REPRODUCIBLE with newly created writer document (and original sample document) and Server Installation of Version: 7.4.0.0.alpha0+ (x64) Build ID b000d964fcc8849d10576bf3539bde7729db2eb1 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: default; VCL: win Locale: de-DE (de_DE); UI: en-US | Calc: CL | Auto Colibre Theme | Special devUserProfile