Bug 59326 - FORMATTING: Foreground and Background Problems of Frames and Basic Shapes in “Wrap Through“ Mode
Summary: FORMATTING: Foreground and Background Problems of Frames and Basic Shapes in ...
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
Whiteboard: BSA
Depends on:
Blocks: Anchor-and-Text-Wrap
  Show dependency treegraph
Reported: 2013-01-13 17:42 UTC by Harald Koester
Modified: 2021-06-15 16:20 UTC (History)
3 users (show)

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

Example document in order to explain the problems (18.80 KB, application/vnd.oasis.opendocument.text)
2013-01-13 17:42 UTC, Harald Koester

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Koester 2013-01-13 17:42:23 UTC
Created attachment 72964 [details]
Example document in order to explain the problems

Problem description: 

I recognized three incorrectnesses according the display of frames and drawing elements. Hence there is a close relationship between these 3 items I describe them here in one bug report. If necessary I can split them into 3 reports. In order to explain the bugs have a look at the attachment. 

At the top of the page there is a paragraph with the paragraph background colour light blue. Some lines beneath there is another paragraph with the character background colour yellow. Furthermore there are a rectangle (orange background) and a frame (grey background). Both are in “Wrap Through” mode and are pushed to the background. 
You can see that the display is different between paragraphs with a filled paragraph background and a filled character background. Hence the frame and the rectangle are pushed to the background, I expect in both cases, that paragraphs (characters, background and border lines) completely cover the frame and the rectangle. That means nothing of the frame/rectangle can be seen in filled areas. So the area of the first paragraph (blue) is displayed wrongly and the area of the second paragraph (yellow) is displayed correctly.

At the bottom of the page there is another paragraph (character colour: magenta) and also another rectangle (left side) and another frame (right side). 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. 

Have a look to the arrow at the red border line of the rectangle. The rectangle is in the foreground. Hence I expect, that the border line covers the characters (magenta) of the paragraph and not the other way round.
Operating System: Windows 7
Version: release
Comment 1 Joel Madero 2013-11-21 01:39:20 UTC
Hi Harold,

First let me apologize for the long delay. That being said we will need three bug reports. This one will be for the first point only and I have confirmed it so:

Thank you for reporting this issue! I have been able to confirm the issue on:
Platform: Ubuntu Linux 13.04 x64
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
Marking as:

New (confirmed)
Normal - can prevent professional quality work
Medium - default seems appropriate as this isn't a regression and probably not impacting a ton of people

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:

There are also other ways to get involved including with marketing, UX, documentation, and of course developing -  http://www.libreoffice.org/get-help/mailing-lists/. 

Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
Comment 2 Harald Koester 2013-11-22 22:44:42 UTC
Hi Joel,

for (2) and (3) I created new bug reports: Bug 71920, bug 71921.

+ + + + + + + + + + + + + + + + + + + + + + + +

By the way some words according to your marking of bugs:
In order to clarify how bugs are prioritised TMO it is a good thing to comment this - like you did it here - in bug reports. Some time ago I thought about something similar: What about writing a short summary of the bug triage. It may look like this:


Bug triaged according "https://wiki.documentfoundation.org/QA/BugTriage":
Step 2: No duplicates found.
Step 3: Information complete and comprehensible.
Step 4: Reproducible with version 4.1.3, OS: Win 7
Step 5: Status set to NEW. Platform set to "All", because reproducible with 
        Win and Linux.
Step 6: Prioritisation:
        "Normal" - can prevent professional quality work
        "Medium" - default seems appropriate as this isn't a regression 
        and probably not impacting a ton of people.


(1) It is reproducible, which triage steps have been performed and which still have to be performed.
(2) For a bug reporter it's more transparent what happens with "her/his" bug.
(3) People recognise how triaging works and are encouraged to join triaging.

Con: Some more writing.

+ + + + + + + + + + + + + + + + + + + + + + + +
Comment 3 Joel Madero 2013-11-22 23:04:40 UTC
Hey Harald, 

Indeed I agree that it's good for QA to get into good habits. What we try to avoid is telling contributors "this is how it's done", instead we lead by example and make suggestions. I actually just have a template that I copy and paste from (most of the time).

As for finding duplicates - I can admit I rarely do this, it's too time consuming when we have over 1,100 bugs waiting to be confirmed. I'd rather confirm the bug and move it to NEW than spend 10 minutes searching for a duplicate. Some would say this is me triaging poorly I would suspect ;)

Many of our triagers do look at this flowchart: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg 

when prioritizing which I think is a good idea. In general people seem happy when they see how we prioritized (occasionally we get unhappy users who want their minor bug to be marked as a blocker which is unfortunate as it just ruins our workflow).

At minimum a triager should include:
Their OS
LibreOffice version
some friendly comment saying confirmed

Prioritizing - while helpful, isn't required. At some point we'll go through all the confirmed bugs and prioritize them but first is getting through these unconfirmed bugs.

If you're interested in helping (we could surely use it) please send me a personal email and we'll talk :)
Comment 4 QA Administrators 2015-04-19 03:23:11 UTC Comment hidden (obsolete)
Comment 5 Harald Koester 2015-05-09 16:49:44 UTC
Case (1): Bug still exists in version with Win7.
Comment 6 QA Administrators 2016-09-20 10:14:12 UTC Comment hidden (obsolete)
Comment 7 Harald Koester 2016-09-28 12:47:53 UTC
Case (1): Bug still exists in version 5.2.1 with Win7.
Case (1): Bug already exists in version 3.3.0. Hence inherited from OOo.
Comment 8 QA Administrators 2018-06-24 02:41:00 UTC Comment hidden (obsolete)
Comment 9 Harald Koester 2018-06-26 10:56:36 UTC
Case (1): Bug still exists in version 6.0.5 (64 bit) with Win10.
Comment 10 QA Administrators 2019-06-27 02:54:23 UTC Comment hidden (obsolete)
Comment 11 Harald Koester 2019-06-28 10:00:09 UTC
Case (1): Bug still exists in version 6.2.4 with Win10.
Comment 12 Riyadh 2021-02-02 23:32:48 UTC
Case (1): Bug still exists in version with Win10.