[whatwg] Questions regarding Path object

[Rik Cabanier]

On Sat, Mar 23, 2013 at 4:38 PM, Jürg Lehni <lists at scratchdisk.com> wrote:

> Hello all,
>
> I am now to this list, so before formulating my questions I'd like to
> introduce myself:
>
> I am one of the creators of Paper.js <http://paperjs.org/>, a JavaScript
> framework focusing on vector graphics in the canvas element. The library is
> built on about a decade of work on <http://scriptographer.org/>, a
> JavaScript plugin for Adobe Illustrator.
>
> Paper.js differs from other Canvas wrappers in its focus on offering
> simple tools to describe, craft and manipulate vector outlines. It
> currently offers path intersection, many handy tools to iterate over paths,
> find positions, precise hit-testing, interaction, creation of tools, etc.
> Soon we are adding stroke expansion and boolean operations. The code is
> based on efficient implementations of curve time parametrisation, curve
> length calculation through numerical integration, etc.
>
> I have recently discovered this list and the discussion about the
> extension of the canvas element, and feel foolish for not joining earlier.
>
> So here my questions:
>
> - Paper.js has its own share of classes, and one of them is called Path.
> We normally run scoped but allow people to inject into the global scope.
> This would override the new Path constructor. I was wondering if this
> constructor should not have a less generic name, since I doubt we are the
> only library that this will collide with? For example CanvasPath?
>

There was a long conversation about this on the mailing list:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0288.html
The SVG WG also look into this during a face-to-face and we examined
paper.js to see if it was a problem. Since we saw it was scoped, we assumed
that there would be no problem.

How common is it that people inject into the global scope?


>
> - I see there are many ways to construct paths from different type of
> data, and perform manipulations on them.


The current path APIs suffer from conflating path segments and geometry. To
fix this, I proposed to modify the API so path just describe the path
segments [1]. In addition, I proposed to create a new 'shape' object that
takes things like winding and the current CTM into account.
Even though it's not in the blog post, we should extend 'shape' so you can
do binary operations such as unions and intersection. The skia people are
working on library to calculate this [2] (see the mailing list for chromium
graphics)


> addPathByStrokingPath() and addPathByStrokingText() are both very welcome,
> for example. Will there be a way to access the resulting path description
> again, for example as SVG-style pathData?


Since some graphics libraries don't give you access to the path segments,
it would be hard to add that.
Going directly from svg paths string will be supported though.


> I have not seen a description of any such property on the object, but
> would strongly suggest that one is added, since having access to the result
> of such path manipulations would hugely increase the usefulness of the Path
> object.
>



1: http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/