From: Bob F. <bfr...@si...> - 2000-12-27 18:52:10
|
For a while now I have been interested in seeing an integration of libwmf with ImageMagick (http://www.imagemagick.org). Initially I am thinking of using libwmf to implement a WMF coder module so that ImageMagick can read WMF files directly (rather than invoking wmftopng as an external program). Ultimately I think that libwmf itself could benefit substantially by depending on ImageMagick's libMagick. Reasons for libwmf to depend on libMagick include: o TrueColor drawing model (no color allocation required). o All drawing is antialiased (no ugly jaggies). o Can write to gobs of output image formats (not just PNG). o Supports XPM & BMP (i.e. DIB) internally (no more dependence on libXpm and libdib). Compressed BMPs are supported. o Provides excellent image resize capabilities (no more dependence on netpbm). o Drawing features are very similar to, or compatible with, those in SVG (work on an ImageMagick driver would benefit the creation of a SVG driver). o Fonts are rendered with the latest FreeType 2.0. o Rendering with X11 & Postscript fonts is also supported. o ImageMagick already renders many SVG files (SVG support is being added to ImageMagick with the assistance of SVG experts). o ImageMagick is ported to Unix/Linux, Windows, Mac, and VMS. o ImageMagick is available as part of all popular Linux distributions and FreeBSD. o The usage license is not restrictive. In summary, you can elminate use of libdib, libgdwmf, libxgd, and netpbm, and eliminate source-level dependence on libttf (or libfreetype) and libpng. The function of the libraries eliminated would be replaced by libMagick. Thoughts and opinions? Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: F J F. <F.J...@sh...> - 2000-12-29 03:46:40
|
Hi. Sounds like an excellent idea. I've been wading around in libwmf for a few weeks now, and I am currently working on a new api. The principal trouble I saw with libwmf is that, having been written as a program, in its current state it is highly unsuitable for working as a library; in particular there are all sorts of external variables and functions and no coherent naming scheme for these. Also, the division between wmfplayer and the various rendering engines was extremely blurred. I agree that the whole DIB/BMP thing is a mess and if ImageMagick is a solution then: great! Unfortunately I know nothing about it. (I have just implemented my own TrueColor color engine for X and was about to start looking into freetype2... but perhaps ImageMagick is the way to go.) I am thinking also of: (1) adding libwmf wmf-import support directly into abiword (2) creating a bonobo object for libwmf, but I am a complete beginner there. As ever, opinions welcome. Ciao, Frank On Wed, 27 Dec 2000, Bob Friesenhahn wrote: > For a while now I have been interested in seeing an integration of > libwmf with ImageMagick (http://www.imagemagick.org). Initially I am > thinking of using libwmf to implement a WMF coder module so that > ImageMagick can read WMF files directly (rather than invoking wmftopng > as an external program). Ultimately I think that libwmf itself could > benefit substantially by depending on ImageMagick's libMagick. > > Reasons for libwmf to depend on libMagick include: > > o TrueColor drawing model (no color allocation required). > o All drawing is antialiased (no ugly jaggies). > o Can write to gobs of output image formats (not just PNG). > o Supports XPM & BMP (i.e. DIB) internally (no more dependence on > libXpm and libdib). Compressed BMPs are supported. > o Provides excellent image resize capabilities (no more dependence on > netpbm). > o Drawing features are very similar to, or compatible with, those in > SVG (work on an ImageMagick driver would benefit the creation of > a SVG driver). > o Fonts are rendered with the latest FreeType 2.0. > o Rendering with X11 & Postscript fonts is also supported. > o ImageMagick already renders many SVG files (SVG support is being > added to ImageMagick with the assistance of SVG experts). > o ImageMagick is ported to Unix/Linux, Windows, Mac, and VMS. > o ImageMagick is available as part of all popular Linux distributions > and FreeBSD. > o The usage license is not restrictive. > > In summary, you can elminate use of libdib, libgdwmf, libxgd, and > netpbm, and eliminate source-level dependence on libttf (or > libfreetype) and libpng. The function of the libraries eliminated > would be replaced by libMagick. > > Thoughts and opinions? > > Bob > ====================================== > Bob Friesenhahn > bfr...@si... > http://www.simplesystems.org/users/bfriesen > > > _______________________________________________ > Wvware-devel mailing list > Wvw...@li... > http://lists.sourceforge.net/mailman/listinfo/wvware-devel > Francis James Franklin F.J...@sh... Diodorus the professor of logic died of shame because he could not at once solve a problem put to him in jest by Stilpo. --- Pliny the Elder |
From: Bob F. <bfr...@si...> - 2000-12-29 04:08:25
|
On Thu, 28 Dec 2000, F J Franklin wrote: > Hi. Sounds like an excellent idea. I've been wading around in libwmf for a > few weeks now, and I am currently working on a new api. The principal > trouble I saw with libwmf is that, having been written as a program, in > its current state it is highly unsuitable for working as a library; in > particular there are all sorts of external variables and functions and no > coherent naming scheme for these. Also, the division between wmfplayer and > the various rendering engines was extremely blurred. I have just got libwmf working as an image decoder in ImageMagick (yay!). This means that it should be in the next ImageMagick release (but not necessarily feature complete). To do this, I add to use these externs: extern wmf_functions WmfFunctions; extern int currentx; extern int currenty; There are likely plenty more exposed symbols. One way to eliminate globals is to add functions to access them. The notion of a current x and current y is disturbing because it is clearly not thread safe. It would be wise for the library to return a unique handle to the user so that there can be multiple users at once. > I agree that the whole DIB/BMP thing is a mess and if ImageMagick is a > solution then: great! Unfortunately I know nothing about it. (I have just > implemented my own TrueColor color engine for X and was about to start > looking into freetype2... but perhaps ImageMagick is the way to go.) ImageMagick produces excellent results, and is the kitchen-sink of image libraries. Being the kitchen-sink, it is also quite large. The largeness is not normally a problem due to shared libraries. Due to the full anti-aliasing, and overall "robustness", rendering of WMFs via ImageMagick is much slower than via GD but still acceptable for most purposes. The following times are with optimization totally disabled in the ImageMagick compile (gcc -O0) but enabled (-O2) for wmftopng: % time wmftopng 2doorvan.wmf 2doorvan.png wmftopng 2doorvan.wmf 2doorvan.png 0.05s user 0.00s system 256% cpu 0.019 total % time convert 2doorvan.wmf 2doorvan.png convert 2doorvan.wmf 2doorvan.png 0.90s user 0.03s system 102% cpu 0.906 total Only testing will prove how much optimization helps. Bob > > I am thinking also of: > (1) adding libwmf wmf-import support directly into abiword > (2) creating a bonobo object for libwmf, but I am a complete beginner there. > > As ever, opinions welcome. > > Ciao, Frank > > On Wed, 27 Dec 2000, Bob Friesenhahn wrote: > > For a while now I have been interested in seeing an integration of > > libwmf with ImageMagick (http://www.imagemagick.org). Initially I am > > thinking of using libwmf to implement a WMF coder module so that > > ImageMagick can read WMF files directly (rather than invoking wmftopng > > as an external program). Ultimately I think that libwmf itself could > > benefit substantially by depending on ImageMagick's libMagick. > > > > Reasons for libwmf to depend on libMagick include: > > > > o TrueColor drawing model (no color allocation required). > > o All drawing is antialiased (no ugly jaggies). > > o Can write to gobs of output image formats (not just PNG). > > o Supports XPM & BMP (i.e. DIB) internally (no more dependence on > > libXpm and libdib). Compressed BMPs are supported. > > o Provides excellent image resize capabilities (no more dependence on > > netpbm). > > o Drawing features are very similar to, or compatible with, those in > > SVG (work on an ImageMagick driver would benefit the creation of > > a SVG driver). > > o Fonts are rendered with the latest FreeType 2.0. > > o Rendering with X11 & Postscript fonts is also supported. > > o ImageMagick already renders many SVG files (SVG support is being > > added to ImageMagick with the assistance of SVG experts). > > o ImageMagick is ported to Unix/Linux, Windows, Mac, and VMS. > > o ImageMagick is available as part of all popular Linux distributions > > and FreeBSD. > > o The usage license is not restrictive. > > > > In summary, you can elminate use of libdib, libgdwmf, libxgd, and > > netpbm, and eliminate source-level dependence on libttf (or > > libfreetype) and libpng. The function of the libraries eliminated > > would be replaced by libMagick. > > > > Thoughts and opinions? > > > > Bob > > ====================================== > > Bob Friesenhahn > > bfr...@si... > > http://www.simplesystems.org/users/bfriesen > > > > > > _______________________________________________ > > Wvware-devel mailing list > > Wvw...@li... > > http://lists.sourceforge.net/mailman/listinfo/wvware-devel > > > > Francis James Franklin > F.J...@sh... > > Diodorus the professor of logic died of shame because he could not at once > solve a problem put to him in jest by Stilpo. > --- Pliny the Elder > > > _______________________________________________ > Wvware-devel mailing list > Wvw...@li... > http://lists.sourceforge.net/mailman/listinfo/wvware-devel > ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: Martin V. <mar...@hu...> - 2000-12-29 04:35:03
|
On Wed, Dec 27, 2000 at 12:52:07PM -0600, Bob Friesenhahn wrote: > From: Bob Friesenhahn <bfr...@si...> ... > For a while now I have been interested in seeing an integration of > libwmf with ImageMagick (http://www.imagemagick.org). Initially I am > thinking of using libwmf to implement a WMF coder module so that > ImageMagick can read WMF files directly (rather than invoking wmftopng > as an external program). Ultimately I think that libwmf itself could > benefit substantially by depending on ImageMagick's libMagick. > > Reasons for libwmf to depend on libMagick include: > > o TrueColor drawing model (no color allocation required). > o All drawing is antialiased (no ugly jaggies). > o Can write to gobs of output image formats (not just PNG). > o Supports XPM & BMP (i.e. DIB) internally (no more dependence on > libXpm and libdib). Compressed BMPs are supported. > o Provides excellent image resize capabilities (no more dependence on > netpbm). > o Drawing features are very similar to, or compatible with, those in > SVG (work on an ImageMagick driver would benefit the creation of > a SVG driver). > o Fonts are rendered with the latest FreeType 2.0. > o Rendering with X11 & Postscript fonts is also supported. > o ImageMagick already renders many SVG files (SVG support is being > added to ImageMagick with the assistance of SVG experts). > o ImageMagick is ported to Unix/Linux, Windows, Mac, and VMS. > o ImageMagick is available as part of all popular Linux distributions > and FreeBSD. > o The usage license is not restrictive. > > In summary, you can elminate use of libdib, libgdwmf, libxgd, and > netpbm, and eliminate source-level dependence on libttf (or > libfreetype) and libpng. The function of the libraries eliminated > would be replaced by libMagick. > > Thoughts and opinions? > > Bob I would say ... go for it! All the things you list for replacement look a bit like being held together with duct tape... what is your estimate for a time frame? On the other hand, it is important to do it in such a way, that libwmf remains functional all the time. So let's not take out any existing functionality until the new stuff can replace it. That may get a bit tricky with the build system, but in the end it will simplify it. Martin -- Martin Vermeer mar...@hu... Helsinki University of Technology Department of Surveying P.O. Box 1200, FIN-02015 HUT, Finland :wq |
From: Bob F. <bfr...@si...> - 2000-12-29 03:04:04
|
On Thu, 28 Dec 2000, Martin Vermeer wrote: > > Thoughts and opinions? > > > > Bob > > I would say ... go for it! All the things you list for replacement > look a bit like being held together with duct tape... what is your > estimate for a time frame? > > On the other hand, it is important to do it in such a way, that libwmf > remains functional all the time. So let's not take out any existing > functionality until the new stuff can replace it. That may get a bit > tricky with the build system, but in the end it will simplify it. My immediate intention is to develop a reasonable back-end driver that uses the ImageMagick drawing commands, and include this driver with ImageMagick so it can render WMF files directly. My initial development uses a 'wmftoimg' utility (stolen from 'wmftopng' source code). There is no reason why the driver can't also be included with libwmf, along with the utility. That is all I am willing to personally commit to at the moment. The remaining enhnacements can be done in the longer term, and don't necessarily have to be done by myself (my commitment is primarily to developing ImageMagick). Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: Martin V. <mar...@hu...> - 2000-12-29 03:03:50
|
On Thu, Dec 28, 2000 at 09:47:04AM -0600, Bob Friesenhahn wrote: > Date: Thu, 28 Dec 2000 09:47:04 -0600 (CST) > From: Bob Friesenhahn <bfr...@si...> > X-Sender: bfr...@sc... > To: Martin Vermeer <mar...@hu...> > cc: wvw...@li... > Subject: Re: [Wvware-devel] libwmf vs ImageMagick > In-Reply-To: <200...@hu...> > > On Thu, 28 Dec 2000, Martin Vermeer wrote: > > > > Thoughts and opinions? > > > > > > Bob > > > > I would say ... go for it! All the things you list for replacement > > look a bit like being held together with duct tape... what is your > > estimate for a time frame? > > > > On the other hand, it is important to do it in such a way, that libwmf > > remains functional all the time. So let's not take out any existing > > functionality until the new stuff can replace it. That may get a bit > > tricky with the build system, but in the end it will simplify it. > > My immediate intention is to develop a reasonable back-end driver that > uses the ImageMagick drawing commands, and include this driver with > ImageMagick so it can render WMF files directly. My initial > development uses a 'wmftoimg' utility (stolen from 'wmftopng' source > code). There is no reason why the driver can't also be included with > libwmf, along with the utility. That is all I am willing to > personally commit to at the moment. > The remaining enhnacements can be done in the longer term, and don't > necessarily have to be done by myself (my commitment is primarily to > developing ImageMagick). Fair enough. I hope to be able to help out a little. A day is just too short. I would love to see wnftoimg, if it is in any state for a test drive. > Bob > ====================================== > Bob Friesenhahn > bfr...@si... > http://www.simplesystems.org/users/bfriesen > Martin -- Martin Vermeer mar...@hu... Helsinki University of Technology Department of Surveying P.O. Box 1200, FIN-02015 HUT, Finland :wq |