Download it now!
Bug 115457 - FILEOPEN: Footer background image replaced by blue area in ODT (comment 19)
Summary: FILEOPEN: Footer background image replaced by blue area in ODT (comment 19)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: low normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
: 112255 (view as bug list)
Depends on:
Blocks: Writer-Header-Footer Regressions-DrawingLayer-FillStyles
  Show dependency treegraph
Reported: 2018-02-05 09:05 UTC by LÉVAI Dániel
Modified: 2020-09-14 13:24 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

sample (597.55 KB, application/vnd.oasis.opendocument.text)
2018-02-28 18:38 UTC, Xisco Faulí
tdf115457_not_XATTR.odt: authored with LO 6.3 - footer image visible until LO 4.4. (20.20 KB, application/vnd.oasis.opendocument.text)
2018-12-31 13:46 UTC, Justin L
tdf115457_not_XATTR.odt: authored with LO 6.3 - footer image visible until LO 4.4. (63.57 KB, application/vnd.oasis.opendocument.text)
2019-01-02 13:02 UTC, Justin L

Note You need to log in before you can comment on or make changes to this bug.
Description LÉVAI Dániel 2018-02-05 09:05:49 UTC
Images in Write document footers are not saved (or reloaded) at all.

I've already reported this last year (112255) and it clearly got mistaken for some other problem and set to resolved -> duplicate... Nonsense. It's been broken since at least 5.4, and still broken in 6.0.

Steps to Reproduce:
1) Create new Writer doc
2) Insert / Header and Footer / Footer / Default style
3) Click inside new Footer
4) Click on "Footer (Default style)" drop-down menu on the top right corner of footer.
5) Click "Border and Background ..."
6) On the Background tab select "As: Image", click browse and select a picture. (it doesn't matter if you click "Link" or not)
7) Click position, select any position (eg. click on the dot in the center)
8) Click OK, save document
9) Close/reload document

Actual Results:  
Instead of the previously set image, a background color is set.

Expected Results:
Save and restore the background image of the footer!

Reproducible: Always

User Profile Reset: No

Additional Info:

User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36
Comment 1 Xavier Van Wijmeersch 2018-02-05 18:34:59 UTC
image is gone and a color is in place of the image

confirm with

Build ID: 949d7b670cda798c54de072ba9d8f0aabe8afd8c
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group
Comment 2 Timur 2018-02-20 12:15:56 UTC
Thank you for your persistence. Bug 112255 was correct and not a duplicate od DOC(x) issue. Was OK in 4.3.7 and started in 4.4.
Comment 3 Timur 2018-02-20 12:16:10 UTC
*** Bug 112255 has been marked as a duplicate of this bug. ***
Comment 4 Xisco Faulí 2018-02-28 18:38:24 UTC
The problem is at import time
Comment 5 Xisco Faulí 2018-02-28 18:38:53 UTC
Created attachment 140228 [details]

Document to reproduce the issue
Comment 6 Xisco Faulí 2018-02-28 18:40:44 UTC
Regression introduced by:

author	Armin Le Grand <>	2014-06-02 15:00:50 +0000
committer	Miklos Vajna <>	2014-07-01 13:30:09 +0200
commit	7d9bb549d498d6beed2c4050c402d09643febdfa (patch)
tree	2caf67e36c9ccd058268b003cf2bc39b9b102b53
parent	a5e137eb1d37361c60175e8fba780fc46b377a23 (diff)
Related: #i124638# Second step of DrawingLayer FillAttributes...

Bisected with: bibisect-44max

Adding Cc: to Armin Le Grand
Comment 7 Justin L 2018-12-31 13:41:19 UTC
OK - interesting note that there is almost identical functionality in "Format Footer" -> More -> Area:bitmap. That too was broken by the 4.4 commit, but fixed in LO 5.0 with commit 65a56636a68451d15499a37c2d5bd9efb71b1279
Author:     Michael Stahl 
CommitDate: Tue Apr 14 17:29:36 2015 +0200
    tdf#88337 tdf#89193: sw: add missing SwXPageStyle properties

It is still true in 6.3 master that the background from OP's "Borders and background" is lost, replaced by the default fill color. (And the default fill colour also started showing up at Michael's 5.0 commit.)
Comment 8 Justin L 2018-12-31 13:46:53 UTC
Created attachment 147907 [details]
tdf115457_not_XATTR.odt: authored with LO 6.3 - footer image visible until LO 4.4.

