Apache OpenOffice (AOO) Bugzilla – Issue 55248
Incorrect cursor key movement between table cells of different directionality
Last modified: 2013-08-07 14:44:35 UTC
When using the cursor keys to move to next/previous cell, the direction of movement depends on the directionality of the cell (LTR - Left to Right, or RTL - Right To Left). For example, when a cell is defined to have LTR direction, and the user presses the left arrow key, the cursor moves to the previous cell (to the left). However, if a cell is set to RTL direction, and the uses presses the left arrow key, the cursor moves to the next cell (to the right). This is incorrect behavior and very confusing. The user expects the cursor keys to behave logically - progress to the next cell relative to the direction of the table, not to the next cell relative to the direction of text in the current cell. An example of how this behavior is very confusing: A user creates a table in a Hebrew document. Hebrew is an RTL language and so the direction of the document, and by default of the table, is RTL. The then selectes one of the columns and clicks the LTR tool-button, to make all cells in the column have LTR text. This is because the column is intended for email addresses, which are always in English. The user then uses the left arrow key to move from the first (right-most) column, to the next, then to the next, etc. Then the user reaches the email column (which is LTR), and again presses the left arrow key. The user expects the curosr to move to the next column - to the left, however the cursor moves to the previous column! Repeated presses on the left arrow key cause the cursor to remain "trapped" among the email column and the column that preceeds it. The solution: cursor movement between cells should depend on the direction of the table, not the direction of the text in the current cell.
MRU->SBA: please have a loo, it is about cursor movement in tables in CTL.
Please attach a sample document to reproduce.
Created attachment 30296 [details] Simple demonstration of the issue
Hmm. Not sure whether this is a bug. Anyway - confirming. At least with visual cursor movement I'd expect the right-arrow key to move to the right cell...
confirmed on 680m3 and 680_m131 reassigend to fme target OOo later changed prio to p4
I was also able to reproduce the defect by following the steps provided in the sample file. This defect was reproducible with the following: Windows 2000 Professional and Open Office 2.0 Windows XP and Open Office 2.0 In addition to reproducing the defect I ran some follow up testing: Test 1 - Test to see if the behaviour of the cursor moving the left if the right arrow key is pressed and vice versa in any other situations. I was also able to reproduce this behaviour in a frame. These are the steps that I used: 1) Open Office Writer 2) Click insert->frame 3) Click on the options tab 4) Set the text direction to Right to Left (horizontal) 5) Click ok and the frame should occur on the screen 6) Click anywhere off the frame and then click back on it 7) The cursor should now be flashing in the frame 8) Type the words test 9) Place the cursor between the t and the e and press the left arrow key The left arrow key will move the cursor to the right which is the same unexpected behaviour that happens in the table cells when the cell direction is set to right to left. Test 2 – Test the behaviour of the delete key and the backspace key in the right to left cell to see if they delete the character to the left of the cursor like they are suppose to or if they perform the same defect and move to the right just because the cell direction is set to right to left. These two keys both moved to the left of the cursor in a cell defined as left to right and right to left, so there is no problem with these keys. I agree with the previous statements that this behaviour can be quite confusing and disappointing to users. At the same time I don't think its importance is too high because once the user realizes that the arrow keys are moving the cursor in the opposite direction they will still be able to move though their table. This behaviour is only seen when the cell direction is set to right to left and I think only a few users will be utilizing this option.
>> This behaviour is only seen when the cell direction is set to right to >> left and I think only a few users will be utilizing this option. This is typical to people who think that Left-To-Right languages are "correct" and all RTL languages are "wrong" and therefore are used by "only a few users". There are well over 500,000,000 people who's native language is RTL. Not only they are users, almost every multi-national corporation produces documents for markets where the language is RTL. To the point of this bug - this is a very COMMON problem in RTL documents, because very often table cells are used for Latin text (eg. email addresses) or numbers. In order to have correct directionality of such data, the cells containing the data must be switched to LTR, and it then becomes impossible to navigate using the arrow keys. >> At the same time I don't think its importance is too high because once >> the user realizes that the arrow keys are moving the cursor in the >> opposite direction they will still be able to move though their table. Believe me there is NO WAY to get used to keys that behave differently in each cell. I'm a programmer with 25 years of experience and I used more than a few bad programs, and this bug drives me mad to the point that I give up and switch to MS Word. Therefore, for RTL users, fixing this bug IS important.
set target 3.x since not relevant for 3.4 release.