Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Close
From: Johan Engelen <jbc.engelen@sw...>  20121006 20:26:44

Hi all, I've lost track of all the problems with powerstroke. Please send me again the bugs you have found (with a test file!) or the UI ideas we definitely need for release. I have been working on "extrapolate by arcs matching path curvature", but I think it will take me too long to make that work reliably before release. There are still too many bumps along that road... I've committed the code, but it is disabled. Thanks a bunch! Johan 
From: Tavmjong Bah <tavmjong@fr...>  20121007 05:49:47

On Sat, 20121006 at 22:26 +0200, Johan Engelen wrote: > Hi all, > I've lost track of all the problems with powerstroke. > Please send me again the bugs you have found (with a test file!) or the > UI ideas we definitely need for release. > > I have been working on "extrapolate by arcs matching path curvature", > but I think it will take me too long to make that work reliably before > release. There are still too many bumps along that road... I've > committed the code, but it is disabled. What is your problem with "extrapolate by arcs matching path curvature"? I've got a hacked version of Cairo that does the extrapolated linejoin... but not properly (it only works at 100% zoom at the moment). Tav 
From: Johan Engelen <jbc.engelen@sw...>  20121007 19:05:39
Attachments:
arc.svg

On 7102012 7:49, Tavmjong Bah wrote: > On Sat, 20121006 at 22:26 +0200, Johan Engelen wrote: >> Hi all, >> I've lost track of all the problems with powerstroke. >> Please send me again the bugs you have found (with a test file!) or the >> UI ideas we definitely need for release. >> >> I have been working on "extrapolate by arcs matching path curvature", >> but I think it will take me too long to make that work reliably before >> release. There are still too many bumps along that road... I've >> committed the code, but it is disabled. > What is your problem with "extrapolate by arcs matching path curvature"? > I've got a hacked version of Cairo that does the extrapolated > linejoin... but not properly (it only works at 100% zoom at the > moment). Determining the curvature is messy, have not found a good way to do that yet. And handling all corner cases is also a mess... the code in trunk should work reasonably well now. The attached file has a "wrong" result for the middle path. Ciao, Johan 
From: Jasper van de Gronde <th.gronde@hc...>  20121008 08:35:20

On 071012 21:05, Johan Engelen wrote: > On 7102012 7:49, Tavmjong Bah wrote: >> On Sat, 20121006 at 22:26 +0200, Johan Engelen wrote: >>> Hi all, >>> I've lost track of all the problems with powerstroke. >>> Please send me again the bugs you have found (with a test file!) or the >>> UI ideas we definitely need for release. >>> >>> I have been working on "extrapolate by arcs matching path curvature", >>> but I think it will take me too long to make that work reliably before >>> release. There are still too many bumps along that road... I've >>> committed the code, but it is disabled. >> What is your problem with "extrapolate by arcs matching path curvature"? >> I've got a hacked version of Cairo that does the extrapolated >> linejoin... but not properly (it only works at 100% zoom at the >> moment). > > Determining the curvature is messy, have not found a good way to do that > yet. In principle, curvature is just the norm of the second derivative w.r.t. arclength (if you want it signed, you'd probably just have to take the dot product with the unit normal, instead of the norm). Of course, the trick is in the "arclength" bit, is that where you're getting stuck? One trick you could try is taking an explicit formula like (x'*y''  y'*x'')/(x'^2+y'^2)^(3/2) and approximating it with a polynomial (which doesn't require any values near the endpoints, where you'll usually get singularities and other problems), then evaluating the polynomial at the endpoints. I haven't tried it, so I'm not sure how well it would work, but my guess is that it could work pretty well. 
From: Johan Engelen <jbc.engelen@sw...>  20121008 23:04:16

