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.

Gimp-developer mailing list

Reply via email to