Re: [Wvware-devel] libwmf copy_xpm recommended change

[Bob F. <bfr...@si...>]

On Mon, 1 Jan 2001, F J Franklin wrote:

> On Sun, 31 Dec 2000, Bob Friesenhahn wrote:
> > Based on what I am seeing in wmfapi.c, I recommend that the signature
> > of wmffunctions->copy_xpm be altered to remove the current filename
> > argument, and replace it with a void* to the BMP data in memory, and
> > an integer to specify the length of the data.  The code that prepares
> > a temporary file should be ripped out (with a vengance).  This removes
> > the dependence of libwmf on libdib, libXpm, and netpbm.
> 
> wmfapi loads the entire bitmap into memory (wmfrecord.Parameters) with
> the bytes swapped; has to save to file in order to reswap (re-swapping
> could be performed in memory, or the bitmap could be re-read from source 
> meta file); & then:
> 
> - reloads using libdib
> - cropping could, I suppose be done while reading
> - scaling is more complicated
> 
> These could be done by the device-implementation (X, magick, whatever).
> However, unless we wish to be entirely dependent on magick for the device
> layer, we ought to (re-?)implement a generic mechanism as well.
> 
> If magick can do this, can we incorporate magick code into libwmf?

All code in ImageMagick is free for use under a very generous license
(basically, "don't blame us", and "don't claim to represent us").  It
would be easier to just use ImageMagick's libMagick.so rather than try
to use its source code since the implementation of ImageMagick is a
bit arcane.

ImageMagick can readily read BMP "files" from memory provided that the
in-memory image is identical to the way a BMP file would appear on
disk.  ImageMagick is written to not be sensitive to endianness.  
Cropping and scaling are trivial (simple function calls). Is the need
for swapping a big/little endian issue due to limitations in libdib?

> The more I think about libwmf, the more I feel the need for two distinct
> interfaces, one with the program(mer) (who wishes to read the meta file),
> and the other with the back-end device library/module. (The weakness with
> libwmf in its present state is that there is no one clear interface, let
> alone two.)

What do you mean by "read the meta file"?  Do you mean that the
programmer just wants a rendered image of the WMF?

Another problem with libwmf that needs to be resolved is that it is
impossible to compile it under Windows since it is based on structures
and types stolen from Windows.  All of these structures and types need
to be re-named.  This is an issue for us (ImageMagick) since we
currently compile and run on Windows, MacOS, VMS, Unix, Linux, and
BeOS.

Bob
======================================
Bob Friesenhahn
bfr...@si...
http://www.simplesystems.org/users/bfriesen