Slashdot Mirror
Evolving ODF Environment: Spotlight on SoftMaker
Andy Updegrove writes "In this fourth in-depth interview focusing on ODF-compliant office productivity suites, I interview Dr. Martin Sommer, of Germany's SoftMaker Software. Most people know about OpenOffice, StarOffice, and KOffice, the ODF poster child software suites. But there are also other products available as well, including this one, which bundles word processing and spreadsheet capabilities (with more modules on the way), runs on both Windows, Linux and mobile platforms, is designed for home users, is available on-line, is localized in many languages - and is dirt cheap, besides. It's also been selected by AMD for use in connection with its ambitious "50x15" plan, which hopes to connect 50% of the world population to the Internet by 2015. This interview series amply demonstrates how a useful standard - in this case ODF - can rapidly lead to the evolution of a rich and growing environment of compliant products, providing customers with variety, choice, price competition, and proprietary as well as open source product alternatives - in stark contrast to the situation that has prevailed in office suite software for the last many years."
i wish i could post back to my own comments on this last time..
when reading a document like ODF (and anything based on XML) you have to read the whole file in to understand any of it (i know this isn't exact but i don't want to type it all out) with a binary format like a doc file.. what you need first is first.. you can understand a section by jumping to it and geting just that portion instead of the whole thing..
it is the same with saving.. updating portions of the file instead of the whole thing.
ODF is nice in that it is human readable and easy to write code to read and write them BUT it is slow.. you can only optmize so much in code.. if your working with a bad layout you can only go so fast
MS has spent years optimizing the doc format ODF was not thought out for speed.
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
There is set of office apps besides MS Office and OpenOffice where ODF really would make a difference: Apple's. But, instead, Apple Pages and Keynote use their own, proprietary format, a format that isn't even consistent between Apple's own releases.
BUT it is slow..
You are mistaken. Have you had a look at the bytes of a typical binary format such as MSDOC? It's mostly zeroes.
A text format with general purpose compression (as ODF is) can be considerably faster than a primitive binary "memory image". The reason is that that by far the biggest limiting factor is disk speed, not CPU, and if compression can reduce the disk size then the CPU needed to decode the text is not important. That's why read+decompress is often faster than read uncompressed.
M$ have highly optimized MSDOC read/write routines. OO's routines aren't highly optimized. The ODF document format is almost irrelevant.
Typical numbers. This is 719 pages. It's about 0.5MB in both sxw and odt forms. A typical disk drive can read 10MB/s (just measured it). The entire document can be read in 50ms. Modern PC's have memory speeds of typically 1GB+/s. The entire document can be read from memory in 500 microseconds.
This doesn't prove that the ODF document can be parsed quickly but unless the ODF document format is totally brain dead, it does strongly suggest that decoding is not a big deal time-wise. It's not as if serial decompression and parsing is a computationally challenging task. e.g. This XML parser read from disk cache the entire uncompressed 5MB (400KB compressed) content.xml from the above document and processed it in 0.7s.
So please, stop spreading the all too common student excuses about primitive binary formats being magically faster. They may be but it's not automatic.
---
Open source software is everything that closed source software is. Plus the source is available.