Hi all...
I preface this discussion with two injunctions:
1. Thou shalt not flame.
2. Thou shalt not cheerlead, nor shalt thou troll.
Ok, so that's really three. Whatever.
I'm beginning to to evaluate whether and how to replace M$ Office
(hereinafter "M$") with OOo at my father's small law firm. Project
planning and needs-assessements aside, I have some very practical
questions about the potential speedbumps in featuresets and
interfaces. For example, most people make the highly subjective and
therefore highly varying observation that "advanced" document
properties do/do not migrate properly from one format to the other.
I'm pretty ignorant about basic productivity-suite functionality (I
use productivity-suites less than .001% of my computing time, and then
use about 1% of features) and have not closely analyzed OOo - so I'd
like to put the question to all of you: What specific
non-compatibilities, feature mismatches and general fsckups are to be
found in a migration from M$ to OOo? More specifically:
The featuresets in use vary greatly from org to org, but at a very
general level there are "show stoppers" in the feature compatibility
between two different systems.
What significant white spaces exist in feature-mappings between OOo
and M$? For example, XEmacs can't use XFT fonts and would require
significant hacking to implement them, whereas Kate does so nicely.
Broadly, in strict terms of functionality, what can M$ do that OOo
can't? What M$ functionality does OOo implement, but so badly as to
impact usability?
What significant incompatibilities exist between OOo and M$?
Disregarding scripting issues and the potential for change in M$
file formats, are there any important document features which are
either impossible to import to OOo or which import wrongly?
Since OOo obviously can't implement VB or any other M$ scripting
technology (since it's a cross-platform app), document scripting is a
big compatibility hurdle. Are there any conversion tools which can
port M$ scripts of varying triviality to the OOo (|| Python || Pascal
etc.) language?
Another great concern is training - the user base will have to be
quickly brought to a level of productivity/comfort roughly equivalent
to what they had with M$. What are the best existing resources for
training users to migrate M$ -> OOo? Imran's Mimos docs are great,
what else out there is Ready For Primetime?
Note that rules 1-2 leave you free to tell me to RTFM or STFW if I'm
asking obvious questions.
--
~ You are in a maze of twisty passages, all alike.
Christopher DeMarco
cdemarco@fastmail.fm
+6013 389 5658
---------------------------------------------------------
To unsubscribe: send mail to ossig-request@mncc.com.my
with "unsubscribe ossig" in the body of the message