Bug 71920 - FORMATTING: Text is not shown behind frame set to 'Wrap Through' and with fill set to None (see comment 10 for implementation rqmt)
Summary: FORMATTING: Text is not shown behind frame set to 'Wrap Through' and with fil...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: high normal
Assignee: Not Assigned
Whiteboard: BSA
Depends on:
Blocks: Anchor-and-Text-Wrap Object-Fill Frame
  Show dependency treegraph
Reported: 2013-11-22 13:08 UTC by Harald Koester
Modified: 2021-06-13 13:28 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:
Regression By:

Example with image, frame and formula (28.75 KB, application/vnd.oasis.opendocument.text)
2017-11-01 15:52 UTC, Regina Henschel

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Koester 2013-11-22 13:08:42 UTC
Problem description: 

I recognized three incorrectnesses according the display of frames and drawing elements. This report describes one of them. The others are described in other bug reports. All three bugs are visible in attachment 72964 [details]. Have a look at this attachment.

At the bottom of the page there is paragraph (character colour: magenta), a rectangle on the left side (red) and a frame on the right side (blue). Rectangle and frame are both in “Wrap Through” mode but in this case they are in the foreground. Furthermore they are not filled with background colours.

You can see that there is a difference between the display of a rectangle and a frame. If such an element (frame, rectangle, ellipse,...) is not filled with a colour, it means for me that the transparency is 100 %. And that means everything beneath the element should be visible. Hence I expect that in the frame area the paragraph (character colour: magenta) should be visible. 
Operating System: Windows 7
Version: release
Comment 1 Harald Koester 2013-11-22 22:48:06 UTC
The other two bugs mentioned above are described in bug 59326 and bug 71921.
Comment 2 Jorendc 2014-07-16 20:29:52 UTC
Reproducible, tested using Linux Mint 17 x64 with LibreOffice Version: Build ID: 7ed283b9bcdde1ae7d858d04880115a1b5a45315

Marking as normal-high

Kind regards,
Comment 3 Harald Koester 2015-05-09 16:53:22 UTC
Bug still exists in version with Win7.
Comment 4 QA Administrators 2016-09-20 09:42:54 UTC Comment hidden (obsolete)
Comment 5 Harald Koester 2016-09-28 13:48:06 UTC
Bug still exists in version 5.2.1 with Win7.
Bug already exists in version 3.3.0. Hence inherited from OOo.
Comment 6 Xisco Faulí 2017-09-29 08:50:37 UTC Comment hidden (obsolete)
Comment 7 Harald Koester 2017-11-01 10:23:48 UTC
Checked with version 5.4.2 (64 Bit, Win 10). Bug still exists. 

Furthermore I Discovered that the transparency is set to "No transparency" (Context menu > Properties > Transparency) in the example file. To my opinion in case of an unfilled area the transparency is always 100 %. Other value do not make sense. Hence a transparency of 100 % should be displayed in the Tranparency tab and there should no possibility to change this value i.e. all options should be greyed.
Comment 8 Yousuf Philips (jay) (retired) 2017-11-01 13:15:44 UTC
The main question is whether or not frames should act like textboxes with this regards, as presently, the frame is using the fill color of the page when it doesnt have a fill color set, and if i set the frame's area transparency to 100%, it will then show the text behind it.

Heiko, Stuart, Regina: thoughts?
Comment 9 Heiko Tietze 2017-11-01 14:04:27 UTC
I wonder what use case would be covered with wrap-through and transparent. Sounds like a useless combination of properties. The most common option is Page Wrap as we have today, where transparency is only relevant when the page has a background. Don't see a benefit when we change color and/or wrapping and/or transparency (not clear what is suggested).

My take is WONTFIX (also bug 59326)
Comment 10 Regina Henschel 2017-11-01 15:52:54 UTC
Created attachment 137421 [details]
Example with image, frame and formula

The attached document contains: top-left a Writer-image, top-right a text-frame, bottom-right a Draw-image, bottom center a formula, bottom-right a T-shape. All these objects have styles, which belong to the family "graphic". Those do not have "background" but draw:fill and draw:opacity attribute.

I agree with the reporter, that if draw:wrap="run-through" is set as hard formatting, the shape should be transparent. That can be done by setting draw:opacity="0%" in the automatic-style.

Currently LibreOffice does not set draw:fill and draw:opacity at all for the "frames". (Those objects, which have frame styles in the Styles panel of the sidebar.) Therefore an "implementation-dependent value is used" [spec section 16.2]. I consider this as bad for interoperabilty. I suggest to add draw:fill and draw:opacity to the styles "Frame", "Graphics" and "Formula"
Comment 11 Regina Henschel 2017-11-01 16:11:48 UTC
Additional problems are:
The UI has only "None" for the area filling and does not distinguish whether the attribute draw:fill="none" is actually set or whether the attribute is missing and an inherited or -here- an implementation-dependent value is use.

The attribute draw:fill="none" as attribute in the automatic style does not set the frame to be transparent, whereas a T-shape becomes transparent with this attribute. That is inconsistent, because from view of file format there is no difference between a frame and a T-shape.
Comment 12 Heiko Tietze 2017-11-15 20:31:30 UTC
We talked about this topic in the design meeting. Suggestion is to change the behavior of frames and make it transparent by default with fill style None. 

It's perhaps an easyhack.
Comment 13 Aron Budea 2017-11-24 10:04:09 UTC
Needs code pointer and mentioning of difficulty/required skill/topic.
Comment 14 QA Administrators 2021-06-13 03:49:03 UTC Comment hidden (obsolete)
Comment 15 Stéphane Guillou (stragu) 2021-06-13 09:07:54 UTC
reproducible in:

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 16 Stéphane Guillou (stragu) 2021-06-13 12:51:20 UTC
So, in essence, isn't this a duplicate of Bug 34585 ?