Re: SVG requires a parser in a parser?

Jon Ferraiolo <jferraio@Adobe.COM> on 07/22/99 06:26:58 PM
Jon Ferraiolo wrote:

>In designing CSS-styled XML grammars, you have four ways that you can
>package data within the grammar:
>(1) As character data instead of start and end tags (your method above)
>(2) As child elements
>(3) As attributes
>(4) As CSS properties
>No matter what approach you take, it is inevitable that someone is going to
>disagree with your decision.


>Regarding path data, the SVG WG looked at many possible formulations before
>coming up with our current approach. We ruled out the approach you have
>suggested above because we wanted only text to be expressed as character
>data. I believe a key reason for this was that we thought it was important
>that searching for the string "10" should find <text>10</text> but not
><M>10 10</M>.

>A major design goal with SVG was small file sizes. We paid close attention
>to feedback from implementors of PGML and VML in formulating path data
>syntax. If you know VML, then you'll recognize that SVG borrowed a lot of
>its approach to path data from VML.

>I think the approach to path data is unlikely to change much at this stage.

Taking your comments into account, I still think that a slightly more object
oriented approach that allows declaration of multiple identical segments within
one object is more appropriate e.g:

<path closed="true" fill="none" stroke="black" strokeWidth="100">
     <M d="10 10"/>
     <L d="40 0 20 20 0 20 20 0"/>
     <A d="2 2 5 0 0 2 2"/>
     <L d="30 30"/>
</path>

Polygons or multi-segment bezier can still be efficiently specified while
element context is preserved.
If deflation is taken into account, the size difference should be even smaller.

The spec also contains both "," and "<WhiteSpace>" as separators in some
examples. IMO only WhiteSpace should be allowed, as this fits more into the
"feel" of XML.


Rainer Prosi
Heidelberger Druckmaschinen AG

Received on Friday, 23 July 1999 05:48:32 UTC