Hi to all. I have a problem if I convert a ellipse to path. The path value have a "d" value. It render ok, but if you move a node and come back to original position the "d" property of the path is diferent. It give me some problems accessing to the Geom::CubicBezier of the original path segment, it give me a false cubic segment.
Here are the "d" values after and before node-> key up -> key down:
Just converted to path (straight segments with Geom::CubicBezier): m 148.5715,1206.648 a 417.1429,374.2857 0 0 1 -417.1429,374.286 417.1429,374.2857 0 0 1 -417.1429,-374.286 417.1429,374.2857 0 0 1 417.1429,-374.2858 417.1429,374.2857 0 0 1 417.1429,374.2858 z
Node up-down m 148.5715,1206.648 c 1e-4,99.267 -43.9487,194.468 -122.17821,264.66 -78.22948,70.192 -184.33149,109.626 -294.96469,109.626 -110.6332,0 -216.7352,-39.434 -294.9647,-109.626 -78.2295,-70.192 -122.1783,-165.393 -122.1782,-264.66 0,-99.267 43.9488,-194.468 122.1783,-264.66 78.2295,-70.1922 184.3314,-109.6258 294.9646,-109.6258 110.6332,0 216.73514,39.4336 294.96461,109.6258 78.22949,70.192 122.17829,165.393 122.17829,264.66 z
Thanks in advance, Jabier.
2014-04-09 9:58 GMT+02:00 Jabiertxo Arraiza Cenoz <jabier.arraiza@...2893...>:
Hi to all. I have a problem if I convert a ellipse to path. The path value have a "d" value. It render ok, but if you move a node and come back to original position the "d" property of the path is diferent. It give me some problems accessing to the Geom::CubicBezier of the original path segment, it give me a false cubic segment.
This is expected. The node editor can currenntly only edit cubic Bezier and linear segments, so when any change is made to a path that contains other segment types, the path will be converted to contain only those segment types.
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: 1. 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. 2. Not only nodes but also segments would have types. 3. I'm not sure what the controls could look like for arc segments.
Regards, Krzysztof
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
Sorry for my little knoweledge, couldent aport to the deep disciussion. But... There is an altenate method to know the values for a ellipse converted to paths when Geom::CubicBezier const *cubic return false?
I want to know the equivalent to (*cubic)[1] in this kind of path/curve.
I attemp, by point from su_v, to convert to curves with Alvin staff in sp_selected_path_combine. Think use the function sp_item_list_to_curves, but i couldent use it in a LPEITEN inside a effect.
Regards, Javier.
Hi to all, i could finaly convert Geom::SVGEllipticalArc to cubic bezier. I do on top pathvector with this function: pathv_to_linear_and_cubic_beziers
Thanks to all for your help! Regards, Jabier.
participants (3)
-
Jabiertxo Arraiza Cenoz -
Krzysztof Kosiński -
Nathan Hurst