Saving an odt file without any modification changes the styles in content.xml

vinc17 · September 22, 2024, 11:57pm

When I open an existing odt file and save it with “Save As” without any modification, the styles in content.xml are changed (see below an example of a part of a diff). I would have expected to get exactly the same contents.

What is the cause and how to avoid this issue?

More generally, I have an odt file that will be modified by several users (on different machines), often with just minor changes. For various reasons (e.g. comparing the raw contents, and avoid huge diffs when different versions of the corresponding fodt file are stored in a VCS), I would like to keep changes in content.xml minimal.

Example of a part of the diff:

   <office:font-face-decls>
-    <style:font-face style:name="Lucida Sans1" svg:font-family="'Lucida Sans'" style:font-family-generic="swiss"/>
     <style:font-face style:name="Liberation Mono" svg:font-family="'Liberation Mono'" style:font-family-generic="modern" style:font-pitch="fixed"/>
-    <style:font-face style:name="NSimSun1" svg:font-family="NSimSun" style:font-family-generic="modern" style:font-pitch="fixed"/>
-    <style:font-face style:name="Liberation Serif" svg:font-family="'Liberation Serif'" style:font-family-generic="roman" style:font-pitch="variable"/>
-    <style:font-face style:name="Times New Roman" svg:font-family="'Times New Roman'" style:font-family-generic="roman" style:font-pitch="variable"/>
     <style:font-face style:name="Liberation Sans" svg:font-family="'Liberation Sans'" style:font-family-generic="swiss" style:font-pitch="variable"/>
-    <style:font-face style:name="Lucida Sans" svg:font-family="'Lucida Sans'" style:font-family-generic="system" style:font-pitch="variable"/>
+    <style:font-face style:name="Liberation Serif" svg:font-family="'Liberation Serif'" style:font-family-generic="roman" style:font-pitch="variable"/>
+    <style:font-face style:name="Lucida Sans" svg:font-family="'Lucida Sans'" style:font-family-generic="swiss"/>
+    <style:font-face style:name="Lucida Sans1" svg:font-family="'Lucida Sans'" style:font-family-generic="system" style:font-pitch="variable"/>
     <style:font-face style:name="Microsoft YaHei" svg:font-family="'Microsoft YaHei'" style:font-family-generic="system" style:font-pitch="variable"/>
-    <style:font-face style:name="NSimSun" svg:font-family="NSimSun" style:font-family-generic="system" style:font-pitch="variable"/>
+    <style:font-face style:name="NSimSun" svg:font-family="NSimSun" style:font-family-generic="modern" style:font-pitch="fixed"/>
+    <style:font-face style:name="NSimSun1" svg:font-family="NSimSun" style:font-family-generic="system" style:font-pitch="variable"/>
+    <style:font-face style:name="Times New Roman" svg:font-family="'Times New Roman'" style:font-family-generic="roman" style:font-pitch="variable"/>
   </office:font-face-decls>
   <office:automatic-styles>
     <style:style style:name="P1" style:family="paragraph" style:parent-style-name="Text_20_body">
       <style:text-properties style:font-name="Times New Roman" fo:font-size="12pt" style:font-size-asian="12pt" style:font-size-complex="12pt"/>
     </style:style>
-    <style:style style:name="P2" style:family="paragraph" style:parent-style-name="Text_20_body">
-      <style:text-properties style:font-name="Times New Roman" fo:font-size="12pt" fo:font-style="italic" style:font-size-asian="12pt" style:font-style-asian="italic" style:font-size-complex="12pt" style:font-style-complex="italic"/>
-    </style:style>
-    <style:style style:name="P3" style:family="paragraph" style:parent-style-name="Preformatted_20_Text">
+    <style:style style:name="P2" style:family="paragraph" style:parent-style-name="Preformatted_20_Text">
       <style:text-properties style:font-name="Times New Roman" fo:font-size="12pt" style:font-size-asian="12pt" style:font-size-complex="12pt"/>
     </style:style>
+    <style:style style:name="P3" style:family="paragraph" style:parent-style-name="Text_20_body">
+      <style:text-properties style:font-name="Times New Roman" fo:font-size="12pt" fo:font-style="italic" style:font-size-asian="12pt" style:font-style-asian="italic" style:font-size-complex="12pt" style:font-style-complex="italic"/>
+    </style:style>
     <style:style style:name="T1" style:family="text">
       <style:text-properties fo:font-weight="bold" style:font-weight-asian="bold" style:font-weight-complex="bold"/>
     </style:style>

mikekaganski · September 23, 2024, 5:45am

Do they use the same LibreOffice versions?

vinc17 · September 23, 2024, 7:21am

No, and this is not possible in practice: LibreOffice evolves over the years. For instance, I have a file that is 5 years old, and the edition will span additional 5 years. Note that ensuring to get the same “office:version” value by changing Tools → Options… → Load/Save → General → “ODF format version” does not have any effect on the styles written in “content.xml”.

BTW, for one of the odt files, I need to change Tools → Options… → LibreOffice Writer → General → “Measurement unit” from the default “Inch” to “Centimeter”. Otherwise, when I save the file, all units are changed from “cm” to “in”. Here again, I would have expected the unit used in the original document to be preserved.

mikekaganski · September 23, 2024, 7:22am

Well, if you need unchanged results, use unchanged versions
But regarding ODF units, I agree. Or rather, I would expect all the units saved in mm, irrespective of original and of the user locale and app units, just because that’s the unit used in the API, so it minimizes the rounding errors (even for Imperial units used by user).

vinc17 · September 23, 2024, 8:08am

Well, if the styles are fixed by the LibreOffice version (which is bad: there should be some compatibility setting), I hope at least that if one saves with version A, then with version B, then with version A again (I cannot try, at least right now), one gets the same styles in the first and last copies saved with version A (round-trip).

For the units, I was wondering of a possible issue of diverging values due to rounding each time the file is edited by users saving with different units. It appears that using centimeters and millimeters are equivalent when saving the file: for cm, LibreOffice rounds to 3 fractional decimal digits, and for mm, it rounds to 2 fractional decimal digits, so that we have the same set of representable values. This should limit issues if some users choose cm and others choose mm. But this may not be true if other units are chosen by some users.

mikekaganski · September 23, 2024, 8:12am

If you see difference in version A → version B → version A roundtrip, which you didn’t mention before - that would be curious to check; but even that is not something we guarantee (in fact, even inside one version it may change - just we hope it would be minimal)…

See also: tdf#88298

vinc17 · October 4, 2024, 1:17am

Even saving with some fixed LibreOffice version is not idempotent. There’s the rename of ids as mentioned in tdf#85660, but there are also more surprising changes: the draw:z-index values sometimes change, and text spans with the same style may be merged as follows.

<text:span text:style-name="T51">A</text:span><text:span text:style-name="T51">B</text:span>

is transformed to

<text:span text:style-name="T51">AB</text:span>

I’m wondering why this was not done on the first save.

Moreover, on some text:list, saving the original .odt file with LibreOffice 24.2.5 or 24.8.2 preserved a text:continue-list attribute. But this attribute disappeared when I first saved the original .odt file with LibreOffice 24.2.5, then saved the resulting file with LibreOffice 24.8.2.

When comparing the generated PDFs, I’ve also noticed that LibreOffice 24.2.5 (libreoffice 4:24.2.5-4 Debian package) breaks the references. For instance, “see 5.3.2, 5.5.2, and 5.7.3” is changed to “see 1.1.2, 1.1.2, and 1.1.1”. There is no such issue when I save the original .odt file directly with LibreOffice 24.8.2.

mikekaganski · October 4, 2024, 5:45am

You may consider filing the problems one by one as bugs. The Z-order one is a clear one; the span merge and continue-list need investigation (and regarding the latter, I have changed handling of it not too long ago).

EDIT: after re-reading your “the draw:z-index values sometimes change”, it doesn’t tell how it change; so it also needs investigation, because if it doesn’t change the relative order of the objects, it is legitimate to change the order of “object 1: zo0rder 2; object 2: z-order 5” into “object 1: zo0rder 0; object 2: z-order 1” (even if it’s clear why one could want it to stay intact).