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

[Jon Ferraiolo <jferraio@Adobe.COM>]

There has been some discussion in the xml-dev@xml.org email list concerning
SVG's <path> element and why the SVG working group decided to pack a whole
bunch of information into the 'd' attribute rather than have separate
elements for each path command, such as a <moveto> element. In the spirit
of fostering communication, I'll attempt to address some of questions.

The primary motivation behind packing a whole bunch of information into the
'd' attribute in the <path> element was:

1) Feedback from users across many industries that if SVG files were too
large, then SVG's adoption would be negatively impacted. (In other words,
if file sizes were too large, SVG was a non-starter)
2) Observation that a very high percentage of SVG files were dominated by
path data. If there was one thing to make compact, it was path data.
3) Observation that compression techniques (e.g., gzip) on verbose syntaxes
for path data didn't yield much additional compression versus compact
syntaxes. In other words, a verbose syntax does NOT get compressed away by
gzip. (If the uncompressed original file is 50% bigger, the compressed file
turned out to be also about 50% bigger.)
4) Observation that the DOM could become huge if each path data command was
its own XML element.

In formulating the syntax for SVG's <path> element, the SVG working group
was able to work from two existing languages, PGML from
Adobe/IBM/Netscape/Sun and VML from Microsoft/Autodesk/HP/Macromedia/Visio.
PGML, which I personally had a lot to do with, has a parent <path> element
along with descendant elements <moveto>, <lineto> and <curveto>. VML is
more like SVG in that the description of the path is contained within an
attribute. The SVG working group thus had a couple of existing languages to
study and present to users for feedback. Typically, PGML files would be
twice as big as the corresponding VML files. Plain and simple, this size
increase was determined to be unacceptable. Thus, SVG's approach to path
data has turned out to be more like VML than PGML.

In recognition that path data into a single attribute makes DOM access
difficult, SVG provides a series of convenience DOM methods to access the
contents of a <path> element on a per-command basis. You can insert, delete
and replace commands within a <path> element via the convenience DOM methods.

We really appreciate everyone's interest and we like to hear feedback of
any type. Even if we don't respond to feedback, we are monitoring
www-svg@w3.org and discuss the topics that come up there in working group
discussions.

However, the particular subject of the <path> element has been debated many
times in the past and, at this stage, for better or worse, given the degree
of debate that has already occurred in this area and the very late point
that we are at with SVG, it is highly unlikely that the path syntax will
change.

Jon Ferraiolo
SVG Editor
Adobe Systems Incorporated


At 09:29 AM 3/6/00 -0700, you wrote:
>A little discussion on "What's wrong with SVG" has been started on
xml-dev, primarily around the use of the path attribute.  The first entry
in the thread is archived as
>http://xml.org/archives/xml-dev/msg00811.html.  I'm sure that the
discussion would benefit from involvement of people from this mailing list.
>
>To subscribe to xml-dev, mailto:majordomo@xml.org&BODY=subscribe%20xml-dev
>
>To post: mailto:xml-dev@xml.org
>
>To unsubscribe: mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
> 

***************************************************************************
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/
***************************************************************************