Bug 1030674 - PNG replacement image inserted in wrong order (odf spec violation)
Summary: PNG replacement image inserted in wrong order (odf spec violation)
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: libreoffice
Version: 20
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-14 22:23 UTC by moondrake
Modified: 2013-11-15 14:18 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-15 14:18:03 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 62461 0 None None None Never

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


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