Actually, I've been thinking for a couple of weeks (on and off) about
resizing images. I haven't said anything 'cause I *don't* have time to
implement anything, and I hate to make suggestions without backing them
up with code. BUT, since you asked... >)
I don't have a (reasonable) opinion on the starting size of the image.
It might be reasonable to import them at a fixed width and assume the
user's going to resize them anyway.
But I haven't looked at the code yet, so lemme do that... Okay, it
appears to me (and *please* correct me if I'm wrong) that we get a
pixel-for-pixel mapping at the current zoom because we have no resize
functions, so we don't have any choice - we have to map 1-to-1. So, if
we *had* resize (scale) functions, we could: a) insert at any arbitrary
original size, and b) resize (scale) as necessary. (Note that I'm
completely ignoring the fact that we'll have to build a UI construct
for this, too - some kind of "handles" for the image.)
So this brings me to a thought I've been kicking around for a little
while. What are the objections to using imlib? It has the scaling
functionality that we want, it works on similar data structures to what
we have set up internally (if I understand correctly), and it knows how
to load many image types into the same internal structure, so we
automagically get multiple graphics format import functionality (imlib
supports PPM, PGM, TIFF, PNG, XPM, JPEG and EIM internally).
Granted, I'm not sure how cross-platform it is, and I'm not sure we
want to add another library to the list of required ones, but it seems
to give us things we want...
Like I said in the beginning, though, I'm hesitant to even make
suggestions, because I can't back them up with code right now (no
time).
Have fun,
Nathan 'Nato' Uno
Nato@unos.net
http://web.unos.net/