Description: 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
image is gone and a color is in place of the image confirm with Version: 6.1.0.0.alpha0+ Build ID: 949d7b670cda798c54de072ba9d8f0aabe8afd8c CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group
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.
*** Bug 112255 has been marked as a duplicate of this bug. ***
The problem is at import time
Created attachment 140228 [details] sample Document to reproduce the issue
Regression introduced by: author Armin Le Grand <alg@apache.org> 2014-06-02 15:00:50 +0000 committer Miklos Vajna <vmiklos@collabora.co.uk> 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
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.) .
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_*.
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 (!)
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.
fix proposed at gerrit.libreoffice.org/65811
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. https://gerrit.libreoffice.org/#/c/64016/ 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:page-layout-properties> <style:header-style> <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"> <style:background-image> <office:binary-data>iVBORw0KGgoAAAANSUhEUgAAApUAAACpCAYAAAENcfbOAAAACXBIWXMAAA7EAAAOxQGMMD9a ... 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 Jim
Using draw:fill and associated attributes in invalid at all, both in 'ODF 1.2' and in 'ODF 1.2 extended'.
(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.
(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.
abandoned patch from comment 11. I don't want to get involved in this thorny area, where implementation has preceded the specs.
When the patch for tdf#116382 is complete it should resolve this.
tdf#116382 has been resolved. Its patch can be found here: https://gerrit.libreoffice.org/#/c/67483/ The patch has also solved this bug, so I'm changing the status to RESOLVED - FIXED. Feel free to verify and update the status accordingly.
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 (https://gerrit.libreoffice.org/65811).
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: 7.0.0.2 (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.
Regina, upon your explanation, please mark bug as invalid or define a solution.
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.
This commit was developed for another code base, and not merged by me. For complex changes like this, side-effects are to be expected; sadly I dont't have the cycles to deal with all the fallout. Un-Ccing myself for the while.
repro 24.2+