[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    koffice file formats
From:       David Faure <david.faure () insa-lyon ! fr>
Date:       1999-06-27 22:34:35
[Download RAW message or body]

Hi.

Just got a lot of feedback from future koffice users, when I was in Japan.
(I met Japanese people but also a lot of European people).

Future users expect a lot from koffice, a lot more than what it currently does ;)
The file format is a huge concern.

It would be great to define the formats (i.e. the DTD) in a common place with
other XML office apps, like gnome ones. A good candidate for the common shared
cvs server I heard about (does it exist finally ?). The file formats should probably
exist as complete even before the app support all of them. Just like we did with
the .desktop standard. (app-specific actions such as "Extract" (with ark) are not 
implemented yet).

Of course, for this, the DTDs shouldn't contain any "K*" names.
I don't know if gnome has already DTDs for its office apps. If yes, time to merge.
If no, time to share ours ;)

And above all, the file format should be _REAL_ XML. It used to be, but
it's not anymore since koStore write binary headers.
But I already suggested a solution for that here. I even made a nicer draft for it :

<?xml ... ?>
<XML_SECTION>
... the xml document
</XML_SECTION>
<BINARY_SECTION file="..." size="..." mimetype="...">
... an image, stored as real binary
</BINARY_SECTION>
<BINARY_SECTION file="..." size="..." mimetype="...">
... an image, stored as real binary
</BINARY_SECTION>


This means we can't use the XML parser for the BINARY, but instead we have to parse 
the BINARY_SECTION line by hand. Well, not a big problem.
It also means we need a smart check (or even better, a converter), to handle
old files that started with "<?xml" (i.e. not recent ones, but the ones that are from
before the binary store).

I'm posting all the details about my idea on this because
1) I prefer this being discussed first, of course
2) I'm not sure I'll have the time to do that - I'll have to move in a few days.

Some kind of file format version would be great as well. Would allow easy conversions
from older file formats, as well as "file format is more recent than app - please upgrade"
error msg.

People are also expecting a lot from file filters. They should be very good, with good 
error checking (not "can't convert this file, aborting"), and possibly even asking the
user about which strategy to chose when seeing an incompatible thing. For instance,
a word document containing a WordArt picture : the user can chose between converting it
into plain text, losing the effect, or into an image, losing the text information.
Expected ones are MSOffice and StarOffice filters, at least ;)

Hope this helps, and hope I'll find the time to contribute to this... but not sure about that.

-- 
David FAURE
david.faure@insa-lyon.fr, faure@kde.org
http://www.insa-lyon.fr/People/AEDI/dfaure/index.html 
KDE, Making The Future of Computing Available Today

[prev in list] [next in list] [prev in thread] [next in thread]