[upstream] flat xml format inaccuracy

[PeterPall]

Binary package hint: libreoffice

The flat XML formats of LibreOffice are very practical when working with version control systems like svn, mercurial, bazaar or cvs.

In lodraw saving files in the .fodt format seems currently to loose information, though:
After saving the file attached to this bug as flat xml and re-opening it
 - the drawing is no longer aligned to the grid
 - and some texts have whitespace attached that being of a much higher vertical size than the rest of the text (I think it was 12pt versus 6pt) ruin the layout.

If the file is saved in the .odt format in the ordinary .odt format instead on opening it will just look as it did before saving the file instead.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: libreoffice-draw 1:3.3.2-1ubuntu5
ProcVersionSignature: Ubuntu 3.0-1.2-generic 3.0.0-rc3
Uname: Linux 3.0-1-generic i686
NonfreeKernelModules: wl
Architecture: i386
Date: Mon Jun 20 06:23:46 2011
EcryptfsInUse: Yes
SourcePackage: libreoffice
UpgradeStatus: No upgrade log present (probably fresh install)

[Gioele Barabucci (gioele)]

Extra spaces (not typed by the user) are inserted by between `<text:span>` elements.

The following testcase illustrates the problem (`*` for bold, '/' for italic):

----
A*B/C/D*E
----

When saved in the ODT format, 'contents.xml' contains

----
<text:p text:style-name="Standard">A<text:span text:style-name="T1">B</text:span><text:span text:style-name="T2">C</text:span><text:span text:style-name="T1">D</text:span>E</text:p>
----

The same document saved in FODT (flat ODT) format end up containing

----
<text:p text:style-name="Standard">A<text:span text:style-name="T1">B</text:span>
  <text:span text:style-name="T2">C</text:span>
  <text:span text:style-name="T1">D</text:span>E</text:p>
----

That is, spaces are added around the second `<text:span>` element, the one containing the text 'C' with an italic style. When this file is read back, the content of the document is changed to

----
A*B /C/ D*E
----

Probably some XML processors used in the save path are indenting those elements because they think that text between `<text:span>` elements is ignored and, thus, these elements can be indented on a new line. If that is the case, adding `xml:space` declarations should avoid such issues.

[Octavio Alvarez (alvarezp)]

It happens with the following code too:

<text:p text:style-name="P1"><text:span text:style-name="T1">A</text:span><text:span text:style-name="T2">B</text:span><text:span text:style-name="T3">C</text:span><text:span text:style-name="T2">D</text:span><text:span text:style-name="T1">E</text:span></text:p>

No spaces, no newlines.

[Josefk-x (josefk-x)]

Created attachment 46948
Example file confirming and expanding bug #31707

Example FODT-file showing that the import XSL (?) insert extra whitespace after text:area and text:note during the import.

[Josefk-x (josefk-x)]

Not only text:area's are affected by this bug, text:note (footnotes, endnotes) are affected as well.

[Jean-Baptiste Lallement (jibel)]

Thanks for your report.
I confirm this in Oneiric with the sample file you provided. Settin to triage/high because of the data loss.

[Jean-Baptiste Lallement (jibel)]

The following warning is displayed on the terminal:
"""
Warning: at xsl:stylesheet on line 2 of file:///usr/lib/libreoffice/basis3.3/share/xslt/odfflatxml/odfflatxmlimport.xsl:
  Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
"""

---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

[PeterPall (peterpall)]

Thanks a lot!

The warning should be due to Bug #772537 and (hopefully) harmless.

[Björn Michaelsen (bjoern-michaelsen)]

needs upstream bug reference => Incomplete

[Björn Michaelsen (bjoern-michaelsen)]

Upstream => Wontfix in ubuntu packaging

[Björn Michaelsen (bjoern-michaelsen)]

[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html

[Gioele Barabucci (gioele)]

This bug seems fixed in LO 3.5-rc1.

[Libreoffice-z (libreoffice-z)]

<https://bugs.freedesktop.org/page.cgi?id=fields.html#status>