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.
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
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.
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.
Created attachment 174837 [details] Screencast exemplifying current behavior (following the four parts) Enjoy this near-feature-length video...
Brought this up at the ESC. Clearly a bug and no UX input needed.
(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.
(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.
(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.
(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)
(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.
(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.
Dear Eyal Rozenberg, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
No changes since this was reported. Although - on second thought, when following the reproduction instructions, don't stay on column E, since you'll get auto-complete kicking in. Switch to different rows and columns for every part of the instructions.
Don't know why I'm getting the auto-comment again :-(
Still relevant with Version: 7.6.0.3 (X86_64) / LibreOffice Community Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265 CPU threads: 4; OS: Linux 6.4; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US