OpenDocument. Was: Photoshop PSD 6 format Spec / Gimp XCF format Spec
js at iidea.pl
Fri Mar 3 10:31:55 CET 2006
Boudewijn Rempt said the following, On 2006-03-02 20:44:
> Okay, so it turned out that I was still subscribed under an old email address,
> but my mailers sends everyone with the current one. Anyway, my fault, and I
> would like to thank Manish for helping me out of my bewilderment. What I
> wanted to propose & work on after my 1.5 release is the following:
> Cooperating on get an OpenDocument specification for layered raster images
> done and into the OASIS OpenDocument standard. Krita would use that format
> for its native format, of course, as all of KOffice is moving to
> OpenDocument automatically means some choices are made for us: a zip file
> store, a certain layout inside that store, and xml main document and
> resources for the binary data. Those choices may not be the best possible
> technical choices, but Krita already uses a similar mechanism and it seems to
> And since the Gimp and Krita have a different set of capabilities, we'd have
> to make a flexible and complete specification, one that includes all possible
> (possibly uninvented as yet) color models, adjustment layers, paths (which
> Krita doesn't have) and so on.
> I would really like to cooperate on this, since a standard used by one
> application isn't a standard at all and since it would mean much better
> interchange of documents than would be possible through either Photoshop
> (ancient version 6 or reverse-engineered later versions) or XCF.
> I'm prepared to do most of the writing & nagging of David Faure about
> procedures and guidelines, but I'm not knowledgeable enough to do it all on
> my own.
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.
I'd like to propose use well documented binary format, e.g. using Binary XML.
I wonder why OASIS picked to only use compressed XML as a medium:
-it will also not work well for video data, BTW.
-OpenOffice.org Base already failed to deliver robust solution because 100% of
the data has to be processed on loading/saving (unless it's stored on the server).
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.
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
[*] MS Excel
regards / pozdrawiam,
Jaroslaw Staniek / OpenOffice Polska
Sponsored by OpenOffice Polska to work on
* Kexi & KOffice: http://www.kexi-project.org | http://koffice.org/kexi
* KDE3 & KDE4 Libraries For Developing MS Windows Applications:
* Kexi For MS Windows: http://kexi.pl/wiki/index.php/Kexi_for_MS_Windows
* Kexi Support: http://www.kexi-project.org/support.html
More information about the kimageshop