line with start and end symbol, bug or feature?

[NotMyFault]

Hi,

 

when moving the end node of a line and reversing it, you can reach a state where the normally parallel orientation of line and symbols breaks.

Bug, feature, or Easter egg?

Only visible with really large stroke settings.

If you reduce stroke, effect collapses at some point.

 

Image shows a copy, then using node tool to re-arrange one of the nodes (going from e.g. 100 to -100, crossing the other node in the process).

 

 

line start end inverse.afphoto

[R C-R]

16 minutes ago, NotMyFault said:

Bug, feature, or Easter egg?

I assume it is a bug, in part because it only seems to happen when the "Place arrow within the line" button is enabled.

[Callum]

Hi All,

I've spoken to our QA team and they have determined that this isn't a bug, the Arrow head is comprised of shapes snapped to a line so when it goes back on itself it just breaks up.

Thanks
C

[R C-R]

4 hours ago, Callum said:

I've spoken to our QA team and they have determined that this isn't a bug, the Arrow head is comprised of shapes snapped to a line so when it goes back on itself it just breaks up.

I don't understand the logic of this. Why should it "break up" when it goes back over itself? Shouldn't the end shapes just keep the same angles relative to the line instead of rotating relative to the line's rotation angle so that they are always oriented so they remain horizontally aligned in the document? Consider for instance this line start end rotate.afphoto example with lines rotated 0, 90, & 120°:

The end shapes are not breaking up; they are rotating.

Moreover, if the line widths are reduced enough, then the end shapes do maintain the same relative angles, so this 'breaking up' only occurs when the line is sufficiently wide.

[Chris B]

Hey R C-R,

I advised Callum a few days ago after quickly glancing at this. 

I think there's a fine line between something being a bug/broken and something just being used in the wrong way. I've poked this a bit more and it could indeed be handled better than it currently is. It's a simple case of the inner part of the arowhead not intersecting the line whereas it should ideally draw it at an angle between the start and end of the curve.

I will log this but I will honestly say it likely will not be a priority.

[R C-R]

6 hours ago, Chris B said:

It's a simple case of the inner part of the arowhead not intersecting the line whereas it should ideally draw it at an angle between the start and end of the curve.

My point is that it is not 'breaking up.' It is not being drawn as it should be, nor is it being drawn consistently for all line widths. This is not just not ideal, it is working in an unexpected way for some line widths & as expected for others. 

As far as I am concerted, that makes it a bug.

[Old Bruce]

14 minutes ago, R C-R said:

This is not just not ideal, it is working in an unexpected way for some line widths & as expected for others. 

I also notice that the size of the arrow ( the Percent) will have an effect on where the things are drawn.

[R C-R]

10 minutes ago, Old Bruce said:

I also notice that the size of the arrow ( the Percent) will have an effect on where the things are drawn.

If the line width is small enough, the end shape sizes can be anything & they still will align properly along the line. For example, compare the two lines in this 50 vs 300 px width.afphoto file. If you reduce the line width of the wider one to 177 px or less, the ends align properly, but at 178 or greater they do not.

This has to be a bug, not an example of something being used "in the wrong way," right?

[Old Bruce]

3 minutes ago, R C-R said:

This has to be a bug, not an example of something being used "in the wrong way," right?

I think it may well be a bug. Having said that I find it odd that things seem to work well with the arrow at the end of the line.

[R C-R]

4 minutes ago, Old Bruce said:

Having said that I find it odd that things seem to work well with the arrow at the end of the line.

I am not sure why in your screenshot the square end is not showing as a square for either arrow placement, but I think for this the only oddity is how placing the arrow(s) within the line behaves differently for different line widths & line rotations.

Another example: yet another line end width.afdesign

The line has a 30 px width. Try gradually increasing it & watch what happens when the width exceeds 80 px. Also compare rotating the line when it is 30 px wide vs. when it is >80 px.

Finally, change the arrow position to the line end & repeat the above. That works fine for all widths & rotations.

[NotMyFault]

7 hours ago, Chris B said:

Hey R C-R,

I advised Callum a few days ago after quickly glancing at this. 

I think there's a fine line between something being a bug/broken and something just being used in the wrong way. I've poked this a bit more and it could indeed be handled better than it currently is. It's a simple case of the inner part of the arowhead not intersecting the line whereas it should ideally draw it at an angle between the start and end of the curve.

I will log this but I will honestly say it likely will not be a priority.

As the OP I’m absolutely ok with this being lowest priority. It’s a bug in my view, but I can’t imagine any practical relevance. 

It really helped me to get the feedback about this nuances between “works as designed”, “clearly a bug”, and all the other shades of grey in between. If this occurs again I can be assured it is not me doing it wrong.

When I observed this initially, I (wrongly) concluded that the Affinity symbol gets a special treatment so it will always stay upright. Testing with other symbols showed it affects all symbols. Have a nice day 

[R C-R]

1 hour ago, NotMyFault said:

When I observed this initially, I (wrongly) concluded that the Affinity symbol gets a special treatment so it will always stay upright. Testing with other symbols showed it affects all symbols.

Could you explain more about what you mean by other symbols being affected? Are you talking about something other than the arrow & other end shapes that can be applied to strokes?

[Old Bruce]

I think symbols is the arrow heads and other end things, like the Affinity logo.

[R C-R]

Just now, Old Bruce said:

I think symbols is the arrow heads and other end things, like the Affinity logo.

I just wondered about that because IIRC one of the staff once mentioned that the Affinity logo end shape is just a placeholder for a yet-to-be-implemented feature that would permit users to create their own custom end shapes, so in some way it might indeed get special treatment.

I also think that we need a better name for referring to all these shape types collectively, since it is obvious they are not all arrowheads or even pointy.

[Chris B]

16 hours ago, NotMyFault said:

It really helped me to get the feedback about this nuances between “works as designed”, “clearly a bug”, and all the other shades of grey in between.

Yes it isn't always a simple case of 'it's a bug' or 'it's by design' - in this case, it looks as though there just hasn't been any consideration or code to handle what would happen if we try to draw all the shapes of the arrowhead on a line that isn't long enough. We consider a bug to be something that isn't working as designed and or prevents the user from completing their goal.

In your attached file, you have a 240pt stroke which is causing the shapes to essentially run out of space on the curve and causes them to jumble up and overlap. Reducing the stroke width will eventually allow the shapes to fit within the allocated space. 

However, as mentioned, a developer agreed it could be handled better and if at some point this is on their list to fix, some code will be written to handle this more effectively. 

[R C-R]

7 hours ago, Chris B said:

We consider a bug to be something that isn't working as designed and or prevents the user from completing their goal.

Should not the code for the line start & ends be designed to work the same for all line lengths, stroke widths, & line rotations? It is evident that it does not, so doesn't that make it a bug according this criteria?