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.
|
Java