I know I'vesaid this before, but I can't help it. Just because an application has 'Save as OpenDocument' feature that does not mean it has useful OpenDocument support.
Benjamin Horst at SolidOfficepoints to Dispelling Myths around ODF (I don't think all the myths really are myths (and why do people keep saying that ODF uses SVG? I reckon that's a myth.) but I don't have time to argue) I will confine myself to a comment on this bit. Benjamin writes:
My favorite section is where Erwin lists some of the prominent applications that use ODF as their default, or one of their primary, formats. These include KOffice, OpenOffice.org, StarOffice, IBM Lotus Symphony, Corel WordPerfect, Apple TextEdit, Google Docs, and plenty more.
I can't comment on all of those, or the full list on Wikipedia but I do know these three things.
-
OpenOffice.org and StarOffice share a codebase – they're really variants on the same application, while IBM Lotus Symphony also uses a lot of the same code, with the menus scrambled and no HTML export. At least they're likely to interoperate.
-
Google Docs still has pretty useless ODT support. I just did another quick test and it still (a) produces awful HTML and (b) loses styles when you import ODT and (c) can't export native Google Docs without significant weirdness.
-
The current shipping version of KOffice uses ODT in such a different way to OpenOffice.org that interoperability doesn't work for anything but straight-ahead text. KOffice doesn't have any implementation of list styles for example. The new version might be better but I have not figured out how to get a copy to try out without building it from source.
I wonder if anyone has looked properly at ODF interop, with a matrix of supported features and notes on how various import/export pairs work? From what I have seen, it would not be a pretty picture.
Comments
comments powered by Disqus