Bug 91292 - FORMATTING: DOCX, Paragraph background color set to 'No Fill' not persisted on save
Summary: FORMATTING: DOCX, Paragraph background color set to 'No Fill' not persisted o...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.3.2 release
Hardware: All All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:6.1.0 target:6.2.0 target:6.1.2
Keywords: bibisectRequest, filter:docx, regression
Depends on:
Blocks: DOCX-Paragraph
  Show dependency treegraph
 
Reported: 2015-05-14 18:19 UTC by Will
Modified: 2020-10-23 05:57 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Will 2015-05-14 18:19:21 UTC
Steps:
 1 Start a new, blank Writer document.
 2 Enter some text.
 3 Set paragraph background to any color.
 4 Save as DOCX, close, re-open.
 5 Set paragraph background to no color ('No Fill').
 6 Save as DOCX, close, re-open.
 7 Observe that background HAS reverted from step 5 'No Fill' to step 3 color.

Expected Results:
 1 DOCX Paragraph background color of 'No Fill' is persisted across saves.

Notes:
 1 Set paragraph background to any color.
 2 Save as DOCX, close, re-open.
 3 Set paragraph background to another color.
 4 Save as DOCX, close, re-open.
 5 Observe that background has NOT reverted from step 3 color to step 1 color.
Comment 1 Michael 2015-05-14 18:58:18 UTC
I can confirm that this problem is in 4.3.7.2 (linux 64bit), except that step 7 shows the background color is set to 'white' rather than the step 3 color.

Also I can not reproduce this with ODT format, it seems DOCX specific.
Comment 2 A (Andy) 2015-05-14 19:58:25 UTC
Reproducible with LO 4.4.3.2, Win 8.1
Comment 3 QA Administrators 2016-09-20 09:41:43 UTC Comment hidden (obsolete)
Comment 4 Telesto 2017-04-11 08:58:22 UTC
Reproducible with:
Version: 5.4.0.0.alpha0+
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-04-05_23:32:27
Locale: nl-NL (nl_NL); Calc: CL

and with
Versie: 4.4.6.3 
Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d
Locale: nl_NL

but not with
Version: 4.3.0.4
Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0
Comment 5 Justin L 2017-10-27 16:40:20 UTC
The ability to round-trip the background was lost as of LO 4.4 commit 7d9bb549d498d6beed2c4050c402d09643febdfa by Author: Armin Le Grand on
CommitDate: Tue Jul 1 13:30:09 2014 +0200
   Related: #i124638# Second step of DrawingLayer FillAttributes...
   for Writer objects, now added support for Paragraph and PageStyle (including
   Header and Footer) for direct attributes and style attributes

At that point, you can't even SEE that a background color is set, until LO5.0 commit 24077b2d52ab3d0fd0db5afb25d8b94b62386e3e by Author: Miklos Vajna on CommitDate: Sun Feb 1 01:48:38 2015 +0100
        writerfilter: import paragraph color as fill attributes

        In theory this is to be in sync with the ODF import. In practice the old
        UNO property seems not to have a proper fallback to populate the doc
        model with the fillattributes, so without this even if the import result
        is visible, it would be lost on ODF export.

It looks like FormatFillStyle needs to update the m_pBackgroundAttrList?  This total hack worked...
if ( m_pBackgroundAttrList.is() && rFillStyle.GetValue() == drawing::FillStyle_NONE )
{
    m_pBackgroundAttrList = FastSerializerHelper::createAttrList();
    m_pBackgroundAttrList->add( FSNS( XML_w, XML_fill ), "auto" );
    m_pBackgroundAttrList->add( FSNS( XML_w, XML_val ), "clear" );
}
Comment 6 Justin L 2017-10-30 18:40:24 UTC
I'm going to put this fix on the backburner, so that it can have a full testing period in 6.1.  https://gerrit.libreoffice.org/44040
Comment 7 Commit Notification 2018-01-11 10:02:03 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=29d57a3f0c60afc1bd3a79a01e18e99bf4e8edcb

tdf#91292 ooxmlexport: cleared fill != use grabbag info

It will be available in 6.1.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 8 Xisco Faulí 2018-02-12 18:45:51 UTC Comment hidden (obsolete)
Comment 9 Commit Notification 2018-08-24 04:30:48 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2902771581ccd6465b3e8cdca0aa3fcb6d51ca60

tdf#91292 docx export: COL_AUTO != cleared fill

It will be available in 6.2.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2018-08-31 07:54:17 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4235206c340f0a8e8cc38b18403a7f0fbee04f7a&h=libreoffice-6-1

tdf#91292 docx export: COL_AUTO != cleared fill

It will be available in 6.1.2.

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

Affected users are encouraged to test the fix and report feedback.
Comment 11 Dieter 2020-10-23 05:57:05 UTC
Fixed in

Version: 7.0.2.2 (x64)
Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: he-IL (de_DE); UI: en-GB
Calc: threaded

but there's the same problem with paragraphs in a table (see bug 137683). Perhaps you can have a look at it, Justin?