Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index

On 15/03/2014, Jim Seymour <> wrote:
On Sat, 15 Mar 2014 03:25:43 -0700 (PDT)
Pedro <> wrote:

nabbler wrote
Please go to m$ and ask if m$office is compatible with the ODF
standard of LO

THAT is exactly the problem! There should never be an "ODF standard
of LO".

I read that as "compatible with the ODF standard, as implemented in
LO."  I.e.: LO uses the ODF standard.  Does MS Office?

Did I read that wrong?  Or does LO not properly implement the ODF

It seems that only yourself and IV (in terms of responses, of course!)
understood correctly. Once again, these types of questions expose a
strategic weakness of those seeking to see open source software
increase in popularity.

The original question asked whether LO is compatible with m$, hence
the reciprocal question as the answer.

It is not known why the original poster (HB) asked this (silly)
question: is (s)he an m$ fan, read elsewhere that LO is "compatible"
with m$ the therefore concludes that LO is a m$ to create perfect m$
documents without having to pay the m$ tax ("licence fee")? If the
answer is (hopefully) no, then the poster should ask LO about
compatibility with m$, but instead compatibility with odf (and also
ask m$ the same question!).

If the original poster and other m$-fans want perfect m$ documents (a
laughable concept, considering the poor quality of m$o, but that's
another discussion), they should please stop complaining, stop asking
and simply pay for a legal copy of m$!!! LO is not an m$-clone! It
(rightly) has nothing to do with m$! The native file format of LO is
odf, _not_ m$!!!

It was amazing to read that there should never be an odf standard,
because LO is so perfect with the rapid introduction of gratuitous new
features (10-year bugs? Who cares about quality, when we have a new
feature to rush out now!). This is the exact strategy of m$, netscape,
etc. in the past: embrace (the standard); extend (the standard);
extinguish (kill the standard!). Apparently, Oasis are at fault for
being slow, methodical and serious about standards development (by
definition, a rigourous, tedious and necessarily time-consuming job);
therefore LO should continue to "improve". As commented elsewhere,
such an opinion is ignorant of the concept of the standard development

If the default behaviour of LO is to produce documents _beyond_ the
current odf standard, it's a bad idea, equivalent to the "extend the
standard" mentality as described previously. If LO wants to see the
development of odf (not necessarily the increase in LO usage: the two
objectives are not equal!), so that the strategic benefit of true
document compatibility is maintained, the odf standard must be the
default. Users must then be made aware of any non-standard features
(writing a list of these "new features" in the "release notes" is not
enough and merely an expedient action).

Those interested in the odf standard for future document compability
and flexibility want to be able to write an odf text document today in
lowriter, an openformula compliant ods spreadsheet tomorrow in localc
and be able to use (in theory, not confirmed) odf-compliant gnumeric,
or abiword, or kwrite, etc. 10 years from now to open those documents.
Otherwise, what is the purpose of the odf standard?

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.