![](https://secure.gravatar.com/avatar/085f3f0ed546c1fab83680c7689443af.jpg?s=120&d=mm&r=g)
Hi Tomasz,
- Should I add arcto method to SPCurve and make both SPGeneralEllipse
methods generate the same "d" attribute value?
- Why there are two different methods that generate "d" attribute value?
Should one of them (sp_arc_set_elliptical_path_attribute or sp_svg_write_path call in update_patheffect) be removed? Be careful as there are three different classes mixed in this single file: SPEllipse, SPCircle, and SPArc. I'm not sure whether there is a good reason for creating different methods for generating the d attribute value. Maybe that's just because different people worked on that. Note that SPCurve should be eliminated from as many places as possible in favor of 2geom. I'll show you a simple example:
// Old void SPDropperContext::setup() { ... SPCurve *c = new SPCurve(); const double C1 = 0.552; c->moveto(-1,0); c->curveto(-1, C1, -C1, 1, 0, 1 ); c->curveto(C1, 1, 1, C1, 1, 0 ); c->curveto(1, -C1, C1, -1, 0, -1 ); c->curveto(-C1, -1, -1, -C1, -1, 0 ); c->closepath(); ... }
// New void SPDropperContext::setup() { ... Geom::PathVector path; Geom::Circle(0, 0, 1).getPath(path);
SPCurve *c = new SPCurve(path); // SPCurve used only as a wrapper ... }
So if you like geometry, this is a nice job to do ;) .
- Should static function sp_arc_set_elliptical_path_attribute be c++-fied
to private member method? Yes, that's a leftover of my refactoring, I simply didn't have the time yet to turn all these functions into members.
Regards, Markus