Bug 159554 - Red vs. Orange background - BackgroundParaOverDrawings True vs. False
Summary: Red vs. Orange background - BackgroundParaOverDrawings True vs. False
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
24.2.0.3 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-02-04 16:39 UTC by heath
Modified: 2024-02-07 04:39 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
right and wrong files (3.99 MB, application/x-zip-compressed)
2024-02-04 16:44 UTC, heath
Details

Note You need to log in before you can comment on or make changes to this bug.
Description heath 2024-02-04 16:39:13 UTC
Description:
This is related to Bug #126513, but somehow different (see this link for a prelim discussion: https://www.reddit.com/r/libreoffice/comments/1aid2ri/frame_style_contains_false/). 

I have a strip of text with an area color that I'm just trying to keep in front of the background image. I can't put them in the same file - when I copy and paste the one that works correctly into any other file (including a brand new one), this issue shows up. Here's the two files...the 'right' one is how I want it to look...and the 'wrong' one is not how I want it to look. For the life of me, I can't figure out how to put the image completely behind the text area color (again, 'send to back' doesn't work). The image is always in front of that burgundy area strip in the 'wrong' file. I had created the 'right' file about a year or so ago in a previous version of Writer (not sure which version number - whatever was the newest version about a year ago).

Steps to Reproduce:
1. open the linked zip file which has two Writer documents (https://drive.google.com/file/d/1kAO5wg1BaxtJRHK3gYkCe9UtYpMUA-oz/view?usp=sharing)...the 'right' file was created in a prior version of Writer (a couple years ago in what was the current version).
2. Create a new Writer file and copy/paste the chart from the 'right' file to a the new file. (this is done in what I'm calling the 'wrong' file).
3. 

Actual Results:
You'll see that the area color on the text is always behind the image...no matter what I do, including 'send to back' on the image.

Expected Results:
The area color should be in front of the image.


Reproducible: Always


User Profile Reset: No

Additional Info:
example files (with the issue made in the current version of Writer and the file that works, created in the current version from a couple years ago) are here: https://drive.google.com/file/d/1kAO5wg1BaxtJRHK3gYkCe9UtYpMUA-oz/view?usp=sharing
Comment 1 heath 2024-02-04 16:44:00 UTC
Created attachment 192386 [details]
right and wrong files

the 'right' file is how I want it to look (created on a previous version of Writer). The wrong file is how it looks in a newly created Writer document.
Comment 2 Tex2002ans 2024-02-06 22:07:24 UTC
I can confirm this on:

Version: 24.2.0.3 (X86_64) / LibreOffice Community
Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1
CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

- - -

The root cause was a compatibility setting called:

- BackgroundParaOverDrawings

The "Right" file had:

- BackgroundParaOverDrawings = true

The "Wrong" file had:

- BackgroundParaOverDrawings = false

where:

- Right = Red background
- Wrong = Orange/Peach background (+ slightly different formatting)

- - -

Note #1: Me and Mike Kaganski live-debugged this one together a few days ago, so I am CCing him.

- - -

Note #2: Adding "Bug #126513" to See Also, based on Kaganski's detective-work. From what he was telling me, I believe it was:

- A setting that is possible to READ, but currently no way for LO to actually tweak/change/adjust after.
- On Copy/Paste to new document, trying to carry over these compatibility flags becomes a nightmare (and has caused many large regressions in the past).
Comment 3 Mike Kaganski 2024-02-07 04:39:57 UTC
(In reply to Tex2002ans from comment #2)
> - On Copy/Paste to new document, trying to carry over these compatibility
> flags becomes a nightmare (and has caused many large regressions in the
> past).

Right. Carrying compat flags was accidentally happening in the past, and became visible after commit a7d9837a8aa6d1233f4c21e4db5d32428a3ffc58, and caused bugs 151974, 151728, 152158 (see bug 151728 comment 4). It was fixed by commit 2d0a87f97e2c9ac50cd6ce329ca8256daf94ead4.

Carrying flags would mean that, while the copied data would look as it was in the source, the *already existing text* in the target document could suddenly change its formatting. It is the sad outcome of having compatibility flags at all; and we indeed try hard to allow working with external formats, with their differences in behavior.

The problem here is invisibility of the compatibility flag(s) to user. Making flags accessible is of course important, but even when we add that flag to the Options->Writer->Compatibility, will anyone really find out that some specific (of tens, potentially hundreds) flag there is responsible for the difference?

MS Word adds a "[Compatibility Mode]" decoration to the document's title bar. Would it help? Maybe. Yet, given the huge amount of compat flags, it is easily possible, that both of your documents are is "compatibility modes" (i.e., some of the compatibility flags are in non-default state), but in *different* compatibility modes...