On 8102012 10:35, Jasper van de Gronde wrote: > On 071012 21:05, Johan Engelen wrote: >> On 7102012 7:49, Tavmjong Bah wrote: >>> On Sat, 20121006 at 22:26 +0200, Johan Engelen wrote: >>>> Hi all, >>>> I've lost track of all the problems with powerstroke. >>>> Please send me again the bugs you have found (with a test file!) or the >>>> UI ideas we definitely need for release. >>>> >>>> I have been working on "extrapolate by arcs matching path curvature", >>>> but I think it will take me too long to make that work reliably before >>>> release. There are still too many bumps along that road... I've >>>> committed the code, but it is disabled. >>> What is your problem with "extrapolate by arcs matching path curvature"? >>> I've got a hacked version of Cairo that does the extrapolated >>> linejoin... but not properly (it only works at 100% zoom at the >>> moment). >> Determining the curvature is messy, have not found a good way to do that >> yet. > In principle, curvature is just the norm of the second derivative w.r.t. > arclength (if you want it signed, you'd probably just have to take the > dot product with the unit normal, instead of the norm). > > Of course, the trick is in the "arclength" bit, is that where you're > getting stuck? One trick you could try is taking an explicit formula > like (x'*y''  y'*x'')/(x'^2+y'^2)^(3/2) and approximating it with a > polynomial (which doesn't require any values near the endpoints, where > you'll usually get singularities and other problems), then evaluating > the polynomial at the endpoints. I haven't tried it, so I'm not sure how well it would work, but my guess is that it could work pretty well. I tried the norm of second derivative but I forgot about arclength reparametrisation, thanks for the hint! Arclength reparametrisation is already present in 2geom, so that is easy. Yes I need it 'signed', such that the touching circle is on the inside of the curve. I indeed get that from the normal, but the trick is to figure out which direction points inward for the normal! :) For that I look at the direction of 2nd derivative w.r.t. the tangent. And just now I find at function named "curvature" in 2geom... (although it has a todo comment that it is claimed incomplete...) Cheers, Johan 
From: Johan Engelen <jbc.engelen@sw...>  20121009 21:37:58
Attachments:
extrapolated_arc_cusp.svg

On 9102012 1:04, Johan Engelen wrote: > On 8102012 10:35, Jasper van de Gronde wrote: >> On 071012 21:05, Johan Engelen wrote: >>> On 7102012 7:49, Tavmjong Bah wrote: >>>> On Sat, 20121006 at 22:26 +0200, Johan Engelen wrote: >>>>> Hi all, >>>>> I've lost track of all the problems with powerstroke. >>>>> Please send me again the bugs you have found (with a test file!) or the >>>>> UI ideas we definitely need for release. >>>>> >>>>> I have been working on "extrapolate by arcs matching path curvature", >>>>> but I think it will take me too long to make that work reliably before >>>>> release. There are still too many bumps along that road... I've >>>>> committed the code, but it is disabled. >>>> What is your problem with "extrapolate by arcs matching path curvature"? >>>> I've got a hacked version of Cairo that does the extrapolated >>>> linejoin... but not properly (it only works at 100% zoom at the >>>> moment). >>> Determining the curvature is messy, have not found a good way to do that >>> yet. >> In principle, curvature is just the norm of the second derivative w.r.t. >> arclength (if you want it signed, you'd probably just have to take the >> dot product with the unit normal, instead of the norm). >> >> Of course, the trick is in the "arclength" bit, is that where you're >> getting stuck? One trick you could try is taking an explicit formula >> like (x'*y''  y'*x'')/(x'^2+y'^2)^(3/2) and approximating it with a >> polynomial (which doesn't require any values near the endpoints, where >> you'll usually get singularities and other problems), then evaluating >> the polynomial at the endpoints. I haven't tried it, so I'm not sure how well it would work, but my guess is that it could work pretty well. > > I tried the norm of second derivative but I forgot about arclength > reparametrisation, thanks for the hint! Arclength reparametrisation is > already present in 2geom, so that is easy. Yes I need it 'signed', such > that the touching circle is on the inside of the curve. I indeed get > that from the normal, but the trick is to figure out which direction > points inward for the normal! :) For that I look at the direction of > 2nd derivative w.r.t. the tangent. > > And just now I find at function named "curvature" in 2geom... > (although it has a todo comment that it is claimed incomplete...) "Extrapolated arc" works much better with the improved curvature calculation (not sure whether it is really the curvature but OK :)). Now what is left is to fix the calculation for zerolength handles. Attached is a modified version of the "Choose your miter" file that I showed at LGM. In many cases, the difference between "Extrapolated" and "Extrapolated arc" is not very big. But there are things that one or the other can't do. For example, with "extrapolate" it is not possible to end up with a curving miter at the end of an almost straight line segment simply because the mirrored piece will be straight too instead of curved. Overall it seems that "Extrapolated arc" is easier to control and leads to nicer results, so I am tempted to pick that one by default. Please play with it a bit and form an opinion. I really hope someone comes up with better names for "Extrapolated" and "Extrapolated arc" Cheers, Johan 
From: Shriramana Sharma <samjnaa@gm...>  20121014 15:59:32

