Hi,
The current Inkscape code converts an elliptical arc to a Bezier curve via converting it first to an SBasic curve. This leads to some loss of accuracy to the curve (noticeable now that we are using SVG <circle> and <ellipse> elements where possible) and control over where the resulting nodes will be placed. lib2geom has been patched (r2122) to fix the accuracy problem. Is there a reason this patch hasn't been applied to the copy of lib2geom in Inkscape? (If no, I can apply the patch.)
Even with this patch, it might be better to provide a direct route to go from an elliptical arc to a Bezier curve bypassing the SBasic step to have better control over where nodes are placed. I have made a first pass at providing a direct route. At the moment, one Bezier curve is created if the arc is less than pi/2 in length. If it is longer, extra nodes are placed on the major and minor ellipse axes. Can the lib2geom experts have a look? I am sure I have not done things in a lib2geom sanctioned way. The branch is available at:
lp:~inkscape.dev/inkscape/elliptical_arc
I've attached a test file where the red ellipses/arcs are drawn using an "ideal" conversion to Bezier curves (with four per circle/ellipse) and the blue curves are test arcs. (The Cairo routines convert the arcs to Beziers for display as Cairo/PostScript/PDF do not have a native elliptical arc path segment so just rendering arcs on screen tests the code.)
One obvious bug is that the flash path when using the node tool is wrong.
Thanks,
Tav
Here is the attachment. My Internet provider would not accept the original email with the attachment, flagging it as spam.
just a couple of quick comments, hopefully not betraying my biases too obviously.
1. it seems that this would be at least a partial reversion of the work that was very recently done in rev 12594. Before rev 12594, the conversion from arc to Bezier was done in sp-ellipse.cpp using a formula that appears to be identical to the one being used in rev 12833 of the proposed branch inkscape/elliptical_arc. This bypassed the sbasis representation entirely, afaict. After rev 12594, the arc form was kept as long as possible, the explicit conversion from arc to Bezier is no longer performed, and is instead done indirectly through sbasis. (The sbasis conversion from arc to Bezier in lib2geom is, I think, closely equivalent to the result obtained before rev 12594.) The purpose of this change in rev 12594, I assume, was to postpone the conversion to Bezier as long as possible, which I would agree with in principle. In Inkscape 0.48.4, if you do a Path->Object to Path operation on a circle, you get a Bezier, which is both lossy and unnecessary. In current trunk, this does not happen.
2. there is an undesirable practical side effect of rev 12594, however: namely it is not clear how many Beziers will actually be produced from an arc. There are two reasons for this. First, the formula that determines the error in the fit appears to be unnecessarily pessimistic as discussed previously: http://inkscape.13.x6.nabble.com/Recent-change-to-ellipse-to-path-conversion...
3. second, the number of Beziers you get from an arc depends on the size of the object, which seems unexpected, given that svg is a scalable format. imho it would be preferable to have a dimensionless measure of the goodness of fit, independent of the size of the object. This would need to be done in the routine build_from_sbasis() in sbasis-to-bezier.cpp. The problem of course would be in defining what the size of the object is, which can be difficult, witness the case of filters where some properties of filters are in dimensionless units while other properties are in absolute units, leading to confusion when the shape changes drastically.
cheers, Alvin
-- View this message in context: http://inkscape.13.x6.nabble.com/Elliptical-arc-branch-tp4968816p4968818.htm... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 29-Nov-2013 12:28, alvinpenner wrote:
- second, the number of Beziers you get from an arc depends on the
size of the object, which seems unexpected, given that svg is a scalable format.
Assuming the arc is defined with respect to an ellipse with major axis A then I would assume that the proper step to take is to translate the center of that ellipse to the origin and divide all coordinate positions by A, reducing the specific ellipse to its "unit ellipse" form. When done with the calculation, apply the inverse scale and offset to the bezier coordinates.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Assuming the arc is defined with respect to an ellipse with major axis A
unfortunately I did not express myself very clearly in that comment. My comment made it sound as though the problem at hand is conversion of an arc to a Bezier. But of course that is not true, the problem at hand is the conversion of an arbitrary sbasis curve to a Bezier without having any knowledge at all of what the original function was that led to the sbasis in the first place. That function may have been an elliptical arc or it may have been something else like a Hypotrochoid, not very likely but still conceivable. So one needs a measure of size that does not presuppose anything, and it needs to behave well in the case that one dimension disappears entirely, like when you convert a square to a straight line. One possibility might be to borrow an idea from the filter code where a blur % is converted to an absolute size in pixels. The way this is done, roughly, is to first get the bbox, then calculate the perimeter of the bbox, then divide it by 4, and then think of that length as being the length of a side of a square which represents the "normalized" object. This is a bit "quick and dirty" but it works well for an object that actually is square and it does not behave pathologically in the case where one dimension goes to zero. It might serve as a measure of size so that the absolute tolerance could be converted into a dimensionless tolerance.
Alvin
-- View this message in context: http://inkscape.13.x6.nabble.com/Elliptical-arc-branch-tp4968816p4968873.htm... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 02-Dec-2013 10:41, alvinpenner wrote:
Assuming the arc is defined with respect to an ellipse with major axis A
unfortunately I did not express myself very clearly in that comment. My comment made it sound as though the problem at hand is conversion of an arc to a Bezier. But of course that is not true, the problem at hand is the conversion of an arbitrary sbasis curve to a Bezier without having any knowledge at all of what the original function was that led to the sbasis in the first place. That function may have been an elliptical arc or it may have been something else like a Hypotrochoid, not very likely but still conceivable.
Would a close approximation to normalization suffice? If so, find a convenient number of standard points on the curve, perhaps the 6 points at t=0,0.2,0.4,0.6,0.8,and 1.0. Project these onto a set of standard lines every 15 degrees between 0 and 180 degrees, and find the distance between the other points on each projection. Use the maximum of those distances as the extent value. (Alternatively calculate a principal component, but I suspect that using the standard projections would be faster.)
There are two sources of error:
1. The maximum extent points might not be included in the set. I cannot estimate this error, it depends on what sorts of cusps and so forth that the s-basis allows, and I know nothing about s-basis curves.
2. The arbitrarily scaled and rotated curve may have its true extent vector rotated from one of the standard vectors by at most 7.5 degrees, so the extent can only be off by at most a factor of 1.0 - cos(7.5deg) == .0086.
Since the issue you are correcting for sounds like it only shows up when there are large differences in scale, these very small differences in the normalized curve should not be a problem.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Hi Tav, As you are working on elliptical arc code, I hope you can find the time to look into the following issue (lib2geom maillist 7-11-2013):
Is there a bug perhaps in this piece of code: elliptical-arc.cpp, lines 608-632
double dsq1 = distanceSq(p, pointAt(from)); double dsq2 = distanceSq(p, pointAt(to)); if ( second_sol ) { if ( mindistsq2 > dsq1 ) { result.clear(); result.push_back(from); mindistsq2 = dsq1; } else if ( are_near(mindistsq2, dsq) ) <--------- BUG ? { result.push_back(from); } if ( mindistsq2 > dsq2 ) { result.clear(); result.push_back(to); } else if ( are_near(mindistsq2, dsq2) ) { result.push_back(to); }
}
From symmetry of the code, shouldn't "dsq" be "dsq1" in that line? The code compiles because earlier, "dsq" was defined. If this is not a bug, please add a comment in the code, saying that it is indeed correct. If it*is* a bug, please correct it, and also reduce the scope of the "dsq" variable defined earlier.
Thanks a lot, Johan
On 29-11-2013 14:50, Tavmjong Bah wrote:
Hi,
The current Inkscape code converts an elliptical arc to a Bezier curve via converting it first to an SBasic curve. This leads to some loss of accuracy to the curve (noticeable now that we are using SVG <circle> and <ellipse> elements where possible) and control over where the resulting nodes will be placed. lib2geom has been patched (r2122) to fix the accuracy problem. Is there a reason this patch hasn't been applied to the copy of lib2geom in Inkscape? (If no, I can apply the patch.)
Even with this patch, it might be better to provide a direct route to go from an elliptical arc to a Bezier curve bypassing the SBasic step to have better control over where nodes are placed. I have made a first pass at providing a direct route. At the moment, one Bezier curve is created if the arc is less than pi/2 in length. If it is longer, extra nodes are placed on the major and minor ellipse axes. Can the lib2geom experts have a look? I am sure I have not done things in a lib2geom sanctioned way. The branch is available at:
lp:~inkscape.dev/inkscape/elliptical_arc
I've attached a test file where the red ellipses/arcs are drawn using an "ideal" conversion to Bezier curves (with four per circle/ellipse) and the blue curves are test arcs. (The Cairo routines convert the arcs to Beziers for display as Cairo/PostScript/PDF do not have a native elliptical arc path segment so just rendering arcs on screen tests the code.)
One obvious bug is that the flash path when using the node tool is wrong.
Thanks,
Tav
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, 2013-12-01 at 16:00 +0100, Johan Engelen wrote:
Hi Tav, As you are working on elliptical arc code, I hope you can find the time to look into the following issue (lib2geom maillist 7-11-2013):
I will certainly take a look at it when I get a chance. I am by no means a lib2geom expert... in fact, one of the reasons I put my work out there was to get feedback from the real experts.
Tav
Is there a bug perhaps in this piece of code: elliptical-arc.cpp, lines 608-632
double dsq1 = distanceSq(p, pointAt(from)); double dsq2 = distanceSq(p, pointAt(to)); if ( second_sol ) { if ( mindistsq2 > dsq1 ) { result.clear(); result.push_back(from); mindistsq2 = dsq1; } else if ( are_near(mindistsq2, dsq) ) <--------- BUG ? { result.push_back(from); } if ( mindistsq2 > dsq2 ) { result.clear(); result.push_back(to); } else if ( are_near(mindistsq2, dsq2) ) { result.push_back(to); } }From symmetry of the code, shouldn't "dsq" be "dsq1" in that line? The code compiles because earlier, "dsq" was defined. If this is not a bug, please add a comment in the code, saying that it is indeed correct. If it *is* a bug, please correct it, and also reduce the scope of the "dsq" variable defined earlier.
Thanks a lot, Johan
On 29-11-2013 14:50, Tavmjong Bah wrote:
Hi,
The current Inkscape code converts an elliptical arc to a Bezier curve via converting it first to an SBasic curve. This leads to some loss of accuracy to the curve (noticeable now that we are using SVG <circle> and <ellipse> elements where possible) and control over where the resulting nodes will be placed. lib2geom has been patched (r2122) to fix the accuracy problem. Is there a reason this patch hasn't been applied to the copy of lib2geom in Inkscape? (If no, I can apply the patch.)
Even with this patch, it might be better to provide a direct route to go from an elliptical arc to a Bezier curve bypassing the SBasic step to have better control over where nodes are placed. I have made a first pass at providing a direct route. At the moment, one Bezier curve is created if the arc is less than pi/2 in length. If it is longer, extra nodes are placed on the major and minor ellipse axes. Can the lib2geom experts have a look? I am sure I have not done things in a lib2geom sanctioned way. The branch is available at:
lp:~inkscape.dev/inkscape/elliptical_arc
I've attached a test file where the red ellipses/arcs are drawn using an "ideal" conversion to Bezier curves (with four per circle/ellipse) and the blue curves are test arcs. (The Cairo routines convert the arcs to Beziers for display as Cairo/PostScript/PDF do not have a native elliptical arc path segment so just rendering arcs on screen tests the code.)
One obvious bug is that the flash path when using the node tool is wrong.
Thanks,
Tav
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (4)
-
alvinpenner -
Johan Engelen -
mathog -
Tavmjong Bah