Evolving ODF Environment: Spotlight on SoftMaker 75
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."
Re:BTW, ODF is a file format (Score:5, Interesting)
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.
Re:BTW, ODF is a file format (Score:3, Interesting)
http://slashdot.org/comments.pl?sid=186756&cid=15
This is a much better explination
Re:Has anyone ever sent you an ODF document? (Score:3, Interesting)
Apple: MIA (Score:4, Interesting)
Re:Has anyone ever sent you an ODF document? (Score:3, Interesting)
Exactly, it's a 2-way channel. People won't send you ODF if they don't use OOo or an equivalent, or they think you don't. I have lots of friends/coworkers which probably use OpenOffice, but I don't know for sure, so I usually go with a more "universal" format. I'll pick PDF if there's no need for editing.
I do ask some people if they use OOo, and yes, I have sent ODF files to coworkers I know use OOo.
Want to convince people? The free PDF converter is a very good selling point.
Re:Has anyone ever sent you an ODF document? (Score:3, Interesting)
I agree with your agreement. As this thread shows, plenty of people are using and sending people ODF documents. For my students (non-tech-savvy, mind you) I routinely post lecture notes etc. online in both ODF and PDF formats, with links to download free readers; when I send documents to (non-tech-savvy) colleagues, I regularly send them in both ODF and PDF formats; out of hundreds of people, no one has complained yet.
If they want to take the responsibility of editing these documents they'll have to take the responsibility of installing an editor; so far, those that have needed to have happily followed my instructions. For those that can't install OpenOffice or similar for some reason (e.g. they don't have root access on their Mac), I'll make a special case and send them a document in another format, usually RTF or CSV, occasionally doc or xls if necessary. Works fine.
Re:BTW, ODF is a file format (Score:4, Interesting)
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 [oasis-open.org] 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 [virgin.net]. 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 [irrlicht3d.org] 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.