Community
Participate
Working Groups
In RTL orientation, there are some strings that should maintain basic LTR reading order - examples are file paths, URLs and file associations. Even though Eclipse provides full BiDi support as of 3.1, these strings are special cases and so are not rendered correctly due to the presence of neutral characters - that is, characters whose directionality is determined based on the directionality of its surrounding text. See http://www.unicode.org/reports/tr9/ for the full specification on the Bidirectional algorithm. The Eclipse platform now provides API that will render these strings correctly in RTL locales (Hebrew and Arabic) by inserting directional marker characters into the string in the appropriate places. Strings that utilize this API are intended to have an overall reading order of left to right (e.g.file paths, file associations, URLs) and are segmented according to delimiter characters where each segment will have the usual BiDi rendering algorithm applied to it. To use this API, call org.eclipse.osgi.util.TextProcessor.process(String, String) where the first string is the string to manipulate (e.g. a file path, URL, etc) and the second string is a string of delimiters which define how the string should be segmented. Example 1 string=d:\AAA\bbb\CCC\ddd.html delimiter=".:\" Example 2 string=*.html delimiter="*." Example 3 http://AAA/bbb/ccc.html delimiter=".:/" Since file paths and URLs will likely be the most common use case for this API, a set of default delimiters="./\:" is provided so a call to org.eclipse.osgi.util.TextProcessor.process(String) is all that is required in these cases. Test cases to check for: URL example to test = http:\\abc\ABC where lower case is Latin (e.g. English) and upper case is Hebrew/Arabic Without using the new API, it renders CBA\http:\\abc File path to test = d:\abc\ABC where lower case is Latin (e.g. English) and upper case is Hebrew/Arabic Without using the new API, it renders CBA\d:\abc Originating from bug 119517. Please do a complete review of the UI elements of this component in order to identify and call the new API for all occurrences of file/directory paths, URLs, file associations and any other strings that should have overall left to right reading order. Check views, wizards, property and preference pages, and dialogs as a starting point. Some examples of this problem that I have found in this component thus far are: *New Variable Classpath Entry dialog: variable paths in list aren't rendered correctly *Javadoc Location property page: location field *Add JRE dialog: JRE Home directory and JRE System libraries list (paths in list don't render correctly) *Classpath variables preference page: paths in listed variables aren't rendered correctly *Installed JREs preference page: Location column (path) *New Java Project from Ant build file wizard: Ant buildfile field *New Java project, Java settings page, Libraries tab: paths in list aren't rendered correctly
Created attachment 35775 [details] screen shots of examples of incorrect rendering
I should mention that this problem seems to be specific only to Windows. I am unsure what Mac does, haven't checked yet. Linux (GTK, at least) seems to render properly.
> I should mention that this problem seems to be specific only to Windows. I am > unsure what Mac does, haven't checked yet. Linux (GTK, at least) seems to > render properly. Shouldn't this be fixed in SWT then?
This is not an SWT bug. I mentioned that you will not see the problem on Linux becaue I originally marked the bug against all platforms, which was untrue. The reason it is not an SWT bug is because certain strings (like URLs and file paths) have semantic meaning that goes beyond what the basic BiDi rendering algorithm can provide. In this case, the overall reading order of (for example) a file path or URL is left to right, but each segment of the file path should still follow the basic BiDi algorithm. In order to achieve the intended rendering of the string we need to insert the correct directional marker characters into the string.
Have to decide if we do this for 3.2
Not for 3.2
I filed bug 146220 to request label renderers for paths where RTL/LRT issues can be encapsulated and not everybody has to know all the details.
not planed for 3.4
sorry, not planed for 3.3, I meant.
Classpath variables preference page is bug 181954 (fixed). I don't think we can fix paths or Java element labels in input fields. User input will distroy our escaping. Best would be if we can mark an input field as LTR as a whole. Dani and I made a pass over the UI and are now processing all Java element labels. Please file separate bugs if you find something new.
