JDK-6638533 : Layout should not apply shaping to precomposed arabic presentation form glyphs.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.2
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-12-06
  • Updated: 2011-04-05
  • Resolved: 2011-04-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other JDK 6 JDK 7
5.0u16-revFixed 5.0u17Fixed 6u12Fixed 7 b123Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
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 ----------

Comments
EVALUATION This was not directly fixed in 7 but was integrated into 7 b123 as a byproduct of the ICU layout engine update : 6886358 That ICU version already contained the 6u12 version of the fix. But because it hasn't been directly fixed we are lacking the regression test : test/java/awt/font/TextLayout/TestLORLigature.java which was pushed into 6u12. I'll ask the R/E for this bug to push that into JDK 7.
24-03-2011

EVALUATION 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.
17-09-2008

EVALUATION Fix from Steven in the layout engine for ligature.
15-08-2008