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 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

...

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.