Q: How can one get the most of the Bidi support in Java?
A: Here are some ways to get the most of the currently existing Bidi support in Java:
1. Use IBM Java 2, since all Java Bidi enablement was done starting with JDK 1.2 (on which IBM Java 2 is based). In JDK1.1.x, whatever Bidi support existed in AWT was dependent on the OS. It is best to use JDK 1.4 or later since it has the most complete Bidi support. TextDrawing methods under Java 2 use the TextLayout Bidi functionality, so text is drawn with the correct order and shape. Also, text dimension calculations are based on the displayed string and not on the stored one, providing more accurate results.
2. Develop applications using Swing under JDK 1.2 or higher. Swing is Bidi-enabled itself, so applications built using Swing don't require a Bidi-enabled operating system, and Swing behavior is platform independent.
3. Use the ComponentOrientation class to mirror the geometry of the application. The default orientation for a given locale can be queried using ComponentOrientation.getOrientation(ResourceBundle bdl).
Note: This has been deprecated. As of J2SE 1.4, use getOrientation (java.util.Locale).
4. Use FlowLayout and BorderLayout Managers to get the geometry mirroring according to the ComponentOrientation. For BorderLayout use BorderLayout.BEFORE_LINE_BEGINS and BorderLayout.AFTER_LINE_ENDS instead of EAST and WEST, which will make the layout sensitive to the ComponentOrientation setting.
5. In JDK 1.4 use the new method applyComponentOrientation to propagate the ComponentOrientation to all of a container's children.
6. For Horizontal alignment and text location, use LEADING and TRAILING instead of LEFT and RIGHT, in order to get the position mirrored properly according to the ComponentOrientation.
7. Use the NumericShaper class to shape digits before they are displayed, to overcome Java's limitations in not having an attribute or methods to set the number shape in Swing components.
8. For Swing to properly handle Arabic and Hebrew data on an English operating system, you must add the proper fonts to the font.properties file. The font.properties files that come with Java 2 usually have the proper fonts (they do for Arabic and Hebrew).
9. You can run the java applications in any desired locale by defining properties on the command line, e.g.
'java -Duser.region=AR -Duser.language=ar myApp [args]'.
This will use the font.properties file defined for that locale. You still need to have the fonts referenced by the font.properties file. To enter data, you need an input method that supports that locale.
10. Programs can be written to use the Java Lucida fonts, which have full support for Arabic and Hebrew. In this way you don't depend on the font.properties file. Typically, though, Swing and other components start off with the default font as defined in the font.properties file, so you have to set the font on the Component before you use it.
11. If your OS does not provide the required input method, you can develop one in Java using the java.awt.im.spi package. This input method has to be installed as a system extension in the user's JVM. This can be done by the system administrator, or an installer program can be given permission to modify the JVM if the proper security procedures are followed.
Q: How are the LamAlef Characters dealt on different platforms?
A: LamAlef characters are stored as one ligature on iSeries™, (in Code Page 420), but on Microsoft Windows (in Code Page 1255 or in UTF-8), LamAlef characters are stored as two separate characters (Lam &Alef), because the for Arabic has no unique code point for representing the ligature. Each LamAlef character must be changed into Lam &Alef characters. This means that we must consider whether we will expand the string or use spaces that may be found at the begining or at the end of the buffer to accomodate the added characters.
Here is an example of two strings: the input string is in Visual mode (as usual for iSeries strings) including a LamAlef ligature occurrence and the output string is in Implicit mode (as usual for Windows strings). In this example, we used the space at the begin of the buffer to convert the LamAlef character to become two characters, Lam & Alef:
Note: The input contains Arabic shaped characters, while the output is in base shapes.
Q: What are some general tips for Bidi support on the WebSphere® Application Server (WAS)?:
A: Each Web page should contain the Arabic or Hebrew Codepage (Windows1256, Windows 1255, iso-8859-6, iso-8859-8-i or UTF-8 ). Listed below is how to specify the code page for the Web page.
For the HTML page, add a META tag similar to the following within the header:
For Arabic:
< head>
< META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8 or windows-1256 or iso-8859-6">
< /head>
For Hebrew:
< head>
< META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8 or windows-1255 or iso-8859-8-i">
< /head>
For the Servlet, add the following two lines:
For Arabic:
response.setContentType("text/html ;charset=windows-1256 or iso-8859-6");
For Hebrew:
response.setContentType("text/html ;charset=windows-1255 or iso-8859-8-i");
or
response.setContentType("text/html ;charset=UTF-8");
PrintWriter out=res.getWriter();
For the JSP, add the following line:
For Arabic:
< %@ page contentType="text/html; charSet=windows-1256 or iso-8859-6" %>
For Hebrew:
< %@ page contentType="text/html; charSet=windows-1255 or iso-8859-8-i" %
Sometimes you need to force the WebSphere Application Server to work with specific character for specific locales. For example, in WAS V4 and V5 the default encoding for the Arabic locales is ISO-8859-6. You can change the default character encoding for each locale by updating the file "WAS_HOME\properties\encoding.properties", but this will affect all the hosted application servers. | 
