Bug 1030674 - PNG replacement image inserted in wrong order (odf spec violation)
PNG replacement image inserted in wrong order (odf spec violation)
Product: Fedora
Classification: Fedora
Component: libreoffice (Show other bugs)
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-11-14 17:23 EST by moondrake
Modified: 2013-11-15 09:18 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-15 09:18:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 62461 None None None Never

  None (edit)
Description moondrake 2013-11-14 17:23:46 EST
Libreoffice 4.x includes a non-configurable feature that includes a PNG image for most SVG images inserted into the document.

The png image is inserted first (possibly to make sure the documents open correctly in older OO.org versions that did not support svg). 

However, this causes older versions of Libreoffice that do include svg support to ignore the svg image and actually drop it from the file once saved. This causes content-loss in a mixed libreoffice 3.x -4.x environment (arguably worse in many cases than just not displaying the content)

The 1.2 ODF spec mentions:

"Each child element of a frame is a different representation of the same content. The order of content elements reflects the document author's preference for rendering, with the first child element being preferred. That means that consumers should render the first child element that they support. A frame may contain multiple content elements, but shall contain at least one content element."

Thus, LO should save the preferred image (that is, the inserted image) (svg) first, and saving png first should only be allowed by user intervention.

Furthermore, I find it questionable to needlessly default to saving bitmap graphics as a compatibility option. There is an option in LO to save compatible ODF that would be more suitable for doing this.

I added a reference to the upstream bug (somewhat polluted by some other issues).

An easy patch (reversing order of the frames) is possible.

A real fix by upstream would be making the behaviour configurable.
Comment 1 moondrake 2013-11-14 17:26:22 EST
Fix external ref.
Comment 2 Caolan McNamara 2013-11-15 09:18:03 EST
I track the mab's so lets move this upstream

Note You need to log in before you can comment on or make changes to this bug.