On Thu, 17 Jul 2003 [EMAIL PROTECTED] 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).
> > 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
> 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.
Gimp-developer mailing list