[prev in list] [next in list] [prev in thread] [next in thread] 

List:       imagemagick-user
Subject:    [magick-users] Re: libEMF library
From:       "Dom Lachowicz" <cinamod () hotmail ! com>
Date:       2002-10-02 20:33:26
[Download RAW message or body]

Hi Vadim,

>|  For the record, ImageMagick is a great library. That said, it's handling
>| of EMF is non-existant, WMF is good (mainly because libwmf does all of 
>the
>| heavy lifting) and its SVG, PS, and PDF support are all fairly abysmal.
>| ImageMagick also tends to be slow and heavy when being used for a general
>
>Can you provide some data on this?
>I am certanly interested.
>What kind of platform you tested, Linux or Windows?

Both. The SVG support has definitely gotten better lately, which is good. 
The PS support has always been pretty good, but only if GS is installed. The 
PDF import support is horrible, but I think that is mainly because of GS's 
limitations with regard to how well it handles PDF (which isn't good at 
all).

>| conversion library. Further, IM *rasterizes* all of its vector formats,
>| with the exceptions of MVG and SVG. Saving a SVG as a PDF or EPS file 
>would
>| leave you with a SVG embedded as a PNG inside of a PDF or EPS. Yick.
>
>Yes, I know.
>And I would highly appreciate further development of IM which will allow
>*native* vector graphics conversion.

This is worthwhile, but I feel it is outside of the scope of this 
discussion. This is something to discuss on the IM-devel list, not here.

>|  This is not to say that we should not concentrate on converting that
>|  "Something" to EMF or WMF so that it can later be viewed by MSWord. It's
>|  just something I'd like to put off for a bit and see as a "parallel
>| project" to this one.
>
>What kind of format should be this "something"?

I'm proposing SVG 1.0 or 1.1 for *my stated needs*, since they are W3C 
standards/recommendations, easy to convert into/from, and I already have a 
viewer for it.  Further, because we control the producers of said SVG, we 
can mandate things like:

*) will use style="fill:red" as opposed to fill="red" type style arguments

In which case, we'll be outputting a subset of the SVG standard. Problems 
like embedded fonts need never arise.

Ideally, SVG's color model will eventually improve so that it can handle 
CMYK, Spot, LAB, ICC, and other color spaces to better support printing 
models as well as their traditional "RGB for the web" marketspace. Since my 
immediate concern is going directly to the screen, CMYK, grayscale et. al. 
can easily be mapped to RGB data, should the problem arise.

>ok, does it mean that I have libwmf2?
>[vad@VPlessky vad]$ rpm -q libwmf
>libwmf-0.2.5-3mdk

You have libwmf2 installed.

>|  Please check out librsvg. It supports the <text> and <tspan> operators
>| just fine using Pango and the Freetype backend to Pango.
>
>It seems librsvg2 requres GTK+2.0, plus a lot of otherdependencies.
>Doesn't sound like a *light* library.
>I will try to complie GTK+2.0 and all required libs, and will let you know 
>my
>opinion.
>What is the current home URL for this lib? Do you have mailing list to 
>discuss
>its bugs and features?

librsvg requires:

libart_lgpl
glib (maybe only 4 functions from...)
gdk-pixbuf (mainly just to turn the resulting RGBA buffer into an onscreen 
image)
pango (well, only 1 call from pango, which we could (but won't) replace with 
freetype, which used to be in there instead)

There is no mailing list presently active to discuss its bugs and features, 
as I am its only current developer. There is no URL for this lib, and I do 
not see the need for it to have one presently. It lives in GNOME CVS. If you 
wish to talk about the relative merits, features, designs, or bugs in 
librsvg, please do so in a private email to me and not cross-posted to 7 
people and a mailing-list or two.

The CVS version of librsvg has an *optional* GDK and GTK+ dependency, but 
that is because you can optionally build a GTK+ theme engine using SVGs via 
the librsvg theme engine. Patent pending ;-)

FYI: your librsvg is ancient.

The discussion of "light" versus "heavy" is of course relative, and why I'm 
saying that we should stay the f*** away from talking about rendering 
solutions and instead talk about conversion utilities. Or am I wasting my 
breath here? I've said this before. Four times now.

A solution is not "heavy" if all of its component technologies are already 
loaded into RAM, as librsvg's would be on any GNOME desktop. An ImageMagick 
based solution would be "heavy" if used on either KDE or GNOME as none of 
its loaders or routines are loaded into memory already by either desktop, 
and it provides duplicate functionality to other desktop programs, 
libraries, and utilities. I hope you understand this.

This was started as a GNOME-office discussion about how to view EMFs inside 
of Gnumeric and Abi, and somehow ballooned into a [GNOME, KDE, ImageMagick, 
OpenOffice] discussion about too many things. As far as I'm concerned, we 
have gotten off-track and my desparate efforts to get it back on track thus 
far have failed. Or perhaps this has taken on a life of its own, in which 
case, I think I want off this train.

>What about to define common criterias for *unified vector format"?
>Do you (and other people) think that SVG is ok as common format?
>Should PostScript be treated as "legacy"?
>I recently asked questin on Freetype-devel mailing list, wether we should 
>use
>(try to use) Hermite Splines, instead of Beziers, for fonts.
>I think similar qustion is valid for common vector format.
>PS is 20 years old. May be, we need something newer?.. :-)

I view the stated problem as: "How can GNOME Office components view WMF and 
EMF graphics in a nice efficient manner?" Going one step further, I may 
possibly expand the problem to also include converting SVG et. al. into a 
format that RTF, DOC, and friends understand that is not a raster format 
(eg. PNG). This problem I consider extremely secondary to the viewing 
problem at this point in time.

The proposed solution for the "viewing" problem is to use an intermediate 
SVG representation, which will work to some absurdly highly accurate degree, 
and won't require a huge amount of effort on our parts to achieve. I (ok, 
Jody) proposed said solution only for GNOME-Office, though you may want to 
adopt the same or a different solution for your own product. For what it's 
worth, SVG has been referred to as "PS for the Web" and, in my opinion, will 
act as a very good and truthful intermediate layer for an EMF or WMF viewer 
or conversion utility.

Discussions of a "unified vector format" and splines vs. beziers are, in my 
opinion, outside the scope of this discussion, and properly belong on a W3C 
list or proposal, or at minimum, the freedesktop list. I want to KISS, at 
least for now. But that's just me. I refuse to make a mountain out of the 
molehill I see in front of me. I just hope I'm being clear and not too 
nearsighted.

Cheers,
Dom

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

_______________________________________________
Magick-users mailing list
Magick-users@imagemagick.org
http://studio.imagemagick.org/mailman/listinfo/magick-users
[prev in list] [next in list] [prev in thread] [next in thread]