Community
Participate
Working Groups
the cursor is in a place, and the typed characters appear in another place. Steps to recreate the problem: 1. Create a file using the WYSIWYG example file wizard. 2. Try inserting and deleting mixed Arabic and English text. Expected bevaviour: Typed characters and the curser should be in the same place. Problem: the typed characters appear in a distance from the curser. please see the screen shot
Created attachment 36835 [details] screen shot
That's because the cursor's at a transition point between an RTL and an LTR run. If you type an LTR-typed character, it will appear where the cursor is. Ahmed, can you reproduce this same behaviour in Microsoft Word?
This is not because the curser is at a transition point. Please try inserting the following text: - English <space> "." - Press home key. - The curser will be placed to the left of the dot while it is expected to be placed to the left of E as E is the beginning of the buffer. Also, please type the following text: English Tree Banana - Now place the curser to the right of the letter 'h'. - Change the keyboard layout to Arabic. (Alt+Left Shift) - Insert any Arabic text, say, ABCD. You will see that the curser is in one position and the Arabic text appears in another position. Please see the attached screen capture for further illustration.
Created attachment 37126 [details] Screen capture of example "Englsih Banana Tree"
Pratik - were you going to look into this problem? Can I assign the bugzilla to you?
Cherie - you'll have to have a look at this...
This seems to be a problem with not only GEF but even text editors and dialogs in Eclipse. Here is one way to reproduce in Eclipse: To reproduce: - Start an Eclipse runtime with options -dir rtl - Create a project called "abc". - Right-click project > Refactor > Rename. - In the dialog, put the text cursor between the 'a' and the 'b'. - Change the input keyboard to arabic and enter a key. - The text is now displayed as "bc?a". The arabic character was put in the wrong spot. I'm not sure which component should own this. Probably SWT?
Ok, it seems that I misinterpreted the issue. The text is supposed to jump to another location, but the cursor is supposed to move with it. Note: This works fine in GMF, just not in the WYSIWYG editor.
Downgrading the priority for the following reason: - It only occurs in right-to-left mode when mixing right-to-left and left-to-right languages. How often are clients going to be working in right-to-left mode? - The issue may be specific to the GEF WYSIWYG example or specific to GEF's TextLayout. It does not occur in text on notes in GMF so it is not such a widespread problem. Notes for when an attempt is made to resolve this defect again: - I spent two days investigating this, but with little knowledge of BIDI issues and GEF I didn't make much progress. - It appears the location of the cursor is reversed from where it should be. - Good points for debugging are: ChangeString.getResultingLocation(), Textflow.GetCaretPlacement().
Removing target milestone. This defect will be prioritized against other outstanding defects in GMF.
(In reply to comment #7) This is actually the expected behavior. A good correct reference is Notepad. The scenario you described works as expected. (you can try it on notepad) The incorrect behavior is detailed in (comment #3) which is very different than your scenario.
(In reply to comment #9) There seems to be a problem in the function that maps the logical indexes (Characters positions in storage) to visual ones (Characters positions on display) and vice versa. Consider the example of mixed Arabic and English text below, where characters in caps represent Arabic characters: When a user types the string "engABC", it is displayed as "engCBA". Hence, in storage array, the character 'A’ has index 3, while in visual array (used for display), it has the index 5.
This problem is marked as a serious bug. Can it be fixed before TVT start ?
In response to comment#13: we downgraded this defect based on our evaluation. See comment #9. It is unlikely to be addressed before TVT.
Defer BIDI issues to the next release.
