Re: [Gimp-developer] GIMP GBR format spec
On Wed, Jul 16, 2003 at 08:27:12PM -0400, Robert L Krawitz wrote: - to be able to execute some Java code out of a (virus-altered) GIMP image (Gimp Graphics Archive) takes: * a person running java -jar picture.gga * some smart program looking inside the image, recognizing the manifest etc (which makes the JAR executable), running this (probably requirng user interaction) * a Java machine Not necessarily. If the appropriate MIME type isn't set up for .gga files, a browser might helpfully run file on the file, identify it as a JAR, and run java on it. That requires a spot of misconfiguration (or social engineering), but it's a bad idea to assume that other things are configured correctly. So you are basically saying: Do not use ZIP files for anything but Java stuff. Your argument holds for any ZIP file. It might get executed somewhere. But I think this is purely academical and has nothing to do with the GIMP file format. But a hierarchical structure would be cool too. What about mapping big parts of the file format to the file system? This way, a lot of information can be stored in the hierarchy and it wouldn't be a big difference whether to read a file from file system or from archive. What properties are you assuming in the filesystem? Probably too many. I imagined something like Image_name/ image.xml (meta-data) comment.txt Layers/ Layer1/ Layer1/ layer.xml (opacity, mode etc.) comment.txt data.png Layer2/ layer.xml comment.txt data.png Layer3/ Layer1/ ... Layer2/ ... Layer2/ Layer1/ layer.xml data.png Paths/ path1.xml path2.xml But there are probably lots of issues with this design. Bye, Tino. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
On Wed, Jul 16, 2003 at 06:19:27PM +0200, Sven Neumann wrote:
HOWEVER, this might be a good time to think about whether we'd
prefer a compressed format that we can random-access de/compress
on the fly instead of going via a huge (and with image data we
can easily be talking HUGE) temporary intermediate file.
If we would compress the image data in the archive there would be no
need for compression of the archive. Sure you could gain a few bytes
by compressing the XML but since the already compressed image data
doesn't compress well and in the worst case even gets larger, I don't
see why anyone would want to compress the archive.
Agreed.
I have a more concrete suggestion (I'm still favoring ZIP files because
they can somehow be handled without a GIMP which is useful, e.g. if they
are broken): Make an uncompressed ZIP (or maybe compress the XML part
only). The XML describes the structure and all attributes.
GIMP-Image.ZIP
|
+- image.xml
|
+- comment.{txt,html,xml}
|
+- layer1.png (stored uncompressed)
|
+- layer1.1.png
|
+- layer2.png
...
|
+- image-thumbnail.png (optional)
|
+- whole-image.png (flattened image, optional)
IMO this is a sane approach. It has lots of benefits:
- image contents are accessible without a GIMP
- thumbnails can be extracted easily
- a user can mess with the image
- images could be generated with external tools
(just create the XML, add some images as layers, here you are)
- it could be scanned for Java-viruses :-
Bye, Tino.
--
* LINUX - Where do you want to be tomorrow? *
http://www.tu-chemnitz.de/linux/tag/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
Hi, Christopher W. Curtis [EMAIL PROTECTED] writes: 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 I don't think the format you proposed is valid XML. There might be XML parsers that are able to read it but it violates the spec. If I am wrong here, please show me where the spec defines the special role of the NULL character. 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... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Menubar in fullscreen mode [Re: [Gimp-developer] the userinstaller]
Hi, David Neary [EMAIL PROTECTED] writes: No - it's enabled by default because I thought it should be. I'm quite sure that Sven has turned it off :) I have it turned on so I get reminded how akward it is all the time I use The GIMP. Actually I tried to get used to it but I still can't stand it. I will however leave it turned on so that I am forced to continue to think about how to improve it (and we have some ideas already... ). Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
Sven Neumann wrote: Christopher W. Curtis [EMAIL PROTECTED] writes: 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 I don't think the format you proposed is valid XML. There might be XML Rule #1 in brainstorming: don't criticise any idea, no matter how silly. parsers that are able to read it but it violates the spec. If I am wrong here, please show me where the spec defines the special role of the NULL character. 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. 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. 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... This would also be a much simpler format, and I like simple. If you want to talk about downsides, I can think of only one: the first data offset is not predictable. But I assert that that is irrelevant because you can specify it to be anywhere. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
Hi, 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 framework. 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. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
Manish Singh wrote: On Thu, Jul 17, 2003 at 12:06:12PM -0400, Christopher Curtis wrote: Rule #1 in brainstorming: don't criticise any idea, no matter how silly. So much for rules... Another downside: needing a special tool to manipulate it. Well, now, I want to end this silliness right here. Here's what you need to manipulate files in my propsed format: (cat and dd), or (vi), or (type and wordpad). There are no tools more standard than these. Consider the case of a corrupted xcf file. Maybe only 1 layer out of 20 is corrupted. With this proposal, a user needs either a special tool to extract out the good layers, or do a lot of work by hand to figure out how to use dd to grab it. With this format, a tool like the gimp can say layer X is corrupt and the user would have to do something crazy like edit the file with vi and delete the ``layer type=corrupt ... /layer'' section from the XML header. With say ar, the user can extract individual layers by some tag, referenced in the xml metadata. Then can edit the xml to stub out the broken layer, and repack it and have a valid xcf file. This could be the difference between losing 10% of the work vs. all of it. Ahh yes, this way all the user has to do is: ar x file look for the right xml and edit it out or something based on some tag (I'm so glad this is so well thought out...) ar a file everythingelse1,2,3 Won't the Windows people be happy that they can do this instead of just opening a friggin binary-safe text editor. So while a user can open a text file header in an editor, they are going to need a tool anyway to manipulate it effectively. Yeah - it's called the same text editor. 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. taptaptap ... is this thing on? You're right about simplicity though -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
Sven Neumann wrote: Hi, 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 framework. I'm not going to argue it. I disagree that an XML preamble is useless becuase you can't XSLT the entire file just as much as I'd disagree if you said that saving a file to disk is useless because it's not a full core image. You don't have to unpack the whole archive and you can use existing widely-available tools to extract the parts you need. Fair enough. When I save a file, I typically need the whole thing. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Gradient dithering
Hi, I've created a little patch against GIMP 1.2.5 to allow dithering of gradients, which significantly improves their appearance when printed. If you're interested, you can find out more here: http://www.blackfiveservices.co.uk/dithergrad.shtml Comments/criticism welcome All the best, -- Alastair M. Robinson Email: [EMAIL PROTECTED] You can't make a program without broken egos. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
Ok .. I want to apologise to everyone for overreacting. After a brief moment of reflection, a simple container has notable advantages over a single file, not to mention that a one of my assumptions didn't make sense. Where is there documentation on the ar format? I can't seem to find any. I'd like to read up on it some before commenting further... Thanks, Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: new-xcf (was:Re: GIMP GBR format spec)
[EMAIL PROTECTED] (2003-07-17 at 0959.32 +0200): Brainstorming, a dir named .xcf2 with the proposed contents inside? :] Would probably cause problems (ie. be cumbersome) copying, moving around on the web, etc. :-) We aren't quite at reiser4 yet. :-) Well, I think people can copy dirs like they copy files (the small nitpick is shell users, and those should know how to solve it). And pack them for web too. Only problem I see is users complaining about what was a single files now being a single dir, and oh, damn, I can look inside. In the end, both are project contaniers. No need of any future FS, NeXT did it long time ago, it is more about the upper level tools than the FS. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
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). 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gradient dithering
Sven Neumann wrote: Alastair Robinson [EMAIL PROTECTED] writes: I've created a little patch against GIMP 1.2.5 to allow dithering of gradients, which significantly improves their appearance when printed. If you're interested, you can find out more here: http://www.blackfiveservices.co.uk/dithergrad.shtml How is that different from enabling Adaptive Supersampling in the blend tool options? It looks quite a lot different -- as far as I can tell from reading the patch, it does what it says on the bottle, that is, it (random-)dithers the truncated precision into the lowest bit(s) of the 8-bit precision that we support. Conceptually I like this, and the gotchas are toggleable via the UI. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
Alan Horkan wrote: It is far better not to XML at all than to break XML. (incidentally this is similar to what has been suggested for Cinepaint). Just for the record ... I read the CinePaint file format, and it doesn't even resemble XML. My PREAMBLE is valid XML. If they implement what they have written, they don't even bother with things like closing tags or putting parameters in quotes. 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 Which is why I said preamble. 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. Which is what, at this point, I would prefer. OTOH, any Using Zip as a container is not On The Other Hand, it does not prevent any of the things you are suggesting. Using a container at all is OTOH. 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. OpenOffice documents are zipped; you can't head them. btw: META-INF/manifest.xml is at the end of my .sxi file. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
Manish Singh [EMAIL PROTECTED] writes: I don't see a compelling argument to use zip/jar. It's complexity that doesn't buy us anything over ar. $ ar t gimp1.2-print_4.2.5-4_i386.deb debian-binary control.tar.gz data.tar.gz The Debian dpkg .deb package format uses an ar archive with gzip compressed members. It's very robust, and it's simple to extract information from any of the members as needed. e.g. $ ar p gimp1.2-print_4.2.5-4_i386.deb control.tar.gz | tar xfz - ./md5sums $ cat md5sums 3698d1f4ce3025bc8c0af73aad39c351 usr/lib/gimp/1.2/plug-ins/print a9e993933c62cf972a07ba60d099a5be usr/share/doc/gimp1.2-print/html/FAQ.html 0f06e25e158d58be369f6c81c74f350f usr/share/doc/gimp1.2-print/html/print-color.png 8af9040e743fdea01d048a9625be3f37 usr/share/doc/gimp1.2-print/html/print-main.png 9bcaba3b091edb324a4e3658d3b4c17b usr/share/doc/gimp1.2-print/html/print-setup.png bdb27f0b9e600cbf067b34d26b62727b usr/share/doc/gimp1.2-print/samples/colorbars4.png cd6014ab378eeebbaee1723b78ef4459 usr/share/doc/gimp1.2-print/samples/colorsweep.png a9e993933c62cf972a07ba60d099a5be usr/share/doc/gimp1.2-print/FAQ.html d41331233e7703ff0c7f365a1f1fa2a4 usr/share/doc/gimp1.2-print/README.Debian 37ae0a31af00c0fa8569104c96927391 usr/share/doc/gimp1.2-print/copyright 9581201d2bf1fc7b5fcf4c3463d79854 usr/share/doc/gimp1.2-print/changelog.gz 7b58392e6bc678907651c89bdb134763 usr/share/doc/gimp1.2-print/README.gz 5fa90d8012eebb8038dd991d46155ff5 usr/share/doc/gimp1.2-print/changelog.Debian.gz -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
On Thu, 17 Jul 2003, Roger Leigh wrote: Date: Thu, 17 Jul 2003 22:22:17 +0100 From: Roger Leigh [EMAIL PROTECTED] To: Manish Singh [EMAIL PROTECTED] Cc: Alan Horkan [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol 10, Issue 18] Manish Singh [EMAIL PROTECTED] writes: I don't see a compelling argument to use zip/jar. It's complexity that doesn't buy us anything over ar. $ ar t gimp1.2-print_4.2.5-4_i386.deb debian-binary control.tar.gz data.tar.gz The Debian dpkg .deb package format uses an ar archive with gzip compressed members. It's very robust, and it's simple to extract information from any of the members as needed. e.g. $ ar p gimp1.2-print_4.2.5-4_i386.deb control.tar.gz | tar xfz - ./md5sums you used a pipe what happened there is that you just unzipped the entire archive then in a seperate operation you extracted just the files you wanted. there is nothing wrong with that, you get better compression that way. In a zip archive you really do just extract the single file, there is no unzipping of the whole archive first, which is useful if you just want to grab one or two files quickly from a large archive. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
On Thu, 17 Jul 2003, Christopher Curtis wrote: Date: Thu, 17 Jul 2003 17:10:02 -0400 From: Christopher Curtis [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol 10, Issue 18] It is far better not to XML at all than to break XML. (incidentally this is similar to what has been suggested for Cinepaint). even resemble XML. My PREAMBLE is valid XML. If they implement what they have written, they don't even bother with things like closing tags or putting parameters in quotes. A preamble, which is effectively full XML file, a boundry then more information which is effectively another file. Two files in one file, sounds like an ad-hoc container to me. Which is what, at this point, I would prefer. OTOH, any Using Zip as a container is not On The Other Hand, it does not prevent any of the things you are suggesting. Using a container at all is OTOH. 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. OpenOffice documents are zipped; you can't head them. btw: META-INF/manifest.xml is at the end of my .sxi file. I made a terrible mistake of generalising from one instance. It is doable it but it was just coincidental in that it was done that way in the file I looked at. While I am apologising, I may as well repeat what I said offlist. I only used Winzip as an example, there are several programs which can recover parts of zip files, so repairing damaged zip files is possible (although I cant guess how difficult it is do it). I expect there must be command line tool for unix zip files, i just dont happen to know what it is yet. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
On 07/17/03 19:41, Alan Horkan wrote: On Thu, 17 Jul 2003, Christopher Curtis wrote: even resemble XML. My PREAMBLE is valid XML. If they implement what they have written, they don't even bother with things like closing tags or putting parameters in quotes. A preamble, which is effectively full XML file, a boundry then more information which is effectively another file. Two files in one file, sounds like an ad-hoc container to me. As interesting as what I said was, I don't see how your comment logically follows. Anyway ... I only used Winzip as an example, there are several programs which can recover parts of zip files, so repairing damaged zip files is possible (although I cant guess how difficult it is do it). This is something that shouldn't really be an issue. The ZIP format keeps the list of files at the end, so that if the file is clipped, the directory is lost, and you can recreate it by scanning the archive for delimiters. The reason it can be repared at all is because the most likely thing to get lost is the meta-information. So, after some research, I've decided that ar is a fine container format. My only conribution, which you may take as you will, would be to specify that the first entry in the archive is the descriptive catalog. Naturally I'm thinking the XML snippet I stated earlier, sans the data offset thing. The advantage to this is that you can detect if the file is corrupt, and you have two ways or accessing data: via meta-information only, or via the actual data entry. This means there's no need to scan through the archive to find its contents, and means that you can read the file using more and it works fine (as long as the XML file is uncompressed). The downside to using 'ar', really, is that WinZip doesn't support it. I haven't verified this - I hope a Windows user can do so for us. Just for reference, attached below is a CP of an ar archive I just made: bash-2.05b$ echo 1 file1 bash-2.05b$ echo 2 file2 bash-2.05b$ ar r myar.xcf file* bash-2.05b$ (echo --; cat myar.xcf; echo --) -- !arch file1/ 1058492021 1000 1000 100644 2 ` 1 file2/ 1058492025 1000 1000 100644 2 ` 2 -- Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
At 5:35 PM +0200 7/16/03, Sven Neumann wrote: I don't think we should use a compressed archive. Instead the binary data in the archive should be compressed. I agree - and that's what ZIP/JAR allow for - some files/blobs are compressed, and some are not. You could either use the built-in methods to specify this, OR use the XML manifest. That allows to choose the best compression scheme for the data and to combine different compression techniques in the archive. Exactly! As I pointed out in an earlier mail, I am not sure if a hierarchical structure in the archive is a good idea. In my opinion the hierarchy should only be defined in the XML part that describes how the contents of the archive should be put together. If we apply the document hierarchy to the archive, it will become painful to keep the XML description and the archive hierarchy in sync. It's an interesting tradeoff. If you leave it flat, that means that it's not possible to establish relationships between objects WITHOUT parsing the XML - so that standard archiving tools wouldn't be helpful. On the other hand, you are right, that syncing the two could be a pain. LDR -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] A comment on CinePaint (was Re: new-xcf)
At 5:10 PM -0400 7/17/03, Christopher Curtis wrote: Just for the record ... I read the CinePaint file format, and it doesn't even resemble XML. Yeah, I've had that argument with Robin - and lost :(. They are going for simple and scriptable over good design - I think they will regret it ver soon... Leonard -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
