Apache OpenOffice (AOO) Bugzilla – Issue 121193
Alt+Arrow & Cmd+Arrow move cursor in the opposite directions, in RTL text editing
Last modified: 2017-05-20 11:51:21 UTC
While editing a Hebrew/Arabic texts, Alt + Left/Right-arrows moves to the previous/next word, but in Hebrew, the arrows behavior is reversed. Solution: Make sure Alt+Left/Right move in the direction the arrow requests. The same goes to Alt+Shift+Left/Right. Just like in English, when you ask to Alt+Left to move to the word on your left. In other words: Alt+Right jumps left, instead of to the right (original intent is to jump to the previous word location, meaning... right, in Hebrew/Arabic). Alt+Shift+Right - same reversed behavior. In the same way, Alt+Left and Alt+Shift+Left should jump to left, instead of to the right. This relates to the 92224 bug, which was initiated at 2008 and reported of awkward keyboard shortcuts behavior on the Mac, but this is an annoying issue I find rather annoying while editing RTL texts. I'm using build 9593 of OpenOffice (3.4.1). Just to be clear, I've checked other applications on the Mac, and this behavior works fine in TextEdit, Mail, and Notes applications. This is an OpenOffice issue. Thanks, Tal
I've found that Cmd+Right/Left Arrows works on MAC just as the Alt+Left/Right Arrow should work. So I guess this is a bypass for all MAC users, which results from Windows Ctrl+Right/Left Arrow behavior. However, MAC users are more used to Alt+Arrows to move between words and adding the Shift to select words within a sentence. Cmd+Arrows are used on MAC to go to the start/end of the line.
Bug is persistent in version 4.0 too now (opened bug in version 3.4). Current description of the bug: On Mac, while editing text in Writer, Alt+Right arrow moves left one word, instead of moving right. Command+Right-arrow moves the opposite way to, to the left, instead of to the right. Please fix, or let me know how can I solve this annoying bug.
Confirmed bug still exists in version 4.0. Tested on a Hebrew text, Mac OS 10.6.8
Relevant thread: https://discussions.apple.com/thread/3740630?start=0&tstart=0
@Tal: Could you provide a sample file containing Hebrew/Arabic text? This would make it easier for others to reproduce the defect and later on to verify the fix. Thanks in advance.
Created attachment 81587 [details] Hebrew sentence, for example, with instructions to recreate bug The document demonstrates the reversed behavior of Alt(Option)+Arrows command, as well as Command+Arrow command, on the Mac.
Found out that on Windows cursor moves fine with modifier keys (Alt/Ctrl). This issue is only for the Mac, AFAIK. Initial attempts to fix the code failed: Tried to change editeng/source/editeng/impedit2.cxx, which seemed to most promising candidate. changed MoveCursor function to call WordRight() instead of WordLeft() on KEY_LEFT/KEY_RIGHT, but the final application wasn't affected by this change. Possible directions for checking: ? check that GetLocale function works fine on Mac, since the code works perfectly on Windows. ? find a better code location that has an effect on text editing? ? check KeyEvent::LogicalTextDirectionality function (how?) ? May be related to sun's star text library previousWord/nextWord (same on Mac/Win?) Any further assistance would be appreciated.
Moved to Internationalization > BIDI.
Reverted Version to 3.4.1; the 1st version I noticed this bug. Still evident in 4.1 dev snapshots.
Tal Daniel asked to raise this RTL bug as a stopper, see QA list. He doesn't have the required privileges, so I'm nominating this bug on his behalf. This seems to break the usability of CTRL-left and CTRL-right when editing RTL text (including Hebrew). Honestly, since I don't use RTL functionality, I cannot evaluate how annoying it is. No patches currently available (but some technical analysis is in the issue). Sample docs attached to issue.
I can confirm the described behaviour with OOo 3.3 and later, MacOS 10.8.2. The issue doesn't occur under Linux/Ubuntu.
it is no regression and it exists for some time, I agree that we should fix this asap but I am not sure if it is really a showstopper. Anyway we will analyze it and will decide later.
it is definitely an annoying issue for user of the RTL feature but we should keep in mind that Hebrew is new and came in late after the translation deadline. I am in favor to move on with the release and use the Hebrew version for a deep analysis and test how well we work for such languages in general. We can fix it asap on trunk together with more expected issues ... But I don't think that we should stop the release for this.
no showstopper, will be fixed on trunk asap
(In reply to jsc from comment #14) > no showstopper, will be fixed on trunk asap Thanks. Confirmed for v4.1.3, OS X 10.11.6. I'd appreciate a fix for that, as it makes editing counterintuitive, in RTL languages.