I believe that Mcrosoft Office can open a LibreOffice document (Writer or Calc).
So what is the advantage of saving a LibreOffice document in Microsoft format?
Only if you are forced to co-edit a document with a user of MSO (who also refuses to install a free alternative) you may prefer OOXML as an exchange format because LO supports foreign file formats better than MSO. For mere reading PDF is the file format for publishing.
No matter which file format you agreed on, you always store your own working copy in the native file format of your application and the other side always stores a working copy in the native file format of his/her application.
When you work with any application, save in its native format. This is the only way to guarantee that your document will always reopen as you intended.
ODF (Open Document Format) is an attempt to provide a non-proprietary format so that documents may be used without the fear that you can always use them hopefully because the encoding is open. Anybody can then implement an application to read them at least.
When the application saves under a closed (proprietary) format, you are vulnerable to any encoding change. And since the format is closed source, you have nearly zero chances to be able to recover your precious data. This has already happened in the past (look towards Redmond …).
LO offers the possibility to save under M$ formats but don’t expect miracles. Since the format is closed source, the conversion is only approximative to the point developers could retro-engineer M$ encoding. But, worse, both suites are based on different founding principles. This means that the features offered by both suite have a non-void intersection but features on both sides have no equivalent. They are therefore translated to the best of the LO developers’ knowledge and this is where your trouble begins. The translation is not perfect (Traduttore, traditore) and a round-trip will not return the exact image of the original file. Divergences accumulate with save-open cycles and in the end you have a dysfunctional document.
So ODF looks like THE solution. Unfortunately, M$ decided to introduce “extensions” to ODF resulting again in a proprietary format. So, yes, M$ can open ODF documents, as long as they don’t conflict with M$ “extensions”. This OK for simple document, but there are chances that very complex documents will behave weirdly in M$ and vice versa.
So you are saying that Microsoft is still actively employing the EEE strategy? I thought they abandoned that in the late '90s, but I guess we shouldn’t be surprised.
If MS unilaterally “adds” to the standard, this should not give trouble with documents edited in LO. A more likely cause is that both suites have a partial support, and some features used by LO is not supported by MSO (as well as vice versa). As I have gathered, “support” does not imply “full support” in either suite. If documents sourced from MSO are opened in LO, those extensions you mention are of course a threat.
You know more than I do about the internal workings of LO, @ajlittoz , so please set me straight if there is something I am missing. While I don’t experience much trouble in the situation at hand (using ODF in transition between the suites), I am always eager to learn. More importantly, the info may be useful to the OP.
Microsoft’s OOXML is an open standard that they do not follow in their own products. OOXML is a lot more complicated, a lot more difficult to comply with than ODF. ODF is as complicated as necessary and as simple as possible. OOXML has been bribed through the international standardization boards in order to fight ODF as a binding standard in public services.
@keme1
As usual, working native with any application is the safe strategy.
In LO: ODF under all its variants .odt (Writer), .ods (Calc), …
In MSO, M$ formats.
Problems arise when you transmit your documents to the other suite. Whatever you do, the file must be transformed to an internal form to be processed. This internal form is not necessarily the same as the external encoding. I’d even dare say it is never the same because you manipulate data in memory while you only store on external media. This internal form is based on the application abstract model. This model is defined once and for all (at least between major revisions) and is “independent” from the external form. An input file must be coerced into the model. This means that even if the file can be read because there is an ad-hoc input filter, it does not imply that all the input structures have an equivalent in internal format.
An obvious example is character and pages styles in Writer (which I know best). There is no such thing in M$ Word.
- Then on LOW->M$W (.doc(x)), Writer replaces character styling by direct formatting and page styling by a hard page break followed by a manually-crafted Word “section”.
- Reciprocally, M$W->LOW (.odt), Word won’t create styles (character + page) because it has no such concept in its internal format. It will simply encode its (direct) formatting into an ODF direct formatting.
This is a very basic example. When it comes to inserted fields, they don’t cover the same data in both suite. Consequently some fields can’t be converted. Table dimensional extension is not based on the same principle (by default in Writer from margin to margin). I’ll just mention list numbering which causes also many headaches.
So the conclusion boils down to the golden rule (platinum rule?): always, always, always store your file in native format.
And if your documents are intended to be archived for at least a decade, prefer an open format so that you can hope to still read them or ask a skilled IT friend to extract the data under some usable form (which is relatively easy with ODF as it is XML).
1 Like
When working on a document alone, it is never an advantage.
When collaborating with MSO users, it is rarely an advantage. MS Office only supports autosave for ooxml files, so the MSO users may be annoyed by the requirement to save the document. Se also the answer from @ajlittoz, in particular his explaining the politics in file formats.
The only situation where it makes sense to save to MS formats is if you are going to submit your file to an entity which insists on MS format.
This entity may e.g. be a print/publishing service which does internal processing, or an exam upload which will strip personal info to anonymize a submission before grading, if their systems only support Microsoft formats. It may also be your teacher, though that should be increasingly rare now.