## lib2geom-devel

 [Lib2geom-devel] rendering arcs - Bug 653315 From: Alvin Penner - 2010-11-30 00:35:48 Attachments: sbasis-to-bezier.h     sbasis-to-bezier.cpp     Message as HTML ```Hi, This is a follow-up to a thread at : https://sourceforge.net/mailarchive/forum.php?thread_name=30327020.post%40ta lk.nabble.com&forum_name=inkscape-devel Have never posted to this list before, hope it arrives. Attached is a modified version of the files src\2geom\sbasis-to-bezier.cpp, and *.h. The original call to the routine : sbasis_to_bezier(bez, B, 4) has been replaced with a call to a new routine : sbasis_to_cubic_bezier(bez, B) in order to improve the conversion from sbasis to cubic bezier. In the original routine the cubic bezier was specified by fitting the four variables : dx/dt(0), dy/dt(0), dx/dt(1), dy/dt(1), where t is the independent variable in the parametric representation. In the new routine the bezier is specified by fitting the four variables dx/dy(0), dx/dy(1), x(0.5), y(0.5). Numerical tests have shown that the original routine, if applied to a circular arc, will yield a bezier curve whose control arms have a length d/r = theta/3 where d = Bezier control arm length r = radius theta = angle of arc. This is a correct zeroth order result for small theta, but is not appropriate for large theta. Numerical tests using the new routine on a circular arc yield a bezier control arm length that is consistent with d/r = 4*tan(theta/4)/3 This is identical to the formula that is currently being used in the routine sp_genericellipse_set_shape (src\sp-ellipse.cpp) to render those ellipses that have sodipodi attributes associated with them. When applied to LP Bug 653315, file p.svg, this patch appears to resolve the rendering problem shown there. Alvin Penner ```
 Re: [Lib2geom-devel] rendering arcs - Bug 653315 From: Dr Nathan Hurst - 2010-11-30 02:41:44 ```On Mon, Nov 29, 2010 at 07:03:23PM -0500, Alvin Penner wrote: > Have never posted to this list before, hope it arrives. It did so, thanks! > This is identical to the formula that is currently being used in the > routine sp_genericellipse_set_shape (src\sp-ellipse.cpp) to render those > ellipses that have sodipodi attributes associated with them. > When applied to LP Bug 653315, file p.svg, this patch appears to resolve > the rendering problem shown there. Yes, the cubic fitting function uses geometric approximation as opposed to parametrix approximation. It is definitely better in this case, thanks for fixing, I'll commit to bzr when I get a chance. I'm not happy with the linear approximation - it contains a cusp at each endpoint and would be better replaced with equally spaced handles to give both geometric and parametric fitting. > else { // linear case > for (int i = 0; i < 2; ++i) { > delx[i] = 0; > dely[i] = 0; > } we really want something like delx[1] = (x[3]-x[0])/3; here. njh ```
 Re: [Lib2geom-devel] rendering arcs - Bug 653315 From: Alvin Penner - 2010-11-30 04:14:45 ```>we really want something like delx[1] = (x[3]-x[0])/3; here. > >njh > sounds good to me, thanks, Alvin ```
 Re: [Lib2geom-devel] rendering arcs - Bug 653315 From: Alvin Penner - 2013-08-14 21:16:38 Attachments: sbasis-to-bezier.cpp     sbasis-to-bezier.h ```The issue of converting from sbasis to bezier has been raised again in the thread: http://inkscape.13.x6.nabble.com/quot-Edit-paths-by-nodes-quot-uses-different-and-wrong-approximation-of-arc-as-bezier-curve-td4967659.html In response to that, I have posted an updated version of sbasis-to-bezier.cpp and .h. These are compatible with current Inkscape trunk and appear to resolve the rendering problem mentioned in that thread. any comments would be welcome, Alvin Penner```
 Re: [Lib2geom-devel] rendering arcs - Bug 653315 From: Krzysztof Kosiński - 2013-08-15 00:54:18 ```2013/8/14 Alvin Penner : > The issue of converting from sbasis to bezier has been raised again in the > thread: > http://inkscape.13.x6.nabble.com/quot-Edit-paths-by-nodes-quot-uses-different-and-wrong-approximation-of-arc-as-bezier-curve-td4967659.html > In response to that, I have posted an updated version of > sbasis-to-bezier.cpp and .h. These are compatible with current Inkscape > trunk and appear to resolve the rendering problem mentioned in that thread. I committed this and also gave you commit access to lib2geom. Regards, Krzysztof ```
 [Lib2geom-devel] size comparison in Affine::inverse() From: Alvin Penner - 2014-07-21 20:22:13 ```while investigating LP Bug 1231990, https://bugs.launchpad.net/inkscape/+bug/1231990, it was found that the routine Affine::inverse() in the file affine.cpp is apparently refusing to calculate the inverse of the following matrix: 0.001, 0.0 0.0, 150.0 The refusal is coming from the line: if (!rel_error_bound(determ, mx*mx)) I would like to propose that this be changed to: if (!rel_error_bound(std::sqrt(fabs(determ)), mx)) so that we would be comparing two numbers which both have units of length. This would be similar to a change was made in rev 2183, where a similar size comparison problem was encountered (LP Bug 1309225). Any comments? Cheers, Alvin ```
 Re: [Lib2geom-devel] rendering arcs - Bug 653315 From: Alvin Penner - 2013-08-15 01:16:23 ```thanks, much appreciated! Alvin Penner ```
 Re: [Lib2geom-devel] size comparison in Affine::inverse() From: Nathan Hurst - 2014-07-21 21:08:30 ```Does it fix the bug? I don't understand because those two algorithms are almost equivalent (there is a slight shift in the bounds due to nonlinearity). In this case det should be 0.150, which is a long way from singular. What is mx in this case? njh On Mon, Jul 21, 2014 at 03:56:48PM -0400, Alvin Penner wrote: > while investigating LP Bug 1231990, > https://bugs.launchpad.net/inkscape/+bug/1231990, it was found that > the routine Affine::inverse() in the file affine.cpp is apparently > refusing to calculate the inverse of the following matrix: > > 0.001, 0.0 > 0.0, 150.0 > > The refusal is coming from the line: > if (!rel_error_bound(determ, mx*mx)) > > I would like to propose that this be changed to: > if (!rel_error_bound(std::sqrt(fabs(determ)), mx)) > so that we would be comparing two numbers which both have units of > length. This would be similar to a change was made in rev 2183, where > a similar size comparison problem was encountered (LP Bug 1309225). > > Any comments? > > Cheers, > Alvin > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Lib2geom-devel mailing list > Lib2geom-devel@... > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel ```
 Re: [Lib2geom-devel] size comparison in Affine::inverse() From: Alvin Penner - 2014-07-22 10:17:14 ```thanks, the change has been committed to rev 2215. Alvin ```
 Re: [Lib2geom-devel] size comparison in Affine::inverse() From: Johan Engelen - 2014-07-21 21:23:07 ```Hi Nathan, Alvin, I was also confused a bit at first, but: inline bool rel_error_bound(Coord a, Coord b, double eps=EPSILON) { return a <= eps*b && a >= -eps*b; } So the fix with sqrt does do a different check. hth regards, Johan On 21-7-2014 23:08, Nathan Hurst wrote: > Does it fix the bug? I don't understand because those two algorithms > are almost equivalent (there is a slight shift in the bounds due to > nonlinearity). In this case det should be 0.150, which is a long way > from singular. What is mx in this case? > > njh > > On Mon, Jul 21, 2014 at 03:56:48PM -0400, Alvin Penner wrote: >> while investigating LP Bug 1231990, >> https://bugs.launchpad.net/inkscape/+bug/1231990, it was found that >> the routine Affine::inverse() in the file affine.cpp is apparently >> refusing to calculate the inverse of the following matrix: >> >> 0.001, 0.0 >> 0.0, 150.0 >> >> The refusal is coming from the line: >> if (!rel_error_bound(determ, mx*mx)) >> >> I would like to propose that this be changed to: >> if (!rel_error_bound(std::sqrt(fabs(determ)), mx)) >> so that we would be comparing two numbers which both have units of >> length. This would be similar to a change was made in rev 2183, where >> a similar size comparison problem was encountered (LP Bug 1309225). >> >> Any comments? >> >> Cheers, >> Alvin >> >> >> ------------------------------------------------------------------------------ >> Want fast and easy access to all the code in your enterprise? Index and >> search up to 200,000 lines of code with a free copy of Black Duck >> Code Sight - the same software that powers the world's largest code >> search on Ohloh, the Black Duck Open Hub! Try it now. >> http://p.sf.net/sfu/bds >> _______________________________________________ >> Lib2geom-devel mailing list >> Lib2geom-devel@... >> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Lib2geom-devel mailing list > Lib2geom-devel@... > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel > > ```
 Re: [Lib2geom-devel] size comparison in Affine::inverse() From: Alvin Penner - 2014-07-21 21:50:55 ```yes, I guess I should have specified. Originally we had mx = 150, determ = 0.15, mx*mx/determ = 150,000, which is larger than 1E5, so it fails. After taking the square root, it will pass. Alvin ```
 Re: [Lib2geom-devel] size comparison in Affine::inverse() From: Nathan Hurst - 2014-07-22 00:47:27 ```Oh right, yeah, Alvin's absolutely(relatively?) right. You get a ship-it/lgtm from me. njh On Mon, Jul 21, 2014 at 11:22:49PM +0200, Johan Engelen wrote: > Hi Nathan, Alvin, > I was also confused a bit at first, but: > inline bool rel_error_bound(Coord a, Coord b, double eps=EPSILON) { return a <= eps*b && a >= -eps*b; } > > So the fix with sqrt does do a different check. > > hth > regards, > Johan > > On 21-7-2014 23:08, Nathan Hurst wrote: > > Does it fix the bug? I don't understand because those two algorithms > > are almost equivalent (there is a slight shift in the bounds due to > > nonlinearity). In this case det should be 0.150, which is a long way > > from singular. What is mx in this case? > > > > njh > > > > On Mon, Jul 21, 2014 at 03:56:48PM -0400, Alvin Penner wrote: > >> while investigating LP Bug 1231990, > >> https://bugs.launchpad.net/inkscape/+bug/1231990, it was found that > >> the routine Affine::inverse() in the file affine.cpp is apparently > >> refusing to calculate the inverse of the following matrix: > >> > >> 0.001, 0.0 > >> 0.0, 150.0 > >> > >> The refusal is coming from the line: > >> if (!rel_error_bound(determ, mx*mx)) > >> > >> I would like to propose that this be changed to: > >> if (!rel_error_bound(std::sqrt(fabs(determ)), mx)) > >> so that we would be comparing two numbers which both have units of > >> length. This would be similar to a change was made in rev 2183, where > >> a similar size comparison problem was encountered (LP Bug 1309225). > >> > >> Any comments? > >> > >> Cheers, > >> Alvin > >> > >> > >> ------------------------------------------------------------------------------ > >> Want fast and easy access to all the code in your enterprise? Index and > >> search up to 200,000 lines of code with a free copy of Black Duck > >> Code Sight - the same software that powers the world's largest code > >> search on Ohloh, the Black Duck Open Hub! Try it now. > >> http://p.sf.net/sfu/bds > >> _______________________________________________ > >> Lib2geom-devel mailing list > >> Lib2geom-devel@... > >> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel > > ------------------------------------------------------------------------------ > > Want fast and easy access to all the code in your enterprise? Index and > > search up to 200,000 lines of code with a free copy of Black Duck > > Code Sight - the same software that powers the world's largest code > > search on Ohloh, the Black Duck Open Hub! Try it now. > > http://p.sf.net/sfu/bds > > _______________________________________________ > > Lib2geom-devel mailing list > > Lib2geom-devel@... > > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel > > > > > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Lib2geom-devel mailing list > Lib2geom-devel@... > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel ```