That's reasonable.
> The user's always free to resize the image, but starting at a fixed
> width seems like it would be wrong about 100% of the time, whereas
> a fixed resolution could be adjusted for beforehand.
Granted, but I was operating off of the assumption that most "ordinary"
users would be pulling clipart, etc, directly from some collection or
other, where the image sizes are basically arbitrary, so the user is
likely to resize about 100% of the time. At least, that's what *I* end
up doing with generic clipart and images...
<snip>
> Another imlib drawback is that it isn't one library, as I remember...
> it requires all the supporting libraries for the image types it
> wants to support. For example, to load PNG, TIFF, XPM, JPEG, and
> GIF, one would need imlib, libpng, libtiff, libxpm, libjpeg, and
> libgif installed. If this has changed, let me know...
This hasn't changed, and for good reason. imlib was designed that way
to avoid re-inventing the wheel. The way I see it, we're going to have
to have importers for each format that we want to support. We can
either: a) write new ones from existing format specifications, b) copy
code from existing functions (like those found in libpng, libtiff, etc.)
directly into AbiWord, or c) use the existing functions in the existing
libraries.
With libpng, you decided (correctly, from my perspective) to just link
against the library, porting it to whichever architectures were
necessary. Why not do the same with libtiff, libxpm, libjpeg, libgif,
etc.?
And, if they're all going to be present for the sake of importing
graphics files, then throwing imlib on top of the pile should actually
*simplify* things, because we could just call imlib's generic "figure
out what kind of file this is and load it for me, please" function,
then copy the relevant portions of imlib's struct into our internal
one...
Have fun,
Nathan 'Nato' Uno
Nato@unos.net
http://web.unos.net/