Subject: Re: some graphic support, extra subdir, extra files, loads of Makefile breakage
From: Leonard Rosenthol (leonardr@lazerware.com)
Date: Tue Nov 30 1999 - 13:13:57 CST
At 11:02 AM -0800 11/30/99, Paul Rohr wrote:
>Actually, insofar as we'd like SVG to be our native format, I expect that
>we're more likely to need lossless conversions in the *other* direction --
>from WMF or other vector formats *to* SVG.
Good point!
In which case, you should be just fine since WMF/PICT -> SVG
isn't all that difficult (provided you have the parsing tools for the
vector format in question). There are a couple of tough spots -
patterns, regions, clipping, but they are all solvable, just not
trivial.
>So long as we've
>implemented enough of SVG to properly import, render, and store that
>content, our users will be in very good shape.
It's the render part that's really the toughest part of the
whole SVG "deal", since it requires features that aren't part of most
native graphic API's (eg. bezier paths) - that's why all of the
public SVG renderers are done with Java 2D that does support these
things. Given your approach to x-platform frameworks, this may be
even more difficult for you...
>Lossy conversions *from* SVG to an older format aren't likely to be a
>practical problem for a while, since there's very little existing content
>which uses any features of SVG, and particularly not the more advanced
>stuff.
And you could just as easily render the SVG to a raster
format for use in other file formats (word, RTF, html, etc.)
Leonard
----------------------------------------------------------------------------
You've got a SmartFriend in Pennsylvania
----------------------------------------------------------------------------
Leonard Rosenthol Internet: leonardr@lazerware.com
America Online: MACgician
Web Site: <http://www.lazerware.com/>
FTP Site: <ftp://ftp.lazerware.com/>
PGP Fingerprint: C76E 0497 C459 182D 0C6B AB6B CA10 B4DF 8067 5E65
This archive was generated by hypermail 2b25 : Tue Nov 30 1999 - 13:10:54 CST