Re: [Gimp-developer] GIMP GBR format spec
On Mon, Jul 14, 2003 at 10:16:28AM -0400, Leonard Rosenthol [EMAIL PROTECTED] wrote: At 08:38 AM 7/14/2003 -0400, Robert L Krawitz wrote: What happens if in the future someone writes a gimp-java interface (like gimp-perl)? Would there be any security issues there? No. I do not believe people like you. Sorry, but how can you so bluntly claim this? These things happened before, and often times, so instead of a simple No there *should* be very good arguments of why it should be different... And yes, java byte code *is* getting executed without having to kick it off, at least, in netscape, ie, mozilla, opera, konquereor -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ 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]
On Wed, 16 Jul 2003, Sven Neumann wrote: Date: Wed, 16 Jul 2003 13:57:18 +0200 From: Sven Neumann [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Menubar in fullscreen mode [Re: [Gimp-developer] the user installer] Hi, Alan Horkan [EMAIL PROTECTED] writes: Go to the menu and toggle View Menubar. How did you miss this? (Gimp 1.3.4) I had the menubar turned on I expected to still have the menubar in fullscreen mode. I don't understand your answer but just to clarify my sentence I will describe the behaviour of fullscreen mode for you. By default, if you I expected the menubar to stay on in fullscreen mode. I just wanted to point out that my expectations were different from what happened, which I realise is unneccessary information from your point of view. (I only have a recent build at home so it takes me a while to check these things). Having to turn it back on for full screen mode is sensible enough, and an entirely reasonably solution. Adobe seems to think Fullscreen with menu bar is an important enough option to give it a toolbar button and menu item. Perhaps the GIMP would consider giving it a menu item (and that menu item would allow a keyboard shortcut which is what I really want. if i recall correctly Photoshop uses Shift+F, instead of just F for fullscreen). normal mode and this state is saved and will be used again when you switch to fullscreen mode again later. I hope this clarifies things. Thanks for the clarification. Should I file a request in bugzilla, asking for a Fullscreen with Menu option or do you think it would not be worth adding? Sincerely Alan Horkan ___ 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, Alan Horkan [EMAIL PROTECTED] writes: Should I file a request in bugzilla, asking for a Fullscreen with Menu option or do you think it would not be worth adding? I think it is not worth to clutter the menu with this since the menu is always available as right-click menu anyway. The menubar has no additional value. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
On Wed, Jul 16, 2003 at 12:42:49PM +0200, Marc A. Lehmann wrote: What happens if in the future someone writes a gimp-java interface (like gimp-perl)? Would there be any security issues there? No. I do not believe people like you. Sorry, but how can you so bluntly claim this? These things happened before, and often times, so instead of a simple No there *should* be very good arguments of why it should be different... And yes, java byte code *is* getting executed without having to kick it off, at least, in netscape, ie, mozilla, opera, konquereor - you can turn it off - it's inside a sandbox (no access to local files) - 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 I think, the security argument against JAR is very far-fetched. A JAR is basically a ZIP with a META-INF directory containing a MANIFEST.MF file. That's it. There is a lot of code around for creating / reading ZIP files - I'm a bit worried about robustness though; if the directory at the end of the ZIP is broken or missing, things get complicated. 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. 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: Menubar in fullscreen mode [Re: [Gimp-developer] the userinstaller]
On Wed, 16 Jul 2003, Alan Horkan wrote: On Wed, 16 Jul 2003, Sven Neumann wrote: Date: Wed, 16 Jul 2003 13:57:18 +0200 From: Sven Neumann [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Menubar in fullscreen mode [Re: [Gimp-developer] the user installer] Hi, Alan Horkan [EMAIL PROTECTED] writes: Go to the menu and toggle View Menubar. How did you miss this? (Gimp 1.3.4) I had the menubar turned on I expected to still have the menubar in fullscreen mode. I don't understand your answer but just to clarify my sentence I will describe the behaviour of fullscreen mode for you. By default, if you I expected the menubar to stay on in fullscreen mode. I just wanted to point out that my expectations were different from what happened, which I realise is unneccessary information from your point of view. (I only have a recent build at home so it takes me a while to check these things). This actually could be a serious usablity issue, since a user who has the menubar on (which a distro might set as default) after going to fullscreen mode might not be able to figure out how to get the menubar back, or even how to return to windowed mode. (bah, watching actual real users in usablity tests at work stumble around when using really fairly simple interfaces has caused me to loose all faith in the intelligence of humanity. Then again, our users are actual real users, too.) Seriously, though, it would be a much better behavior to keep the menubar when the window is made fullscreen. A user that prefers a menubar will probably prefer one in fullscreen mode also. Besides, a user with a clue will be able to turn off the menubar anyway. Rockwalrus ___ 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]
This actually could be a serious usablity issue, since a user who has the menubar on (which a distro might set as default) after going to fullscreen mode might not be able to figure out how to get the menubar back, or even how to return to windowed mode. Hit Escape (Esc) should work. Also the keybinding for Fullscreen mode should take them back. Many programs do also provide some sort of extra clearly obvious button that takes you out of fullscreen. (bah, watching actual real users in usablity tests at work stumble around when using really fairly simple interfaces has caused me to loose all faith in the intelligence of humanity. Then again, our users are actual real users, too.) I have to be regularly reminded that most users dont use software on a regular basis and essentially have to relearn from scratch each time they try to use an appliction. Seriously, though, it would be a much better behavior to keep the menubar when the window is made fullscreen. A user that prefers a menubar will probably prefer one in fullscreen mode also. Besides, a user with a clue will be able to turn off the menubar anyway. I am just really glad to have the menu bar at all. (Thanks to who ever added it) - Alan H. ___ 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, Alan Horkan [EMAIL PROTECTED] writes: Go to the menu and toggle View Menubar. How did you miss this? (Gimp 1.3.4) I had the menubar turned on I expected to still have the menubar in fullscreen mode. I don't understand your answer but just to clarify my sentence I will describe the behaviour of fullscreen mode for you. By default, if you enter fullscreen mode and your WM signals that it supports this operation, all widgets around the canvas are switched off. You can however access the Image-View menu using the right-click menu. There you can reenable individual elements like menu-bar, rulers, status-bar and the like. These changes do not affect the state of the view in normal mode and this state is saved and will be used again when you switch to fullscreen mode again later. I hope this clarifies things. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
new-xcf (was:Re: [Gimp-developer] GIMP GBR format spec)
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote:
Well, ar's limitations with respect to name length etc. are in practise
not every severe (nobody will have 1 character file names (the ar
limit), and even antique ar implemnentations will support up to 255
characters).
Technically I don't know if that's true. From my ar man page:
GNU ar can maintain archives whose members have names of
any length; however, depending on how ar is configured on
your system, a limit on member-name length may be imposed
(for compatibility with archive formats maintained with
other tools). If it exists, the limit is often 15 charac-
ters (typical of formats related to a.out) or 16 charac-
ters (typical of formats related to coff).
But, that is of no consequence -- we wouldn't need to keep
meaningful names, we just need unique resource ids that the XML
structure can refer to... these could quite simply be numbers
counting up from zero, or hash strings. In either case just
15 characters could be fine.
I am not opposed to uncompressed jar files, but compression is certainly a
bad idea (the jar compression algorithm is rather ineffective)
I like the idea of ar files. Compression then happens by
[un]{b,g}zipping the ar via a compression plugin in the usual
GIMP style.
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. In
this case something like a ZIP (or okay, equivilently, a compressed
jar, whatever you want to call it) is a better (and still
exceedingly standard in its most basic form) choice of
wrapper for the hierarchy-file-plus-linked-resources.
--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] GIMP GBR format spec
Hi, [EMAIL PROTECTED] (Tino Schwarze) writes: I think, the security argument against JAR is very far-fetched. A JAR is basically a ZIP with a META-INF directory containing a MANIFEST.MF file. That's it. There is a lot of code around for creating / reading ZIP files - I'm a bit worried about robustness though; if the directory at the end of the ZIP is broken or missing, things get complicated. I don't think we should use a compressed archive. Instead the binary data in the archive should be compressed. That allows to choose the best compression scheme for the data and to combine different compression techniques in the archive. Compressing the whole archive again would probably only reduce the size marginally and would add unneccessary complexity. You robustness argument is also a very good argument against compressing the whole archive. 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. 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. 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]
Nathan Carl Summers wrote: (bah, watching actual real users in usablity tests at work stumble around when using really fairly simple interfaces has caused me to loose all faith in the intelligence of humanity. Then again, our users are actual real users, too.) Yes, quite so. :( Seeing such studies pretty much turned around my ideas on UIs. -- 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: Menubar in fullscreen mode [Re: [Gimp-developer] the userinstaller]
Hi, Nathan Carl Summers [EMAIL PROTECTED] writes: This actually could be a serious usablity issue, since a user who has the menubar on (which a distro might set as default) after going to fullscreen mode might not be able to figure out how to get the menubar back, or even how to return to windowed mode. Pressing F11 again or hitting ESC will get you out of full-screen mode again. Seriously, though, it would be a much better behavior to keep the menubar when the window is made fullscreen. A user that prefers a menubar will probably prefer one in fullscreen mode also. Besides, a user with a clue will be able to turn off the menubar anyway. Fullscreen mode was added to be able to view the image in a neutral environment w/o being distracted by any user interface elements. Adding a menubar would completely ruin this effort. The fact that you can edit the image in full-screen mode and that we even decided to allow you to tweak what gets hidden and what not is just an additional nicety and I'm actually tempted to remove it. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: new-xcf
Hi, Adam D. Moss [EMAIL PROTECTED] writes: 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. 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]
On Wed, 16 Jul 2003, Sven Neumann wrote: Hi, Nathan Carl Summers [EMAIL PROTECTED] writes: Fullscreen mode was added to be able to view the image in a neutral environment w/o being distracted by any user interface elements. Adding a menubar would completely ruin this effort. I'm sure any UI expert you talk to (or really, anyone who thinks about it for twelve seconds) will tell you that putting up a fullscreen image without any obvious method of exiting is likely to inspire panic in the user, who doesn't know how to get out. The fact that you can edit the image in full-screen mode and that we even decided to allow you to tweak what gets hidden and what not is just an additional nicety and I'm actually tempted to remove it. Don't! Fullscreen mode is useful for more than that. It is nice when working on a large image, or a smaller image with high magnification, to get rid of superfluous stuff like the window decoration, but in that case the user may still want to use of the stuff that would otherwise be hidden. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
On Wed, Jul 16, 2003 at 05:35:42PM +0200, Sven Neumann wrote: I don't think we should use a compressed archive. Instead the binary data in the archive should be compressed. That allows to choose the best compression scheme for the data and to combine different compression techniques in the archive. Yes! Just in case anyone taking part in this discussion didn't know, the compression routines used by gzip and ZIP are generic text compression techniques, they don't understand interleaved formats (commonly used for RGB data, stereo audio etc.) nor multi-byte representations such as the 32-bit IEEE floats we might be using in a few years in The GIMP so they produce rather poor results compared to specialised compression techniques which The GIMP could inherit from existing Free Software. Nick. ___ 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]
On Wed, Jul 16, 2003 at 03:39:25PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: Should I file a request in bugzilla, asking for a Fullscreen with Menu option or do you think it would not be worth adding? I think it is not worth to clutter the menu with this since the menu is always available as right-click menu anyway. The menubar has no additional value. That (no additional value) must be the reason why it's enabled by default :) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ 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]
On Wed, 2003-07-16 at 18:28, Nathan Carl Summers wrote: Don't! Fullscreen mode is useful for more than that. It is nice when working on a large image, or a smaller image with high magnification, to get rid of superfluous stuff like the window decoration, but in that case the user may still want to use of the stuff that would otherwise be hidden. I find this a lot more useful as well, probably because that's what the fullscreen mode was for in Photoshop. A preview is nice as well, but fullscreen editing is quite a kick-ass feature. -- Jakub Steiner [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: new-xcf (was:Re: [Gimp-developer] GIMP GBR format spec)
On Wed, Jul 16, 2003 at 04:28:18PM +0100, Adam D. Moss [EMAIL PROTECTED] wrote: Technically I don't know if that's true. From my ar man page: GNU ar can maintain archives whose members have names of any length; however, depending on how ar is configured on your system, a limit on member-name length may be imposed (for compatibility with archive formats maintained with other tools). If it exists, the limit is often 15 charac- ters (typical of formats related to a.out) or 16 charac- ters (typical of formats related to coff). But, that is of no consequence -- we wouldn't need to keep The archive formats that the ar manpage above refers to are what mortla people call object files. Since ar is part of binutils it tries to be compatible to other object formats which often have severe limitations. ar also handles hierarchical structures within ar files, but for compatibility it doesn't create them. (and there are common extensions that allow unlimited name lengths, these are also handled by ar). can easily be talking HUGE) temporary intermediate file. In this case something like a ZIP (or okay, equivilently, a compressed jar, whatever you want to call it) is a better (and still exceedingly standard in its most basic form) choice of wrapper for the hierarchy-file-plus-linked-resources. something like zip is the key. zip won't do, of course, since it's lousy at compression and also doesn't support random access like we want. Also, I think compression at the file level (whole file) is not a good idea anyway, so we could keep a simple wrapper format (like ar) and implement a more intelligent block structure within the constituent files. However, the reason why people propose ar, jar, cpio etc... as formats is that they cna be handled by users with ease, being well established. If we would design our own extremely simple wrapper format there would be no need to work with the compatibility mess existing formats are (all of them :). If we say that access by other tools than gimp is not important we could get away with an extremely simple format, say, cat files*, index at end which could be just offset and length, indexed by number, meta-info is all handled by an xml sub-file. The question is simply wether it should be a standard format or not. If we want to implement a kind-of tile cache within the image to speed up loadign and operations, using a format like ar/jar/etc. would just be a hindrance, as users wouldn't be able to deal with the files within them anyways. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: new-xcf
Hi, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: If we would design our own extremely simple wrapper format there would be no need to work with the compatibility mess existing formats are (all of them :). If we say that access by other tools than gimp is not important we could get away with an extremely simple format, say, cat files*, index at end which could be just offset and length, indexed by number, meta-info is all handled by an xml sub-file. The question is simply wether it should be a standard format or not. I would really like to see a format that is suited to serve as a more general exchange format for image data. If possible it should not be designed as a GIMP-only format. People already use XCF in other apps simply because there is no reasonable format for layered images. So there's seems to be a need for such a format which is why I would like to make access to it as simple as possible. Of course this goal could also be achieved by providing a library that handles whatever weirdo binary format we come up with... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: new-xcf (was:Re: GIMP GBR format spec)
[EMAIL PROTECTED] (2003-07-16 at 2223.29 +0200): If we would design our own extremely simple wrapper format there would be no need to work with the compatibility mess existing formats are (all of them :). If we say that access by other tools than gimp is not important Brainstorming, a dir named .xcf2 with the proposed contents inside? :] GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Menubar in fullscreen mode [Re: the userinstaller]
[EMAIL PROTECTED] (2003-07-16 at 2244.11 +0200): Don't! Fullscreen mode is useful for more than that. It is nice when working on a large image, or a smaller image with high magnification, to get rid of superfluous stuff like the window decoration, but in that case the user may still want to use of the stuff that would otherwise be hidden. I find this a lot more useful as well, probably because that's what the fullscreen mode was for in Photoshop. A preview is nice as well, but fullscreen editing is quite a kick-ass feature. I always wondered why then the app has to do it, instead of the wm providing a trully full screen mode (no decors). I thought special full screens where due something different, like viewing video without any widget. :-/ GSR ___ 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 10:43:13PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: designed as a GIMP-only format. People already use XCF in other apps simply because there is no reasonable format for layered images. That is not true. MIFF was around for years, for example, was always able to store layers, animations, and an unlimited amount of meta information. There are probably others, too. XCF isn't the first (nor the most open) format for this task (and it wasn't intended as one). there's seems to be a need for such a format which is why I would like to make access to it as simple as possible. This, of course, is a good goal in it's own. However: - maybe there is a need to have a gimp-specific file format, especially when you want to store the image data in a non-trivial way to speed up access. - maybe there is a need to have a nicely defined exchange format for complex images (xml + data is nicer than the ad-hoc design of miff). These are conflicting goals. Realisticelly, however, it'll be a long time till gimp wants a special, optimized on-disk format. (as for a format, miff is basically line-based header + image data, iterated, which is very nice... it'S not nifty XML, but the fatc that image data and metadata are grouped so near to each other is also nice...) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
Date: Wed, 16 Jul 2003 16:12:37 +0200 From: [EMAIL PROTECTED] (Tino Schwarze) On Wed, Jul 16, 2003 at 12:42:49PM +0200, Marc A. Lehmann wrote: What happens if in the future someone writes a gimp-java interface (like gimp-perl)? Would there be any security issues there? No. I do not believe people like you. Sorry, but how can you so bluntly claim this? These things happened before, and often times, so instead of a simple No there *should* be very good arguments of why it should be different... And yes, java byte code *is* getting executed without having to kick it off, at least, in netscape, ie, mozilla, opera, konquereor - you can turn it off But the default configuration of most browsers is for it to be turned on. - it's inside a sandbox (no access to local files) That depends upon the JVM configuration. - 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. I think, the security argument against JAR is very far-fetched. A JAR is basically a ZIP with a META-INF directory containing a MANIFEST.MF file. That's it. There is a lot of code around for creating / reading ZIP files - I'm a bit worried about robustness though; if the directory at the end of the ZIP is broken or missing, things get complicated. 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? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
On 07/16/03 20:26, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: - maybe there is a need to have a gimp-specific file format, especially when you want to store the image data in a non-trivial way to speed up access. - maybe there is a need to have a nicely defined exchange format for complex images (xml + data is nicer than the ad-hoc design of miff). 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: gimp type=image version=1.0 nameMy Example Image/name authorChristopher W. Curtis/author descriptionA big, purple, E/description date format=logical2003/07/18/date copyright2003 FSF, All Rights Reserved/copyright layer name=Background mode=overlay opacity=0% dimensions width=800 height=600 / origin x=0 y=0 / data offset=2000 format=RGBA bpp=12 / /layer [...] /gimp \000\000\000 [...] \000 until file offset=2000 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 buffer space for those too lazy to do math]), it is completely human readable and very descriptive, highly extensible, and fully functional. You can add an encoding= or compression= option, specifying none, bzip2, or whatever, or even format= and jpg (at the layer mode, making the dimension, etc. tags optional; you'd still need data offset, etc.) The other nice thing is that you can just read the header, and load the rest of the layers on demand (for other 'preview' tools or what have you), and it can be used for other items as well. Instead of type=image you can have type=brush, etc. Maybe even add an attribute like thumbnail format=jpg offset=12580 /. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