(In reply to Xisco Faulí from comment #4)
> The problem is at import time
Yes, that is a good observation. Even newly created documents must be using the old style attributes (since LO 4.3 shows them nicely), and not the new XATTR_FILL_*.
Comment 9 Justin L 2019-01-02 06:55:06 UTC
When loading the document in a debug build, I get this message:

warn:legacy.osl:svx/source/sdr/primitive2d/sdrattributecreator.cxx:640: No fill graphic in SfxItemSet (!)
Comment 10 Justin L 2019-01-02 13:02:44 UTC
Created attachment 147934 [details]
tdf115457_not_XATTR.odt: authored with LO 6.3 - footer image visible until LO 4.4.

Umm, my previous version of this document must have been created via the area/bitmap instead of borders/background. This one works up till 4.4.
Comment 11 Justin L 2019-01-02 16:21:19 UTC
fix proposed at
Comment 12 Jim Raykowski 2019-01-27 07:31:30 UTC
Hi Justin,

I noticed this bug when replacing the background tab page in Border/Background dialog with the new background tab page derived from the area tab page. 

Earlier today I asked on the mailing list about an observation I came across while trying to understand how this works and what is causing this bug. I did not know you were working on this. Found out while submitting a bug report. Hope the observation will help you. I don't have much knowledge about the xmloff stuff yet.

Here is the message I sent to the mailing list:

Greetings All,

Trying to make header and footer background images redisplay on opening. I noticed draw:fill="bitmap" in style:header-footer-properties in a .fodt test file.

    <style:header-footer-properties fo:min-height="0in" fo:margin-bottom="0.1965in" draw:fill="bitmap" style:repeat="repeat" draw:fill-image-ref-point="top-left">
 If draw:fill="bitmap" is removed the image shows on reopen. When not removed blue background fill is shown.
 Is draw:fill="bitmap" needed?

All the best
Comment 13 Regina Henschel 2019-01-27 13:23:06 UTC
Using draw:fill and associated attributes in invalid at all, both in 'ODF 1.2' and in 'ODF 1.2 extended'.
Comment 14 Justin L 2019-01-28 05:23:41 UTC
(In reply to Jim Raykowski from comment #12)
>  Is draw:fill="bitmap" needed?
The experts have never commented on any of my RES_BACKGROUND <-> XATTR_* patches, so my only knowledge about the subject is "it is broken, and this change makes it look right". But as Regina notes, this whole area is extremely complicated because practically LO has moved ahead of its specifications...

If I should abandon the patch in order to help push things back towards ODF-compliance, I'm happy to do that.
Comment 15 Jim Raykowski 2019-02-03 00:01:56 UTC
 (In reply to Justin L from comment #14)

> The experts have never commented on any of my RES_BACKGROUND <-> XATTR_*
> patches, so my only knowledge about the subject is "it is broken, and this
> change makes it look right".
Would this patch break this more than it is already broke? Making it look right seems to be a better than how it looks now.
Comment 16 Justin L 2019-02-19 18:29:32 UTC
abandoned patch from comment 11. I don't want to get involved in this thorny area, where implementation has preceded the specs.
Comment 17 Jim Raykowski 2019-02-19 20:20:12 UTC
When the patch for tdf#116382 is complete it should resolve this.
Comment 18 Aditya Sahu 2019-02-28 22:02:40 UTC Comment hidden (obsolete)
Comment 19 Justin L 2019-03-01 15:30:10 UTC
The document from comment 10 still doesn't load properly.  This file could have been created prior to 4.4, or in one particular way up to 6.2. So re-opening this issue to deal with the file import side of this bug, which the abandoned patch fixes (
Comment 20 Regina Henschel 2020-09-13 22:55:36 UTC
The error is in the document. The draw:fill-image-name is missing, so LibreOffice does not know what image to show.

I cannot reproduce the error, if I create a document with image in footer using Version: (x64)
Build ID: c01aa64b6c3d89ebe5fe69c28c7adb24eb85249c
CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL

I see the image in the footer, if I remove all draw:fill and related attributes, because then the style:background-image element is used. From point of ODF  style:background-image is the only method to get a background-image for the footer. Using draw:fill is invalid.
Comment 21 Timur 2020-09-14 06:11:25 UTC
Regina, upon your explanation, please mark bug as invalid or define a solution.
Comment 22 Regina Henschel 2020-09-14 13:24:09 UTC
The draw:fill and related attributes should not have been written at all, because they are invalid in this context.

We can try to solve the problem on import: In case a draw:fill="bitmap" is found but no draw:fill-image-name, ignore all the draw:fill related attributes. A further solution could be to generate a <draw:fill-image> element on the fly from the image given in the <style:background-image> element, if that exists. (Of cause this has not to be done on XML, but on the internal representation.)

A total different solution would be a separate repair tool, that corrects the XML directly and works on the file.

Because LibreOffice has produced such documents, I think marking as "invalid" would not be the correct way.