Bug 140336 - FILESAVE: DOCX RTF: Inherited background colour not cancelled, but assigned
Summary: FILESAVE: DOCX RTF: Inherited background colour not cancelled, but assigned
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.0.3 release
Hardware: All All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:7.2.0 target:7.3.0
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Blocks: DOCX-Frames
  Show dependency treegraph
 
Reported: 2021-02-11 12:34 UTC by Telesto
Modified: 2021-06-18 17:34 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (13.82 KB, application/vnd.oasis.opendocument.text)
2021-02-11 12:34 UTC, Telesto
Details
The original document and its docx version in Writer (131.66 KB, image/png)
2021-02-16 09:06 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2021-02-11 12:34:07 UTC
Description:
Background color of frame off after export

Steps to Reproduce:
1. Open the attached file
2. Save as DOCX
3. File reload
4. Compare

Actual Results:
Text in dark red square

Expected Results:
Same as ODT


Reproducible: Always


User Profile Reset: No



Additional Info:
Found in
Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 3ed9bba283a6a67864c0928186e277240be0d9ba
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

4.4.7.2

white square in 4.3
Comment 1 Telesto 2021-02-11 12:34:22 UTC
Created attachment 169669 [details]
Example file
Comment 2 Roman Kuznetsov 2021-02-12 09:23:26 UTC
confirm in

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 6ab1feb2604d2620435a2aecbafff1d8c21255e9
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: threaded
Comment 3 NISZ LibreOffice Team 2021-02-16 09:06:08 UTC
Created attachment 169777 [details]
The original document and its docx version in Writer

Looks like the paragraphs inside the frame get an unexpected dark red background color.
Comment 4 NISZ LibreOffice Team 2021-02-16 09:15:02 UTC
Worked in:

Version: 4.4.0.3
Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7
Locale: hu_HU

But not anymore in:
Version: 5.0.0.5
Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b
Locale: hu-HU (hu_HU)
Comment 5 NISZ LibreOffice Team 2021-02-16 10:04:23 UTC
Seems to have started with:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=60cdeb2d441a6bf5c55f511f574b2b9dd598fbb8

author	Miklos Vajna <vmiklos@collabora.co.uk>	2015-01-31 10:55:39 +0100
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2015-01-31 10:57:50 +0100

tdf#88583 MSWordExportBase: fix handling of paragraph background color
Comment 6 Justin L 2021-03-25 18:53:07 UTC
I can't believe it took so long for this bug report to surface. I guess it isn't often that you assign a background colour, and then cancel it. But it affects both paragraphs, and para-styles (and has nothing to do with frames).

Items with XATTR_FILLSTYLE == NONE have conflicts with XATTR_FILLTRANSPARENCE (and perhaps some others). Seen by duplicate opacity values in
ooxmlexport6: fdo74605.docx, 
ooxmlexport7: test77219.docx, testWordArtWithinDraingtool.docx, fdo78663.docx

Proposed fix at gerrit.libreoffice.org/c/core/+/113105
Comment 7 Justin L 2021-03-27 09:15:25 UTC
(In reply to Justin L from comment #6)
> Items with XATTR_FILLSTYLE == NONE have conflicts with XATTR_FILLTRANSPARENCE
Probably not accurate. Instead, it is probably the failure to getFlyFillAttrList().clear() when bTextBoxOnly.

Apparently the "fake" textframe has no fill attributes (well, except for directly specifying FILLSTYLE_NONE, and FILLTRANSPARENCE), so it otherwise would never populate FlyFillAttrList.

So that is probably why failing to clear FlyFillAttrList wasn't a regression.
commit 6b5c0a5cb25fc0c7c673a9332c8d30b6efbb819b
Author: Miklos Vajna on Jun 16 19:38:38 2014 +0200
    VML export: handle textbox text
    
    Previously, we always exported the text of the shape itself. Bring the
    VML export in sync with the drawingML export, where we only do that if
    the shape doesn't have an associated textbox -- if that's the case, then
    export the textbox's text instead.
Comment 8 Telesto 2021-03-27 15:44:06 UTC Comment hidden (no-value)
Comment 9 Commit Notification 2021-03-30 10:51:18 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/8ef5d0f724b75ef62c20996271e9a6997ff6c3dd

tdf#140336 ms formats export: export NONE background for ParaBackColor

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2021-06-18 17:34:24 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/83dc9d3b77f9f6b03af0e7a4be4805e4ecf12145

related tdf#140336 docxsdrexport: always clear vmlTextFrame attrs

It will be available in 7.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.