On 07/22/2011 10:24 AM, e-letter wrote:
On 21/07/2011, Andrew Douglas Pitonyak<firstname.lastname@example.org> wrote:
On 07/21/2011 08:47 AM, e-letter wrote:
On 21/07/2011, Andrew Douglas Pitonyak<email@example.com> wrote
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.
That is your prerogative, but it is preferable to see writer used to
create such large documents in the native odt format, at least to
demonstrate the power of LO.
The problem is that the final deliverable to the client is an MSO
document and the complicated structures that I frequently use do not
properly export to the MSO document format. It is very time consuming to
work through a 250 page document full of cross-references and text
frames that do NOT export to the format required by the client. I lost
many hours fixing up the document in MSO so that it would be ready for
In my opinion interoperability with the _m$ format_ weakens increased
adoption of the odf. At the start of a 250 page document, ideally the
decision should be made to use odt and the issue become ensuring that
LO behaviour in native odt format occurs with minimal bugs. This
experience alone should promote wider adoption of LO. The claim to
offer (or attain to) perfect interoperability with the _m$ format_
leads to time wasted trying to get LO to work with m$. If the end
requirement is m$, pay to use m$.
If anything, this experience means that LO is less likely to be used
because if there is a change in requirements and I must generate and
deliver an MSO document, then I had better not be using LO if the
document will be sufficiently complex that it will not export well.
Even worse, given that MSO has the greatest market share it means that
most legacy documents use the MSO formats. I knew many people that
refused to switch from Word Perfect when I told them that OOo would NOT
read their document archives that they spent years creating.
To date, I have seen only one client that requested that an ODF document
be the final deliverable. As they went around the table trying to figure
out what experience the large team had with OOo, the best that was there
was "yeah, heard about it, never used it".
LO does not have sufficient penetration to play like MS to force users
into staying with LO.
point of the original post, is that priority should be for LO
performance in native odf to be better than m$o performance in native
m$ format (or indeed secondary odf).
Oh! Ummm, yeah. I think that I was just hit in the head with something
important and logical. :-)
It does not seem right that
people complain that "writer does not save to m$ format well", when
the statement "writer creates beautiful, easily-created odf documents"
should be the main reason to use LO.
Let me add to your statement, because much of it is VERY important.
1. Many people find the LO interface more intuitive, easy, and obvious
to use than learning the new MSO interface.
2. Most people do NOT write complex documents (think home user that
writes letters and such) so complex support is not required.
That said, when people complain that there is an issue with formatting,
it tells me that either
(a) The document has some level of complexity
(b) There are probably things that float around (like frames or images),
and these are very difficult to get right. Even MSO has issues when
moving between versions.
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
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
- Re: [tdf-discuss] ignore m$ legacy? (continued)
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