Make it more obvious if and why an operation fails

[matt.baker]

The lines in this document don't work with the join curves tool: Join curves failure.afdesign

These were from a PDF import of this: Sanus VLF628_TD_180917.pdf

[Alfred]

Those two ‘lines’ are actually closed curves. If you select both of them and ‘Break Curve’, you should find that a subsequent ‘Join Curves’ command works as expected.

[matt.baker]

Well spotted. I had just come to the same conclusion.

I would have expected a minimum of 3 nodes to close a curve. Confused.

 

Is that the real bug?

[Alfred]

It’s perfectly legitimate to close a curve which only has the two end nodes, even when that ‘curve’ is actually a straight line. If you use the Node Tool to drag on the closed curve thus formed, you’ll curve one of the sides and open up a hole in the middle.

[matt.baker]

I'd never really considered it before. Perhaps it could be improved with a reason for why the curve join, or any operation for that matter, failed?

Another one for migration to the feature requests and feedback forum I guess.

 

[JET_Affinity]

Quote

I would have expected a minimum of 3 nodes to close a curve. Confused.

There is no bug. This behavior is common to all Bezier-based drawing programs. Since paths can be opened, closed, cut, added to, subtracted from and otherwise reshaped at any time, it would be quite debilitating if closing of "straight" paths were somehow "disallowed" whenever a move resulted in a path's being "straight."

Each "segment" of a path is a complete cubic Bezier curve. The interface of the drawing program effectively "strings them together" end-to-end.

By definition, a cubic Bezier curve has four ordered XY coordinate pairs, even if it appears to be just a "straight line" with "just two nodes." The whole "nodes" thing is just an interface convention. The first and last of the four coordinate pairs are the "from" and "to", or "start" and "end" of the plotted curve, so are always located on the curve. So those are the coordinate pairs which drawing programs treat as "nodes" or "anchor points" or just "points." But the second and third coordinate pairs still exist, even with what appears to be a "straight line." They may be coincident with the first or last, or they may just happen to lie somewhere along the straight line between the first and last.

Closing an open path simply adds another segment which starts where the last segment of the open path ends, and ends where the first segment of the open path starts. So there's no reason a single-segment path (your "straight line" with "just two nodes") cannot be closed by adding a second segment identical to it in shape.

For example, forget straight paths and consider a curved path. There's nothing preventing you from doing this:

1. Create a curved single-segment path; for example, a 90 degree arc.
2. Copy it.
3. Paste the copy in the same position, exactly in front of the original. You now have two complete cubic Bezier curves, each still having four defining coordinate pairs.
4. Join the two identical single-segment paths at one end. You still have two complete Bezier curves. But the smoke and mirrors of the software interface treats this construct as a "single path with two segments." It's just treating the end coordinate pair of the first curve and the start coordinate pair of the second curve as a single "node" since they are at the same location. It's effectively "sharing" a coordinate pair between two Bezier curves and through the smoke-and-mirrors of the interface, enabling their associated "handles" (the third coordinate pair of the first curve and the second coordinate pair of the second curve) to be optionally "linked" in one of several behavioral ways when you manipulate them.
5. Close the path. Now you have what the interface presents as a 2-segment closed path. It's still two complete cubic Bezier paths, each defined by four coordinate pairs, but the interface is effectively "sharing" two pairs of start and end coordinates and providing that optional "linking" at both of those "shared" locations (the two on-path "nodes.") This "closed path" still has a start and an end. It also still has a direction.

But now, because of that wonderful "magic" of the software interface, you can:

1. Select one of the two nodes.
2. "Convert" it to a smooth node, causing the third coordinate pair of the first segment and the second coordinate pair of the second segment to act like they are interdependently "linked" so as to be constrained to make a straight line with the "shared" coordinate pair...

...and have a teardrop shape, while being confident that the two curves (segments) remain perfectly tangent at the other node. And now, just because the two segments are not identically shaped, it doesn't seem at all strange that a path having "just two nodes" can be closed.

JET

 

[matt.baker]

Thanks for the explanation @JET_Affinity

I understand how Affinity handles it with the control points; it was just my intuition being way off and not thinking n nodes allows for a maximum of n lines/segments per path.

As soon as one of these lines becomes a curve, it seems obvious to allow a closed path and I can see why disallowing closed paths for straight lines may be a hindrance to the user.

Two more suggestions then: numerical manipulation of the control points and the number of lines / segments in addition to the number of nodes per path.