Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Close
From: Tavmjong Bah <tavmjong@fr...>  20120508 06:25:57

Johan (and others), In looking at your slides I see that you added two new types of joins... how useful would these be to have as part of the SVG standard? I think the Extrapolated join might be easy to add; the Spiro less so. Tav On Tue, 20120508 at 01:01 +0200, jbc.engelen@... wrote: > Hi all, > Quick note to tell that I uploaded my presentation about Powerstroke on our wiki. > > http://wiki.inkscape.org/wiki/index.php/PowerStroke#LGM_2012_Presentation > > I'm sad I had to leave so early and had no time for the party :'( :'( > > Ciao, > Johan > > > >  > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Inkscapedevel mailing list > Inkscapedevel@... > https://lists.sourceforge.net/lists/listinfo/inkscapedevel 
From: <jbc.engelen@sw...>  20120507 23:01:14

Hi all, Quick note to tell that I uploaded my presentation about Powerstroke on our wiki. http://wiki.inkscape.org/wiki/index.php/PowerStroke#LGM_2012_Presentation I'm sad I had to leave so early and had no time for the party :'( :'( Ciao, Johan 
From: Just Fill Bugs <mozbugbox@ya...>  20120508 05:05:15

On 05/08/2012 07:01 AM, jbc.engelen@... wrote: > Hi all, > Quick note to tell that I uploaded my presentation about Powerstroke on our wiki. > > http://wiki.inkscape.org/wiki/index.php/PowerStroke#LGM_2012_Presentation > Any reference papers on the algorithms used in the Powerstroke implementation? 
From: Tavmjong Bah <tavmjong@fr...>  20120508 06:25:57

Johan (and others), In looking at your slides I see that you added two new types of joins... how useful would these be to have as part of the SVG standard? I think the Extrapolated join might be easy to add; the Spiro less so. Tav On Tue, 20120508 at 01:01 +0200, jbc.engelen@... wrote: > Hi all, > Quick note to tell that I uploaded my presentation about Powerstroke on our wiki. > > http://wiki.inkscape.org/wiki/index.php/PowerStroke#LGM_2012_Presentation > > I'm sad I had to leave so early and had no time for the party :'( :'( > > Ciao, > Johan > > > >  > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Inkscapedevel mailing list > Inkscapedevel@... > https://lists.sourceforge.net/lists/listinfo/inkscapedevel 
From: Josh Andler <scislac@gm...>  20120508 06:38:06
Attachments:
Message as HTML

Replying from phone, sorry if short. Extrapolated would rock imho. The segment limit the lpe uses is quite frustrating though when getting creative, otherwise it's really awesome. Cheers, Josh On May 7, 2012 11:27 PM, "Tavmjong Bah" <tavmjong@...> wrote: > > Johan (and others), > > In looking at your slides I see that you added two new types of > joins... how useful would these be to have as part of the SVG standard? > I think the Extrapolated join might be easy to add; the Spiro less so. > > Tav > > On Tue, 20120508 at 01:01 +0200, jbc.engelen@... wrote: > > Hi all, > > Quick note to tell that I uploaded my presentation about Powerstroke > on our wiki. > > > > > http://wiki.inkscape.org/wiki/index.php/PowerStroke#LGM_2012_Presentation > > > > I'm sad I had to leave so early and had no time for the party :'( :'( > > > > Ciao, > > Johan > > > > > > > > >  > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Inkscapedevel mailing list > > Inkscapedevel@... > > https://lists.sourceforge.net/lists/listinfo/inkscapedevel > > > > >  > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Inkscapedevel mailing list > Inkscapedevel@... > https://lists.sourceforge.net/lists/listinfo/inkscapedevel > 
From: Tavmjong Bah <tavmjong@fr...>  20120508 14:57:18

On Mon, 20120507 at 23:37 0700, Josh Andler wrote: > Replying from phone, sorry if short. Extrapolated would rock imho. The > segment limit the lpe uses is quite frustrating though when getting > creative, otherwise it's really awesome. > We just discussed this at the SVG Working Facetoface meeting (I called in). There is support for adding the extrapolated version to the spec. Two small hiccups... one, a couple people asked for the exact mathematical formula to use to find the curvature of the last point (could you supply this?), and two, current rendering libraries that browsers use don't support this so it would have to be added (or simulated via a fill). A miter limit would have to be included to prevent the join from getting too long. Tav 
From: Josh Andler <scislac@gm...>  20120508 22:19:19

On Tue, May 8, 2012 at 7:57 AM, Tavmjong Bah <tavmjong@...> wrote: > We just discussed this at the SVG Working Facetoface meeting (I called > in). There is support for adding the extrapolated version to the spec. > Two small hiccups... one, a couple people asked for the exact > mathematical formula to use to find the curvature of the last point > (could you supply this?), and two, current rendering libraries that > browsers use don't support this so it would have to be added (or > simulated via a fill). A miter limit would have to be included to > prevent the join from getting too long. Johan would be the one who knows the math behind it. Hopefully he will chime in with it when he gets back from his business trip next week (he didn't expect to be online/available during it). Related to support, in Inkscape it's currently simulated by a fill (since the lpe is an actual filled object). The LPE does have a miter feature, but the interpolation method currently gets limited more quickly by the number of segments it uses for the calculation (I would like to see that number bumped up just a little, and leave it to miter to limit). Cheers, Josh 
From: Johan Engelen <jbc.engelen@sw...>  20120517 21:53:53

