LO compatibility

users
#21

[snip]

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

[snip]

I don't think the OP's original question silly. I think he or she
wanted to know if LibréOffice's support for MS Office formats was
compatible with those of MS Office's.

A reasonable question, in my view. The poor guy or gal, rather than
getting an answer to his or her question, instead ran into a buzz saw
of anti-proprietary-formats sentiment, criticisms of Microsoft's
behaviour and arguments about LO's implementation of non-standard
"standards."

So, to answer the OP's original question (at least as I believe it to
have meant): "Kind of more-or-less." Probably more more than
less :). I use the LibréOffice suite *exclusively*, and encounter few
problems with the documents generated by my MS-Office-using
colleagues.

    In fact: The only problem I've run into recently was attempting
    to export an MS Word document into PDF. LibréOffice Writer
    mangled the output. I had to resort to MS Office on my company
    laptop, booted into MS-Windows, accomplish the task.

My experience is limited to .doc/.docx and .xls/.xlsx files. I do no
PowerPoint (tho I did once do a presentation in LO's native
presentation format), nor do I use the database application (Base).

Is Draw able to read/write Visio files? Never even thought about
that. I don't do much of that kind of thing, either.

Regards,
Jim

#22

My initial impression was the question was vague because there are several MSO formats especially when you included the ones deprecated by MS. I was not sure if original question was badly phrased out of ignorance or to troll. I could understand that many do not understand that MS has several MSO formats and a simple question could lead to it being misunderstood. Which formats are important to the user. I still must use MSO XP formats because many people I need to send spreadsheets are still using MSO XP not the newer formats.

#23

ODF as implemented by OpenOffice and then LibreOffice has always been
the "extended" version, and not the "strict standard" version, although
it has always been possible to choose the latter. ODF become a standard
in 2006, based on OOo 2.0 (2005) file format, but OOo was already
shipping some additional features which have been integrated in ODF 1.2
(consolidated in 2008, and standardized in 2011).

Today, LibreOffice integrates some additional features in ODF 1.2, which
will hopefully become part of ODF 1.3 (like font embedding). In general,
saving as ODF 1.2 Extended does not create problem to users of other ODF
compatible software, as the format is backward compatible (so font
embedding will not create problems, but will not be recognized by other
software).

This is the reason why LibreOffice suggests ODF 1.2 Extended, and not
the ODF 1.2 "strict" version. Being the format XML based, the tags will
not be recognized if they belong to ODF 1.2, but this will not create
problems to the document.

#24

Practical implementations of a proposed standard are wonderful, but,
before it's part of the standard, documents written with such
extensions are, _by definition_, non-standard formats.

It's a worry that some users prefer new "features" over standards
compliance and quality control.

In my opinion: LibréOffice ought not be writing documents, by
default, in non-standard formats.

Agree, it means that if a user is concerned about compatibility, they
must understand to disable the default settings in LO.

How does OO compare; are documents created to the odf standard by default?

#25

ODF as implemented by OpenOffice and then LibreOffice has always been
the "extended" version, and not the "strict standard" version, although
it has always been possible to choose the latter. ODF become a standard
in 2006, based on OOo 2.0 (2005) file format, but OOo was already
shipping some additional features which have been integrated in ODF 1.2
(consolidated in 2008, and standardized in 2011).

Thanks for this information. The difference between extended and
strict allows for confusion to occur. In the option
"load/save,general", there is no option "strict standard", only 10/11,
12, 12extended.

Today, LibreOffice integrates some additional features in ODF 1.2, which
will hopefully become part of ODF 1.3 (like font embedding). In general,
saving as ODF 1.2 Extended does not create problem to users of other ODF
compatible software, as the format is backward compatible (so font
embedding will not create problems, but will not be recognized by other
software).

How can font-embed occur if affected by licence restrictions on a font
(e.g. font x is licenced to be used only on gpl systems)?

This is the reason why LibreOffice suggests ODF 1.2 Extended, and not
the ODF 1.2 "strict" version. Being the format XML based, the tags will
not be recognized if they belong to ODF 1.2, but this will not create
problems to the document.

So how are non-standard elements treated when ignored?

It seems safer to select either odf 10/11 or 12"strict". Is there a
definitive list of these LO 12extended "features" so that users can
decide if it beneficial to use them, or revert to standard odf?

#26

As the *leading* 'user' of the format, I would argue otherwise.

How else are new features and improvements supposed to make it into the standard, if someone doesn't actually start implementing them in the real world?

I guess you prefer the Microsoft way of pushing out huge new changes all at once with a new release of Office, thereby forcing all of their users to experience pain unless until they all upgrade?

Sorry, I much prefer the Libreoffice/OASIS/ODF way.

If you want document fidelity across different platforms/programs, use PDF.

#27

Thanks for this information. The difference between extended and
strict allows for confusion to occur. In the option
"load/save,general", there is no option "strict standard", only 10/11,
12, 12extended.

