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)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Anchor-and-Text-Wrap
  Show dependency tree / graph
 
Reported: 2013-01-13 17:42 UTC by Harald Koester
Modified: 2023-06-16 03:13 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
Example document in order to explain the problems (18.80 KB, application/vnd.oasis.opendocument.text)
2013-01-13 17:42 UTC, Harald Koester 		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-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. 

(1)
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.

(2)
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. 

(3)
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: 3.6.4.3 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:
Version 4.1.1.3
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:
https://wiki.documentfoundation.org/QA/BugTriage

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.

---------

Pros:
(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 4.4.3.2 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 7.2.0.0.alpha0+ with Win10.
Comment 13 QA Administrators 2023-06-16 03:13:58 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