You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by "Dennis E. Hamilton" <or...@apache.org> on 2016/02/07 20:51:53 UTC

[DISCUSS][POLICY?] Lost Features When Saving to ODF

[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


Re: [DISCUSS][POLICY?] Lost Features When Saving to ODF

Posted by "Keith N. McKenna" <ke...@comcast.net>.
Dennis E. Hamilton wrote:
> Patricia,
> 
> I share your disdain for rubber-stamp feature-loss warnings.  It
> arouses FUD and does not help users, especially concerning their
> expectations for support of Microsoft formats.
> 
Dennis; Let us remember that those warnings have been in OpenOffice
since at least the beta for version 2 that I am aware of, and most
likely before. Then all of the Microsoft formats were proprietary and
support of them was based on whatever specs Microsoft chose to release
and reverse engineering. Support of those older binary formats has
vastly improved over the years, but is still not perfect. Since AOO does
not yet write the newer Microsoft XML based formats the old binary ones
are all we have for collaboration with many Microsoft users.

Keith

> This is apparently a tit-for-tat activity between Microsoft Office
> and the OpenOffice.org family.
> 
> The message that AOO uses is nearly a literal version of what the
> Microsoft Office software puts up when a non-native Save is requested
> [;<).  So we mirror their worst feature.
> 
> It is interesting that when Microsoft Office documents have features
> that cannot be preserved with full fidelity (i.e., uploading to
> OneDrive and accessing via Office Web or mobile application versions)
> by MSO variants, there are specific warnings in the case of such
> recognized feature-loss if the document is edited.
> 
> - Dennis
> 
> PS: One of my dreams about interoperable use among standard formats
> and known profiles of conformance would be to have a processor that
> actually identified the features that are not preservable and allowed
> user review of the consequences before doing anything irreversible.
> And also finding ways to make things not so irreversible.  I said
> dream. It is probably beyond my grasp and I doubt such a prospect
> could be grafted into AOO.  My thinking is that one would have to
> architect and design for that from the very beginning.
> 
>> -----Original Message----- From: Patricia Shanahan
>> [mailto:pats@acm.org] Sent: Sunday, February 7, 2016 15:00 To:
>> dev@openoffice.apache.org Subject: Re: [DISCUSS][POLICY?] Lost
>> Features When Saving to ODF
>> 
>> On 2/7/2016 11:51 AM, Dennis E. Hamilton wrote: ...
>>> 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.
>> ...
>> 
>> As an OpenOffice user, I find the rubber-stamp warning useless to
>> the point of being annoying. I get it on the most vanilla text
>> documents that do not, in practice, lose any features.
>> 
>> ---------------------------------------------------------------------
>>
>> 
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org



RE: [DISCUSS][POLICY?] Lost Features When Saving to ODF

Posted by "Dennis E. Hamilton" <de...@acm.org>.
Patricia,

I share your disdain for rubber-stamp feature-loss warnings.  It arouses FUD and does not help users, especially concerning their expectations for support of Microsoft formats.

This is apparently a tit-for-tat activity between Microsoft Office and the OpenOffice.org family.

The message that AOO uses is nearly a literal version of what the Microsoft Office software puts up when a non-native Save is requested [;<).  So we mirror their worst feature.

It is interesting that when Microsoft Office documents have features that cannot be preserved with full fidelity (i.e., uploading to OneDrive and accessing via Office Web or mobile application versions) by MSO variants, there are specific warnings in the case of such recognized feature-loss if the document is edited.

 - Dennis

PS: One of my dreams about interoperable use among standard formats and known profiles of conformance would be to have a processor that actually identified the features that are not preservable and allowed user review of the consequences before doing anything irreversible.  And also finding ways to make things not so irreversible.  I said dream. It is probably beyond my grasp and I doubt such a prospect could be grafted into AOO.  My thinking is that one would have to architect and design for that from the very beginning.

> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Sunday, February 7, 2016 15:00
> To: dev@openoffice.apache.org
> Subject: Re: [DISCUSS][POLICY?] Lost Features When Saving to ODF
> 
> On 2/7/2016 11:51 AM, Dennis E. Hamilton wrote:
> ...
> > 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.
> ...
> 
> As an OpenOffice user, I find the rubber-stamp warning useless to the
> point of being annoying. I get it on the most vanilla text documents
> that do not, in practice, lose any features.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Re: [DISCUSS][POLICY?] Lost Features When Saving to ODF

Posted by Patricia Shanahan <pa...@acm.org>.
On 2/7/2016 11:51 AM, Dennis E. Hamilton wrote:
...
> 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.
...

As an OpenOffice user, I find the rubber-stamp warning useless to the 
point of being annoying. I get it on the most vanilla text documents 
that do not, in practice, lose any features.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org