Community
Participate
Working Groups
Build Identifier: 20100917-0705 Project name containing mixed Arabic and English Text and Numerals display numerals in the wrong order. Reproducible: Always Steps to Reproduce: 1. Set system locale and language to Arabic-Egypt. 2. Open Eclipse IDE. Choose Arabic name for the workspace folder. 3. Choose Window>>Preferences>>General>>Workspace. 4. Change the text file encoding to UTF-8. Click OK to save the changes. 5. Create a new java project that has a title of the following series "ArabicEnglishNumberArabic". 6. Observe the project name in the project Explorer. Expected Result: Project name should be correctly displayed in the same order it was entered. Actual Result: Numerals are displayed at the end of the project name although this is not the order it should be displayed in.
Example project name is "واحدtwo3أربعة"
Can you please attach a sample project (or workspace) that shows it? Does it work if you create a simple/general project? Does it work in the Package Explorer?
Created attachment 186007 [details] Sample Java project
It doesn't work if you create a simple/general project. This happens in the Package Explorer as well.
The rendering with "3" at the end is used everywhere in the Windows Explorer and in Eclipse (even in the Java Editor when I create a type with this name).
(In reply to comment #5) > The rendering with "3" at the end is used everywhere in the Windows Explorer > and in Eclipse (even in the Java Editor when I create a type with this name). Maham, can you confirm that?
Notepad also puts 3 at the end, but Wordpad and Firefox render it as *two3*. Looks like a problem that should be solved in TextProcessor or its successor, if at all. Moving to SWT, since this problem should also be addressed by the solution for bug 230854.
Comment 5 confirmed.
Notepad or SWT Text reorder text according to the bidi algorithm variant known as Windows-compatible algorithm, while Firefox, IE or Wordpad are compliant with the Unicode standard here. It won't be possible to get the desired text appearance in a Text widget without using Unicode control characters. An acceptable solution can be attaching a Segment Listener to the Text, so this bug likely depends on bug 230854.
Sorry - Markus already mentioned that this problem should also be addressed by the solution for bug 230854.
However, some work would have to be done also at the application level to trigger SegmentListener. So this bug has dependency - but won't be fully covered by bug 230854.
You don't need bidi segments listener to solve this problem (in other words, you don't need bug 230854). The text in this case is read-only. You need TextProcessor (?) Please move this problem where it belongs. Thank you.
OK, moving to Equinox/Components, since the concrete case of label rendering is in TextProcessor (although any change there will make the rendering diverge from what is seen in the Text widget). When I launch with -nl ar, the UI is RTL and TextProcessor is active, but the "3" is still rendered at the end. In this setup, the unprocessed name is rendered with "two3" in the middle but with "أربعة" on the left and "واحد" on the right. That's also how it looks like when I rename a file with such a name in the Windows Explorer and then press Ctrl+Right_Shift. I don't know which form is to be considered "correct". See also bug 229010 and bug 183164.
Sorry, I thought this bug was reported against an input field (it does exist there too though...). As I understand it, it's related to the following Windows feature: in *LTR* orientation, when an Arabic-European number is followed by an RTL character, the order of the two characters gets reversed in display. paragraph level: 0 buffer: EN1R1 Windows-compatible display: R1EN1 Unicode standard-compatible display: EN1R1 If this is the problem indeed, to comply with the standard, we need to insert an LRM character (or add a bidi segment if SegmentListener is available) between the number and the RTL character. Unfortunately, TextProcessor won't help here (moreover, appearance in RTL/bidi locales, for which TextProcessor is enabled exclusively, is correct).
(In reply to comment #14) > in *LTR* orientation, when an Arabic-European number is followed by an RTL > character, the order of the two characters gets reversed in display. This also happens in *RTL* orientation of course, but in that case it's standard-compliant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
