[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice
Subject: Re: koffice file formats
From: Robert_Schöftner <robert () whisker ! rmu>
Date: 1999-06-28 20:12:36
[Download RAW message or body]
On Mon, Jun 28, 1999 at 12:34:35AM +0200, David Faure wrote:
> 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.
there´s some discussion in linux-kernel about multi-fork files just now. your
approach could become problematic if you include some _large_ bitmaps (e.g. for
offset-printing). the some minimal manipulation of some text could result in 10s of
MBs being shuffled around.
I think such "sections" belong in different files and the document should
essentially be a directory. this can be put into a tar-file for transport.
pros:
* "legacy" tools (like xv) can be used
* documents can be "tweaked"
* it´s simpler
* less error-prone
* corruption is unlikely and is easily dealt with
* it should be _significantly_ faster (esp. for large documents)
cons:
* it could confuse users if not done carefully
* will be slower for small documents with _many_ small embedded parts
(fs overhead). this effect should be negligible
of course some standard structure has to be agreed upon, e.g.
KOffice.d/ <- the name of the document with .d appended to indicate this is a document
.desktop <- sort-of .desktop "lnk"-file with information like mime-type, icon, ...
index.xml <- the xml-file
drawing.eps <- some eps-file
dragon.tiff <- a tiff-file
shot1.gif <- a screen-shot
welcome.au <- and some sound
embed1/ <- an embedded KOffice-document...
.desktop
index.xml
just an example :)
refs: the albod-discussion on linux-kernel (archived at vger.rutgers.edu IIRC)
servas,
robert
--
In Root we Trust!
[STOP ENFOPOL: http://www.quintessenz.at]
[ campaign mailto:nobody@quintessenz.at]
[ contact: mailto:k@quintessenz.at]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic