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)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Anchor-and-Text-Wrap Object-Fill Frame
  Show dependency tree / graph
 
Reported: 2013-11-22 13:08 UTC by Harald Koester
Modified: 2023-06-14 03:12 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:

Attachments
Example with image, frame and formula (28.75 KB, application/vnd.oasis.opendocument.text)
2017-11-01 15:52 UTC, Regina Henschel 		Details
View All Add an attachment (proposed patch, testcase, etc.)

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: 4.1.3.2 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: 4.4.0.0.alpha0+ Build ID: 7ed283b9bcdde1ae7d858d04880115a1b5a45315

Marking as normal-high

Kind regards,
Joren
Comment 3 Harald Koester 2015-05-09 16:53:22 UTC 
Bug still exists in version 4.4.3.2 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: 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
Comment 16 Stéphane Guillou (stragu) 2021-06-13 12:51:20 UTC 
So, in essence, isn't this a duplicate of Bug 34585 ?
Comment 17 QA Administrators 2023-06-14 03:12:47 UTC 
Dear Harald Koester,

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 https://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://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug