Bug 91140 - ODF Import: Frame Area changed from image to color:white / 100% transparent on invalid legacy documents
Summary: ODF Import: Frame Area changed from image to color:white / 100% transparent o...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.0.3 release
Hardware: Other All
: high normal
Assignee: Not Assigned
URL:
Whiteboard: odf target:5.0.0 target:4.4.4 target:...
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-07 15:30 UTC by tmacalp
Modified: 2015-05-25 14:55 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example legacy doc containing a frame with an image applied to background (330.79 KB, application/vnd.oasis.opendocument.text)
2015-05-07 15:30 UTC, tmacalp
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tmacalp 2015-05-07 15:30:44 UTC
Created attachment 115420 [details]
Example legacy doc containing a frame with an image applied to background

When loading legacy odt documents in LibreOffice 4.4, a frame with an image set as the background is loaded incorrectly.  The frame's area is changed to color: white and the transparency is set to 100%.

LibreOffice 4.4 brought many changes to the way frame backgrounds are handled.  The changes brought quite a few bugs dealing with loading frames with an image applied to their background areas.  Many of these bugs were fixed, but I still have many legacy documents that are affected.

We've been using some form of StarOffice/OpenOffice/LibreOffice since before Sun aquired StarOffice.  Many of our documents are based on templates originally created a decade ago.  Some of these documents are very complicated newsletters kept for archival purposes.

This is probably very similar to (if not the same bug as) bug 86578 and bug 90640, but the patches don't fix legacy documents.  Rather than go through the nightmare of reopening those, I'm creating this new report.

The frames loaded correctly in versions up to 4.4.0.  I tested this in 4.4.3.2 and the most recent nightly and it is still broken:

Version: 5.0.0.0.alpha1+
Build ID: 6e78bf76f3a10b43475e1bd801bdcbb9ce62f668
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2015-05-07_00:08:39
Locale: en-US (en_US.UTF-8)
Comment 1 V Stuart Foote 2015-05-07 17:50:44 UTC
Confirming.  Frame background image is visible in
Version: 4.3.7.2
Build ID: 8a35821d8636a03b8bf4e15b48f59794652c68ba

But not visible when the ODT is opened in 4.4.0+, including current builds of master. And if saved there, the background graphic is being lost to a "color" fill in white. Reopening in < 4.3.7.2 no longer shows background graphic--the Penguin .PNG is deleted from the ODF archive, so there is data loss as things are.
Comment 2 Michael Stahl (CIB) 2015-05-15 15:12:08 UTC
the document has this in content.xml:

      <style:graphic-properties fo:background-color="transparent" style:background-transparency="100%" draw:fill="solid">
        <style:background-image xlink:href="Pictures/10000000000002A6000001B3A05E6B9F.png" xlink:type="simple" xlink:actuate="onLoad" style:repeat="stretch" draw:opacity="100%"/>
      </style:graphic-properties>


... the draw:fill="solid" in there is clearly bogus given that everything
else implies it has a background image.

  <meta:generator>LibreOffice/4.3.4.1$Linux_X86_64 LibreOffice_project/bc356b2f991740509f321d70e4512a6a54c5f243</meta:generator>

sigh... what are the steps to create such an invalid document / how many of these documents are out there?
Comment 3 Michael Stahl (CIB) 2015-05-15 16:05:38 UTC
hmm so if i load and store the attachment, the draw:fill is preserved starting here:

c5cf7905a2df4660695afe4f690e8d466931b58c..bc4f4de5fde53a46ff835a150f3128db2f63f860

which contains some commits about adding Gradient background like:

commit bb00150ef62ccd256b3e8ec2dabec5eb2d6a667f
Author:     Miklos Vajna <vmiklos@suse.cz>
AuthorDate: Tue Jan 29 11:10:22 2013 +0100

    xmloff: export Wrtier's RES_FILL_STYLE and RES_FILL_GRADIENT
    
commit 81a46fc86a530f028a5bd2f5e52fe0372d50ee38
Author:     Miklos Vajna <vmiklos@suse.cz>
AuthorDate: Mon Jan 28 18:07:45 2013 +0100

    SvXMLExport::_ExportStyles: also try to export text gradients
    
    They are not exported automatically, as SvxUnoNameItemTable needs a
    Which ID, and it's different for drawinglayer and Writer gradients.
Comment 4 Michael Stahl (CIB) 2015-05-15 19:02:17 UTC
added a workaround on master
Comment 5 Commit Notification 2015-05-15 19:02:22 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=97887cd810194ee556d2ec12f2a8be40075c29d2

tdf#91140: ODF import: try to ignore invalid draw:fill="solid"

It will be available in 5.0.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 6 Commit Notification 2015-05-18 10:34:00 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=fad75997e6060c63e6d79327573dd51950da1acb&h=libreoffice-4-4

tdf#91140: ODF import: try to ignore invalid draw:fill="solid"

It will be available in 4.4.4.

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 7 Commit Notification 2015-05-22 16:44:46 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=12f907da9535ae9fb28fb7ef1b05240eabf51e82

tdf#91140: tweak fix a bit, turns out xmloff was also passing empty URL

It will be available in 5.0.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 Commit Notification 2015-05-22 16:46:16 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7dba64e6e4e7dfa4268b5d4c3ba296ac02aa814b&h=libreoffice-5-0

tdf#91140: tweak fix a bit, turns out xmloff was also passing empty URL

It will be available in 5.0.0.0.beta2.

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 9 Commit Notification 2015-05-25 14:55:00 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7cbcb57df49d8b0cc28c28c5a04bcac464b504fb&h=libreoffice-4-4

tdf#91140: tweak fix a bit, turns out xmloff was also passing empty URL

It will be available in 4.4.4.

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.