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; doc.trolltech.com/main-snapshot/qtextdocumentwriter.html
18 Responses to “Opendocument format”
Very nice to hear that Qt 4.5 will support a lot of new things, like the ODF. Also support for QWebKit plugins is a nice feature.
Qt has become a stable cross-platform development tool for people who want do to low-level stuff. But now also adding other things to it is really the way to go. Hope to hear more such great news in the future.
Oh yeah, is there already a target date for Qt 4.5?
Awesome, thanks Thomas!
Are there any plans to support this as part of QMimeData formats?
I.e. for drag&drop, copy&pastre operations
Thank you for supporting ODF in Qt. I have a question: Will it be possible to inject content into the generated ODF that is not supported by QTextDocument? I am in particular interested to generate documents with math content, seeing that neither KHTML nor WebKit support MathML yet.
I have a Dream… where the standard format of email is ODF. That would be nice!
@Kevin Krammer
Yes, thats already working
This is truly exciting. In an app I’m working on I have various QTextEdit fields that I save/load, currently in plain text. We’ve always wanted to add support for stuff like bold, underline, font sizes, super and subscripts, and colors, perhaps even fonts. It sounds like in the not to distant future we can save/load that type of information using ODF. That would be perfect!
Nice to hear support is going into Qt for ODF, but I do wonder if your cohorts on the QtJambi side know about the ODFDOM library for working with ODF from the Java side. That lib is by OpenOffice.org, supported by Sun, and looks to be going towards a full standalone implementation for ODF. I don’t know about anything similar on the C++ side, but perhaps the Trollies working on the Java parts can avoid some duplication by using what’s already there. It’s under LGPL, so it can still be used in your commercial stuff.
See it - http://wiki.services.openoffice.org/wiki/ODFDOM
Regards,
Raymond
@Raymond
I’m not sure how you made the connection. The odfdom is API for creating ODFs. The QTextDocumentWriter works on the heavilly used text code in Qt which is used in most Qt components already.
Very different usecases.
Note that your qoute “full standalone implementation for ODF” would probably be misleading to some 
It is neither a full solution and it is not standalone. It depends on the OpenOffice codebase and OOo is not supporting all of ODF by a longshot.
Just to be clear, I like the fact that there is something like ODFDOM. The more ways there are to generate ODF the faster the uptake will be. It just creates more possibilities for developers to choose the solution that they feel is best.
The ODF text document output sounds pretty cool. I wouldn’t be surprised if people started asking for (simple) spreadsheet output though — it could fit in nicely with Qt’s table/item model and SQL support.
The new Qt feature is great, but WTF, ODF mail? HTML mail is already enough of a plague! E-mail should be plain text!
@Thomas
ODFDOM is standalone, does NOT depend on OO.org, is 100% Java and does support 100% of the specs. That’s the case cause, just like PyODF, it’s a wrapper around the specs created using the relax-NG schemas. So, that part has nothing to do with the ODF-toolkit except being an additional and optional part of it. Though I agree that’s rather confusing that the org.openoffice-namespace is used but iirc the plan is to turn OO.org into a reusuable component-framework where the office-suite itself is just one of the implementations building up on the ODF-toolkit.
yay, s/PyODF/ODFPy/ - happens each time since I always assume that the Py comes first
Will Qt 4.5 provide a mechanism to populate a QTextDocument from an ODF file i.e. will reader functionality be provided along with the writer functionality in the QTextDocumentWriter class?
No, it will not. Only writing functionality for now.
What happens in the future, no body knows..
I hope that reading functionality for ODF makes it to Qt 4.5. Seems like a tease to be able to just write and not read it 
Sorry to disappoint you, but it won’t. There are only so many hours in a day (and so many days in a week). We can’t do everything for 4.5.
But we thought that ODF writing was important enough to be included without the reading part being available.
The standard is long overdue. What we now need is a piece of Open Source software that works in a similar manner to PDFCreator - installs on your computer as a printer and can therefore be selected to save any document from any programme in the ODF format. This would make the process of communicatrion so much easier.