The Open Document Format (ODF) is an ISO standardized method of storing rich text and other office data. The ODF standard has grown in popularity over the last years quite a bit. Many governments around the world have passed laws stating that any sort of communication between the government and its people has to be done in ODF.
The attraction for ODF is strong, it is the first standard in this field that is completely open and it has a wide enough coverage that you can store your word processor and even most DTP documents in it without losing data.
I find the part where the standard is open very important, as an individual I have been able to sit on the ODF technical committee and I have been able to co-decide the direction of the standard. Various list-item related stuff has a finger of mine in there, for example.
Equally important is that everyone who wants to can implement ODF support in his or her application. All the information is available to do so, for free, on the web.
So, for end users the biggest advantage of the uptake of ODF is that more and more applications will standardize on this one format and thus applications will be much more interoperable. OpenOffice and KOffice are the early adopters here, I expect that many more applications will start to generate or consume ODF in some form or other. For example to export an abstract dataset to a nicely formatted document ready for printing, or the web.
Currently rich-text is mostly exchanged between different applications as html. Unfortunately html was not designed for this purpose. Sending an email with html markup kind of works. But you should take a look at the html that Qt or Word generate. Loads of extra non-html tags are written out just to put the layout information somewhere when html doesn’t have any equivalent features.
Those made up tags will be lost when the html is opened by another application than the one that created it.
Longer term I expect to see email applications to send ODF as well as html in their emails. Just so they can use the much broader ODF set of features.
Interestingly, a text exchange format gets more useful when more applications support it. This should be obvious.
To speed up ODF recognition Qt 4.5 will ship with an ODF writer. Qt’s text module turns into a one stop document generation API where you can use QTextCursor to create your document via a nice API and you can then export the created QTextDocument to ODF ready to be opened by any opendocument implementation. Naturally exporting to plain text and html are still supported, as is printing to PDF.
Support for writing ODF in Qt sets a trend that we believe in the OpenDocument Format and we think its useful to have for our customers, the open source community and all end-users out there.
I always think its important to point out what our current solution does not do, just to avoid disappointment. The QTextDocumentWriter has support for each feature in Qt. So you can expect all features you can access using QTextCursor to be exported. This, however, is a subset of features in ODF. Qt’s ODF-writer does not aim to support each and every feature in ODF. So don’t expect you can write spreadsheets or some obscure ODF-text features that Qt doesn’t have.
There is work going on to make an ODF Reader too for a future release, the aim is to support all the features we write out but also try to map ODF features to Qt’s feature set where it makes sense.
The writer is in the unstable snapshots already, and will be released in 4.5. You can find the documentation online at; http://doc.trolltech.com/main-snapshot/qtextdocumentwriter.html