[webkit-dev] SVGPathSegList relative coordinates and segment lengths

[Nikolas Zimmermann]

Am 25.03.2010 um 16:44 schrieb David Yonge-Mallo:

>
> Hi,
>
> I'm trying to fix bug 30219, and the problem is that relative path  
> data commands appear to be internally stored in absolute  
> coordinates.  So an insertion of a relative path command requires  
> all subsequent coordinates to be updated.  (I'm not entirely clear  
> on where or how or even if pathSegList and normalizedPathSegList are  
> synchronized.)
This is not entirly true. SVGParserUtilities offers two operating  
modes, one which delivers unaltered coordinates (not converting  
relative to absolute coordinates) (mainly) used to create  
SVGPathSegList DOM representations. The other operating mode returns  
absolute-coordinates -- this is an optimization and is used in  
SVGPathElement (part of the bug, see below).

Note that normalizedPathSegList / animatedPathSegList /  
animatedNormalizedPathSegList are all not implemented returning 0, so  
there is nothing to synchronize so far.

> As a first step to get the test case working, I've made a patch that  
> calculates the correct coordinates in SVGPathSegList::toPathData().   
> This isn't the correct fix (presumably the reason the coordinates  
> appear to be stored as absolute coordinates is so they wouldn't have  
> to be recomputed, for speed reasons), but it gets the test case to  
> render correctly.
The problem you are running into is because of  
SVGPathElement::parseMappedAttribute and how it parses the d-attribute.
         if (!pathSegListFromSVGData(pathSegList(), attr->value(),  
true))

The core SVG path parsing utilities offer all functionality you will  
need, though SVGPathElement specifically asks for altered paths (bool  
process = true, the last parameter above). You might want to  
investigate there.


> As a part of my investigation, I came across the  
> SVGPathSegList::getPathSegAtLength function.  This function is  
> supposed to take in a distance and return the index to the segment  
> at that distance, but it appears never to use its parameter.   
> Furthermore, the value that is actually being used for the distance,  
> PathTravelState::m_desiredLength, appears to never be initialised  
> anywhere.
m_desiredLength is used & initialized, grep for it in platform/ 
graphics. The text-on-path code depends on this function and clearly  
works (it has interpolation problems, but that's another story).

>
> The above is possibly related to bug 12047, which seems to suggest  
> that getSegmentAtLength isn't implemented.
getSegmentAtLength? You mean getPathSegAtLength? This is implemented,  
see SVGPathSegElement.cpp (using the same code that text-on-path needs).

>
> Any advice about what needs to be updated for an inserted relative  
> path command and where those changes should properly go, as well as  
> an explanation of getPathSegAtLength, would be appreciated.  Thank  
> you in advance.

I'll try to get at it during the next days, but I'm rather busy atm.  
Dirk Schulze and/or Eric Seidel might be able to help out as well.

Cheers,
Niko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100326/160a9aa7/attachment.html>