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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
