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

On 21/07/2011 01:33, Andrew Douglas Pitonyak wrote:
On 07/20/2011 05:02 PM, e-letter wrote:
On the users mailing list, a significant proportion of a random view
of questions seems to be with relation to using LO is some way with m$
document formats.

What should be the priority of LO development: bug-free and excellent
behaviour in native odt format, or minimising "interoperability
issues" with m$?

No doubt it is convenient in a gnu/linux environment to be able to
receive a document attached in an e-mail message and at least be able
to view that document. However, is it really worthwhile, or fair to
LO, to be able edit such documents so perfectly that the recipient
doesn't realise LO was used instead of m$?

In a business scenario, a customer who sends a document is m$ format
(for simpliciticy assume for subsequent editing) would most likely
expect the recipient to have the money to buy m$ software and edit the
document accordingly. It is difficult to understand why a business
would waste time trying to use LO; if a customer uses m$, the supplier
might as well do so also and consider the m$ price as a cost of
conducting business. Is the cost of m$ such a massive proportion of a
business cost structure that transferring to LO is the difference
between the business remaining profitable or not?

In a non-business scenario, for example academia, one could imagine a
scenario where the teacher sends a document in m$ format, the student
uses LO because it is free. The student could explain his/her
circumstances to the teacher who may be flexible in either accepting
slight formatting differences, or even deciding to use LO also (the
ideal result).

To conclude, it does not seem a good long-term idea to be constantly
seeking high (if not perfect) compatibility with the constantly moving
targets that are m$ formats. The priority for LO should be to ignore
self-inflicted problems such as "I saved a document is m$ format x and
something has disappeared" and focus upon "when using writer to create
a new odt file, a table alignment error occurs".

I might also conclude that there is NO reason to support any other file format either. I mean, really, why should I support a non-ODF format? PDF generation? Remove it! Any other office file format? Remove it! Why single out file formats associated with MS?

I am more comfortable in OOo than I am in MSO, so, I have created many MSO deliverables in OOo and LO. The only time that I make an exception is when I believe that I am not able to seamlessly move between formats because of incompatibilities. So, if I intend to create a large document with multiple images, links, and fields, I begin and end with MSO.

While writing a book on OOo, I worked in OOo on a Linux platform and some of the editors worked in MSO. We moved documents back and forth seamlessly with no problems. They had no intention of using OOo or LO. If MSO support were removed, then I would have been stuck with using MSO. As a side note, the owner of the publishing company was so impressed with how well this worked, that internally they moved to OOo and then published their templates in ODF format.

I download numerous MSO files from numerous sources. if LO is not able to read these files, well, then I need to purchase MSO (and a Windows computer) so that I can read them.

Do you ever have reason to open an MSO file? Ever try to send an ODF file to a neighborhood or club mailing list? I receive the same reaction as when someone sends out a MS Publisher file that is not supported outside of MS Publisher. "Hey, what is that file that I cannot open?"

I do believe that MSO now supports ODF files, so perhaps...

But isn't this the epitome of seamlessness? It shouldn't matter one jot what application the use prefers to use, the result should be the same.

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