Thomas Fletcher écrit:
> I think that it is important to realize that ImageMagick
> is not a straight replacement for having our png/jpeg
> libraries, it provides a standard interface which we can
> use for manipulating images. Last time I checked IM required
> a large number of "helper libs" (such as libjpeg, libpng,
> zlib etc) in order to actually do the translation of image
> types.
It still require helpers libraries. I found this out after sending my mail
about moving to IM, and I was a little disappointed as it removed for me the
advantage of one lib for everything.
> The proposal of a miniIM would be to trim out the excessive
> functionality that AW doesn't need, which includes those
> image formats we don't want to support natively. I agree
> that we need to have some scheme to take advantage of locally
> available API's where possible, but one would hope that
> all it would take would be a bit of work to create a miniIM
> module that would use the local system resources instead
> of the "helper libraries".
These local API are here already. Look at ie_impGraphic.h. My JPEG import is
done using ie_impGraphic_JPEG.cpp. I have changed code nowhere but in this
directory: the .cpp and .h specific to JPEG import, ie_impGraphic.cpp to add
my importer to the list (will be obsoleted by dynamic loading) and the
makefiles. That's all, and we get preview support within the open file
dialog, for free.
As for miniIM, i'm not sure whether we really need it. Use IM as an option
or don't use it. stripping it down is not worth the effort IMHO since all
the import code, the actual file reading, is still in separate library.
> I don't think that anyone is arguing that we shouldn't use
> the native imaging interface where it is possible, it is
> simply a question of how can we integrate various platform
> imaging interfaces in an XP style (ie use IM API across the
> board) while still providing the same functionality across
> the board platformwise (ie use native interface for IM where
> possible, otherwise use the modules provided by IM). Since
> we are talking about a reduced subset of guaranteed image
> support (right now PNG, JPEG, BMP? and SVG for the future)
> this shouldn't be too arduous a task.
For me adding platform imaging would have only been by creating such an
importer, and nothing else (of course, specific to the platform).
We currently have PNG, BMP. I do have JPEG (I'm willing to send the patch to
anyone who wish to try it out). SVG is a different matter as it is a native
imaging format and require implementing gr_VectorImage and it rasterization.
Hub
--
Lead developer on libcwk
<http://sourceforge.net/projects/libcwk/>
