JDK-8189858 : [macosx] Arabic character cannot be rendered on MacOS X
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 8u152,9
  • Priority: P2
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2017-10-24
  • Updated: 2017-10-27
  • Resolved: 2017-10-24
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.
JDK 10
10Resolved
Related Reports
Relates :  
JDK-7162125 - [macosx] A font has different behaviour for ligatures depending on its creation mode
Relates :  
JDK-8147002 - [macosx] Arabic character cannot be rendered on MacOS X
Description
Testsuite name: 2D
Test name(s): Attached testcase (FontDrawingTest) 
Product(s) tested: JDK 8 u162 b01
OS/architecture: Mac OS (x64)

Reproducible: Always

Is it a Regression: Yes, Test passed for jdk1.8.0_152b16, but failed for JDK 8 u162 b01
Comments
Hi Phil, I have filed a separate bug for AIOBE failure: JDK-8190280
27-10-2017
>Due to this f2d_onscreen_arabic tonga test is also failing for 8 u162 b01 which is passing for 1.8.0_152b16 > RULE "2D_AutoFont2DTest/f2d_onscreen_arabic" Exception java.lang.ArrayIndexOutOfBoundsException: ... Huh ?? What does an AIOBE have to do with this (non-)bug ?
26-10-2017
There is no bug here but it needs some explanation as to what changed. This test looked extremely familiar .. it was also used in a report against JDK 9 b96 over 10 months ago : https://bugs.openjdk.java.net/browse/JDK-8147002 There the actual rendering was a missing glyph ! That earlier bug was introduced somewhat innocently by the fix for https://bugs.openjdk.java.net/browse/JDK-7162125 : "A font has different behaviour for ligatures depending on its creation mode" which was a severe problem that layout was not being given access to font tables. When that was fixed it was backported to 8u-dev and only appeared in 8u162b01. Then the missing glyph bug https://bugs.openjdk.java.net/browse/JDK-8147002 was reported and it was discovered to be because previously An Apple JRS* method there just for JDK was apparently including the JRE fonts as fall backs. This was no longer being found as we were now using the proper CFont cascading list and it will not include JRE fonts. Since there is no ITALIC font in the cascading list with this glyph we got a missing glyph. The fix was to include Lucida Sans from the JDK as an explicit fallback. Details here: http://mail.openjdk.java.net/pipermail/2d-dev/2017-February/008186.html This new bug (8189858) was not seen in any previous build since 8u162 was not built until recently so both 7162125 and 8147002 made their first appearance in 8u162 b01 So the upshot is a different font is now used in this case. And so it looks different .. but is still a legitimate representation of the Arabic Alef
24-10-2017
Due to this f2d_onscreen_arabic tonga test is also failing for 8 u162 b01 which is passing for 1.8.0_152b16 RULE "2D_AutoFont2DTest/f2d_onscreen_arabic" Exception java.lang.ArrayIndexOutOfBoundsException: ... RULE "2D_AutoFont2DTest/f2d_onscreen_arabic" ExitCode 255
24-10-2017
test also fails for 9b180
24-10-2017