On 852012 16:57, Tavmjong Bah wrote: > On Mon, 20120507 at 23:37 0700, Josh Andler wrote: >> Replying from phone, sorry if short. Extrapolated would rock imho. The >> segment limit the lpe uses is quite frustrating though when getting >> creative, otherwise it's really awesome. >> > We just discussed this at the SVG Working Facetoface meeting (I called > in). There is support for adding the extrapolated version to the spec. > Two small hiccups... one, a couple people asked for the exact > mathematical formula to use to find the curvature of the last point > (could you supply this?), and two, current rendering libraries that > browsers use don't support this so it would have to be added (or > simulated via a fill). Nice to hear people are interested in powerstroke's feature that I am most proud of :) The extrapolation does not use the curvature of the path, but the path's direction instead. The direction of the path is then rotated 90 degrees to get the normal, which is then used to simply mirror the path itself to obtain the extrapolation. The direction is easily calculated from the derivative of the path (or 2nd derivative if 1st is zero, or 3rd if...); something like that must be already used to draw the standard SVG miter. A word of caution: my method of extrapolating might be harder computationally than necessary. This mirroring+intersection was the first thing that popped in my head (*) when thinking up the extrapolation concept, but perhaps there are other easier and just as visually pleasing methods. I do not know how normal strokes are rendered, and have no clue of what is feasible in terms of computational effort. One of the responses to my presentation at LGM was to try and use the curvature of the path and extrapolate with circles. I have not yet tried this... (*) well, actually, my first idea was to just take the values of the bezier curve beyond its normal [0..1] domain. But I remember that this didn't really work very intuitively if at all. So... how do other programs draw thick stroked lines? Surely, I am not the first to think of this. Cheers, Johan 
From: Tavmjong Bah <tavmjong@fr...>  20120518 05:30:44

On Thu, 20120517 at 23:53 +0200, Johan Engelen wrote: > On 852012 16:57, Tavmjong Bah wrote: > > On Mon, 20120507 at 23:37 0700, Josh Andler wrote: > >> Replying from phone, sorry if short. Extrapolated would rock imho. The > >> segment limit the lpe uses is quite frustrating though when getting > >> creative, otherwise it's really awesome. > >> > > We just discussed this at the SVG Working Facetoface meeting (I called > > in). There is support for adding the extrapolated version to the spec. > > Two small hiccups... one, a couple people asked for the exact > > mathematical formula to use to find the curvature of the last point > > (could you supply this?), and two, current rendering libraries that > > browsers use don't support this so it would have to be added (or > > simulated via a fill). > > Nice to hear people are interested in powerstroke's feature that I am > most proud of :) > > The extrapolation does not use the curvature of the path, but the path's > direction instead. The direction of the path is then rotated 90 degrees > to get the normal, which is then used to simply mirror the path itself > to obtain the extrapolation. The direction is easily calculated from the > derivative of the path (or 2nd derivative if 1st is zero, or 3rd if...); > something like that must be already used to draw the standard SVG miter. Ah, this explains why my first attempt at creating a demo image didn't look quite right and when I used circular arcs it looked better. When there is a large change in the rate of curvature along a path I don't think mirroring give's the best looking results. I think you want to keep the curvature constant or even the first and second derivatives constant (although the latter would be tougher to implement). When I get a chance, I'll create some tests. > A word of caution: my method of extrapolating might be harder > computationally than necessary. This mirroring+intersection was the > first thing that popped in my head (*) when thinking up the > extrapolation concept, but perhaps there are other easier and just as > visually pleasing methods. I do not know how normal strokes are > rendered, and have no clue of what is feasible in terms of computational > effort. > One of the responses to my presentation at LGM was to try and use the > curvature of the path and extrapolate with circles. I have not yet tried > this... > > (*) well, actually, my first idea was to just take the values of the > bezier curve beyond its normal [0..1] domain. But I remember that this > didn't really work very intuitively if at all. > > So... how do other programs draw thick stroked lines? Surely, I am not > the first to think of this. Hmm, anybody with other drawing programs to check? It could be that the PostScript standard became the de facto standard for this. Tav 
From: Jasper van de Gronde <th.gronde@hc...>  20120518 08:18:17

