[Libreoffice-bugs] [Bug 144296] New: Under-engineered and inconsistent cell edit mode overflow direction with RTL text

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Sat Sep 4 18:43:25 UTC 2021


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 at lists.freedesktop.org
          Reporter: eyalroz1 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210904/a377125d/attachment-0001.htm>


More information about the Libreoffice-bugs mailing list