KOffice To Use Open Office File Format 48
InodoroPereyra writes "This article at
The Dot indicates that the KOffice
developers decided to switch to the Open Office file format (OASIS) for their next major release. Excellent news both for KOffice, which will benefit from OpenOffice's excellent filters, and for the GNU/Linux Desktop users in general, who will benefit from a unified file format standard between these office suites."
That other office suite (Score:5, Interesting)
Re:That other office suite (Score:2)
Old files (Score:4, Insightful)
Basically, that "other vendor" is facing irrelevancy. Especially looking at the proposed changes with DRM, server lock-in, a proprietary XML schema and the software as subscription model.
The OASIS format supported by Koffice, StarOffice, and OpenOffice.org is not only cheaper and more flexible, but safer in the long run because it's open. That means you're not locked into one platform, one vendor, or even on package. Though the differences are not so dramatic in a word processor, package independence means that individuals can choose the tool that works best for their needs or work methods and still collaborate.
Being an open format means you don't have to depend on the goodwill of a monopoly to keep your format alive. Nor is there a risk of breaking the DMCA, EEA, commit a computer related crime and violate several patents when you try to read that 5 year old file.
Re:Old files (Score:4, Insightful)
Uniformed public (Score:2)
Yes, for right now. But people and businesses eventually start to ask themselves why they are running low on money. Or they ask themselves why they are spending so much time just trying to get/keep the MS machines running when all the others brands do just fine.
I supposed the prohibition on product reviews [infoworld.com] and general criticism [infoworld.com] are contributing to the problem by preventing informed decisions. Likewise when the media refer to the Microsoft Worm / Vi
Re:That other office suite (Score:2)
Let's hope this will be the new trend (Score:5, Insightful)
Electronic Publishing (Score:5, Interesting)
I suspect that it is also a big step closer to electronic documents with a long shelf life. This may lead towards electronic publishing where well-formed and, possibly, valid documents become the norm. Even if the structures are rudimentary, this still will help portability and retrieval.
Right now, [X]HTML and PDF are only part way there. PDF is useful for rapid dissemination, but can more or less be thought of as a compact form of paper. Most HTML document are neither well-formed nor valid and often too dependent on transient constellations of technologies. So, a format like this will let organizations choose tools suited for their specific needs and tasks.
One format... (Score:5, Funny)
One format to find them,
One format to bring them all,
And in the saving lose all formatting.
So this one format it: (Score:1, Flamebait)
Does anyone know of a good ANSI editor for X?
Re:So this one format it: (Score:2, Insightful)
Yes. it's called emacs. And you don't even have to be running X, or even Linux for that matter.
Yes, I know it takes a couple of days to get productive with it, but once you've got past the initial learning curve it's very easy, and quick to use with Tex if you're into real typesetting.
sorry (Score:2)
Re:So this one format it: (Score:2, Funny)
Obligatory Nitpicks (Score:2)
Not that it really matters, except that the A is ASCII is "American", so Western Europeans will accuse you of being U.S.-centr
Abiword (Score:5, Insightful)
Re:Abiword (Score:3, Insightful)
Re:Abiword (Score:5, Informative)
http://abisource.com/mailinglists/abiword-dev/2
http://abisource.com/mailinglists
Basically, while it makes sense for us to support the OOo file formats as best as possible, it is not desirable for us to make them the default file formats. If anything, RTF is a much better choice for this particular job, as I don't believe MS will be supporting the OOo file format anytime this century. However, both support RTF, and RTF is capable of preserving ~100% of the content and data that DOC is, albeit oftentimes more verbosely.
That said, it might make sense for upstream packagers (RedHat, Ximian,
This all boils down to different worldviews - Abi and OO won't ever have a 1:1 mapping of features, nor will we agree on how to represent those features in any single file format. The best you can hope for is "really close" conversions. Loss of content or presentation markup is unacceptable in a "native" file format.
IMO, the best solution is to all have a "common tongue", which may well be the OOo format, or say RTF. We should all use the common language when we want to speak to each other, and hope nothing gets lost or misinterpreted on either side during the translation (remember a translation from Abi -> KOffice using the OOo format as an "intermediary" has at least 2 points of failure instead of just 1). Unfortunately, that's all unavoidable. But when we're speaking "at home," we really want to speak our mother tongue. There's less ambiguity and a higher level of precision.
For those reasons, I don't think that the KOffice folks are necessarily making the best decision here, though I continue to wish them the best of luck and success.
Best regards,
Dom Lachowicz, AbiWord maintainer
Re:Abiword (Score:2, Interesting)
But now the OASIS format will BE KOffice's native tounge...
Re:Abiword (Score:3, Insightful)
Dom
Additional XML benefits (Score:5, Interesting)
Or use a stylesheet on the document and adopt it for, say, mobile devices (my favourite topic, I must admit). XML->HTML, XML->WML, XML->cHTML
Is this possible with
Re:Additional XML benefits (Score:2, Interesting)
Re:Additional XML benefits (Score:4, Interesting)
The xml files would be a lot bigger than a binary format, but the zipping process manages to get it down to about the same size again most of the time..
Incorrect. Go try it on a few documents. In practice, I see that OOo Writer documents (without images) are less that half the size of their Word counterparts, and OOo is not (yet) very careful about the XML it spits out, tending to save lots of style and other information that isn't even used in the document.
The zipping process makes the files a lot *smaller* than you normally get out of a binary file format. Why? Rather simple, really. In most binary file formats (e.g. Word), the formatting information is fairly compact, but the content isn't compressed in any way. Given that English text has about one bit per character of entropy and given that (hopefully!) there's much more content than formatting, there's a lot of room for compression to do its work. In the case of embedded images, it really doesn't matter what format you use, they don't compress, but the XML doesn't add a significant amount of overhead to them, either.
Re:Additional XML benefits (Score:1, Interesting)
Re:Additional XML benefits (Score:4, Informative)
Schema, DRM, server dependency - unresolved issues (Score:1)
First, it seems that only two of the 6 flavors of MS-Word 2003 get the XML as touted. Second, the schema is still proprietary. Third, the application uses DRM so earlier versions are not compatible and must buy upgrades. Fourth, the DRM is dependent on MS-Server 2003 with expensive per-seat client licenses.
So, at first glance to use MS-Word 2003's XML format it looks like you need at
Re:Additional XML benefits (Score:3, Informative)
Not that simple (Score:2)
That only works if you're transforming XML that imposes some kind of structure on the document. OO XML doesn't. Here's some pretty typical OO XML:
Re:Not that simple (Score:2)
Re:Not that simple (Score:2)
The OO people are experimenting with support for XML export by associating styles with XML tags. The latest version has a beta implementation of "simplified DocBook". But again, this is pretty much what people already do with Word and Framemaker. The difference is
And in other news... (Score:2, Funny)
Re:And in other news... (Score:1)
Great News?! (Score:1)
Gtg for my class - will continue this post later.
Nandz.
Clarification... (Score:5, Informative)
OASIS (Score:1)
I'm glad we can all finally agree on one brow...um, file format.
Sorry, that's all the gallagher references I've got without smashing a watermelon.
Which openoffice format? (Score:2, Interesting)
Re:Which openoffice format? (Score:1)
"Excellent Filters"???!!! (Score:3, Interesting)
From my experience, OO's filters are decent, perhaps a little better than Microsoft's, but hardly anything to get excited about. The last time I read a Word file in OO, it screwed up a very simple bulleted list. Face it, it's very, very hard to write a really good word processor filter, especially for a file format as messy as Microsoft's.
The OO native file format is pretty good, or at least the current version is. I have some issues with it, like throwing in every obscure XML namespace that has some silly feature that somebody likes. And there's still too much device-specific information. But I guess you can always just ignore the noise, especially since it's more neatly separated out than in previous formats.
OK, I'm cynical about attempts to challenge Word's workplace dominance. But here's a scenario/fantasy that's worth thinking about: Bush II loses the '04 election, despite his carrier landing skills. An "anti-business" Attorney-General revives the anti-trust actions against Microsoft. This time, they ignore silly outdated rememdies like splitting off the application divisions (multiple monopolies, great) and come up with something that's ahead of the curve. Like forcing Redmond to work harder at standards compliance. Hey, you say Word dominates because it's better? Prove it: have it read and write OO format! Then you can compete on features, rather than locking out the competition with format crap.
Re:"Excellent Filters"???!!! (Score:2)
In my humble opinion, one (or all!) of these would be a better punishment:
*publish ALL their APIs... MS tried to avoid this siting some security reasons, but in reality is there even a downside to this?
*Docume