Hi Johan, is there a reason you reposted your extrapolated_arc_cusp SVGZ as an SVG? I don't see any changes except for the compression.  Shriramana Sharma 
From: Johan Engelen <jbc.engelen@sw...>  20121009 21:55:12
Attachments:
extrapolated_arc_cusp.svgz

On 9102012 1:04, Johan Engelen wrote: > On 8102012 10:35, Jasper van de Gronde wrote: >> On 071012 21:05, Johan Engelen wrote: >>> On 7102012 7:49, Tavmjong Bah wrote: >>>> On Sat, 20121006 at 22:26 +0200, Johan Engelen wrote: >>>>> Hi all, >>>>> I've lost track of all the problems with powerstroke. >>>>> Please send me again the bugs you have found (with a test file!) or the >>>>> UI ideas we definitely need for release. >>>>> >>>>> I have been working on "extrapolate by arcs matching path curvature", >>>>> but I think it will take me too long to make that work reliably before >>>>> release. There are still too many bumps along that road... I've >>>>> committed the code, but it is disabled. >>>> What is your problem with "extrapolate by arcs matching path curvature"? >>>> I've got a hacked version of Cairo that does the extrapolated >>>> linejoin... but not properly (it only works at 100% zoom at the >>>> moment). >>> Determining the curvature is messy, have not found a good way to do that >>> yet. >> In principle, curvature is just the norm of the second derivative w.r.t. >> arclength (if you want it signed, you'd probably just have to take the >> dot product with the unit normal, instead of the norm). >> >> Of course, the trick is in the "arclength" bit, is that where you're >> getting stuck? One trick you could try is taking an explicit formula >> like (x'*y''  y'*x'')/(x'^2+y'^2)^(3/2) and approximating it with a >> polynomial (which doesn't require any values near the endpoints, where >> you'll usually get singularities and other problems), then evaluating >> the polynomial at the endpoints. I haven't tried it, so I'm not sure how well it would work, but my guess is that it could work pretty well. > > I tried the norm of second derivative but I forgot about arclength > reparametrisation, thanks for the hint! Arclength reparametrisation is > already present in 2geom, so that is easy. Yes I need it 'signed', such > that the touching circle is on the inside of the curve. I indeed get > that from the normal, but the trick is to figure out which direction > points inward for the normal! :) For that I look at the direction of > 2nd derivative w.r.t. the tangent. > > And just now I find at function named "curvature" in 2geom... > (although it has a todo comment that it is claimed incomplete...) "Extrapolated arc" works much better with the improved curvature calculation (not sure whether it is really the curvature but OK :)). Now what is left is to fix the calculation for zerolength handles. Attached is a modified version of the "Choose your miter" file that I showed at LGM. In many cases, the difference between "Extrapolated" and "Extrapolated arc" is not very big. But there are things that one or the other can't do. For example, with "extrapolate" it is not possible to end up with a curving miter at the end of an almost straight line segment simply because the mirrored piece will be straight too instead of curved. Overall it seems that "Extrapolated arc" is easier to control and leads to nicer results, so I am tempted to pick that one by default. Please play with it a bit and form an opinion. I really hope someone comes up with better names for "Extrapolated" and "Extrapolated arc" Cheers, Johan 
From: Tavmjong Bah <tavmjong@fr...>  20121010 07:52:30

