[svgwg] Clarify behaviour of getPointAtLength() and getPathSegmentAtLength() at discontinuities.

BigBadaboom has just created a new issue for 
https://github.com/w3c/svgwg:

== 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?


Please view or discuss this issue at 
https://github.com/w3c/svgwg/issues/282 using your GitHub account

Received on Friday, 16 September 2016 10:14:46 UTC