https://bugs.documentfoundation.org/show_bug.cgi?id=144296
Bug ID: 144296 Summary: Under-engineered and inconsistent cell edit mode overflow direction with RTL text Product: LibreOffice Version: 7.2.0.1 rc Hardware: All OS: All Status: UNCONFIRMED Keywords: needsUXEval Severity: normal Priority: medium Component: Calc Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: eyalr...@gmx.com Blocks: 43808, 65563, 112128, 129661 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. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=43808 [Bug 43808] [META] Right-To-Left (aka Complex Text Layout) language issues (RTL/CTL) https://bugs.documentfoundation.org/show_bug.cgi?id=65563 [Bug 65563] RTL: Arabic/Hebrew text appears left aligned during cell edit when horizontal text alignment is set to Default https://bugs.documentfoundation.org/show_bug.cgi?id=112128 [Bug 112128] [META] Cell edit mode bugs and enhancements https://bugs.documentfoundation.org/show_bug.cgi?id=129661 [Bug 129661] [META] Right-To-Left (RTL) user interface issues -- You are receiving this mail because: You are the assignee for the bug.