On Apr 30, 2014, at 00:27 , Ian Hickson i...@hixie.ch wrote:
On Mon, 7 Apr 2014, Jürg Lehni wrote:
Well this particular case, yes. But in the same way we allow a group of
items to have an opacity applied to in Paper.js, and expect it to behave
the same ways as in SVG: The group should
Here another simple example:
When both filling and stroking a path and then drawing it with with an opacity
of less than 100%, the path will be rendered differently than in an SVG (a
large stroke width will make the issue more apparent):
- In Canvas, both the fill and the stroke will be
The request has come up multiple times on the paper.js mailing list [1], and we
will emulate this in JavaScript.
But since this will involve baking the CTM into the path to be drawn, and
setting the CTM to the identity matrix, I was wondering if this is something
worth supporting natively for
, 2014, at 23:18 , Rik Cabanier caban...@gmail.com wrote:
On Wed, Dec 4, 2013 at 5:18 PM, Rik Cabanier caban...@gmail.com wrote:
On Wed, Dec 4, 2013 at 11:10 AM, Jürg Lehni li...@scratchdisk.com wrote:
I somehow managed to oversee all the things that happened in this discussion
I think it is dangerous to make any kind of assumption about valid postal
addresses.
Here's a great list of all kinds of exceptions to rules that programmers tend
to believe to be true:
(Don't we love rules?)
http://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/
Jürg
On
Rik,
I read through the whole thread again and realized I've caused some redundancy
by asking questions that were already answered. Apologies for that. I
understand the reason for the check for non-revertible matrices, and should
have seen that example mentioned earlier, as it would have
On Nov 5, 2013, at 00:17 , Dean Jackson d...@apple.com wrote:
ctx.currentPath != ctx.currentPath
Instead of using getCurrentPath and setCurrentPath methods as a solution, this
could perhaps be solved by returning the internal path instead of a copy, but
with a flag that would prevent further
I somehow managed to oversee all the things that happened in this discussion,
but I'm very happy to see that Path2D is being proposed and agreed on now. It's
also what I've originally suggested on April 10 this year, and I completely
agree that it leaves much less doubt about its functionality
On Dec 4, 2013, at 20:10 , Jürg Lehni li...@scratchdisk.com wrote:
oversee
...and with oversee I meant ignore. I't s a common German mistake.
This discussion seems to have stalled.
Implementing this would help us greatly to optimize aspects of Paper.js, as
double buffering into separate canvases is very slow and costly. Is this still
on the map?
There appears to be a library that emulates this functionality, using the same
approach
On Nov 29, 2013, at 06:03 , Rik Cabanier caban...@gmail.com wrote:
I agree it's not the most useful API but it will be helpful. From one of the
previous message:
It would be a very fast way to set a cached path in the graphics state
and:
In the case of Paper.js, this optimization was not
for setCurrentPath.
1:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-paths-to-the-canvas
On Wed, Nov 6, 2013 at 3:30 AM, Jürg Lehni li...@scratchdisk.com wrote:
On Nov 4, 2013, at 20:25 , Rik Cabanier caban...@gmail.com wrote:
On Mon, Nov 4
On Nov 4, 2013, at 18:14 , Rik Cabanier caban...@gmail.com wrote:
The SVG WG would like to start using the 'Path' object for its objects as
well. We'd like this to be a generic object that can be used by other parts
of the web platform.
It would be strange to require a canvas context just
On Nov 4, 2013, at 13:32 , Anne van Kesteren ann...@annevk.nl wrote:
Objects not having constructors is a bad API practice we are moving away from.
I'm not sure everybody thinks so. There are whole libraries out there that
avoid the use of 'new' in favor of functions that create the objects
What's the use case?
I intentionally didn't add this to the spec when I was adding the last set
of path-related features, because it seems entirely redundant with Path
objects. I thought we'd want people to move away from using the implicit
path, rather than making it more powerful.
I
Hi Norto,
On Nov 2, 2013, at 02:19 , Michael Norton no...@me.com wrote:
Hi Jürg,
On Oct 29, 2013, at 1:46 PM, Jürg Lehni li...@scratchdisk.com wrote:
More recently, things appear to have been named a bit more specifically,
often with prefixes, e.g. HTMLCanvasElement, DOMParser
Regardless of good practices, I still believe that Path is too general a name
for a new prototype that is introduced at this point. Option and Image come to
mind, but those are from the early days. More recently, things appear to have
been named a bit more specifically, often with prefixes,
Apologies for the slow reply on this, just seeing your answer now:
On Aug 20, 2013, at 11:32 , Ian Hickson i...@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
PS: iOS 7 is barely released, but the first bug reports are already coming in,
because the new Mobile Safari now defines Path, and clashes:
https://twitter.com/danetag/status/380636739251220480
On Jun 17, 2013, at 17:55 , Rik Cabanier caban...@gmail.com wrote:
I think we need to get some browser vendors on board.
What's the process to do so?
However, I believe Firefox has been working on landing 'path' and there was a
patch for WebKit that also landed a partial path object. I'm
to all global constructors that
relate to 2D graphics and canvas.
I doubt we're the only library that clashes.
Jürg
On Jun 24, 2013, at 08:55 , Dirk Schulze dschu...@adobe.com wrote:
On Jun 24, 2013, at 8:38 AM, Jürg Lehni li...@scratchdisk.com wrote:
On Jun 17, 2013, at 17:55 , Rik Cabanier
On Apr 9, 2013, at 16:17 , Rik Cabanier caban...@gmail.com wrote:
I like the following naming scheme, as it is really short and already
familiar for people from the Java world, but I can imagine that a prefix
would be preferred.
Path2D, Shape2D, Gradient2D, Matrix2D
Path2d and Shape2d
I am very much interested in this feature. Of course you can use separate
canvases to achieve the same, which is what we currently do in Paper.js, but it
appears to be rather slow to do so. I think performance could improve a lot
which this alternative API proposal.
Jürg
On Jun 13, 2013, at
On Apr 9, 2013, at 14:52 , Rik Cabanier caban...@gmail.com wrote:
It is not too late. Someone started the implementation on Firefox but it
stalled. [1]
The Webkit implementation is behind a compile time flag so it can still
change.
Great!
The intent is that we can use this object with SVG
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
25 matches
Mail list logo
