Bug 34585 - Frame with no-fill background has white background instead of transparent
Summary: Frame with no-fill background has white background instead of transparent
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
: 60525 62505 68001 82005 (view as bug list)
Depends on:
Blocks: Frame
  Show dependency treegraph
Reported: 2011-02-22 16:12 UTC by Kissaki
Modified: 2022-05-03 06:35 UTC (History)
17 users (show)

See Also:
Crash report or crash signature:

See Comment 1 (10.46 KB, application/vnd.oasis.opendocument.text)
2011-02-22 22:27 UTC, Rainer Bielefeld Retired

Note You need to log in before you can comment on or make changes to this bug.
Description Kissaki 2011-02-22 16:12:15 UTC
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.

No-fill background is transparent.
Only when selecting white as BG it should be white.
Comment 1 Rainer Bielefeld Retired 2011-02-22 22:27:52 UTC
Created attachment 43689 [details]
See Comment 1

[Reproducible] with "LibreOffice 3.3.1 RC2 – WIN7  Home Premium  (64bit) German UI [OOO330m19 (build 8 / tag]"
A rectangle without filling shows 100% transparency as expected.
A frame without filling unexpectedly shows 100% white background.
Comment 2 Björn Michaelsen 2011-12-23 11:49:39 UTC Comment hidden (obsolete)
Comment 3 Florian Reisinger 2012-08-14 14:02:10 UTC Comment hidden (obsolete)
Comment 4 Florian Reisinger 2012-08-14 14:03:11 UTC Comment hidden (obsolete)
Comment 5 Florian Reisinger 2012-08-14 14:07:45 UTC Comment hidden (obsolete)
Comment 6 Florian Reisinger 2012-08-14 14:09:51 UTC Comment hidden (obsolete)
Comment 7 sasha.libreoffice 2012-08-24 09:29:09 UTC
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)
Comment 8 Owen Genat (retired) 2013-07-30 05:34:59 UTC
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.
Comment 9 tmacalp 2013-09-10 03:24:59 UTC
I can confirm that this is still an issue in

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.)
Comment 10 tmacalp 2013-10-07 19:51:14 UTC
*** Bug 68001 has been marked as a duplicate of this bug. ***
Comment 11 tmacalp 2013-10-08 16:27:22 UTC
*** Bug 62505 has been marked as a duplicate of this bug. ***
Comment 12 tmacalp 2013-10-08 16:36:57 UTC
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.
Comment 13 tmacalp 2013-10-10 13:55:29 UTC
*** Bug 60525 has been marked as a duplicate of this bug. ***
Comment 14 Carlos Mazon 2014-07-31 11:49:52 UTC Comment hidden (obsolete)
Comment 15 sasha.libreoffice 2014-08-01 10:01:46 UTC Comment hidden (obsolete)
Comment 16 sophie 2014-08-01 16:07:31 UTC
*** Bug 82005 has been marked as a duplicate of this bug. ***
Comment 17 Carlos Mazon 2014-09-20 14:08:38 UTC
Bug persists in LibreOffice
Comment 18 Timur 2014-11-11 13:47:55 UTC Comment hidden (obsolete)
Comment 19 tmacalp 2014-11-12 21:57:25 UTC
(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.
Comment 20 tmacalp 2015-01-28 05:34:11 UTC
I tested LO 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:

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.
Comment 21 bugzilla 2015-03-06 21:12:50 UTC
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 on Win7, and as a new user I find issues like this very frustrating and reduce product confidence.
Comment 22 Eldar 2016-01-31 16:40:31 UTC Comment hidden (no-value)
Comment 23 Frank Berke 2016-02-13 17:59:52 UTC
Now testing LO 5.1 (Linux AMD64), I still see this bug.
Comment 24 QA Administrators 2018-08-24 02:43:53 UTC Comment hidden (obsolete, spam)
Comment 25 Regina Henschel 2020-07-10 15:55:48 UTC
Tested with Version: (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.
Comment 26 Stéphane Guillou (stragu) 2021-06-13 12:45:36 UTC
Reproduced as in Description with:

Version: / 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
Comment 27 alex 2022-05-03 06:01:56 UTC
This bug still exists in version
Comment 28 Rainer Bielefeld Retired 2022-05-03 06:35:25 UTC
Still REPRODUCIBLE with newly created writer document (and original sample document) and Server Installation of Version: (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