On Thu, 17 Jul 2003 gimp-developer-request@xxxxxxxxxxxxxxxxxxxxxx wrote: > If we really are in brainstorming mode here, following the suggestions > listed above, how about a format something like the following, which is > essentially just an XML preamble, followed by raw binary data: > The nice thing about this is that it should be fully parseable by XML > parsers (up until the first NULL [1 is required, the rest are optional Fully parseable XML until it is isn't :) It is far better not to XML at all than to break XML. (incidentally this is similar to what has been suggested for Cinepaint). The proper XML way to do what you describe would be to take the raw binary and base 64 encode it (ick) which is grossly inefficient for anything large. The more sensible way and still valid way is to use a container format and to link to the raw BLOB (binary large object) that would be another file in your container format. > I just don't see using another archive format as giving you anything. > So say you use ZIP or JAR or TAR or AR: you still have to unpack (and > possibly decompress) the thing just to find out what's in it. > OTOH, any Using Zip as a container is not "On The Other Hand", it does not prevent any of the things you are suggesting. Zip allows you to grab just one file out of the archive if that is all you want, you can have differnt files inside a Zip archive each with different amounts of compression (including no compression). > program that can open a file can read the XML header here, even if they > don't parse it, it's still human readable. And this lets you do your run 'head' on an OpenOffice document and you will see that the manifest is left uncompresses so that you can easily read it as text. > fancy compression-based-on-data-type instead of generic-text-compression > over each layer or the whole archive. If GIMP were to use Zip/Jar only as a conatianer and not use the Zip compression then the whole container could be compressed using different / "better" compression if that is what you want. (I say "better" very guardedly because compression is often a trade off against how long you want to spend compressing or decompressing). yosh wrote: > > data offset is not predictable. But I assert that that is irrelevant > > because you can specify it to be anywhere. > > Another downside: needing a special tool to manipulate it. To reiterate what Yosh said, Needing specialised external tools would require more developement work, and add complexity not make things simpler. By reusing standards you can leverage existing tools, libraries and other peoples work, leaving more time to focus on image manipulation. > That's the advantage of using a standard format. Using standard tools to > manipulate it. More likelihood of a machine having a tool installed, and > less work for the GIMP team in maintaining special tools. > You're right about simplicity though, and ar is simpler than tar or zip/jar, > which is why I prefer it. zip/jar is especially crappy since the file index > is at the end, which means it's harder to recover from a partial file. I think the JAR format gets around the Zip crappiness by putting the manifest.xml at the start of the file. I could not say how hard it is but Winzip seems to do a pretty good job of repairing any broken zip archives I throw at it, at least allowing me to get some of the files out. - Alan
