![](https://secure.gravatar.com/avatar/283b2540e7846a3831b030a05daf968e.jpg?s=120&d=mm&r=g)
On Wed, Apr 09, 2014 at 01:08:26PM +0200, Krzysztof Kosi??ski wrote:
Editing other segment types is something I would like to eventually add, but it would require a fairly extensive rewrite. There are also some UI problems:
- Smooth nodes would be much harder to support, and symmetric nodes
wouldn't make a lot of sense; auto nodes would probably have to be removed.
Smooth nodes have C1 continuity which means that the first derivatives match, symmetric means C2 which means second derivatives match. Both of these constraints can be enforced with circular and elliptic arcs and indeed with any 'curve'. Writing the constraint solver is an interesting exercise, in the case of beziers it turns out that they can be enforced with some very simple geometric rules.
- Not only nodes but also segments would have types.
Yes, the node types would be continuity constraints and the segment types would be curve families.
- I'm not sure what the controls could look like for arc segments.
I spent some time on this (a long time ago :), there are a few ideas in the toys on 2geom. There is a 5 handle elliptic arc control which provides endpoint interpolation, tight convex bounding (and hence G1 continuity on the boundaries) and complete support for all conic sections. I can't remember why I didn't like it, but we could dig it out.
If we went in this direction I'd like to add: * geometric contraints such as curvature (look at curvature toy for a possible implementation) * spiros as first class curves * construction constraints (snap to tangent, fillet etc) * pen width annotations
Almost anything in this direction means throwing away a lot of the current UI code, and also means things like seamless persistence of non svg data on curves.
I guess I should write some code :)
njh