On Tue, 20121009 at 23:37 +0200, Johan Engelen wrote: > On 9102012 1:04, Johan Engelen wrote: > > On 8102012 10:35, Jasper van de Gronde wrote: > >> On 071012 21:05, Johan Engelen wrote: > >>> On 7102012 7:49, Tavmjong Bah wrote: > >>>> On Sat, 20121006 at 22:26 +0200, Johan Engelen wrote: > >>>>> Hi all, > >>>>> I've lost track of all the problems with powerstroke. > >>>>> Please send me again the bugs you have found (with a test file!) or the > >>>>> UI ideas we definitely need for release. > >>>>> > >>>>> I have been working on "extrapolate by arcs matching path curvature", > >>>>> but I think it will take me too long to make that work reliably before > >>>>> release. There are still too many bumps along that road... I've > >>>>> committed the code, but it is disabled. > >>>> What is your problem with "extrapolate by arcs matching path curvature"? > >>>> I've got a hacked version of Cairo that does the extrapolated > >>>> linejoin... but not properly (it only works at 100% zoom at the > >>>> moment). > >>> Determining the curvature is messy, have not found a good way to do that > >>> yet. > >> In principle, curvature is just the norm of the second derivative w.r.t. > >> arclength (if you want it signed, you'd probably just have to take the > >> dot product with the unit normal, instead of the norm). > >> > >> Of course, the trick is in the "arclength" bit, is that where you're > >> getting stuck? One trick you could try is taking an explicit formula > >> like (x'*y''  y'*x'')/(x'^2+y'^2)^(3/2) and approximating it with a > >> polynomial (which doesn't require any values near the endpoints, where > >> you'll usually get singularities and other problems), then evaluating > >> the polynomial at the endpoints. I haven't tried it, so I'm not sure how well it would work, but my guess is that it could work pretty well. > > > > I tried the norm of second derivative but I forgot about arclength > > reparametrisation, thanks for the hint! Arclength reparametrisation is > > already present in 2geom, so that is easy. Yes I need it 'signed', such > > that the touching circle is on the inside of the curve. I indeed get > > that from the normal, but the trick is to figure out which direction > > points inward for the normal! :) For that I look at the direction of > > 2nd derivative w.r.t. the tangent. > > > > And just now I find at function named "curvature" in 2geom... > > (although it has a todo comment that it is claimed incomplete...) For my Cairo hack, I used the last three points (two handles, end point) of the cubic Bezier curve to determine the curvature. If the last two points are degenerate, I uses the start point, first handle, and end point. This seems to work fine (and as Cairo only uses cubic Bezier and lines at the rendering point I don't have to worry about arcs, quadratic Beziers, etc.). The math for finding the curvature of a cubic Bezier can be found at: http://tavmjong.free.fr/SVG/LINEJOIN/index.html > "Extrapolated arc" works much better with the improved curvature > calculation (not sure whether it is really the curvature but OK :)). Now > what is left is to fix the calculation for zerolength handles. > Attached is a modified version of the "Choose your miter" file that I > showed at LGM. In many cases, the difference between "Extrapolated" and > "Extrapolated arc" is not very big. But there are things that one or the > other can't do. For example, with "extrapolate" it is not possible to > end up with a curving miter at the end of an almost straight line > segment simply because the mirrored piece will be straight too instead > of curved. Overall it seems that "Extrapolated arc" is easier to control > and leads to nicer results, so I am tempted to pick that one by default. > > Please play with it a bit and form an opinion. I would choose the extrapolated arc. (This also matches what will be in SVG 2.) There seems to be a bug in your code where the wrong intersection of the two circles is sometimes chosen. I noticed in your code that if the two circles don't intersect, you fall back to bevel join. I am thinking in the SVG 2 spec about falling back to miter join. > I really hope someone comes up with better names for "Extrapolated" and > "Extrapolated arc" > Yes, a better name would be nice... If someone comes up with one it might just end up in the SVG 2 spec. Maybe just "arc"? Tav 
From: Martin Owens <doctormo@gm...>  20121010 16:24:08

On Tue, 20121009 at 23:37 +0200, Johan Engelen wrote: > I really hope someone comes up with better names for "Extrapolated" > and > "Extrapolated arc" Is "Extrapolated" not an arc? Explain what these things are and I'll give you your names. :) Martin, 
From: Johan Engelen <jbc.engelen@sw...>  20121010 17:28:35

On 10102012 18:23, Martin Owens wrote: > On Tue, 20121009 at 23:37 +0200, Johan Engelen wrote: >> I really hope someone comes up with better names for "Extrapolated" >> and >> "Extrapolated arc" > Is "Extrapolated" not an arc? > > Explain what these things are and I'll give you your names. :) "Extrapolated" = extend the incoming segment by mirroring it "Extrapolated arc" = extend the incoming segment by a circle that has same curvature as last point on incoming segment. Johan 
From: Johan Engelen <jbc.engelen@sw...>  20121010 21:08:39

