FULL PRODUCT VERSION :


A DESCRIPTION OF THE PROBLEM :
The output displayed in Arabic Locale for the string : "\u202d\ufef2\ufe91\ufeae\ufecc\ufedf\ufe8e\ufe91"  is different in JDK1.3 and higher JDK's i.e. JDK1.4 and JDK1.5.  Though the output for the text:
"\ufef2\ufe91\ufeae\ufecc\ufedf\ufe8e\ufe91" is same across all JDK's but inserting the Left Right Override character (\u202D) introduces this difference.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Run the test case in JDK1.3
2. See the output in the two text fields.
3. In JDK1.3 both the text fields have same output.
4. In JDK1.4 the output in the two text fields differ, i.e. shape of the character differs. In left text field  we are inserting LRO character while in the right text field we are inserting the same text but for this LRO character.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The results in JDK1.4 and JDK1.5 should be similar to JDK1.3, i.e. the insertion of LRO character shouldn't alter the shape. It should only prevent flipping of the text.
ACTUAL -
I have seen that inserting LRO character changes the shape of the character in JDK1.4 and JDK1.5.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.ComponentOrientation;

import javax.swing.JFrame;
import javax.swing.JButton;
import javax.swing.JPanel;
import javax.swing.JTextField;

public class SwingTest2 extends JFrame
{
  public void init()
  {
    JPanel pane = new JPanel();
    
    _inputText1 = new JTextField("\u202d\ufef2\ufe91\ufeae\ufecc\ufedf\ufe8e\ufe91",12);
    _inputText1.setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT);
    pane.add(_inputText1);
    
    _inputText1 = new JTextField("\ufef2\ufe91\ufeae\ufecc\ufedf\ufe8e\ufe91",12);
    _inputText1.setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT);
    pane.add(_inputText1);
    setContentPane(pane);
    setVisible(true);
  }
    
  public static void main(String str[])
  {
    new SwingTest2().init();
  }
  private   JTextField _inputText1;
}



---------- END SOURCE ----------
Posted Date : 2007-12-06 19:01:10.0

N/A

Fix from Steven in the layout engine for ligature.
Posted Date : 2008-08-15 17:35:01.0

The original synopsis was
Effect of LRO character inconsistent with respect to JDK1.3

This is a bit misleading as to the actual problem.
The customer consistently uses LRO to disable bidi processing.
Once they went to 1.4 their actual problem is that a ligature
was forming which did not previously form.

They then observed that in 1.4 removing the LRO gave their
desired results. The text was in LRO and no ligature :
But in 1.5 and later this also didn't have any effect.

Here are the customer's words :
/@ Please have a look at the 1st textField display between 1.3 and 1.4, 1.5, /
/@ 1.6. The right most characters look different in the first textfield in 1.4 /
/@ and higher. I have also put a diff.gif which shows the actual issue in our /
/@ component ewt in 1.3, 1.5 and the correct behaviour in windows notepad./
/@ ./
/@ We are not using the same string with and without LRO character. We are /
/@ showing the text without LRO character only for comparison purpose. We want /
/@ to show how using the same string without LRO has not resulted in any change /
/@ in 1.4, whereas introducing LRO changes the display. Our problem is only with /
/@ LRO. We have our own BIDI logic for many years and we are making use of this /
/@ LRO character to prevent JDK from flipping and/or applying its own BIDI /
/@ logic, so that whatever chars we are sending to JDK appears as it is. Now /
/@ this issue is creating regressions for our clients who are upgrading from JDK /
/@ 1.3 to higher JDK. /

So there's the case they care about
 1) what happens when an LRO is present in 1.4 and later

And the case they don't care about (at least for now)
 2) what happens when there's no LRO in 1.5 and later

The root of (1) is that the JDK is forming a ligature
when processing precomposed Arabic Presentation forms.
ie the JDK is applying shaping: finding the nominal form glyphs
and applying features. In this case it should not do this.
One possible exception to this if the font doesn't contain the
Arabic presentation forms (B?) in the 'cmap' table, but that's not
the case here.

The root of (2) is that the ligature should not form, but
also prior to 1.5 the text was not being properly re-ordered.
It now is in 1.5 and later, so that part of the new behaviour is correct.
Posted Date : 2008-09-17 16:52:45.0