W3C home > Mailing lists > Public > www-svg@w3.org > September 2012

Re: ACTION-3388: Investigating ArcThrough

From: Alex Danilo <alex@abbra.com>
Date: Thu, 20 Sep 2012 22:48:03 +1000
Message-Id: <3KFNAM.TSLSA5NPJWBL@abbra.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-svg <www-svg@w3.org>
Hi Tab,

Yes indeed, well spotted.

This is sensible.

It's also remarkably similar to the HP GL/2 command AT
which is documented at:

http://www.hpmuseum.net/document.php?catfile=213

see page 110.

Most degenerate cases are treated there as well.

You could also download this source: http://ishtek.com/gl2-0_1.zip

and look inside at the source file Source/vector.c at line 248 or so
which implements equivalent functionality.

BSD licenced so can be adapted by any browser implementer if they so
choose.

Cheers,
Alex

--Original Message--:
>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 12:48:39 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:52 GMT