ACTION-3388: Investigating ArcThrough

This discharges my action-3388.

Near the end of the f2f yesterday, Dirk pointed us to Paper.js, to
look at some of their details around paths.  One thing that
immediately jumped out was one of the overloads for their "arcTo()"
function, which takes an implicit startpoint, an endpoint, and a third
point, and defines a circular arc that intersects the third point.
This immediately seemed like a convenient functionality, as it lets
you easily describe arcs that are tangent to another shape, or that
can be easily sized with mouse interaction.  This seems to meet our
goal of adding things that are useful and reduce the need to do trig
just to write a path.

So, I'm officially proposing this for inclusion in the <path> syntax.
We can call it "ArcThrough", and it takes 4 arguments - an x,y pair
for the pass-through point, and an x,y pair for the end point.  You
don't need to specify a radius or anything, as the circle is already
uniquely specified by the three points:
<http://paulbourke.net/geometry/circlefrom3/>.

There are three degenerate cases that need special attention:

1. When the "through" point is colinear with the start and end points.
 This one is really easy because it just defines a circle with
infinite radius, which usually goes by the name "line".  If the
"through" point is between the other two, it devolves to a lineTo
between the start and end point; if the "through" point is on either
end of the other two, it's the infinite line through those two points,
minus the segment connecting them.

2. When the "through" point is coincident with the start or end point:
This devolves into defining a circle from two points, for which there
are infinite solutions.  I propose we define this as producing the
smallest such circle, which has its center exactly between the start
and end points.  (Note that there's a slight difficulty here - any
solution you choose will produce a discontinuity for many directions,
as the command's results are unstable (large output changes from small
input changes) when the "through" point closely approaches one of the
endpoints.

3. When the start and points are coincident.  This again devolves into
defining a circle from two points, but it potentially has different
constraints on its solution, since it's constrained to start and end
on those points.  I propose we take the same solution as (2) - it
defines a full circle with its center exactly between the start/end
point and the "through" point.  This avoids any discontinuities, since
as the start and end points approach each other, the arc approaches
this form.  This also happens to give you an interesting unexpected
ability - you can do gui drawing of circles *really* easy by clicking
on a point you want the circle to start from and then dragging to
where you want it to end, and creating a path with start/end points
both set to the mousedown coord and the "through" point set to the
mousemove coord.

~TJ

Received on Thursday, 20 September 2012 07:02:39 UTC