On 10102012 9:52, Tavmjong Bah wrote: > On Tue, 20121009 at 23:37 +0200, Johan Engelen wrote: >> On 9102012 1:04, Johan Engelen wrote: >>> On 8102012 10:35, Jasper van de Gronde wrote: >>>> On 071012 21:05, Johan Engelen wrote: >>>>> On 7102012 7:49, Tavmjong Bah wrote: >>>>>> On Sat, 20121006 at 22:26 +0200, Johan Engelen wrote: >>>>>>> Hi all, >>>>>>> I've lost track of all the problems with powerstroke. >>>>>>> Please send me again the bugs you have found (with a test file!) or the >>>>>>> UI ideas we definitely need for release. >>>>>>> >>>>>>> I have been working on "extrapolate by arcs matching path curvature", >>>>>>> but I think it will take me too long to make that work reliably before >>>>>>> release. There are still too many bumps along that road... I've >>>>>>> committed the code, but it is disabled. >>>>>> What is your problem with "extrapolate by arcs matching path curvature"? >>>>>> I've got a hacked version of Cairo that does the extrapolated >>>>>> linejoin... but not properly (it only works at 100% zoom at the >>>>>> moment). >>>>> Determining the curvature is messy, have not found a good way to do that >>>>> yet. >>>> In principle, curvature is just the norm of the second derivative w.r.t. >>>> arclength (if you want it signed, you'd probably just have to take the >>>> dot product with the unit normal, instead of the norm). >>>> >>>> Of course, the trick is in the "arclength" bit, is that where you're >>>> getting stuck? One trick you could try is taking an explicit formula >>>> like (x'*y''  y'*x'')/(x'^2+y'^2)^(3/2) and approximating it with a >>>> polynomial (which doesn't require any values near the endpoints, where >>>> you'll usually get singularities and other problems), then evaluating >>>> the polynomial at the endpoints. I haven't tried it, so I'm not sure how well it would work, but my guess is that it could work pretty well. >>> I tried the norm of second derivative but I forgot about arclength >>> reparametrisation, thanks for the hint! Arclength reparametrisation is >>> already present in 2geom, so that is easy. Yes I need it 'signed', such >>> that the touching circle is on the inside of the curve. I indeed get >>> that from the normal, but the trick is to figure out which direction >>> points inward for the normal! :) For that I look at the direction of >>> 2nd derivative w.r.t. the tangent. >>> >>> And just now I find at function named "curvature" in 2geom... >>> (although it has a todo comment that it is claimed incomplete...) > For my Cairo hack, I used the last three points (two handles, end point) > of the cubic Bezier curve to determine the curvature. If the last two > points are degenerate, I uses the start point, first handle, and end > point. This seems to work fine (and as Cairo only uses cubic Bezier and > lines at the rendering point I don't have to worry about arcs, quadratic > Beziers, etc.). The math for finding the curvature of a cubic Bezier can > be found at: > > http://tavmjong.free.fr/SVG/LINEJOIN/index.html Nice explanation, we should link our release notes to it. I think my 2geom's math is sound now, but... I could transform to cubic bezier and do the math there, to make sure it is identical to yours/SVG's............ But... I spot a difference with my implementation: I extrapolate with circles that are tangent to the stroke of the path, instead of the concentric circles with reduced radius like you do. Because of varying stroke width, the direction and curvature at the stroke itself may be very different from the direction and curvature of the original path. Intuition tells me that our two approaches are identical for fixed stroke width, but am too lazy to do the math. I guess for you it is an easy change, so hoping you can change that aspect to "my" calculation, so your text is valid for varying stroke width too! >> "Extrapolated arc" works much better with the improved curvature >> calculation (not sure whether it is really the curvature but OK :)). Now >> what is left is to fix the calculation for zerolength handles. >> Attached is a modified version of the "Choose your miter" file that I >> showed at LGM. In many cases, the difference between "Extrapolated" and >> "Extrapolated arc" is not very big. But there are things that one or the >> other can't do. For example, with "extrapolate" it is not possible to >> end up with a curving miter at the end of an almost straight line >> segment simply because the mirrored piece will be straight too instead >> of curved. Overall it seems that "Extrapolated arc" is easier to control >> and leads to nicer results, so I am tempted to pick that one by default. >> >> Please play with it a bit and form an opinion. > I would choose the extrapolated arc. (This also matches what will be in > SVG 2.) > > There seems to be a bug in your code where the wrong intersection of the > two circles is sometimes chosen. Which rev did you use? Should've been fixed yesterday. Have to fix the effect for straight paths now. > > I noticed in your code that if the two circles don't intersect, you fall > back to bevel join. I am thinking in the SVG 2 spec about falling back > to miter join. Ok, I just did the fallback as a temp fix. Let's see if it makes much difference. (because very often the miter will have to fallback to bevel I think) >> I really hope someone comes up with better names for "Extrapolated" and >> "Extrapolated arc" >> > Yes, a better name would be nice... If someone comes up with one it > might just end up in the SVG 2 spec. Maybe just "arc"? Do people still want the original extrapolate? I'm not too proud of my original idea to not leave it out if people find it to have very little use. I have not made up my mind yet. The mirrorextrapolate allows for some funky looking stuff that you can't get with circleextrapolate, but perhaps it is too extreme to be useful :P Cheers, Johan 
From: Johan Engelen <jbc.engelen@sw...>  20121010 21:24:58