On 180512 07:30, Tavmjong Bah wrote: > ... >> The extrapolation does not use the curvature of the path, but the path's >> direction instead. The direction of the path is then rotated 90 degrees >> to get the normal, which is then used to simply mirror the path itself >> to obtain the extrapolation. The direction is easily calculated from the >> derivative of the path (or 2nd derivative if 1st is zero, or 3rd if...); >> something like that must be already used to draw the standard SVG miter. > > Ah, this explains why my first attempt at creating a demo image didn't > look quite right and when I used circular arcs it looked better. When > there is a large change in the rate of curvature along a path I don't > think mirroring give's the best looking results. I think you want to > keep the curvature constant or even the first and second derivatives > constant (although the latter would be tougher to implement). When I get > a chance, I'll create some tests. Keeping both the first and second derivatives constant would indeed be hard (as in, impossible in general), but keeping their magnitude constant might be doable. In fact, this is probably equivalent to keeping the curvature constant. If I am not mistaken (with at least Wikipedia to back me up), the curvature can be defined as the magnitude of the second derivative in the arclength parametrization. Now, if you keep the magnitude of the first derivative the same, then you're essentially using a (scaled) arclength parametrization. So if you then also keep the magnitude of the second derivative the same, then you're keeping the curvature the same. (Similarly, if you keep the curvature the same, there should be a parametrization such that, etc., etc.) Assuming you use the above or some other (direct) formula to find the curvature at the end, extending the curve with constant curvature is then relatively easy. It will be a circle arc with radius 1/K (with K the curvature). The center of the circle is easy to find (normal to the curve at a distance of 1/K). You then just need to find the intersection with the other side (which is just a matter of intersecting two circles and choosing between two intersection points) and figure out a way to encode the result (but you're probably doing this all with SBasis curves anyway, so that shouldn't really be a problem). If you need more details, just ask. 
From: Tavmjong Bah <tavmjong@fr...>  20120518 08:44:18

On Fri, 20120518 at 10:18 +0200, Jasper van de Gronde wrote: > On 180512 07:30, Tavmjong Bah wrote: > > ... > >> The extrapolation does not use the curvature of the path, but the path's > >> direction instead. The direction of the path is then rotated 90 degrees > >> to get the normal, which is then used to simply mirror the path itself > >> to obtain the extrapolation. The direction is easily calculated from the > >> derivative of the path (or 2nd derivative if 1st is zero, or 3rd if...); > >> something like that must be already used to draw the standard SVG miter. > > > > Ah, this explains why my first attempt at creating a demo image didn't > > look quite right and when I used circular arcs it looked better. When > > there is a large change in the rate of curvature along a path I don't > > think mirroring give's the best looking results. I think you want to > > keep the curvature constant or even the first and second derivatives > > constant (although the latter would be tougher to implement). When I get > > a chance, I'll create some tests. > > Keeping both the first and second derivatives constant would indeed be > hard (as in, impossible in general), but keeping their magnitude > constant might be doable. In fact, this is probably equivalent to > keeping the curvature constant. If I am not mistaken (with at least > Wikipedia to back me up), the curvature can be defined as the magnitude > of the second derivative in the arclength parametrization. > > Now, if you keep the magnitude of the first derivative the same, then > you're essentially using a (scaled) arclength parametrization. So if > you then also keep the magnitude of the second derivative the same, then > you're keeping the curvature the same. (Similarly, if you keep the > curvature the same, there should be a parametrization such that, etc., etc.) > > Assuming you use the above or some other (direct) formula to find the > curvature at the end, extending the curve with constant curvature is > then relatively easy. It will be a circle arc with radius 1/K (with K > the curvature). The center of the circle is easy to find (normal to the > curve at a distance of 1/K). You then just need to find the intersection > with the other side (which is just a matter of intersecting two circles > and choosing between two intersection points) and figure out a way to > encode the result (but you're probably doing this all with SBasis curves > anyway, so that shouldn't really be a problem). If you need more > details, just ask. My brain was obviously still sleeping when I replied... substitute second derivative for first derivative and third derivative for second in my last email. And I meant an 'or' instead of an 'and'. In other words, the simplest thing to do is to use the curvature at the end of the line to extend the curve; a perhaps better, but more difficult option, is to instead use the derivative of the curvature. 