ODF 1.2 is the standard, and I have used "strict" to underline the
difference. There is only one version of the ODF standard, so we do not
need to use "strict".

How can font-embed occur if affected by licence restrictions on a font
(e.g. font x is licenced to be used only on gpl systems)?

LibreOffice is only using fonts with a free license (mostly SIL) which
can be distributed freely to any kind of operating system. There is not
a single font that can be used only with GPL licensed operating systems
or applications.

So how are non-standard elements treated when ignored?
It seems safer to select either odf 10/11 or 12"strict". Is there a
definitive list of these LO 12extended "features" so that users can
decide if it beneficial to use them, or revert to standard odf?

Nothing happens when XML tags are ignored, to systems which are not
supporting the ODF 1.2 Extended document format. This is the reason why
we can suggest to use ODF 1.2 Extended as the preferred format, because
backward compatibility is maintained.

Somewhere in the wiki there is a list of the extended features, but
please remember that we are speaking of a document format and not of
software features. So, most of the new LibreOffice features do not
impact the document format.

#28

It's a worry that some users prefer new "features" over standards
compliance and quality control.

Please do not see new software features as changes to the document
format. Over 99% of new features do not have any impact on the document
format, which is the same as before. And there might be a change in the
document format which is not reflected in any software feature.

So, new software features and standard compliance are different
problems/issues. When you talk about standards document formats you
never consider software features, because the two are not related. You
should really have a look at some of the OASIS ODF TC meeting minutes to
understand what the standard is about.

Agree, it means that if a user is concerned about compatibility, they
must understand to disable the default settings in LO.

No, if a user is concerned about interoperability - as I am - he should
use the ODF 1.2 Extended document format, because this is the format
with the best standard compatibility.

How does OO compare; are documents created to the odf standard by default?

Same as LibreOffice. Actually, the "extended" format strategy was
started by OOo when OOo 2.0 was launched back in 2005, and has been
maintained so far. Actually, not even Microsoft was able to complain
with this strategy, and has never dared to say that the ODF Extended
document format was not standard.

#29

It is extremely rare for features to have a negative impact on standards compliance.
It is not uncommon for features to enhance standards compliance.

Whether or not a new feature hinders or enhances quality control, depend upon how well the affected source code is documented and how structured the program as a whole is.

One of the major obstacles that Microsoft ran into, and why it could not adhere to EEU court rulings, was that its source code was not documented, and the overall program was completely unstructured. Both Apache OpenOffice and LibreOffice are refactoring the OOo codebase, so that quality control related to standards compliance is enhanced.

jonathon

#30

italovignoli wrote

Somewhere in the wiki there is a list of the extended features ...

For those interested, these can be found in the ODF Implementor Notes
<https://wiki.documentfoundation.org/Development/ODF_Implementer_Notes#LibreOffice_ODF_extensions>
.
Best wishes, Owen.

#31

If the question was is it 100% compatible, then yes, it is a very silly *and* unreasonable question - since even the different versions of Microsoft Office are not 100% compatible, and in my opinion, this is purely intentional to try to keep as many of their (microsofts) customers on the upgrade train as possible.

#32

Thank you. It is a worry that 17 out of 24 "features" are in fact
devoted to "interoperability" with m$. Seems to prove the hypothesis
that making LO a poor-man's m$-clone detracts from standards
compliance. The web page indicates that because development of
standards is (necessarily) slow, it is sensible for LO to break odf
validation by default. This is a very surprising conclusion for an
open software product; to adopt the m$ embrace, extend, extinguish
policy and leave standards development to "catch up". Any m$ fan
should be laughing at the strategic folly of LO...

So, new users to LO, be _very_ _very_ aware: LO documents by default
are not standards compliant, which minimises the possibility that such
documents created by LO in default mode will be accessible by other
(including future LO?) odf-compliant products.

#33

Nothing happens when XML tags are ignored, to systems which are not
supporting the ODF 1.2 Extended document format. This is the reason why
we can suggest to use ODF 1.2 Extended as the preferred format, because
backward compatibility is maintained.

Thanks to the odf implementor notes web page, how can this claim be
true when these LO "features" break odf validation?

Somewhere in the wiki there is a list of the extended features, but
please remember that we are speaking of a document format and not of
software features. So, most of the new LibreOffice features do not
impact the document format.

If LO "feature" (most likely designed to provide some sort of
"compatibility" with m$) prevent odf validation, the document format
must be impacted. Or is this a false conclusion?

#34

e-letter wrote:

Nothing happens when XML tags are ignored, to systems which are not
supporting the ODF 1.2 Extended document format. This is the reason why
we can suggest to use ODF 1.2 Extended as the preferred format, because
backward compatibility is maintained.

Thanks to the odf implementor notes web page, how can this claim be
true when these LO "features" break odf validation?

I haven't seen anything to say that the extensions prevent validation of ODF documents. The implementer notes you refer to say, under Extension namespaces, "Elements and attributes that are not defined in an ODF specification yet... have to be written with an extension namespace, otherwise validators will complain about invalid elements or attributes." This suggests that the standard and validators allow for extensions to the format.

