xml-dev - RE: What is wrong with SVG?

[Jon Ferraiolo <jferraio@Adobe.COM>]

Liam,

At 07:50 PM 3/9/00 -0500, Liam R. E. Quin wrote:
>Is this all an Intel conspiracy to sell 1GHz PCs to run web browsers?

I would expect that the chip manufacturers and system manufacturers are
hoping the web will be covered with SVG content consisting of animated
filter effects on very large screen areas.

>
>Interchange of 2d graphics is, a very difficult problem to solve.
>But is XML the right approach, and, if it is, is the DOM appropriate?
>
>I saw the DOM as a compromise effort to get Microsoft and Netscape
>to agree on an API for browser access.  I don't like it as a general
>panacea for an XML API.  For one thing, it assumes that a node has
>only one parent, making reuse of components difficult.  If you
>wwanted to give access to a Unix file system using DOM, you'd have to
>decide what to do about linked files (hard links, not symbolic, which
>are like entity refs).
>
>This is not to criticise the DOM, because it succeeded in its
>objective, as I see it, to a very large degree. It's to criticise
>projects that use the DOM without asking why they are doing so.
>
>Do I want DOM access to graphics?  Well, not particularly.  I'd
>rather have functions like IntersectedArea(path1, path2).

We have attempted to put a few utility methods into the SVG DOM in order to
make it more convenient for scriptwriters to do their job. The ones that
are in the spec now are the ones people in the working group could think of
in anticipation and in advance of actually writing useful scripts. If
anyone has suggestions for utility methods in the SVG DOM, please send them
in.

Note that the utility methods most likely to go in are ones where the
underlying algorithms are already required in order to implement features
in the spec. For example, distance-along-a-path utility functions are more
likely to get in since SVG implementations already need to have these
facilities in order to implement text-on-a-path and motion paths. However,
I don't think boolean logic operations are required to implement SVG, so
those kinds of APIs are less likely to go in. As people have been pointing
out, there is already plenty to implement.

>
>The wonderful thing about PostScript is that the same graphics model
>is used at every level, including within glyphs.  Does this mean
>we need SVG fonts, adding yet more complexity?

You apparently didn't notice chapter 20: http://www.w3.org/TR/SVG/fonts.html
The good news: no need to add more complexity as this particular complexity
is already in the spec.

Jon Ferraiolo
SVG Editor
Adobe Systems Incorporated



***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************