- From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
- Date: Fri, 16 Sep 2016 18:53:20 +0000
- To: public-svg-issues@w3.org
AmeliaBR has just labeled an issue for https://github.com/w3c/svgwg as
"Paths chapter":
== Clarify behaviour of getPointAtLength() and
getPathSegmentAtLength() at discontinuities. ==
https://svgwg.org/svg2-draft/single-page.html#types-__svg__SVGGeometryElement__getPointAtLength
https://svgwg.org/specs/paths/#InterfaceSVGPathElement
I think we need to enhance the algorithm for `getPointAtLength()` to
clarify which segment is considered current when calculating the
coordinates. Browsers have some differences in this regard.
Consider the following test:
```
<svg>
<path id="mypath"
d="M50,50 L150,50
M50,100 L150,100"/>
</svg>
var mypath = document.getElementById("mypath");
var lens = [0, 100];
for (var i=0; i<lens.length; i++) {
var p = mypath.getPointAtLength(lens[i]);
console.log("Point at length "+lens[i]+" = "+p.x+","+p.y);
console.log("PathSeg at length "+lens[i]+" =
"+mypath.getPathSegAtLength(lens[i]));
}
```
https://jsfiddle.net/yn6t6gr0/1/
At length 100,
Chrome returns (150,50) and path seg 1
IE11 returns (50,100) and path seg 1
Firefox returns (50,100) and path seg 1.
I'm not sure which of the two alternative points should be considered
the more "correct", but browsers ought to be consistent. Also whatever
coords are returned should match with the segment returned at that
point. Chrome is consistent here, but the other two are not.
If, for example, it is decided that path segments are considered to be
start-inclusive and end-exclusive, then the FF and IE coords (50,100)
would make sense, but then the path seg probably ought to be 2 or 3
in that case.
Finally, in the case of a length like 0, should that point be
considered in the "move" path segment, or in the path segment
immediately following it? Does it make sense for it to jump to the
next segment at length=+epsilon?
See https://github.com/w3c/svgwg/issues/282
Received on Friday, 16 September 2016 18:53:30 UTC