Presumably extensions to the format would be ignored by applications not supporting that extension, but the rest of the document show as intended. e.g. with the extension for font embedding, applications supporting the extension would use the embedded fonts, while others would ignore the embedded fonts and use those on the system (as if the fonts were not embedded at all).

#35

Thank you. It is a worry that 17 out of 24 "features" are in fact
devoted to "interoperability" with m$.

Nope, not a worry at all. Compatibility with the office product that holds the vast majority of the market share is a decent objective.

e-letter, your rabid purist attitude really gets tiring.

So, new users to LO, be_very_ _very_ aware: LO documents by default
are not standards compliant, which minimises the possibility that such
documents created by LO in default mode will be accessible by other
(including future LO?) odf-compliant products.

And also please STOP WITH THE FUD.

Your comment above is a plain, outright LIE.

#36

Hi :slight_smile:
It all depends what you mean by "standards".

If you mean ISO standards then you need to set your default format to
ODF 1.1/1.0. This is very easy in LibreOffice, OpenOffice and
probably tons of other suites and programs. The full specification
for the ISO standard is available from the organisation that sets
ISOs, for a price - or free from OASIS. This is the format that is
apparently so badly implemented in MS Office 2007 and 2010 that
spreadsheets don't work properly in MS Office but all other programs
and suites seem to have no such problems with it.

If you mean a standard that is fully documented and used by tons of
other programs and suites then you might need to set your default
format to ODF 1.2. That is the one implemented (supposedly at least
but so far no apparent problems) in MS Office 2013 and maybe 365 too.

However the ODF 1.2 (Extended) which will eventually be released as
the next version of ODF, perhaps called ODF 1.3 is also fully
documented. It's being developed by OASIS as a co-operative effort
between many different organisations NOT just by LibreOffice! Many
other programs and suites are likely to be using it already to make
sure new features work well out in the real world.

How about trying to get involved with OASIS to see if any of the
critical assumptions have any basis in reality? If you find something
you don't like then you could be part of improving the process!
Assuming the worst of people all the time does have the advantage that
you are likely to be pleasantly surprised sometimes but making
assumptions like that and then spreading it around as fact is a little
dicey.

Regards from
Tom :slight_smile:

#37

Tanstaafl wrote

Thank you. It is a worry that 17 out of 24 "features" are in fact
devoted to "interoperability" with m$.

Nope, not a worry at all. Compatibility with the office product that holds
the vast majority of the market share is a decent objective.

In fact, there is even an ODF / OOXML Translation Guidelines standard
(ISO/IEC TR 29166) to further clarify the issue. This is another standard
that also may need updating once the final less-clear parts of OOXML are
worked out by ISO/IEC JTC 1, SC 34.

General comment:
While this thread appears to have taken on a life of its own with respect to
"compliance" and "validation" (which are not the same) the comment by T.
Behrens in bug fdo#30711
<https://bugs.freedesktop.org/show_bug.cgi?id=30711#c3> is worth reading.
Of particular interest is the reference to "ODF-Next". This is an expression
used to generally refer to the version of the standard that is under
development (but never actually arrives, it rolls over). The term is widely
used within OASIS. In standards terms it is a mirroring of the train
development model used by LO i.e., a past, present, and future version at
any one time.

This is what I meant up-thread when I stated that ODF development "needs to
be practical (based on real-world use cases) and community-driven" i.e.,
adapted to cater for unforseen use cases by people who are creating
documents or even matters that were not thought of in the original
spcification. Even so, I can understand the concern that ODF v1.2 Extended
is not an ISO/IEC standard. I guess all that can be said by way of
reassurance is to re-iterate what Italo and Mark Bourne have each indicated:
the extra bits will not affect either validation or compatibility as they
will be ignored.

TomD wrote

How about trying to get involved with OASIS to see if any of the critical
assumptions have any basis in reality?

Thanks for bringing this up. All these standards organisations, including
ISO/IEC and OASIS, rely on volunteered time. There is a mis-conception that
because the voting rights list reads like the Fortune 500 that hundreds of
paid professionals are tirelessly working away. That is really only part of
the story. As with any free / open source / community venture issues are
often left to languish unless someone takes an interest. I recently enquired
of OASIS whether a proposal for a new chart type (box plot) had moved along,
as there was little detail in the related OASIS issue. The response was an
invitation to become more involved by writing up the required technical
proposal, which is exactly as it should be. I am still hopeful I can.

Best wishes, Owen.

#38

e-letter, can you please stop repeating wrong statements on this mailing
list. As I said before, not even Microsoft is telling that LibreOffice
documents are non standard.

So, if you are paid by MS, please stop as you are going beyond your
assignment, while if you are not paid please stop as you are doing a bad
job.

LibreOffice documents will be ALWAYS accessible by any other software
supporting ODF, and vice versa. The ODF standard has been conceived in
such a way that backward and forward compatibility is assured.

The same is not true for OOXML.