From: Alvin Penner <penner@va...>  20101130 00:35:48

Hi, This is a followup to a thread at : https://sourceforge.net/mailarchive/forum.php?thread_name=30327020.post%40ta lk.nabble.com&forum_name=inkscapedevel Have never posted to this list before, hope it arrives. Attached is a modified version of the files src\2geom\sbasistobezier.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\spellipse.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 
From: Dr Nathan Hurst <njh@nj...>  20101130 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\spellipse.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 
From: Alvin Penner <penner@va...>  20101130 04:14:45

>we really want something like delx[1] = (x[3]x[0])/3; here. > >njh > sounds good to me, thanks, Alvin 
From: Alvin Penner <penner@va...>  20130814 21:16:38
Attachments:
sbasistobezier.cpp
sbasistobezier.h

The issue of converting from sbasis to bezier has been raised again in the thread: http://inkscape.13.x6.nabble.com/quotEditpathsbynodesquotusesdifferentandwrongapproximationofarcasbeziercurvetd4967659.html In response to that, I have posted an updated version of sbasistobezier.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 
From: Krzysztof Kosiński <tweenk.pl@gm...>  20130815 00:54:18

2013/8/14 Alvin Penner <penner@...>: > The issue of converting from sbasis to bezier has been raised again in the > thread: > http://inkscape.13.x6.nabble.com/quotEditpathsbynodesquotusesdifferentandwrongapproximationofarcasbeziercurvetd4967659.html > In response to that, I have posted an updated version of > sbasistobezier.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 
From: Alvin Penner <penner@va...>  20140721 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 
From: Alvin Penner <penner@va...>  20130815 01:16:23

thanks, much appreciated! Alvin Penner 
From: Nathan Hurst <njh@nj...>  20140721 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 > _______________________________________________ > Lib2geomdevel mailing list > Lib2geomdevel@... > https://lists.sourceforge.net/lists/listinfo/lib2geomdevel 
From: Alvin Penner <penner@va...>  20140722 10:17:14

thanks, the change has been committed to rev 2215. Alvin 
From: Johan Engelen <jbc.engelen@sw...>  20140721 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 2172014 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 >> _______________________________________________ >> Lib2geomdevel mailing list >> Lib2geomdevel@... >> https://lists.sourceforge.net/lists/listinfo/lib2geomdevel >  > 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 > _______________________________________________ > Lib2geomdevel mailing list > Lib2geomdevel@... > https://lists.sourceforge.net/lists/listinfo/lib2geomdevel > > 
From: Alvin Penner <penner@va...>  20140721 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 
From: Nathan Hurst <njh@nj...>  20140722 00:47:27

Oh right, yeah, Alvin's absolutely(relatively?) right. You get a shipit/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 2172014 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 > >> _______________________________________________ > >> Lib2geomdevel mailing list > >> Lib2geomdevel@... > >> https://lists.sourceforge.net/lists/listinfo/lib2geomdevel > >  > > 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 > > _______________________________________________ > > Lib2geomdevel mailing list > > Lib2geomdevel@... > > https://lists.sourceforge.net/lists/listinfo/lib2geomdevel > > > > > > >  > 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 > _______________________________________________ > Lib2geomdevel mailing list > Lib2geomdevel@... > https://lists.sourceforge.net/lists/listinfo/lib2geomdevel 