[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]