openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject [DISCUSS][POLICY?] Lost Features When Saving to ODF
Date Sun, 07 Feb 2016 19:51:53 GMT
[BCC to AOO Project Management Committee]


We have some situations of the following kind:

 1. An user is working in Apache OpenOffice and makes use of various features that appear
to succeed and the desired result is visible in the presentation.

 2. When the working document is saved in the default OpenDocument format, the save occurs
and there is no observed indication that the saved document is in any way different than what
the user sees.

 3. On later opening the document from the saved file, the thought-to-be successful feature
result is corrupted to something else.  

 4. There are three flavors of this condition:
    a. It is a bug (e.g., change-tracking in AOO Writer that is not preserved across a save
in OpenDocument Text file format).
    b. A feature that works if saved to Microsoft Office format yet silently fails without
any indication when the document is saved to OpenDocument format.  E.g.,
    c. Situations, similar to (a), where a document is saved in an Office format such that
it is opened successfully in Office, but not back in AOO.  There is no problem with saving
as OpenDocument though, and it is apparently an inconsistency between export and import. I've
seen this; I don't have an example handy. 


Category (4a) and (4c) cases are essentially defects.

Category (4b) presents policy questions concerning interoperability.

THE QUESTION IS, should the policy be that interoperability in interchange via OpenDocument
Format has precedence and is by default?

Please [DISCUSS].

 - Dennis



The background principle is that any silent loss of features in saving to default, native
formats is a serious usability issue, since it occurs as loss/corruption to the user. It is
necessary to consider how to prevent such confidence-undermining behaviors while also supporting
users in what we want them to be able to accomplish.

Using the example from (4b), the problem is that the illustrated feature is found in .xls

 1. The feature works in Excel and is presented by AOO Calc as expected on import of the .xls.
 The feature can be applied in AOO Calc by an user with an opened .xls, .ods, or brand new

 2. The feature can be preserved on saving to a .xls document but it cannot be preserved in
OpenDocument Spreadsheet (.ods) document.  Instead, saving to .ods *silently* alters the document
to a form that is acceptable in the OpenDocument Spreadsheet format.

 3. Note that on saving to .xls, the rubber-stamp warning about possible loss of features
occurs, but in this case the feature is not lost.  There is no such warning when the feature
in its unsupported form is transformed and saved as an .ods file.


These are not proposals.  They are just to illustrate the complexity of the policy question.

 1. In the specific case of the (4b) example, it is pretty clear that the feature adjustment
happens during Save and there is no good way to know, before Save starts, that such a condition
will arise without prior detection.  We would then be faced with warning an user, either prior
to or after the save, that a feature was not preserved and saving as an .xls should be done
to retain it.  If we instead did a reload so that the altered form can be seen, the original
will be lost from the still-open document.  (Note that there is nothing to be done if the
save happens as part of a shut-down of AOO or even the computer.)

 2. Another approach is to restrict features to those that are preserved in ODF formats by
AOO and to not allow their exercise otherwise. This means that the formatting done in the
example of situation (4b) would not be allowed.  It also means that, on import of an Office
document where features are not preserved, the user be warned that has happened.

 3. There is a middle case.  If a feature such as that of (4b) is preserved on round-trips
from an AOO non-native format (such as .xls) but not OpenDocument, there could be a warning
on opening of such a non-native format when there are features of the document that are only
preserved if the document is only saved back to the same format.  (Those should be documented
somewhere, of course.)  If the feature is not supported at all, alternative (2) here could
  Warning could also pop-up when an user relies on such a feature in an edit, if not already
warned.  If the document is saved to AOO-native OpenDocument format, then alternative (1)
above could kick in.  Since more is known, in this case, the warning in (1) could happen before
the save is carried out, just as there are (unfortunately rubber-stamp) warnings on saves
to non-native formats.


Except for doing nothing or rejecting documents in some heavy-handed way, any improvements
in this area will likely have to be gradual and will all depend on our capacity and capability
for making changes in this area.  It may mean that we do nothing for an extended time.

That does not mean we should be unclear about what our policy is about these questions.  It
just remains to ensure that future execution is aligned.
 *** end of further considerations ***

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message