On 21/07/2011 01:33, Andrew Douglas Pitonyak wrote:
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.
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$
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
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
I do believe that MSO now supports ODF files, so perhaps...
Unsubscribe instructions: E-mail to firstname.lastname@example.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted
Impressum (Legal Info)
: 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