A National Archive Moves to ODF
Andy Updegrove writes "The National Archives of Australia (NAA) has announced that it will move its digital archives program to OpenOffice 2.0, an open source implementation of ODF. Unlike Massachusetts or the City of Bristol (which announced it would convert to save on total cost of ownership), the NAA will deal almost exclusively with documents created elsewhere in multiple formats. As a result, it provides a "worst possible case" for testing the practicality of using ODF in a still largely non-ODF world. If successful, the NAA example would therefore demonstrate that the use of ODF is reasonable and feasible in more normal situations, where the percentage of documentation that is created and used internally is much larger."
Years ago when Novell switched over to Linux operating systems, one of their largest fears was the trouble integrating their documents in a Microsoft stardard based world. It turns out that Open Office was more than adequate concerning reading/writing various document standards.
Note: Said software doesn't exist.
Get with the times. That hasn't been true for a while. The current list includes: Abiword 2.4, eZ publish, IBM Workplace Documents 2.6+, KWord 1.4+, NeoOffice 1.2 Writer, OpenOffice.org Writer, Scribus 1.2.2+ , StarOffice 8 Writer, TEA text editor , TextMaker 2005, Visioo Writer 0.6, and Writely for the word processor portion of the format, with similar lists for the other components. There are a lot more that have announced support on the way.
I think the dutch national archive also switched to odf.
"OOo is slow because it's still largely impelemented using a Java VM-based architecture with bytecode and all that entails."c ontroversy is a list OpenOffices use of Java.
No it isn't. I just ran OpenOffice writer V2.0 and checked my task list. No java was running at all!
OOo uses java for some functions but it in not "largely impelemented using a Java VM-based" anything
http://en.wikipedia.org/wiki/OpenOffice.org#Java_
OpenOffice is mostly a C++ or C program.
I have not run a profiler on OOo so I can not tell you 100% what makes OO slower than Office but I would guess that part of it is the XML format that OO uses.
Just from my own experence I have found that you can write a fast XML parser and you can write a "safe" XML parser. But a fast safe XMP parser is very hard.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
What I think they meant to convey is that this will be a worse case scenario they can use for testing the practicality of using ODF in a non-ODF world.
But I don't actually think so...
Whereas I think this will be great for ODF, as the NAA will have to produce heaps conversion software to convert many formats to ODF but because they are an archiving operation, they won't ever have to convert back. Instead, I imagine that the common document format for outgoing files from of the archive will most likely be PDF...
This scenario won't test the ability for ODF in collaborative work among entities, something that I would see as the worst case scenario needed to test the practicality of using this format.
Having said all of that - to hell with everyone else - I have been using non Microsoft formats (first Star Office formats and now ODF) for five years now and rarely come across a problem. Then again, I am a simple user so I wouldn't expect too much grief. From my experience advising other people I can see that the true hurdle is not the file format, rather the application. Word and Excel are automated from so much business and scientific software that people just expect the results of their query or analysis to be dumped directly into their spreadsheet or word processor. So until Quicken or MYOB support something other that MS software, or until alternative software is produced that does, business will largely use MS.
On the other hand I strongly recommend to people to use OOo at home and with the ever increaseing compatability that OOo has with MS formats, this is not a bad option.
All documents were made with a flavour of Word or another, from word for MacOS 6.0 to the latest (at the time) word XP for windows. As you'd have already guessed, the only word processor able to make sense of all the documents at once was Openoffice.org. Of course, I faced issues (bulleting appearing "funny", for instance), but as I was applying a style I created, that was not a problem as long as the text was there.
No single version of word in my possession was able to open all the documents, some documents even crashing word XP with thunder and lighting.
I wrote the original version of the National Archives software that does the conversion. The current version of the software is available here: http://sourceforge.net/projects/xena
If anybody wants to ask any questions here I'll try and answer.
ODT
- Abiword
- EZ publish
- IBM Workplace
- Scribus
- TextMaker
Writely is web-native, so you could use that too.Kword might work in cygwin (I really don't know--I know you can run some KDE apps).ODS
- Gnumeric
- IBM Workplace
Same note on KSpread.ODP
Same note on KPresenter as on KWord
ODG
- Scribus
What does this have to do with anything? I have seen relatively few MS Office, OO.o, or Corel WordPerfect ads either. People giving away software usually don't spend money to ensure you'll take it from them.Our use of the OpenDocument format will be quite important, but it's only one facet of what we do. The Xena software has been developed with a plugin architecture that lets us use various external helpers to 'normalise' or convert to open formats any data objects in our care. For each data object, we use Xena to create a base64 encoded copy so that we can embed some metadata with it, and separately for a conversion to an open format. Much of the data ends up as XML, while images for example are png or jpg. We're currently investigating open audio formats. Xena is also used to 'present' data objects that it normalises.
Until now, Xena has made use of OOo 1.1.x for the normalising of office documents into flat XML. Other development priorities have kept the move to OOo2 in the background. I must stress that we have not yet released Xena with OOo2 support, there is more testing to be done and we feel that the release must be accompanied by good user and developer documentation.
The 'current' binary of Xena available at sourceforge is waaaaay out of date and will shortly be replaced by a much sleeker and more intuitive version. For the curious, anonymous cvs is pretty up to date. If you have a java 1.5 sdk and apache ant, check out a pile of modules and go nuts. Anyone who wishes to become involved in the development effort is more than welcome.
For anyone else, keep an eye on the http//xena.sourceforge.net/ for the upcoming binary release.