Bug 144296 - Under-engineered and inconsistent overflow/extension direction choice incl. with cell edit mode
Summary: Under-engineered and inconsistent overflow/extension direction choice incl. w...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.2.0.1 rc
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevAdvice
Depends on:
Blocks: RTL-CTL 65563 Cell-Edit-Mode RTL-UI
  Show dependency treegraph
 
Reported: 2021-09-04 18:43 UTC by Eyal Rozenberg
Modified: 2021-09-15 13:15 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Screencast exemplifying current behavior (following the four parts) (21.26 MB, video/x-matroska)
2021-09-06 20:56 UTC, Eyal Rozenberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2021-09-04 18:43:25 UTC
This is a generalization of bug 65563. To get the wider picture, let's follow some "reproduction" instructions in four parts.


Preparation
------------

1. Open a new LO Calc document (I'm assuming your default page style is LTR and default cell style is inherit; that horizontal alignment is "Default"; and that wrapping is disabled.)

Part 1L
------------

2. Double-click cell 3E.
3. Type in the following text: "The quick brown fox jumps over the lazy dog." (without the quotes)
4. Press Enter, noting what happens to the text. You are now on cell 4E.
5. Switch to Hebrew keyboard layout.
6. Type in the following text: "אל תדאג אמר הדג יש לי עורך דין כריש." (without the quotes); note how the text extends as it gets longer - what stays in place and what moves. 
7. Press Enter, noting what happens to the text.


Part 2L
------------

Select the cells 6E, 7E. Change the cell direction (e.g. using the toolbar) to RTL. Now Repeat Part 1L, but starting at cell 6E.


Part 1R
------------

Set the sheet direction to Right-to-Left; ensure the direction of cells 3E and 4E is still set to LTR (if bug 138862 is resolved, the cells' direction is now RTL and you need to set the cell direction manually). Now repeat the steps of Part 1L.


Part 2R
------------

Set the sheet direction to Right-to-Left and repeat Part 2L.


===========================================


Main problem
--------------

* In Part 1L step 6, the text was extending rightwards, i.e. all glyphs were moving rightwards as one was typing.
In Part 1L step 7, the text jumped leftwards, so that its beginning was aligned to the right of the cell.

Regardless of which of these choices is correct - it can't be both: When you leave cell edit mode (in this case and with D and F columns being empty), the text should stay in place. and overflow in the same direction as during its editing. This is bug 65563.

* In Part 2L step 3, the LTR text extends rightwards, but in step 4 it jumps leftwards, so that its beginning is aligned with the right edge of the cell. Why does this make sense?

* In Part 2L steps 6 & 7, the same extension and jump happened as in Part 1L steps 6 & 7. Is this reasonable? If it is, then - why did the behavior of Part 2L steps 3 & 4 change with the cell direction?; if it's a bug, then why even have the RTL text extend rightwards at all during the edit?


More generally - what controls the direction the text extends in? Is it...

- The cell direction?
- The cell alignment?
- The sheet direction?
- The input locale's associated direction?

It is not clear to me which _should_ be the correct answer.

But - right now, there is no correct answer. It's all inconsistent. The only thing we can say is that the sheet direction is ignored completely - the behavior in Parts 1L and 1R is identical to that in Parts 2L and 2R. Sheet direction being ignored also remind us of bug 138862, and that cell direction is supposed 

Actually, there are three decisions/choices to be made:

* The direction of text extension while it is being typed 
* The direction of text overflow as the text area increases, in cell edit mode
* The direction of text overflow as the text area increases, when an edit is completed

It can well be argued that the former is simply the intra-cell text alignment setting. As for the other two - again, I'm not sure what the correct answer should be. It certainly merits a bit more thought.


Secondary problem
--------------------


In Part 1L Step 6, whenever you type a space or punctuation mark after a work, the text extends slightly in the opposite direction - the direction-neutral-glyph space appears at the beginning of the text run rather than its end. This is disorienting and a bit annoying. One could argue that "nothing can be done", since it's an LTR cell. However, at least during Cell Edit Mode, it could be argued that we are allowed to assume that additional glyphs from the current keyboard layout are forthcoming, and thus pretend as though the next neutral is between two RTL-directed glyphs - and only when we're out of cell edit mode, enforce the cell's direction. I believe this would better capture user's expectations (or desires) in this case, with the same final result. Yes, it would mean the last period in the sentence would switch directions on Enter, but that's better than multiple direction switches, again and again.

The same problem manifests in Part 1R, step 3 - with the LTR text. And the same suggestion stands.
Comment 1 Eyal Rozenberg 2021-09-04 18:47:26 UTC
I'll try to make a video of this sometime (at least of parts 1L and 2L).

Also, this is not a new issue obviously, but my specific version is currently:

Version: 7.2.0.1 / LibreOffice Community
Build ID: 32efc3b7f3a71cfa6a7fa3f6c208333df48656cc
CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: en-US (en_IL); UI: en-US
Calc: threaded
Comment 2 Heiko Tietze 2021-09-06 08:13:39 UTC
Fun fact: If you switch the language from English (and likely any other too) to None (or any other language) via statusbar, the overflow works for RTL too after step 6.
Comment 3 Eyal Rozenberg 2021-09-06 20:46:53 UTC
And I forgot:

Main Problem 2
----------------

On an LTR sheet, in a RTL cell, when typing in Hebrew text in cell edit mode - the text extends due right... but only until the cell boundaries, and characters simply disappear, with only the latest ones visible.
Comment 4 Eyal Rozenberg 2021-09-06 20:56:16 UTC
Created attachment 174837 [details]
Screencast exemplifying current behavior (following the four parts)

Enjoy this near-feature-length video...
Comment 5 Heiko Tietze 2021-09-13 10:41:18 UTC
Brought this up at the ESC. Clearly a bug and no UX input needed.
Comment 6 Eyal Rozenberg 2021-09-14 16:50:03 UTC
(In reply to Heiko Tietze from comment #5)
> Clearly a bug and no UX input needed.

Heiko, while there is at least one, and probably more than one, bug at play here - the questions I bring up are UX decisions to be made, which have not been made. Unless you believe they all have obvious answers? 

To recap, the questions are which of the four possible factors I listed should control the three directions I listed (text extension while typing, text overflow as the text area increases in cell edit mode, text overflow when cell is not being edited) - and in what combination/priority orider of the factors.
Comment 7 Heiko Tietze 2021-09-15 08:02:03 UTC
(In reply to Eyal Rozenberg from comment #6)
> To recap, the questions are which of the four possible factors I listed
> should control the three directions I listed (text extension while typing,
> text overflow as the text area increases in cell edit mode, text overflow
> when cell is not being edited) - and in what combination/priority orider of
> the factors.

RTL should behave like LTR: overflow to the cell right-hand (or left-hand) if empty on editing and when done.

Hossein, you might be interested in this topic. Probably an easy hack since any update even zoom in/out starts repaint and makes the overflow work.
Comment 8 Eyal Rozenberg 2021-09-15 09:57:24 UTC
(In reply to Heiko Tietze from comment #7)
> RTL should behave like LTR: overflow to the cell right-hand (or left-hand)
> if empty on editing and when done.

I believe this is too simplistic, for several reasons:

1. You write "RTL" or "LTR", but - this is not always uniform. What if the cell is RTL and the sheet/page is LTR? Overflow outside the cell is, on one hand, part of the cell's contents; but on the other hand it is a multi-cell/sheet-level phenomenon.

2. Should the alignment really not affect the direction of extension? If your text extends in a certain direction _within_ the cell, why not have it extend in the same direction outside the cell, as well?

3. The cell edit mode is more of a UI element - like the cell contents line on the toolbar - than a part of the "final" sheet. With this being the case - what if the LO UI is RTL but the cell and sheet are LTR? Should not the UI direction be accounted for w.r.t. how text appears in cell edit mode? 

Like I said earlier, I haven't formed an opinion of my own on all this, but your single sentence doesn't answer these questions.
Comment 9 Eyal Rozenberg 2021-09-15 10:29:16 UTC
(In reply to Eyal Rozenberg from comment #8)

By the way, this is how it's like in Excel 2010:

* Excel has "General" cell alignment which we don't; it also has "Context" cell direction. I'm not 100% sure how those are defined.
* Same extension/overflow directions when editing and after editing; the only change is that during an edit, you see your text over adjacent cells' content.
* Cell extension/overflow direction is based ON CELL ALIGNMENT ONLY - completely disregarding the direction of the cell and the sheet.
* In "General" alignment, the extension/overflow direction seems to be decided by the directionality of the first character typed into the cell when its empty (and later it gets weird, there might even be a bug somewhere)
Comment 10 Heiko Tietze 2021-09-15 10:36:54 UTC
(In reply to Eyal Rozenberg from comment #8)
> 1. You write "RTL" or "LTR", but - this is not always uniform. What if the
> cell is RTL and the sheet/page is LTR?
Same as for LTR: what counts is the cell.

> 2. Should the alignment really not affect the direction of extension?
Prob. I don't get this but reading direction inside/outside is the same for me. And again: what happens LTR should be the same on RTL.

> 3. ...what if the LO UI is RTL but the cell and sheet are LTR? 
We had the discussion somewhere else. And it is unrelated to this issue regarding overflow.
Comment 11 Eyal Rozenberg 2021-09-15 13:15:52 UTC
(In reply to Heiko Tietze from comment #10)
> (In reply to Eyal Rozenberg from comment #8)
> > 1. You write "RTL" or "LTR", but - this is not always uniform. What if the
> > cell is RTL and the sheet/page is LTR?
> Same as for LTR: what counts is the cell.

You mean "same as the cell's internal direction". This is a legitimate choice, but it is not a trivial/tautological choice.

> > 2. Should the alignment really not affect the direction of extension?
> Prob. I don't get this but reading direction inside/outside is the same for
> me. And again: what happens LTR should be the same on RTL.

To restate: If the text within the cell starts from the left edge (= left-aligned), and extends towards the right edge of the cell - regardless of its directionality - then it continues extending in the same direction after reaching the cell boundary. I find this behavior in Excel quite pleasing, and am now leaning towards recommending we also adopt it.

Please try the steps I listed above (2-7) with MS Excel, with different cell directions and cell (horizontal) alignments, to experience this.

> > 3. ...what if the LO UI is RTL but the cell and sheet are LTR? 
> We had the discussion somewhere else. And it is unrelated to this issue
> regarding overflow.

It is related, because it is not necessarily the case that the direction of overflow in cell edit mode is the same as after the edit is completed. That is another UX choice to make. There is already some difference in how the cell edit mode extends over other cells contents; in theory, it could extend in another direction than the final result. I'm not saying that this is a great choice; and in fact, if the "go by alignment rather than direction" approach is chosen, then it seems to have no benefits; but if "go by direction" is chosen for the non-cell-edit-box state of the cell, then it might make sense for editing convenience.