Re(2): SVGPathElement::getPathSegAtLength()

At 05:45 PM 5/9/00 -0700, Steve Dickson wrote:
>>
>>The spec does in fact say that it returns an index into pathSegList.
>
>Yes, I overlooked that part.  Thanks.
>>
>>
>>Sorry I didn't respond to your earlier note.
>
>No problem, I know that you're busy.
>
>>
>>The user can use either pathSegList or normalizedPathSegList, depending on
>>their needs. 
>[snip]
>
>That's fine as long as the user is handling the element as an
>SVGPathElement explicitly.  I'm thinking of situations where the user is
>treating the object as a DOM Element or DOM Node.  Say, for example, that
>the user is stepping through the DOM tree (in this case, an SVGDOM tree)
>using a treewalker or nodeiterator,  and they want to perform some
>processing of attribute "d" on this particular node.  For the purposes of
>a concrete example, assume that they want to serialize the DOM tree to
>file.  To do so, they walk the tree serializing each node and that node's
>attributes.  Now, what happens when they attempt to serialize an
>SVGPathElement node?  Which list should be used as the "d" attribute? 
>There are ways to code around this, but I think it might be useful to
>consider adding some switch which allows the user to specify which list is
>used by default in these sorts of situations.

Steve,
The easiest thing to do would be to access the 'd' attribute as a string
via the XML DOM. The intent is that the 'd' attribute is also synchronized
with pathSegList and normalizedPathSegList. (Statements to this effect used
to be in the spec, but now I see we lost those statements during the big
SVG DOM cleanup a few months ago. I'll add a sentence talking about the 'd'
attribute being synchronized.)

If you want object-oriented access, then most of the time you would want to
use pathSegList as this directly conveys the original document contents and
generally offers a higher level of abstraction than normalizedPathSegList.

Jon

Received on Tuesday, 9 May 2000 21:05:38 UTC