[luau] Open Office functionality responses

[Jon Reynolds]

On Thu, 2003-04-03 at 00:08, Warren Togami wrote:
> On the bottom of this e-mail are responses to Christine's questions,
> both are from Sun Microsystems employees and I'm guessing developers of
> OpenOffice. If I understand what they are saying, it seems that
> OpenOffice will not automatically translate VBA macros, but it has its
> own very powerful macro system which you can build OOo macros. 
> Conversion of VBA macros to OOo macros should be possible long as it
> doesn't make use of 3rd party software.
> 
> You should also look at the functionality of the commercial "StarOffice
> 6.0" suite which is based on OpenOffice, but with several added features
> like WordPerfect import, metrically equivalent fonts to the Microsoft
> fonts.  If you try StarOffice 6.0, make sure that apply the update 2
> patch which makes it work much better.  I don't know if the macro
> capability is different in StarOffice.
> 
> http://marketing.openoffice.org/comparison.html
> Here is a comparison of rendering capability between OpenOffice 1.0 and
> Microsoft Office 2002.  It gets most of the simple/moderate documents
> correct, but very complicated documents don't quite work properly yet. 
> Keep in mind that OpenOffice 1.0 is old at this point with development
> moving very swiftly, I would compare functionality with the current
> 1.1beta or StarOffice 6.1beta.
> 
> If my understanding of this situation is correct, here are the main
> points about feasibility:
> 1) StarOffice and OpenOffice are roughly equivalent in capability,
> except StarOffice is a low cost commercial product (free for schools)
> that has commercial support and manuals available.
> 2) StarOffice and OpenOffice works well for import/export of Microsoft
> DOC, XLS and PPT documents when Macros are not involved.  I think if it
> there are macros, it wont damage them if you re-export it, but I haven't
> tested this.
> 3) StarOffice and OpenOffice works best if you only use it and do not
> need to export to Microsoft formats.  The native data format is very
> small and efficient compared to Microsoft Office formats, while being an
> Open Documented Standard unlike the anti-competitive closed Microsoft
> format.  Fortunately import/export of Microsoft formats is very good as
> long as you don't have macros or certain types of complicated tables. 
> For this reason it may be ideal for lower end-users like schools or less
> complicated office staffers.
> 4) StarOffice and OpenOffice can natively print to PDF or Postscript,
> while Microsoft Office usually needs additional commercial software to
> do this.
> 5) Note that if government documents are published online as native
> OpenOffice formats (alternatively Microsoft and PDF format), government
> can also have a download link for anybody to download the entire
> OpenOffice suite for Windows, Linux, Solaris or MacOS X.
> 6) Also note that OpenOffice development is always happening at a brisk
> pace with thousands of volunteer developers worldwide.  Due to its Open
> Source status, upgrades of OpenOffice will always be free in the
> future.  Due to copyright law and the GNU GPL license this Open Source
> status can never be revoked, even if companies go bankrupt.  This means
> a) No vendor lock in b) No risk of dead-end upgrade path.
> 
> Also note that WordPerfect suite is also a popular office suite for
> Linux, and even Microsoft Office can run on Linux very well.
> 
> StarOffice and OpenOffice are not perfect, but are very functional in
> several ways and constantly improving.  Desktop applications are
> generally not the strength of Open Source yet as OSS has only begun
> heavy development in that sector during the past few years.  Open
> Source's current real strength is in server applications and security,
> and that is where the most cost savings for government will happen
> today.  That is where the resolution should examine most.
> 
> If the resolution passes, our advocacy group would be happy to
> demonstrate and suggest Open Source applications that we feel would be
> of great benefit to government.
> 
> Warren Togami
> warren at togami.com
> 
> On Wed, 2003-04-02 at 21:59, Caolán McNamara wrote:
> > 
> > It is indeed possible to write your own macros and programs that use OOo,
> > theres certainly a lot of advanced functionality there.  With the recently
> > released monster 900page developer guide at
> > http://api.openoffice.org/DevelopersGuide/DevelopersGuide.html which is very
> > impressive and the also recently announced neat looking scripting framework at
> > http://framework.openoffice.org/scripting/index.html
> > 
> > Perhaps the overview presentations given at the OOo conferences on both the SDK
> > and also "Scripting OpenOffice.org in the language of your choice" at
> > http://marketing.openoffice.org/conference/thursday.html and the friday
> > presentation on "Common experiences using the OpenOffice.org API"
> > (http://marketing.openoffice.org/conference/friday.html) would also be useful.
> > 
> > C.
> 
> On Wed, 2003-04-02 at 23:27, Michael Hoennig wrote: 
> > 
> > I don't know where anybody might have gotten these 80% from.  OOo itself 
> > has an API which covers almost everything of the document models and the 
> > configurtation.  The big exception is regarding the user interface (UI). 
> >   The API only has very few funktions to modify the UI, mostly because 
> > we are not shure that it will stay the way it is 
> > (programmtically/internally), there were many ideas around like using 
> > XUL or Gtk.
> > 
> > The biggest issue might be that VBA macros cannot be converted 
> > automatically.  This is a one time effored to be considered.  I could 
> > bring up an analogy of The Count of Montecristo, but I already say 
> > enough I guess.
> > 
> > Anyway, most VBA macros can be converted, as long as no third party 
> > software is used which is not available for OOo and there is no substitute.
> > 
> > dev at api.openoffice.org is the right mailing list for detail questions on 
> > the API.  And dev at udk.openoffice.org for questions on the object model, 
> > which makes it possible to use scripting languages, C++ or Java with the 
> > OOo API.  The 900 page Developers Guide in the SDK gives an deep 
> > introduction into the power of the OOo API:
> > http://www.openoffice.org/dev_docs/source/sdk/
> > 
> > 	Michael
When we started trying to save a little money in our organization we put
OOo on a few of the lab systems for general public use. One problem that
has really bothered us is that if a user creates a resume using a
microsoft template there is no way, that I have found, that they can
open it in OOo and edit it. Where the template is highlighted for you
add text to, when you try to add text it didn't put it in the
highlighted area. Instead, it added the text in before the highlighted
area and shifted it to the right as you typed. In the body of the
template? Forget about it, you couldn't even add text.

Now I am no great OOo user, but if we could get around this issue we
could switch all of our labs over to OOo. But as it stands, we have to
have a mixture of the two so we can edit the resume templates that the
user created in msoffice.
-- 
Jon Reynolds <jonr at destar.net>