Bug 1030674

Summary: PNG replacement image inserted in wrong order (odf spec violation)
Product: [Fedora] Fedora Reporter: moondrake
Component: libreofficeAssignee: Caolan McNamara <caolanm>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 20CC: caolanm, dtardon, erack, ltinkl, mstahl, sbergman
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-15 14:18:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description moondrake 2013-11-14 22:23:46 UTC
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 22:26:22 UTC
Fix external ref.

Comment 2 Caolan McNamara 2013-11-15 14:18:03 UTC
I track the mab's so lets move this upstream