[whatwg] proposed canvas 2d API additions

Philip Taylor excors+whatwg at gmail.com
Sat Feb 28 14:48:43 PST 2009

On Sat, Feb 28, 2009 at 8:38 PM, JustFillBug <mozbugbox at yahoo.com.au> wrote:
> On 2006-04-26, Ian Hickson <ian at hixie.ch> wrote:
>> On Mon, 24 Apr 2006, Vladimir Vukicevic wrote:
>>> We can always add isPointInStrokedPath if we ever want to bother with
>>> that (which is where the "...Fill" bit came from in my API, because the
>>> region covered by a stroked path and that covered by a filled path are
>>> different, even though testing for a hit against a filled region would
>>> by far be the common case).
>> We can also call the other one isPointOnPath(), if we want to keep the
>> method names reasonably short. I'm not sure we'll ever need to add it,
>> though. Getting people to click on a line is generally silly.

(Or maybe we could add a convertStrokeToPath() function, which
replaces the current path with a path representing the outline of what
you'd get if you stroked the current path, and then use isPointInPath
on it.)

> We do have a need of isPointOnPath() for editing Bezier lines
> interactively (on a font editing interface). [...]
> Doing point on curve in javascript is painful. And since checking
> isPointInPath() already need to detect the on edge case, this shouldn't
> be too much a burdern on the browser developers.
> So please conside add the isPointOnPath() call to the function.

What makes it painful? If you're only using Beziers, it doesn't seem
too hard to approximate the curves as line segments and then calculate
distances from that.
http://philip.html5.org/demos/canvas/bezier-approx.html is fairly
straightforward (and a much more accurate version shouldn't be much
more complex) and can detect when your mouse is near a curve. (But if
this is a common problem, it would indeed be nicer if the canvas API
provided the functionality instead of forcing you to reimplement it.)

Philip Taylor
excors at gmail.com

More information about the whatwg mailing list