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