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

[Jaroslaw Staniek]

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.
> 
> 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 
> work.
> 
> 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.

http://www.w3.org/TR/xbc-use-cases/#intro

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 
good reason.

Comments?


[*] 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:
                   http://www.kdelibs.com/wiki
See also:
* Kexi For MS Windows: http://kexi.pl/wiki/index.php/Kexi_for_MS_Windows
* Kexi Support:        http://www.kexi-project.org/support.html