Adding pretty=True causes extra spaces in output

[keestux]

Let's assume a simple sequence, read an ODT, write it to some other file.

    mydoc = Document(inp_fname)

    content = mydoc.get_part('content')

    mydoc.save(target=output_fname, pretty=True)

The call to get_part shouldn't be doing much, but it is essential for the bug to show up. Probably reading anything from mydoc will trigger it.

If the input ODT contains simple text paragraphs. However, some of the text is edited, delete a letter in a word, or add a letter in a word. The result is a Paragraph with multiple spans. Something like

      <text:p text:style-name="P7">
        <text:span text:style-name="T12">This is an example with =&gt;</text:span>
        <text:span text:style-name="T5"> v</text:span>
        <text:span text:style-name="T8">8</text:span>
        <text:span text:style-name="T5">.1.</text:span>
        <text:span text:style-name="T8">4</text:span>
        <text:span text:style-name="T5"> &lt;</text:span>
        <text:span text:style-name="T12">= spaces </text:span>
        <text:span text:style-name="T13">after reading and writing with odfdo.</text:span>
      </text:p>

The input document shows:

This is an example with => v8.1.4 <= spaces after reading and writing with odfdo.

The output document shows:

This is an example with => v 8 .1. 4 < = spaces after reading and writing with odfdo.

[keestux]

The example program

#!/usr/bin/env python3

from odfdo import Document, Paragraph

mydoc = Document('BugOdfdo.odt')

content = mydoc.get_part('content')

mydoc.save(target='BugOdfdo2.odt', pretty=True)

[keestux]

Here is the example input ODT BugOdfdo.odt

[keestux]

Maybe it is a bug in LibreOffice. When I look at content.xml there is nothing different, except for the white space (pretty print).

[jdum]

Hi, thanks for this interesting bug. Actually I'm not sure to remember of what should be the correct interpretation of the standard. But a few first thoughts:

• as main ODF implementation, let's consider LibreOffice as "always right"...
• I'm surprised the pretty option breaks things, however maybe I use it mainly to analyse and debug the XML result, not in actual production code,
• the ODF standard says: http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html at "3.18White Space Processing and EOL Handling" that "ODF processing of whitespace characters is in conformance with the provisions of XML, ..." but this can be quite complex (ODF uses the "tail" part of XML tags, aka the text after the tag itself...), and ODF has a special feature for multiple white chars. And if I remember, XML knows about "significant" and "insignificant" whitespaces (thus allowing the pretty output?). Thus a whitespace at "tail" position of a Span inside a paragraph, between Span tags is unclear for me. Should be insignificant as XML, but maybe still significant in ODF ?
• As a result, at least, I should add some information about the pretty print to possibly breaks the rendering in major ODF softwares.