On 10102012 23:08, Johan Engelen wrote: > On 10102012 9:52, Tavmjong Bah wrote: >> There seems to be a bug in your code where the wrong intersection of the >> two circles is sometimes chosen. > > Which rev did you use? Should've been fixed yesterday. Hmm, bzr up, it didn't commit yesterday. (I also changed fallback to miter, but there is a downside: when it falls back to miter, you may not spot that the corner is ugly again if you are not careful) Cheers, Johan 
From: Martin Owens <doctormo@gm...>  20121010 22:21:27

On Wed, 20121010 at 19:28 +0200, Johan Engelen wrote: > "Extrapolated" = extend the incoming segment by mirroring it > "Extrapolated arc" = extend the incoming segment by a circle that has > same curvature as last point on incoming segment. * Mirror Extension or Reflective Extension * Arc Extension or Circular Extension Vote for your favorite. Martin, 
From: SorinN <nemes.sorin@gm...>  20121011 03:26:19

Arc Extension or Circular Extension sound good for large masses yet Circular has +0.1 meaning for the peoples with not many math classes ;) ..just a voice from the crowd 2012/10/11 Martin Owens <doctormo@...>: > On Wed, 20121010 at 19:28 +0200, Johan Engelen wrote: >> "Extrapolated" = extend the incoming segment by mirroring it >> "Extrapolated arc" = extend the incoming segment by a circle that has >> same curvature as last point on incoming segment. > > * Mirror Extension or Reflective Extension > * Arc Extension or Circular Extension > > Vote for your favorite. > > Martin, > > >  > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelicdev2dev > _______________________________________________ > Inkscapedevel mailing list > Inkscapedevel@... > https://lists.sourceforge.net/lists/listinfo/inkscapedevel  Nemes Ioan Sorin 
From: Martin Owens <doctormo@gm...>  20121011 11:35:26

On Thu, 20121011 at 11:26 +0800, SorinN wrote: > yet Circular has +0.1 meaning for the peoples with not many math > classes ;) Actually it doesn't have to be concrete. it just has to be a little "lie to children" which is on the right track, explains a little and is distinctive. Martin, 
From: Jasper van de Gronde <th.gronde@hc...>  20121012 12:59:22

