[luau] Open Office functionality responses

[Warren Togami]

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