Bug on stroke?

[chrispa]

Hi,

I want to change the aligment of my stroke on a path. So I click on the dedicated icons of the Stroke panel. It doesn't work because my path is open.
With closed path, it works fine.

Is it a bug?

[GarryP]

The way the software currently works, an open path doesn’t have an inside or outside so you can't align the stroke of an open path to the inside or outside.

It has been requested elsewhere in the forums that open paths can have an inside and outside.

[chrispa]

Yep, it could be nice.

When two paths are facing each other, if one path have a stroke (and tje other not) there aren't "joined perfectly" 🙃

[Alfred]

44 minutes ago, chrispa said:

When two paths are facing each other, if one path have a stroke (and tje other not) there aren't "joined perfectly" 🙃

 Remove the stroke, join the two paths, and then reapply the stroke. If you’re unsure of the stroke parameters, cut and paste the stroke so that the information is stored on the clipboard, and then use ‘Edit > Paste Style’ to apply the copied style to the joined object.

[Pšenda]

1 hour ago, chrispa said:

Yep, it could be nice.

Just for interest:

 

[chrispa]

4 hours ago, Alfred said:

 Remove the stroke, join the two paths, and then reapply the stroke. If you’re unsure of the stroke parameters, cut and paste the stroke so that the information is stored on the clipboard, and then use ‘Edit > Paste Style’ to apply the copied style to the joined object.

Hi Alfred, that was the solution for this particular drawing. Everything is good today.
But sometimes closing the path could not be the solution… 🙁

[R C-R]

10 hours ago, GarryP said:

It has been requested elsewhere in the forums that open paths can have an inside and outside.

It has ... but I'm still trying to figure out what would be considered the inside or outside of several open curves, like S or Z shaped ones, zig-zags, or 2-node straight lines.

What would you suggest for ones like in this inside or outside?.afdesign example?

[Alfred]

27 minutes ago, R C-R said:

or 2-node straight lines

Or, for that matter, multi-node straight lines!

 

[Pšenda]

2 hours ago, R C-R said:

but I'm still trying to figure out what would be considered the inside or outside of several open curves, like S or Z shaped ones, zig-zags, or 2-node straight lines.

Of course, as has been said many times before, an open curve is not about "outside" and "inside", it's about "right" and "left", and examples are in the linked thread:

 

 

[Pšenda]

13 hours ago, chrispa said:

So I click on the dedicated icons of the Stroke panel. It doesn't work because my path is open.

A typical example of a wrongly/badly designed UI. If the inside/outside option does not make sense on an open curve, the corresponding buttons must be Disabled.

[thomaso]

2 hours ago, R C-R said:

I'm still trying to figure out what would be considered the inside or outside of several open curves, like S or Z shaped ones, zig-zags, or 2-node straight lines.

How do we know which Fill Mode is active: "Alternate" or "Winding"? – As discussed already in @Pšenda's linked thread, to move a stroke on an open path to the other side it is not required to know or decide about in- or outside. (your question reminds me to the co-driver joke: "Left! Left!! No, the Other Left!!!") – At the end the clip also illustrates that left/right may be quite different to in-/outside.

[R C-R]

2 hours ago, thomaso said:

At the end the clip also illustrates that left/right may be quite different to in-/outside.

No disagreement from me about that, but it remains true that for many curves there is no obvious inside or outside.

[thomaso]

4 minutes ago, R C-R said:

it remains true that for many curves there is no obvious inside or outside.

It is just not relevant.

[chrispa]

For some simple paths, inside could where the background colour could be applied. In my case (that was why I post), an half circle. Easy!

But for more complex paths, like in the example above, even an AI would be flabbergasted! 😄

But maybe, it's just semantic. If outside/inside isn't relevant, maybe "one side" and "other side" could be… And in my case, everything would have been easier.

[R C-R]

9 hours ago, thomaso said:

It is just not relevant.

Why not? If there is no definable inside or outside for certain curve shapes then what would anyone reasonably expect a stroke alignment button named "Inside" or "Outside" to do for those curves? If instead they were named "Left" & "Right" or something similar then that would not work as many would expect for closed shapes.

BTW, the fill mode isn't relevant to the stroke alignment so I do not know why you mentioned it.

[R C-R]

4 hours ago, chrispa said:

For some simple paths, inside could where the background colour could be applied.

What do you mean by background color? Are you talking about a fill color or something else?

[Old Bruce]

4 hours ago, chrispa said:

But maybe, it's just semantic. If outside/inside isn't relevant, maybe "one side" and "other side" could be… And in my case, everything would have been easier.

I haven't a clue as to how difficult it would be to code but there is the river metaphor, Left Bank and Right Bank. The first node would be the source and the final node would be the mouth of the river. 

[R C-R]

33 minutes ago, Old Bruce said:

I haven't a clue as to how difficult it would be to code but there is the river metaphor, Left Bank and Right Bank. The first node would be the source and the final node would be the mouth of the river. 

That I think is the same as the "Left" & "Right" stroke alignment idea, & would work OK (IOW, unambiguously) on paths drawn with the Pen Tool where we have the option to show the curve's direction with the tiny red line, which clearly defines the first & last node of both open & closed curves, but doesn't work for the quick shapes which have no clearly defined direction or first or last node.

