Christopher Curtis <[EMAIL PROTECTED]> writes:

> I would reiterate what I said, but you quoted it.  "fully parseable by
> XML parsers up until the first NULL".  I'm not trying to jam image
> data into an XML format - simply prepending an XML header and using
> NULL as a separator.  This means you can cat the file and know exactly
> what's there.  Or you can open it in notepad (maybe make it NULL, ^Z
> for Windows people...)  "file" will be able to readily identify the
> individual formats, and people could even use dd to extract the layers.

But you couldn't use any generic XML tools like validators or XSL
transformations. If we go for XML we should really make sure that we
make it proper XML, otherwise XML doesn't make sense at all. We could
then as well go for a sexp syntax. Actually the latter would be a lot
easier to implement since we could build on the established GimpConfig

>> Is there a special reason you dislike the idea of using an archive
>> instead of a single XML file? I thought we would have been past this
>> point already...
> 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.

You don't have to unpack the whole archive and you can use existing
widely-available tools to extract the parts you need.

> OTOH, any 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 fancy compression-based-on-data-type instead of
> generic-text-compression over each layer or the whole archive.  If you
> want something fast, you can leave compression off and modify the data
> directly on disk without having to unpack/pack, as long as you stay
> within limits (ie: you can paint on a layer or move the layer around,
> but not add a new layer or change the bit-depth, and you just have to
> munmap() that section).  This makes it easy to have specialized
> external tools that manipulate layer data without all the GIMP
> overhead, easily scriptable, etc...

You can do all this with an uncompressed archive as I suggested.

Gimp-developer mailing list

Reply via email to