- 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