Also, an open curve can have its stroke alignment set to inside or outside which will become obvious if it is later closed, so it is sort of a 'latent' property & thus should not be greyed out. Likewise, a closed curve can be broken so that property once again becomes latent.

So the dilemma for the developers is how to make the stroke align buttons work consistently & logically for all possible path objects that can be stroked.

[thomaso]

52 minutes ago, R C-R said:

If there is no definable inside or outside for certain curve shapes then what would anyone reasonably expect a stroke alignment button named "Inside" or "Outside" to do for those curves?

Just as currently already with arrow heads + path orientation (direction): We simply try + switch to the other option if wanted.
(while I wonder why only "Curve" objects may show their orientation, and why this setting also gets deactivated for "Curve" objects if a "Shape" object gets selected)

59 minutes ago, R C-R said:

If instead they were named "Left" & "Right" or something similar then that would not work as many would expect for closed shapes

It's not required to rename them, they could just get an additional function coded for open curves. If you need less ambiguous semantics add two separate buttons.

1 hour ago, R C-R said:

BTW, the fill mode isn't relevant to the stroke alignment so I do not know why you mentioned it.

I mentioned the "Fill Mode" interface and wording because it touches a similar issue or potential question: "What would anyone reasonably expect?". – These buttons do work, regardless of our ability to know, imagine or prophecy in detail what the labels mean and a selection of the alternative option will cause.

[R C-R]

4 minutes ago, thomaso said:

Just as currently already with arrow heads + path orientation (direction): We simply try + switch to the other option if wanted.

??? So you are suggesting that it just should be a "try one & if that doesn't do what you expect, try the other" kind of option? That strikes me as a terrible idea, about as user unfriendly as it could possibly be.

Also, what about the issue I just mentioned about opening/closing curves? What logic do you think should apply there?

As for the Fill Mode, it has long been established that the 'winding' determines how this works for self-intersecting vector paths & AFAIK all vector apps use the same convention for its effects. 

[Pšenda]

1 hour ago, R C-R said:

So the dilemma for the developers is how to make the stroke align buttons work consistently & logically for all possible path objects that can be stroked.

There is no dilemma, just use your mind. As long as the curve is open, the buttons are Centre/Right side/Left side. If the curve is closed, it will change to Centre/Inside/Outside. After closing an open curve, or after opening/breaking a closed curve, the drawing position of the stroke can of course change, because Right side suddenly becomes Inside, and due to the shape of the curve, this causes a jump to the other side of the stroke.
For Quick shapes - which are of course "closed", there is logically no right/left side, but only inside/outside.

Edited March 20 by Pšenda

[thomaso]

1 hour ago, R C-R said:

??? So you are suggesting that it just should be a "try one & if that doesn't do what you expect, try the other" kind of option? That strikes me as a terrible idea, about as user unfriendly as it could possibly be.

No, I'm not suggesting any specific UI/UX, just arguing for the technical possibility of such an option as expected by the OP... after you've repeatedly expressed that with open paths a knowledge or decision for in- and outside would be required. I am confident the Serif developers find an interface solution if they want to implement the feature and don't see a need to discuss its range of possible details at the current state. The Affinity UI and UX already contains various ambiguities that I don't like, but that Affinity users will have to learn and live with. Forum discussions about details of their product design also seem to be rather irrelevant for Serif.

1 hour ago, R C-R said:

As for the Fill Mode, it has long been established that the 'winding' determines how this works for self-intersecting vector paths & AFAIK all vector apps use the same convention for its effects. 

Your view confirms that the names for a function don't have to be clear, comprehensible or even predictable in their result to get used successfully and even become a "convention".

[R C-R]

1 hour ago, Pšenda said:

As long as the curve is open, the buttons are Centre/Right side/Left side.

So then how do you think they should they be labeled in the tooltips to avoid confusion? Should the names change depending on if the curve is open or closed?

[R C-R]

4 minutes ago, thomaso said:

I am confident the Serif developers find an interface solution if they want to implement the feature...

OK, but how specifically do you think they should do that, & do you think there would be any clear consensus for how it should be implemented & labeled?

5 minutes ago, thomaso said:

Your view confirms that the names for a function don't have to be clear, comprehensible or even predictable in their result to get used successfully and even become a "convention".

I'm not sure what you mean by this. The results of setting the fill mode of vector paths are completely clear, predictable, & comprehensible if one understands the logic of the Even-Odd & Nonzero rules, & thus why the Fill Mode names are labeled in the UI.

The same is not true for the stroke alignment options of vector path objects since there are two possible interpretations of how the results of changing the two non-centered alignments should work whens curves are opened or closed.

[R C-R]

27 minutes ago, thomaso said:

The Affinity UI and UX already contains various ambiguities that I don't like, but that Affinity users will have to learn and live with.

On that I completely agree, but the issue here is if there is any reasonable way to make stroke alignment options less ambiguous for all possible operations on vector path objects, & if so what would a way be that would be clear & comprehensible to the greatest number of users.

Personally, I do not think there is any obvious solution for this; thus why I think it is a dilemma the developers have not already addressed.