d3 / d3-path

Serialize Canvas path commands to SVG.

d3-path

This module provides a common API for drawing in SVG and canvas.

Resources

• Documentation
• Examples
• Releases
• Getting help

d3-path's Issues

arc should take a counterclockwise flag

From http://www.w3.org/TR/2dcontext/#dom-context-2d-arc:

If the counterclockwise argument false and endAngle-startAngle is equal to or greater than 2π, or if the counterclockwise argument is true and startAngle-endAngle is equal to or greater than 2π, then the arc is the whole circumference of this circle.

Otherwise, the arc is the path along the circumference of this circle from the start point to the end point, going anti-clockwise if the counterclockwise argument is true, and clockwise otherwise. Since the points are on the circle, as opposed to being simply angles from zero, the arc can never cover an angle greater than 2π radians. If the two points are the same, or if the radius is zero, then the arc is defined as being of zero length in both directions.

Fix prototype.constructor.

The current definition obliterates the constructor property.

• Path

access to relative paths

Hello,

this module builds SVG paths using absolute commands (M, Z, H, V, ..).

would it make sense for d3 to have an API to be able to build relative paths using (m, z, h, v, ..) ?

I am currently using both d3-path which has a nice arc API and https://www.npmjs.com/package/svg-path-generator which has a relative() facility and trying to see how to go forward to have a unified path generator.

my need for relatives path does not really come out of d3 so I would understand if the design goals of d3-path do not emcompass this feature. I am trying to generate shape paths for a laser cutter and it is easier to reason about with relative positions.

Cannot chain methods

I'm not sure if this is intentional or not, but the Path API doesn't appear to be fluent like the rest of D3 is. If I say

d3.path().moveTo(x, y)

I am returned undefined instead of a path instance. Is this correct?

arcTo should end on tangent point, not control point.

See http://bl.ocks.org/mbostock/2ff125ac774e5fb5764c.

Expected:

Actual:

Scale path generated by path.arcTo() or path.arc()

Hi, I'm working with D3 v4 and writing a function that draws a path with a rounded corner.
My problem is how to scale (translate?) a path with arc segment.

For example, here is a function without scaling. (at codepen)

const context = d3.path();
context.moveTo(50, 50);
context.lineTo(100, 50);
context.arc(100, 100, 50, -0.5 * Math.PI, 0);
context.lineTo(150, 150);

I introduced scale functions to get a feature of zooming in/out.
The functions are used globally, I have to apply them to the draw function. (at codepen)

const x = d3.scaleLinear()...;
const y = d3.scaleLinear()...;

const context = d3.path();
context.moveTo(x(50), y(50));
context.lineTo(x(100), y(50));
context.arc(x(100), y(100), ???, -0.5 * Math.PI, 0); // how to scale radius?
context.lineTo(x(150), y(150));

Is there way to scale radius parameter in arc() or arcTo() method?

Reduce the precision of numbers in path strings?

Hi,

while I'm aware that numbers in
M0.123456,0.123456L1.123456,1.123456L1.123456,0.123456Z
are used internally by the browser to calculate shapes, it seems weird to me the we really need 1e-6 pixel precision. I'm wondering if reducing numbers precision in path strings can enhance DOM performances because of shorter d strings to be parsed.

This function:

(pathString, precision) => pathString.replace(/\d+\.\d+/g, s => parseFloat(s).toFixed(precision))

works well, but parsing the path string seems a waste of CPU cycles: maybe it'd be better passing a precision option to path.toString() and process all floats with f => f.toFixed(precision) before creating the output string.
In that case it would be nice to have d3.geoPath.precision([digits]) too.

What do you think about it?
Thanks!

Register with bower.

Add support for ellipse() ?

It would be very useful to have support for the ellipse() method.
Specs: https://html.spec.whatwg.org/multipage/canvas.html#dom-context-2d-ellipse

Arc and arcTo draw only circular arcs.

Currently, neiher path.arc nor path.arcTo allow to draw elliptical arcs - only circular. Single radius is passed and used for both rx and ry parameters.

d3-path/src/path.js

Lines 118 to 120 in fb809cd

	else if (da > epsilon) {
	this._ += "A" + r + "," + r + ",0," + (+(da >= pi)) + "," + cw + "," + (this._x1 = x + r * Math.cos(a1)) + "," + (this._y1 = y + r * Math.sin(a1));
	}

It's possible to draw first, but not the second arc:
https://jsfiddle.net/qd1ph9y0/5/

Drop redundant L in arc commands.

We’re always drawing the straight line, even if it’s not needed.

d3-path

Given x1, x2 and y coordinates how can I plot loops using path function? The x1 and x2 are start and end coordinates of the loop and the y coordinate corresponds to the height of the loop. I am using d3 version 3.5.17

Thank you very much!
Parul

path.arc(…anticlockwise) must be true or 1, not truthy

We have cw = 1 ^ ccw

• 0, "0"(edited), undefined, false => draws a clockwise arc
• 1, "1", true => draws an anticlockwise arc

So far so good, but trying with anticlockwise = "anticlockwise" or anticlockwise = 3 (or most other truthy values) will give a very weird path with an inverted curvature, because it will have both ccw truthy, and cw = 1.

I don't think the code should be fixed as this is probably the fastest approach, but maybe the documentation?

Currently we say

If anticlockwise is true, the arc is drawn in the anticlockwise direction; otherwise, it is drawn in the clockwise direction

"otherwise" could be changed to "if false or undefined", or "if false"…

Another possibility:

If anticlockwise, a boolean, is true, the arc is drawn in the anticlockwise direction; otherwise, it is drawn in the clockwise direction.

(I got bitten by using a checkbox’s value, which gave me anticlockwise="On".)

See interactive test at https://observablehq.com/d/d8c04cb491a6c444

Support for Transforms

The spec says that the current transform should be applied to each point as the path is constructed. This means that if the transform changes whilst constructing the path, the output will be different, and it is noe enough to apply a transform at the end of path creation.

Are there any plans to support transforms? Or would a PR to do this be accepted?

path generating incorrect sequence in Chrome/IE/Safari, correct in Firefox

bl.ock here: https://bl.ocks.org/moman822/7a05fb2becde5f2081e9bdb4ee5c9511

To run, check a box then click the button. Correct execution is a growing path animation.

The issue seems to be with how d3.path is putting the d attribute together in Chrome vs Firefox.

On Firefox, it is correct and the line animation comes together fine. However, in Chrome d comes out like this:
"MNaN,514.8428887547777CNaN,514.8428887547777,NaN,496.99907463287065,NaN,496.99907463287065CNaN,496.99907463287065,NaN,494.1202977268...

I have console.logged the relevant parts around the issue, from line 199.

svg.selectAll('path')
		.data(datNestTemp, function(d){console.log(d); return d})
		.enter()
		.append('path')
			.attr('d',function(d){console.log(lineScale(d.values)); return lineScale(d.values)})

lineScale is straigthforward:

lineScale = d3.line()
			.curve(d3.curveCardinal())