openoffice-dev mailing list archives

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

A. THE SITUATION

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.,
<https://bz.apache.org/ooo/show_bug.cgi?id=126827>.
    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. 


B. THE POLICY QUESTION

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

FURTHER CONSIDERATIONS

C. COMPLICATIONS

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
documents.  

 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
document.  

 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.

D. ALTERNATIVES

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
apply.  
  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.

E. IMPLEMENTATION

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: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message