Apache OpenOffice (AOO) Bugzilla – Issue 16368
bidi caret not synced with text / input type (always LTR)
Last modified: 2013-08-07 15:00:01 UTC
usually the cursor is bent towards the paragraph's direction, however writing an English word in a R2L para. then switch to Hebrew and a space, although still we're in Hebrew charset and direction the cursor bends left. Really minor but still.
Confirmed on Windows 2000 - the bidi caret is always in LTR position, even when the active input language is RTL (Hebrew). We should either drop a bidi caret altogether (like mac applications do), or sync the caret properly with the keyboard/input type.
Really confiming now that I have the privlages...
mehlng->sforbes "We should either drop a bidi caret altogether (like mac applications" I think this is a bad idea, if bidi caret is already implemented fixing it is not a very big deal and IMHO it's really helpfull. Anyhow MS-Word has it - so we must also.
DL->HDU: Would you please takeover?
HDU->FME: your area of expertise
FME: We implemented the "Guidelines of a Logical User Interface for Editing Bidirectional Text" which can be found here: http://imagic.weizmann.ac.il/~dov/Hebrew/logicUI24.htm (Feel free to verify!) The flag at the cursor reflects the current "cursor bidi level". It does _not_ show the current input method, since you can already see the current input mode in the language bar of your operating system. The flag is only shown if there are at least two different directional runs in your paragraph. I'll have to check if the flag is set correctly in the described situation (RTL paragraph, RTL word, LTR word, blank).
1.1RC3 on winXP: the caret directionality flag now seems to sync in the writer, but not in the HTML editor/impress etc.
.
SBA: According to the OpenOffice.org roadmap (see http://tools.openoffice.org/releases) this issue was retargeted to "OOo Later".
aminm -> FME: 'The flag at the cursor reflects the current "cursor bidi level". It does _not_ show the current input method, since you can already see the current input mode in the language bar of your operating system' Your statement contradicts itself. When you change input method you want to run a new bidi level. Why sould it remain unsynced until a different bidi level is encountered? Moreover, it goes against grain for MS Word users and causes confusion :(
FME->aminm: '[...] Your statement contradicts itself [...]' No, I cannot see a contradiction here. The cursor bidi level is independent from the current input method. The cursor bidi level is synced on user actions like inserting or deleting a character, or by cursor travelling. But you are right, changing of the input method could be defined as a user action, that trigges a resync of the cursor bidi level. But there is definitely no contradiction. I think you mix up the cursor bidi level and the text bidi level. 'Moreover, it goes against grain for MS Word users and causes confusion :(' Sorry, you are wrong. MS Word does not sync the cursor bidi level on changing the input method. Have a look at this example: someWERBEHtext Lower caps letters are English, upper case are Hebrew. If the cursor is located between the 'e' of 'some' and the 'H' of 'Hebrew', there are two possibilities, where the cursor should be painted (right from the 'e' of right from the 'H'). The cursor bidi level determines, which of these two positions to choose. Try it with MS Word. Does the cursor change its position on switching the input method between English and Hebrew? For a general description of what we implemented, have a look at "Guidelines of a Logical User Interface for Editing Bidirectional Text" which can be found here: http://imagic.weizmann.ac.il/~dov/Hebrew/logicUI24.htm If you think, these guidelines do not fit your needs, please file a 'request for enhancement'. But this issue is about a possible wrong cursor bidi level in a very special situation.
aminm->FME: If I understood your points right, you insist that the cursor should synch with bidi level of the text, irrespective of the current input method (or keyboard language). In contrary, MS Word takes the opposite approach: the cursor never syncs with the uderlying bidi level. It is a vertical bar when input method is English, even if it is traveling on a Hebrew or Farsi block AND a flag-shaped when input method is an RTL language. IMHO, this is a productivity feature. The end user doesn't care about the current bidi level. On the other hand, they want a visual clue as to the current input method. How many times you distract your attention to look down the bottom of screen for the current input method on a cluttered desktop? BTW, your link didn't work (error 404) :(
FME->aminm: "The end user doesn't care about the current bidi level." The current cursor bidi level is quite important to indicate the actual cursor position if the cursor is visually located between a RTL and a LTR portion of text. Again, feel free to file a request for enhancement or continue this discussion on a public mailing list (dev@l10n.openoffice.org). The comment section of this bug is definitely the wrong place.
OpenOffice.org Issue Tracker - Feedback Request. The Issue you raised has the status 'New' pending further action, but has not been updated within the last 4 years. Please consider re-testing with one of the latest versions of OOo, as the problem(s) may have already been addressed. Either use the recent stable version: http://download.openoffice.org/index.html or consider trying the new OOo 3 BETA (still in testing): http://download.openoffice.org/3.0beta/ Please report back the outcome so this Issue may be Closed or Progressed as necessary - otherwise it may be Resolved as Invalid in the future. You may also wish to search for (and note) any duplicates of this Issue that may have advanced further by checking the Issue Tracker: http://www.openoffice.org/issues/query.cgi Many thanks, Andrew Cleaning-up and Closing old Issues as part of: ~ The Grand Bug Squash, pre v3 ~ http://marketing.openoffice.org/3.0/announcementbeta.html