Re: [whatwg] Questions regarding Path object

Apologies for the slow reply on this, just seeing your answer now:

On Aug 20, 2013, at 11:32 , Ian Hickson <ian@hixie.ch> wrote:

> On Sat, 23 Mar 2013, Jürg Lehni wrote:
>> 
>> - 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.
> 
> This was last considered last October:
> 
>   http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-October/037548.html
> 
> My conclusion then was that we didn't have much evidence that Path was 
> going to work, but we also didn't have much evidence that it was going to 
> be an insurmountable problem.
> 
> How much of a problem is the paper.js case?

It is quite a problem for us really because many people choose to inject the scoped library into the global scope, for simpler code. That is also the way one writes code in PaperScript (which is executed in its own scope where these constructors appear global, but do not pollute the actual global scope), and thus how all our examples and tutorials are written.

Path is the most important constructor in Paper.js, a lot is built on top of it. Changing it now would be a huge nuisance for us.

> The name "Path" is generic, but that's kind of the point -- this interface 
> might get used by SVG and other contexts, which is why I didn't call it 
> CanvasPath, Path2D, or some variant of Shape.

I would like to argue that Path2D is more precise and accurate than simply Path. It is about two dimensional vector graphics after all, and about performing geometric operations with / on it (hit testing, boolean operations, drawing). Path2D makes as much sense in a Canvas context as it does in SVG.

>> - I see there are many ways to construct paths from different type of 
>> data, and perform manipulations on them. 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? 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.
> 
> Manipulating paths is something I am punting on until browsers implement 
> what's in the spec already, but I imagine at some point we'll add that, 
> yeah.

Maybe we can be of help there: We have put a lot of thought and work into how Paper.js allows users to directly draw and manipulate Path data, and tried to come up with solutions to make that as easy and convenient as possible. I believe we could contribute insight to that discussion.

Also, thanks to Harikrishnan Gopalakrishnan, since a couple of months Paper.js has a working implementation of fat bezier clipping for very fast path intersections, and a very resourceful implementation of boolean operations (both in amount of code, and execution speed). Perhaps this could serve as an example implementation?

We are currently working on implementing stroke expansion also.

> On Sat, 23 Mar 2013, Rik Cabanier wrote:
>> 
>> 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.
>> 
>> http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/
> 
> I disagree with the premise of this post -- it's not the case that you 
> never want to add segments. It is in fact quite common to add segments to 
> a path -- that's what constructing a path is.
> 
> Also, it's not at all clear to me that there's really a distinction 
> between a "shape" and a "path". They're really the same thing -- sets of 
> path segments. What distinguishes them is not anything intrinsic to them, 
> it's the behaviour when you combine segments.
> 
> Thus the clearer solution, IMHO, insofar as there's a problem, is to add 
> methods that describe the various ways to combine paths.
> 
> Right now we have two options (ignoring the text parts of the path API): 
> concatenating path segments, and concatenating path segments after having 
> first outlined one of them.
> 
> On the long run I think it would make sense to add other methods, e.g. one 
> combining two or more paths together such that the resulting path would 
> outline the union of the "insides" of the provided paths, or the 
> intersections, or whatnot.

In Paper.js we make the distinction between CompoundPath and Path, which stems from working with Adobe Illustrator. Path describes one open or closed loop of Segments connected by Curves (each Segment having a point, handleIn and handleOut attribute, the Curve in between two Segments in fact just describe the same information in a different way). CompoundPath then are simply groups of Path items, which are rendered together with the same color and fill rule. It's very different to what SVG does, but this distinction has helped us reduce the complexity of what Path needs to do a lot, and it really helps when manipulating Path items directly.

>> Path, Shape, Gradient, Matrix all seem way too generic, and will 
>> definitely clash with many libraries.
> 
> It's not that clear that this is true. There really haven't been that many 
> reports of clashes, all things considered -- and it's not clear that 
> Path2D, GraphicsPath, CanvasPath, or any number of other variants, would 
> really be any more or less likely to clash.

Shape, Matrix and Gradient are all constructors that we have in Paper.js as well.

>> Well I know there will be problems: Paper.js has a Path class since 
>> 2011, and these will clash when using the library without scoping, which 
>> is what many people do.
> 
> How many is many? How high-profile are they?

Google, Foursquare and the NY Times have used Paper.js for interactive features, games and dynamic graphics on their websites, just to name a few. I'm not sure if they were used in a scope manner or not, though.

>> I doubt we're the only library that clashes.
> 
> Do we have any data on this? Do any libraries use Path2D?

I've been looking for Path2D + JavaScript on Google Code search and Github, and have not found one single occurrence. The idea for the name comes from Java, where all 2D geometric classes have 2D behind their name. I'm pretty confident there would not be a single clash.

Best,

Jürg

Received on Friday, 20 September 2013 17:49:08 UTC