OpenDocument. Was: Photoshop PSD 6 format Spec / Gimp XCF format Spec

[Boudewijn Rempt]

On Friday 03 March 2006 10:31, Jaroslaw Staniek wrote:

> I have feeling that packaging graphics "document" in a zip file is overkill
> _similar_ to doing that with database "document", in terms of
> saving/loading time and disk space needed for loading/saving. Think about
> _large_ documents.

Actually, a zip file with an internal file structure is a very good match for 
a graphics document. And it works -- see Krita.

> Or, any chances to join forces with GIMP and their XCF format? Ideally, I'd
> see both projects moving to binary (read: extendable) XML. Even sticking
> with another iteration of XCF, as a container seems better. Eventually, you
> can always append a chunk of XML data (metadata) to such a binary block _in
> place_ ang get really good performance.

This mail was in the first place an attempt at initiating cooperating with the 
Gimp. Of course, the xcf file format is not something that's easily used 
outside the Gimp.

> BTW: You all seem to know about poor performance (time, memory usage) of
> OpenOffice.org Calc (not mentioning KSpread) in terms of large document
> saving/loading, compared to competition[*], even if the compettion that
> uses XML too. What's wrong with text XML in Calc is that Calc is used by
> some of the users as a database medium, what's terible but it's true.
> Good XML parser (we're going to use with KSpread too) is only to make us
> perform 2 times slower except 10 times slower, because the competition use
> more flattened and simplified XML, what OpenDocument backers criticize for
> a good reason.

Entirely different things. With a graphics file format based on an xml 
metadocument, you'd never have to parse very much xml. I mean -- take a big 
document with two hundred layers -- that still wouldn't take much to describe 
in xml. If the binary data isn't stored in the xml file itself.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20060303/6aa7bfa7/attachment.pgp