On 20121010 09:52, Tavmjong Bah wrote: > For my Cairo hack, I used the last three points (two handles, end > point) of the cubic Bezier curve to determine the curvature. If the > last two points are degenerate, I uses the start point, first handle, > and end point. This seems to work fine (and as Cairo only uses cubic > Bezier and lines at the rendering point I don't have to worry about > arcs, quadratic Beziers, etc.). The math for finding the curvature of > a cubic Bezier can be found at: > http://tavmjong.free.fr/SVG/LINEJOIN/index.html Nice exposition! The cross product is illdefined in 2D though, so what you can do is take the determinant of the matrix with row (or column vectors) corresponding to v and v'. Alternatively, you can extend the vectors to be 3D of course, but that would essentially just be a roundabout way to compute a determinant of a 2x2 matrix. To deal with zerolength handles, the easiest (and correct) method is probably to specify that the curvature is zero at the endpoint with the zerolength handle (if both handles are zerolength, then the Bézier curve forms a line segment). That this is correct can be derived from the fact that the unit tangent vector at the endpoint with a zerolength handle points in the same direction as the second derivative (so locally it's a straight line). This is a consequence of l'Hôpital's rule btw. If the first handle is zerolength and the second handle corresponds to the starting point, then again the whole curve is straight, and the curvature should be zero everywhere. One way of doing this "automatically", is to simply add a small epsilon to the denominator (or clamp it to some small positive value). (Perhaps a bit obvious, but it's nice to know that it actually "does the right thing".) > ... I noticed in your code that if the two circles don't intersect, you fall > back to bevel join. I am thinking in the SVG 2 spec about falling back > to miter join. It might make more sense to use (something like) miterlimit, in some cases at least. Essentially there are two cases, either one circle is inside the other, or not. If they are "inside" each other, it might simply make perfect sense to just fill the area between the two circles, unless the area gets (really) large, then you'd probably want to limit it (using something akin to miterlimit). If the circles are not inside each other, the area "between" is always infinite (the entire plane minus the inside of the two circles). In that case, you really have to limit the extent of the join. But even then, it should be possible to still show part of the "true" join. One possible way to specify the restriction for this kind of join would be to limit the arclength on either side of the join. The main problem is then joining the end points, as a line segment between the two is not guaranteed to not intersect the circles. Some experimentation suggests that it might be possible to define a sensible boundary using interpolation between the two end points that is guaranteed not to intersect either of the circles. 
From: Alexandre Prokoudine <alexandre.prokoudine@gm...>  20121012 13:34:26

On Wed, Oct 10, 2012 at 1:55 AM, Johan Engelen wrote: > I really hope someone comes up with better names for "Extrapolated" and > "Extrapolated arc" Wasn't "Artistic" suggested at some point? BTW, is this SVG 2.0 material? Alexandre Prokoudine http://libregraphicsworld.org 
From: Tavmjong Bah <tavmjong@fr...>  20121012 13:53:12

On Fri, 20121012 at 17:34 +0400, Alexandre Prokoudine wrote: > On Wed, Oct 10, 2012 at 1:55 AM, Johan Engelen wrote: > > > I really hope someone comes up with better names for "Extrapolated" and > > "Extrapolated arc" > > Wasn't "Artistic" suggested at some point? The SVG WG liked "arc", as is short and fits with the style of the other line join options (miter, round, bevel). > BTW, is this SVG 2.0 material? Yes and no. Inkscape's implementation is in the Power Stroke LPE which is independent of anything the SVG WG is doing. However, I suggested to the WG that it be added to SVG 2 as an option for regular paths and they have agreed. Tav 
From: Johan Engelen <jbc.engelen@sw...>  20121012 21:11:55

On 12102012 14:59, Jasper van de Gronde wrote: > On 20121010 09:52, Tavmjong Bah wrote: >> For my Cairo hack, I used the last three points (two handles, end >> point) of the cubic Bezier curve to determine the curvature. If the >> last two points are degenerate, I uses the start point, first handle, >> and end point. This seems to work fine (and as Cairo only uses cubic >> Bezier and lines at the rendering point I don't have to worry about >> arcs, quadratic Beziers, etc.). The math for finding the curvature of >> a cubic Bezier can be found at: >> http://tavmjong.free.fr/SVG/LINEJOIN/index.html > Nice exposition! The cross product is illdefined in 2D though, so what > you can do is take the determinant of the matrix with row (or column > vectors) corresponding to v and v'. Alternatively, you can extend the > vectors to be 3D of course, but that would essentially just be a > roundabout way to compute a determinant of a 2x2 matrix. > > To deal with zerolength handles, the easiest (and correct) method is > probably to specify that the curvature is zero at the endpoint with the > zerolength handle (if both handles are zerolength, then the Bézier > curve forms a line segment). That this is correct can be derived from > the fact that the unit tangent vector at the endpoint with a zerolength > handle points in the same direction as the second derivative (so locally > it's a straight line). This is a consequence of l'Hôpital's rule btw. I don't think this is correct. It is possible to make segments with and without a zerolength handle that look exactly the same. Also, as you are moving the handle closer and closer to the knot, it does not converge to zero curvature, in fact it tends to lead to higher curvature instead of lower curvature. Wouldn't l'Hopital imply that you can get away by using +1 higher derivs instead? > > If the first handle is zerolength and the second handle corresponds to > the starting point, then again the whole curve is straight, and the > curvature should be zero everywhere. > > One way of doing this "automatically", is to simply add a small epsilon > to the denominator (or clamp it to some small positive value). (Perhaps > a bit obvious, but it's nice to know that it actually "does the right > thing".) >> ... I noticed in your code that if the two circles don't intersect, you fall >> back to bevel join. I am thinking in the SVG 2 spec about falling back >> to miter join. > It might make more sense to use (something like) miterlimit, in some > cases at least. Essentially there are two cases, either one circle is > inside the other, or not. If they are "inside" each other, it might > simply make perfect sense to just fill the area between the two circles, > unless the area gets (really) large, then you'd probably want to limit > it (using something akin to miterlimit). If the circles are not inside > each other, the area "between" is always infinite (the entire plane > minus the inside of the two circles). In that case, you really have to > limit the extent of the join. But even then, it should be possible to > still show part of the "true" join. > > One possible way to specify the restriction for this kind of join would > be to limit the arclength on either side of the join. The main problem > is then joining the end points, as a line segment between the two is not > guaranteed to not intersect the circles. Some experimentation suggests > that it might be possible to define a sensible boundary using > interpolation between the two end points that is guaranteed not to > intersect either of the circles. I have no clue what you are saying here. :) I am starting to strongly dislike the miter fallback btw, simply because of it not being clear whether you have arc extension or a miter. Bevel fallback has a much better UI experience for me. Cheers, Johan 
From: Shriramana Sharma <samjnaa@gm...>  20121013 15:18:27

On Thu, Oct 11, 2012 at 2:38 AM, Johan Engelen <jbc.engelen@...> wrote: > But... I spot a difference with my implementation: I extrapolate with > circles that are tangent to the stroke of the path, instead of the > concentric circles with reduced radius like you do. Because of varying > stroke width, the direction and curvature at the stroke itself may be > very different from the direction and curvature of the original path. Hi  nice to hear the idea about the arc join. Can you give me a pointer to the two separate codes which implement the extrapolation based on the stroke and that base on the path? I'm interested to see what algorithm you are using for this.  Shriramana Sharma 
From: Johan Engelen <jbc.engelen@sw...>  20121013 16:05:26

On 13102012 17:18, Shriramana Sharma wrote: > On Thu, Oct 11, 2012 at 2:38 AM, Johan Engelen > <jbc.engelen@...> wrote: >> But... I spot a difference with my implementation: I extrapolate with >> circles that are tangent to the stroke of the path, instead of the >> concentric circles with reduced radius like you do. Because of varying >> stroke width, the direction and curvature at the stroke itself may be >> very different from the direction and curvature of the original path. > Hi  nice to hear the idea about the arc join. Can you give me a > pointer to the two separate codes which implement the extrapolation > based on the stroke and that base on the path? I'm interested to see > what algorithm you are using for this. In Inkscape's source: /src/live_effects/lpepowerstroke.cpp The arc extrapolation code starts at line 409 ("case LINEJOIN_EXTRP_MITER_ARC:") Cheers, Johan 
From: Shriramana Sharma <samjnaa@gm...>  20121014 16:06:06

On Sat, Oct 13, 2012 at 2:41 AM, Johan Engelen <jbc.engelen@...> wrote: > > I am starting to strongly dislike the miter fallback btw, simply because > of it not being clear whether you have arc extension or a miter. Bevel > fallback has a much better UI experience for me. I also prefer bevel fallback FWIW, but are we talking about the "extrapolated" join or the "extrapolated arc" thing (w.r.t. the example SVG)? And please tell me whether I have understood correctly that extrapolated arc is more like bevel and basically ensures that all bevels are straightlines whereas extrapolated is more like miter and just ensures continuity of curvature? Personally I feel extrapolated arc is too extreme (too many sharp ends... Naah!)  Shriramana Sharma 
From: Johan Engelen <jbc.engelen@sw...>  20121021 22:03:50

On 14102012 18:05, Shriramana Sharma wrote: > On Sat, Oct 13, 2012 at 2:41 AM, Johan Engelen > <jbc.engelen@...> wrote: >> I am starting to strongly dislike the miter fallback btw, simply because >> of it not being clear whether you have arc extension or a miter. Bevel >> fallback has a much better UI experience for me. > I also prefer bevel fallback FWIW, but are we talking about the > "extrapolated" join or the "extrapolated arc" thing (w.r.t. the > example SVG)? We were talking about the fallback for "extrapolated arc". > And please tell me whether I have understood correctly that > extrapolated arc is more like bevel and basically ensures that all > bevels are straightlines Extrapolated arc = extrapolate with a circle segment. With continuity of curvature/smoothness. (the whole arc has the same curvature as path join point. > whereas extrapolated is more like miter and > just ensures continuity of curvature? Personally I feel extrapolated > arc is too extreme (too many sharp ends... Naah!) Extrapolated = extrapolate by mirroring the path segment. This also results in continuity of curvature and smoothness. Johan 
From: Tavmjong Bah <tavmjong@fr...>  20121015 14:34:05

On Fri, 20121012 at 23:11 +0200, Johan Engelen wrote: > I am starting to strongly dislike the miter fallback btw, simply because > of it not being clear whether you have arc extension or a miter. Bevel > fallback has a much better UI experience for me. But that is exactly what you want. Think about a path with multiple line joins. You want all the line joins to look similar but not all the joins may be possible with the arc join so you want those that aren't possible to be the closest thing... mitered. If you can't tell visually the difference, then it doesn't matter if you have an arc join or a mitered join but it may matter on some other join on the path. Tav 