## 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 text/plain ```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 ```
 [Lib2geom-devel] https://bugs.launchpad.net/inkscape/+bug/1482806 From: Alvin Penner - 2015-08-13 00:31:09 ```Hi, this is a request for comment on a proposed fix for Bug 1482806. The bug is apparently caused by returning a null value when attempting to take the unary negative of an sbasis which is zero. The proposed code returns the original sbasis instead. Any comments on whether this is acceptable? The code is fairly deeply embedded, so it may have implications elsewhere. Alvin Penner ```
 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 ```
 Re: [Lib2geom-devel] https://bugs.launchpad.net/inkscape/+bug/1482806 From: Krzysztof Kosiński - 2015-08-13 12:50:50 ```Instead of changing the unary minus operator, the default constructor for SBasis should be changed so that it creates an SBasis that is identically zero (i.e. contains only one Linear(0, 0)). Null values should not be representable in the SBasis object, and there should assertions everywhere verifying that there is at least one element; no member functions should ever remove the last Linear. Regards, Krzysztof 2015-08-13 2:11 GMT+02:00 Alvin Penner : > Hi, > this is a request for comment on a proposed fix for Bug 1482806. The > bug is apparently caused by returning a null value when attempting to > take the unary negative of an sbasis which is zero. The proposed code > returns the original sbasis instead. Any comments on whether this is > acceptable? The code is fairly deeply embedded, so it may have > implications elsewhere. > > Alvin Penner > > > ------------------------------------------------------------------------------ > _______________________________________________ > Lib2geom-devel mailing list > Lib2geom-devel@... > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel ```
 Re: [Lib2geom-devel] https://bugs.launchpad.net/inkscape/+bug/1482806 From: Alvin Penner - 2015-08-13 14:39:52 ```Sounds like a good idea, a somewhat similar problem occurred recently in https://bugs.launchpad.net/inkscape/+bug/1473317 Unfortunately, I don't know how to actually do this. My C programming skills are limited to microprocessors that are 15 years old and still use integer arithmetic. Alvin At 08:50 AM 8/13/2015, Krzysztof KosiÅski wrote: >Instead of changing the unary minus operator, the default constructor >for SBasis should be changed so that it creates an SBasis that is >identically zero (i.e. contains only one Linear(0, 0)). Null values >should not be representable in the SBasis object, and there should >assertions everywhere verifying that there is at least one element; no >member functions should ever remove the last Linear. > >Regards, Krzysztof > >2015-08-13 2:11 GMT+02:00 Alvin Penner : > > Hi, > > this is a request for comment on a > proposed fix for Bug 1482806. The > > bug is apparently caused by returning a null value when attempting to > > take the unary negative of an sbasis which is zero. The proposed code > > returns the original sbasis instead. Any comments on whether this is > > acceptable? The code is fairly deeply embedded, so it may have > > implications elsewhere. > > > > Alvin Penner > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Lib2geom-devel mailing list > > Lib2geom-devel@... > > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel ```
 Re: [Lib2geom-devel] https://bugs.launchpad.net/inkscape/+bug/1482806 From: Krzysztof Kosiński - 2015-08-13 14:41:44 ```Okay, I'll get this patched then. 2015-08-13 16:39 GMT+02:00 Alvin Penner : > Sounds like a good idea, a somewhat similar problem occurred recently in > https://bugs.launchpad.net/inkscape/+bug/1473317 > > Unfortunately, I don't know how to actually do this. My C programming skills > are limited to microprocessors that are 15 years old and still use integer > arithmetic. > > Alvin > > > At 08:50 AM 8/13/2015, Krzysztof KosiÅ„ski wrote: >> >> Instead of changing the unary minus operator, the default constructor >> for SBasis should be changed so that it creates an SBasis that is >> identically zero (i.e. contains only one Linear(0, 0)). Null values >> should not be representable in the SBasis object, and there should >> assertions everywhere verifying that there is at least one element; no >> member functions should ever remove the last Linear. >> >> Regards, Krzysztof >> >> 2015-08-13 2:11 GMT+02:00 Alvin Penner : >> > Hi, >> > this is a request for comment on a proposed fix for Bug 1482806. >> > The >> > bug is apparently caused by returning a null value when attempting to >> > take the unary negative of an sbasis which is zero. The proposed code >> > returns the original sbasis instead. Any comments on whether this is >> > acceptable? The code is fairly deeply embedded, so it may have >> > implications elsewhere. >> > >> > Alvin Penner >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > _______________________________________________ >> > Lib2geom-devel mailing list >> > Lib2geom-devel@... >> > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel > > ```