On 8/24/05, michael chang <[EMAIL PROTECTED]> wrote: > The only "portability" issue here is that you'd need to compile it on > all target OS's. No big deal -- that's how GIMP is made anyways. Use > MinGW for Windows, and Linux uses the GCC and related tools. Easy > enough.
Which means I'd have to mess around with getting access to the right development environment every time I needed to make a change. (And I do anticipate needing to make changes.) > Script-Fu only has the "advantage" of not requiring compilation before > execution, but it doesn't handle Raw IO or pixel-based image creation > IIRC (for good reason, too, proally). > > Perl probably has similar limitations, to a certain extent. Perl > handles text best -- binary data, it's best at simply passing... I > believe the term is ad verbatim or something. So it takes a second or two to convert an image using perl. Longer if it's a format varient where pixels adjacent visually aren't stored adjacent to each other, or some of those format variants. This costs what, a few minutes out of a day? Anyone using this image format is going to have to spend considerably longer than that just to load it into the environment which uses these images. Speed is not one of my priorities. Simplicity is. > Try copying a C image format plugin that already exists, maybe (e.g. xbm)? BMP and TGA are closer than XBM (all the image formats are binary pixel formats with a short header at the front. Some of the details can get strange, but those tend to be issues unique to this format.) But I'll take a look at XBM to see if it deals with multiple layers. Sure, GIMP is written using C, but I'm not planning on building or distributing the GIMP. I suppose I can try doing this in C, but shudder at the time I'm going to have to spend, building and maintaining those binaries. (woc) _______________________________________________ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
