Subject: Re: XP design for image support
From: Leonard Rosenthol (leonardr@lazerware.com)
Date: Sat Apr 21 2001 - 08:43:46 CDT
At 10:27 AM 4/20/2001 +0200, Hubert Figuiere wrote:
>The problem with IM is that it is for bitmap output.
Not true!
IM can also write out SVG and MVG (IM's internal vector
representation) with full vector info, along with PS and PDF (vector
formats, but that will CURRENTLY only contain images). All of the
"plumbing" is inside of IM to maintain vector information for different
format (in fact, that's how SVG is handled - it's converted from SVG to
MVG) and only at the "last minute" is the vector information rasterized if
requested.
Try this with IM - "convert foo.svg foo.mvg"
>The advantage of SVG
>it that it is a vector format. We need to be able to use SVG natively.
But do we need to RASTERIZE it natively? I completely agree that
AW should handle the SVG internally for the file format, clipboard,
etc. HOWEVER, at some point it needs to get turned into bits to be drawn
to the screen. We can either do that internally (as we are currently
attempting to do in a limited fashion!) OR we can pass the SVG off to
something like IM that already does a good job of turning it into bits.
>-printing: printing is mainly a vector image processing on any platform I
>have seen.
Agreed, BUT it's not that simple :(. In order to print, we
currently fall back on OS-centric graphic API calls (GDI, QuickDraw) or we
convert to something like Postscript (and then rely on GS to do the hard
work for us). The problem with this approach is that none of these API's
(except Postscript) can accurately represent the depth of graphic features
expressable in SVG (dashes, line caps/joins, different types of curves,
etc.). So to do SVG printing WELL, we actually need to do all sorts of
printer querying to determine the best approach - which may be to generate
bits.
(I have to deal with this same problem when printing PDF!)
LDR
This archive was generated by hypermail 2b25 : Sat Apr 21 2001 - 19:47:26 CDT