Wednesday, March 28, 2007
TextProcessor and BIDI
Lets start from the javadoc:
"This class is used to process strings that have special semantic meaning (such as file paths) in RTL-oriented locales so that they render in a way that does not corrupt the semantic meaning of the string but also maintains compliance with the Unicode BiDi algorithm of rendering Bidirectional text.
Processing of the string is done by breaking it down into segments that are specified by a set of user provided delimiters. Directional punctuation characters are injected into the string in order to ensure the string retains its semantic meaning and conforms with the Unicode BiDi algorithm within each segment."
So where do I use it?
Anywhere where the string you are displaying has a series of segments where the ordering of the segments is the same no matter what language you are displaying. The most common examples are file associations, file paths, URLS and URIs.
When is it processing Strings?
The TextProcessor will do bidirectional String processing anytime you are running with your Locale set to one of the four bidirectional languages (Arabic, Farsi, Hebrew or Urdu).
Will it process if my layout is right to left?
Only if your Locale is one of the languages mentioned above.
Do these extra characters get picked up if I copy the String?
Yes. In some applications that do not try and interpret these characters (such as Notepad) they will show up as control characters.
How do I strip the extra directional characters out?
TextProcessor#deprocess(String)will allow you to remove them.
What should I do about input fields for these Strings?
The Eclipse Platform tries to avoid creating behaviour that is inconsistent with the operating system as much as possible. As a result we do not process the input String - the user gets whatever the operating system wants to show them.
Once again we would love to hear from anyone who is using our bidirectional support day to day to give us more feedback.
Monday, March 26, 2007
Bidirectional Support FAQ
1) What is the difference between using -dir rtl and -nl iw?
-dir rtl was a command line parameter that Help was using before the workbench added it's general BIDI support in 3.1. When we added the BIDI support ourselves we continued to support the old flag but we also felt that the -nl command line parameter made more sense. If you are using a Arabic, Farsi, Hebrew or Urdu locale as the argument to the -nl parameter you will get right to left support.
The TextProcessor does not support the -dir rtl parameter so it is recommended that you use the -nl parameter to get all of the bidi support. Note that TextProcessor will process BIDI strings whenever the Locale is bidirectional whether or not the Locale was set by -nl or taken from the OS.
So if you use -dir rtl your orientation will be set to right to left but your paths etc. will not use the text processing.
2) What is the difference between TextProcessor and Window#getDefaultOrientation ?
TextProcessor is a class supplied by OSGi to used to process strings that have special semantic meaning (such as file paths) in RTL-oriented locales so that they render in a way that does not corrupt the semantic meaning of the string but also maintains compliance with the Unicode BiDi algorithm of rendering Bidirectional text. (from the javadoc).
So for instance http://www.eclipse.org/
org.eclipse.jface.Window#getDefaultOrientation is a method used to determine the default orientation for windows. If it is not set the default value will be unspecified (SWT#NONE) (also from the javadoc).
Dialogs, Windows, IWorkbenchParts and FormToolkits use this value to determine their default orientation. All of these classes allow the orientation to be overridden.
3) Why do I not get bidirectional text processing in left to right orientations?
Using the TextProcessor to evaluate paths is slower than not processing them at all (of course). For performance reasons we do not use
4) How do I set my inputs to use bidirectional support?
All input processing is done using the platform widgets. Eclipse generally does not try and work differently than the OS so we use the OS input methods.
5) What happens if I use multiple direction parameters?
There is a precedence of these parameters. As document in the help at org.eclipse.platform.doc.isv/reference/misc/bidi.html:
The orientation of the workbench is determined in one of the following ways (in order of priority):
- -dir command line parameter. If the -dir command line option is used this will be the default orientation. Valid values are -dir rtl or -dir ltr.
- system properties. If the system property eclipse.orientation is set this will be used. The recognized values of this property are the same as the -dir command line argument.
- -nl command line parameter. If the -nl option is used and the language is Arabic, Farsi, Hebrew or Urdu the orientation will be right to left.
- Failing all of the above, the platform defaults to a left to right orientation.
- -dir rtl will give you right to left windows but no text processing
- -nl fa will give you right to left windows and text processing
- -nl ur -dir ltr will give you left to right windows and text processing
- Starting Eclipse in a bidirectional Locale with no arguments will give you left to right windows and text processing
6) Is right to left ever the default?
No. When we initially did this work we made right to left the default for users in the right to left locales but the overwhelming response was that they developed in left to right and then we should only switch orientation if explicitly asked to.
So if you start Eclipse on an Urdu machine with no command line arguments you will get left to right orientation. If you start Eclipse using the command line argument -nl ur on the same machine you will get right to left orientation.
7) Who uses this support?
This is actually a question for you. We know there are lots of users who use Eclipse left to right in a right to left locale but we are interesting in hearing from
- Users who use right to left for their Eclipse development - especially if they want some right to left support changes in JDT or EMF.
- Users who use left to right but frequently have to deal with right to left strings and find the lack of bidirectional text support problematic