Reproduction instructions: 1. Create a new Writer document. 2. Insert a new frame, which is much wider than it is tall 3. Right-click the frame and open the Properties... dialog 4. Under Position & Size, uncheck Autosize 5. Place the cursor in the frame 6. Increase the font size so that the frame does not fit a single character 7. Type a single character - so that you exceed the vertical dimensions of the frame, but not the horizontal ones. Result: You should see a red rectangle pointing at the right edge of the frame, indicating that it can't fit its contents. The problem is, that the triangle direction is indicating the wrong thing: It suggests that there's more content to right of the frame area, while in fact there's more content "below" it. A similar problem occurs if you make the frame RTL and start typing: The arrow will point rightwards, even though the excess is to the left.
Created attachment 197220 [details] Document with the bug manifesting Instead of the reproduction instructions - just open this file. The triangle points right, the excess in the frame is only due bottom.
No objection to make the arrow point into the correct direction. Low priority though. Note that the arrow points to the left if the cursor is at the last line and more content is above the current view. The calculation is wrong, and "hello \n bye" clears the right-ward pointing arrow if the first line is fully visible. This is much more relevant, IMO.
1. What is the problem that this bug talks about (i.e., how fixing it would *help* user)? I *guess*, that it is "the user would try to expand in the indicated direction, but in this corner case, it won't help" - but I have to guess. Without a problem that prevents / makes something harder, it is INVALID. 2. I think, that this should be WONTFIX - because the decision where to draw the triangle would actually be mostly random in typical case (when at least one line fits vertically, and you may expand both ways to see the data); and the improved algorithm to decide the correct direction would be too expensive for the marginal benefit it could bring (a corner case not often seen, and actually, unlikely to really block anyone - I won't believe in someone trying to expand to the left / right for a day, and never trying to expand vertically). The knowledge how to expand to fit it doesn't exist in Writer actually - it detects that the content doesn't fit, but can't tell what would result in a fit (expansion in which direction) - that would need a loop with trial and error.
(In reply to Mike Kaganski from comment #3) > 1. What is the problem that this bug talks about (i.e., how fixing it would > *help* user)? Well, why do we have the red arrow to begin with? And - a very prominent, even garrishly-colored, red arrow? Because it is supposedly very important to us to indicate to the user that there is content overflow from the non-autosized frame. Given that, the arrow direction tells us where content is overflowing. And - right now it's not pointing in the right direction. If we don't care about the direction - let's not make it a triangle pointing in a given direction. Perhaps make the frame have a reddish halo or something. Or even have four small arrows in all directions. What happens right now (and you can see this in the linked-to bug) is that the user believes they need to prevent, or handle, overflow due right - which may not exist. And if we _do_ care about the direction - then we need to point in the directions in which there is overflow.
The arrow "continuing the flow of the text" is much more intuitive than any suggestions you presented in comment 4. No, we don't care about the direction of *expansion* of the box to view it: we only care about the symbol being sufficiently clear and visible. Yes, it *is* *very* important to know that not all content is shown. No it is absolutely irrelevant in which direction should the box be expanded.
(In reply to Mike Kaganski from comment #5) > No, we don't care about the direction of *expansion* of the box to view it: > we only care about the symbol being sufficiently clear and visible. You say "we", but it is rather clear that the triangle was chosen for indicating the direction; and there's also the fact that Calc uses triangles for this purpose as well - and they point either right or left, depending on the direction of overlow. So is there a policy about this? > Yes, it *is* *very* important > to know that not all content is shown. No it is absolutely irrelevant in > which direction should the box be expanded. It's clearly not _absolutely_ irrelevant. Regardless - if we decide it is not relevant enough, let's switch the graphic to something non-directional; and if it is, lets have the triangles pointing in the right directions.
(In reply to Eyal Rozenberg from comment #6) > You say "we", but it is rather clear that the triangle was chosen for > indicating the direction; Please re-read the words "continuing the flow of the text" that I wrote. Yes the "direction" is implicit there; no, it is not the direction in which the box needs to be enlarged, but rather a metaphor for "... continuation of the text". The text flow has a direction, but it doesn't necessarily co-incides with the direction where "the rest of the text is" (even ignoring the fact, that - as I said - the rest of the text is *not* anywhere, since Writer - or Calc - doesn't layout the text outside of the box, so they both have no idea where it is). > and there's also the fact that Calc uses triangles > for this purpose as well - and they point either right or left, depending on > the direction of overlow. So is there a policy about this? It is just the direction in which the alignment of the cell is - left/right/middle. Nothing else. Additionally, it only has that when no text wrap is used - if it does, then the alignment becomes unused. > It's clearly not _absolutely_ irrelevant. Regardless - if we decide it is > not relevant enough, let's switch the graphic to something non-directional; > and if it is, lets have the triangles pointing in the right directions. And that's what I claim: the *goal of the pictogram* is not what you imagine it to be; it was implemented with one goal in mind - to tell you the user, that not everything fit. Then you decide to ask for *expansion* of its behavior; and then I claim, that the possible improvement is absolutely not worth it (the *huge* increase of complexity behind it) - as I explained in my WONTFIX clause.
... forgot to mention: you repeat that "it is not relevant enough, let's switch the graphic to something non-directional" - which is fine, *iif* you manage to suggest a metaphor that is equally telling. I could imagine something like "..." (ellipsis) - which would still be "directional" is a sense (it would need to be, again, in a "natural continuation" place) - but it would be much worse as an icon, because to be understandable, it would need to be much larger (more obtrusive); it would have to be positioned much more precisely; and - it would assume that the "ellipsis" is a "universal" metaphor. The arrow is much more universal - and recognizable at much smaller size. And it doesn't conflict with border decorations (your "make the frame have a reddish halo" idea). It only covers small part of one corner (unlike your "four small arrows in all directions" idea). No, the "we can make it non-directional" is not the same as "we can make it non-directional, *and* at the same time, no worse".
(In reply to Mike Kaganski from comment #7) > so they both have no idea where it is. Calc knows (or can know) well enough to have the triangle point at the appropriate direction. > It is just the direction in which the alignment of the cell is - > left/right/middle. Nothing else. It is just the direction of the overflow. It also happens to be the direction in which the cell is aligned. > Additionally, it only has that when no text > wrap is used - if it does, then the alignment becomes unused. ... in which case there is no triangle. > And that's what I claim: the *goal of the pictogram* is not what you imagine > it to be; it was implemented with one goal in mind - to tell you the user, > that not everything fit. No, that can't true. If that were the case, it would not have been a triangle - an arrow-head - placed at the right side, and pointing right. That is a strong, clear visual signal and not a fluke. > which is fine, *iif* you manage to suggest a metaphor that is equally telling. The current metaphor tells one thing, and it's the wrong thing. I've already suggested two possible alternatives - a halo of some sort (which you disapprove of because of the clash with borders; although we could have it somewhere which doesn't quite clash, so perhaps on the inside rather than the outside); and arrows in multiple directions. You've suggested ellipsis - but noted that it would likely also imply a direction and be less obvious; I'm not sure that's the case: If the elipsis was contained in a small box in one of the corners, there would be less of that implication, since a diagonal is not really an overflow direction. In fact, we could use four (smaller?) triangles at the four corners of the frame instead of the single triangle.
(In reply to Eyal Rozenberg from comment #9) > (In reply to Mike Kaganski from comment #7) > > so they both have no idea where it is. > > Calc knows (or can know) well enough to have the triangle point at the > appropriate direction. > > > It is just the direction in which the alignment of the cell is - > > left/right/middle. Nothing else. > > It is just the direction of the overflow. It also happens to be the > direction in which the cell is aligned. Please. You are really trolling at this point. I tell you, that the arrow shows the alignment. It is implemented to show the alignment. Your reply just tells "I'm not listening, you can tell whatever you want, lalala". Well, that's a possible behavior - just not the one suggesting something constructive. > > Additionally, it only has that when no text > > wrap is used - if it does, then the alignment becomes unused. > > ... in which case there is no triangle. Wrong - there is, if your row is short enough to not fit the text. > > And that's what I claim: the *goal of the pictogram* is not what you imagine > > it to be; it was implemented with one goal in mind - to tell you the user, > > that not everything fit. > > No, that can't true. If that were the case, it would not have been a > triangle - an arrow-head - placed at the right side, and pointing right. > That is a strong, clear visual signal and not a fluke. Finally, I see that all you do is that "I ignore you". Bye.
(In reply to Mike Kaganski from comment #10) > Please. You are really trolling at this point. I tell you, that the arrow > shows the alignment. It is implemented to show the alignment. > Your reply > just tells "I'm not listening, you can tell whatever you want, lalala". > Well, that's a possible behavior - just not the one suggesting something > constructive. Mike, I believe you are mis-perceiving our positions. I'm speaking (or trying to speak) from the a user's perspective. I know what I see, I don't know what the code says, or what the developer's intent was. Even if the code has a comment saying "this command will show the alignment" - that still doesn't change things from the user's perspective; the application's behavior is its _perceived_ behavior, and that's what matters. This is like the "Death of the author" concept in literature: https://en.wikipedia.org/wiki/The_Death_of_the_Author Also, if someone wanted to show me the left-alignment of a cell, they would have placed the triangle at the point to which the text is aligned, which is on the left of the cell, not its right... Similarly, if we align-center, we get arrows on both sides - not anything marking the center-point. Another reason the typical user - I claim - would perceive this as indicating the overflow direction is that they already _have_ an indication of the alignment - on the toolbar; and the reason the triangles appear is that overflow has occurred, so it stands to reason the indication will regard that fact, rather than alignment which is relevant even without overflow. Again, it's quite possible the developer who implemented this wanted something else - but it's not what's been done.
Looks like Affinity has the indicators as either two circles or two rightward-pointing triangles plus a disembodied eye with a strikeout: https://forum.affinity.serif.com/index.php?/topic/177784-frame-text-overflow-not-showing-indicator-when-text-frame-not-selected-user-error-please-ignore/&do=findComment&comment=1023900 In any case, I don't see a need to change things. The problem statement in the description is pointless, there is no concrete problem for the user arising from the triangle direction. The user will not "take the wrong turn" because of the direction of the indicator. Enlarging the frame in any way will fix the hidden overflow.
(In reply to Buovjaga from comment #12) > The problem statement in the description is pointless , there is no concrete > problem for the user arising from the triangle direction. I described the concrete problem. The UI is telling me there is overflow to the left, while there may not be. > The user will not "take the wrong turn" > because of the direction of the indicator. Of course they will, just like I have. > Enlarging the frame in any way will fix the hidden overflow. 1. The user may well not want to, be able to, enlarge the frame. Typically, non-autosized frames have fixed sizes and can't just be enlarged. 2. Even if the user enlarged the frame - that would sometimes not solve the problem. Specifically, it would not solve the problem if the overflow is vertical and the enlargment is horizontal - which it likely will be, given what the arrow clearly tells us. I don't understand the insistence on this poor UI indication. What's so great about the red triangle that we would want to hold on to it so badly?
(In reply to Eyal Rozenberg from comment #13) > (In reply to Buovjaga from comment #12) > > The user will not "take the wrong turn" > > because of the direction of the indicator. > > Of course they will, just like I have. And how exactly? You have made several comments in this report, yet not once have you described the actual failure scenario. > > Enlarging the frame in any way will fix the hidden overflow. > > 1. The user may well not want to, be able to, enlarge the frame. Typically, > non-autosized frames have fixed sizes and can't just be enlarged. So? That's completely irrelevant to this discussion. Shrinking the text is another way to fix it. > 2. Even if the user enlarged the frame - that would sometimes not solve the > problem. Specifically, it would not solve the problem if the overflow is > vertical and the enlargment is horizontal - which it likely will be, given > what the arrow clearly tells us. Why would the user not see that their paragraph has ended and it's time to enlarge vertically? > I don't understand the insistence on this poor UI indication. What's so > great about the red triangle that we would want to hold on to it so badly? The red triangle is awesome and I want to have its baby! Nah, it's just that you have created an imaginary problem and people would like to focus on real problems.
(In reply to Buovjaga from comment #14) > And how exactly? You have made several comments in this report, yet not once > have you described the actual failure scenario. So, I open a document someone sent me, which has a frame. I see the frame as a red triangle near its right edge pointing right, and understand that there's a problem to the right, or on the right edge, of the frame. Remembering what these arrows mean elsewhere (slide presentation software, Calc overflow indication) I conclude that there must be too many characters to fit the frame, and they must be overflowing. So, I delete some characters - but there don't seem to be that many; it all seems to fit nicely in the frame - and I am dumbfound. If I delete _everything_, the triangle goes away, but if I paste it back, it comes back. Now I start to think maybe the triangle is attached to the content somehow and was intentionally put in; after all, it's rather out-of-line in its garish style with, say, the Calc triangle indicators. But of course, I can't select it. Perhaps it's anchored to one of the letters? I try and delete individual letters, or even pairs, but to no avail. If I had seen a triangle facing _downwards_, I would at least have had a fighting chance to figure out what's going on. If there had been, oh, a tooltip or something, that could have helped me. But - nothing but the red arrowhead point my attention to the right of the frame. This is inspired by the related bug 162382 (although there I was actually worried about DOC-vs-DOCX import behavior).
(In reply to Eyal Rozenberg from comment #15) > (In reply to Buovjaga from comment #14) > > And how exactly? You have made several comments in this report, yet not once > > have you described the actual failure scenario. > > So, I open a document someone sent me, which has a frame. I see the frame as > a red triangle near its right edge pointing right, and understand that > there's a problem to the right, or on the right edge, of the frame. > Remembering what these arrows mean elsewhere (slide presentation software, > Calc overflow indication) I conclude that there must be too many characters > to fit the frame, and they must be overflowing. So, I delete some characters > - but there don't seem to be that many; it all seems to fit nicely in the > frame - and I am dumbfound. So your argument centers around you/the user not noticing that there is a paragraph break?
(In reply to Buovjaga from comment #16) > So your argument centers around you/the user not noticing that there is a > paragraph break? There doesn't need to be a paragraph break. It's apparently enough for the paragraph to be slightly too high for the frame.
(In reply to Eyal Rozenberg from comment #17) > (In reply to Buovjaga from comment #16) > > So your argument centers around you/the user not noticing that there is a > > paragraph break? > > There doesn't need to be a paragraph break. It's apparently enough for the > paragraph to be slightly too high for the frame. I don't reproduce this. Anyway, for this case the only problem would be the annoyance caused by the triangle.
(In reply to Buovjaga from comment #18) > I don't reproduce this. Can't consistently reproduce either. In fact, I'm getting rather weird behavior when playing with sizes and text lengths. So, closing this bug for now. I still this this is broken but as I now have less of a clear characterization in my head of how exactly it's broken.
I filed bug 163606 for a glitch I saw. Testing with your example file, I also see that the triangle sometimes does not appear when it should when the height is increased. So the code needs to be made more robust.
Created attachment 197229 [details] Some pointer/triangle behavior changes as we type text - RTL and LTR