-
Bug
-
Resolution: Unresolved
-
P3
-
None
-
11, 17, 21, 25
-
generic
-
generic
Filed on behalf of Ben Taylor <benty@amazon.com>
The below code sample changes behavior in unexpected ways on some platforms with JDK 11+ when compared to the same code run under JDK 8.
On JDK8 and JDK 11+ using Linux, the text is laid out as follows:
>Segment: បន្ទាប់ពីអ្នកធ្វើការប្ដឹងឧទ្ធរណ៍ យើងនឹងពិនិត្យករណីរបស់អ្នកឡើងវិញ 0 65
>Segment: ហើយផ្តល់សេចក្ដីសម្រេចដល់អ្នក។ 65 30
>Segment: ប្រសិនបើឱសថណាមួយដែលអ្នកបានស្នើសុំនៅតែត្រូវបានបដិសេធ 95 52
>Segment: អ្នកអាចស្នើសុំបណ្តឹងឧទ្ធរណ៍កម្រិតបន្ទាប់ 147 41
>Segment: ដែលជាការពិនិត្យឡើងវិញដោយឯករាជ្យលើករណីរបស់អ្នកដោយអ្នកត្រួតពិនិត្យនៅខាងក្ 188 71
>Segment: រៅគម្រោងរបស់អ្នក ។ ប្រសិនបើអ្នកមិនយល់ស្របនឹងសេចក្តីសម្រេចនោះ 259 61
>Segment: អ្នកនឹងមានសិទ្ធិប្តឹងឧទ្ធរណ៍បន្ថែមទៀត។ 320 39
>Segment: អ្នកនឹងទទួលបានដំណឹងអំពីសិទ្ធិប្តឹងឧទ្ធរណ៍របស់អ្នក ប្រសិនបើរឿងនេះកើតឡើង។ 359 71
However, with JDK11+ (including nightly builds of JDK 25) on macOS aarch64, it is laid out differently, causing the final line to exceed the requested width:
>Segment: បន្ទាប់ពីអ្នកធ្វើការប្ដឹងឧទ្ធរណ៍ យើងនឹងពិនិត្យករណីរបស់អ្នកឡើងវិញ ហើយផ្តល់សេចក្ដីសម្រេចដល់អ្នក។ 0 95
>Segment: ប្រសិនបើឱសថណាមួយដែលអ្នកបានស្នើសុំនៅតែ 95 37
>Segment: ត 132 1
>Segment: ្រូវបានបដិសេធ អ្នកអាចស្នើសុំបណ្តឹងឧទ្ធរណ៍កម្រិតបន្ទាប់ ដែលជាការពិនិត្យឡើងវិញដោយឯករាជ្យលើករណីរបស់អ្នកដោយអ្នកត្រួតពិនិត្យនៅខាងក្រៅគម្រោងរបស់អ្នក ។ ប្រសិនបើអ្នកមិនយល់ស្របនឹងសេចក្តីសម្រេចនោះ អ្នកនឹងមានសិទ្ធិប្តឹងឧទ្ធរណ៍បន្ថែមទៀត។ អ្នកនឹងទទួលបានដំណឹងអំពីសិទ្ធិប្តឹងឧទ្ធរណ៍របស់អ្នក ប្រសិនបើរឿងនេះកើតឡើង។ 133 297
We have a customer report that this issue also reproduces on Amazon Linux, but have not so far been able to replicate that behavior.
The first divergence seems to occur after the call to `er.layout()` here: https://github.com/openjdk/jdk8u-dev/blob/master/jdk/src/share/classes/sun/font/GlyphLayout.java#L466
JDK 11+ use harfbuzz to do the layout, while 8 uses the older ICU code path. I was not able to trace the issue further than this.
11+:
```
/* Native method to invoke harfbuzz layout engine */
private static native boolean
shape(Font2D font, FontStrike strike, float ptSize, float[] mat,
long pFace,
char[] chars, GVData data,
int script, int offset, int limit,
int baseIndex, Point2D.Float pt, int typo_flags, int slot);
```
8:
```
private static native void
nativeLayout(Font2D font, FontStrike strike, float[] mat, int gmask,
int baseIndex, char[] chars, int offset, int limit,
int min, int max, int script, int lang, int typo_flags,
Point2D.Float pt, GVData data, long upem, long layoutTables);
```
Reproducer: see KhmerTest.java
The below code sample changes behavior in unexpected ways on some platforms with JDK 11+ when compared to the same code run under JDK 8.
On JDK8 and JDK 11+ using Linux, the text is laid out as follows:
>Segment: បន្ទាប់ពីអ្នកធ្វើការប្ដឹងឧទ្ធរណ៍ យើងនឹងពិនិត្យករណីរបស់អ្នកឡើងវិញ 0 65
>Segment: ហើយផ្តល់សេចក្ដីសម្រេចដល់អ្នក។ 65 30
>Segment: ប្រសិនបើឱសថណាមួយដែលអ្នកបានស្នើសុំនៅតែត្រូវបានបដិសេធ 95 52
>Segment: អ្នកអាចស្នើសុំបណ្តឹងឧទ្ធរណ៍កម្រិតបន្ទាប់ 147 41
>Segment: ដែលជាការពិនិត្យឡើងវិញដោយឯករាជ្យលើករណីរបស់អ្នកដោយអ្នកត្រួតពិនិត្យនៅខាងក្ 188 71
>Segment: រៅគម្រោងរបស់អ្នក ។ ប្រសិនបើអ្នកមិនយល់ស្របនឹងសេចក្តីសម្រេចនោះ 259 61
>Segment: អ្នកនឹងមានសិទ្ធិប្តឹងឧទ្ធរណ៍បន្ថែមទៀត។ 320 39
>Segment: អ្នកនឹងទទួលបានដំណឹងអំពីសិទ្ធិប្តឹងឧទ្ធរណ៍របស់អ្នក ប្រសិនបើរឿងនេះកើតឡើង។ 359 71
However, with JDK11+ (including nightly builds of JDK 25) on macOS aarch64, it is laid out differently, causing the final line to exceed the requested width:
>Segment: បន្ទាប់ពីអ្នកធ្វើការប្ដឹងឧទ្ធរណ៍ យើងនឹងពិនិត្យករណីរបស់អ្នកឡើងវិញ ហើយផ្តល់សេចក្ដីសម្រេចដល់អ្នក។ 0 95
>Segment: ប្រសិនបើឱសថណាមួយដែលអ្នកបានស្នើសុំនៅតែ 95 37
>Segment: ត 132 1
>Segment: ្រូវបានបដិសេធ អ្នកអាចស្នើសុំបណ្តឹងឧទ្ធរណ៍កម្រិតបន្ទាប់ ដែលជាការពិនិត្យឡើងវិញដោយឯករាជ្យលើករណីរបស់អ្នកដោយអ្នកត្រួតពិនិត្យនៅខាងក្រៅគម្រោងរបស់អ្នក ។ ប្រសិនបើអ្នកមិនយល់ស្របនឹងសេចក្តីសម្រេចនោះ អ្នកនឹងមានសិទ្ធិប្តឹងឧទ្ធរណ៍បន្ថែមទៀត។ អ្នកនឹងទទួលបានដំណឹងអំពីសិទ្ធិប្តឹងឧទ្ធរណ៍របស់អ្នក ប្រសិនបើរឿងនេះកើតឡើង។ 133 297
We have a customer report that this issue also reproduces on Amazon Linux, but have not so far been able to replicate that behavior.
The first divergence seems to occur after the call to `er.layout()` here: https://github.com/openjdk/jdk8u-dev/blob/master/jdk/src/share/classes/sun/font/GlyphLayout.java#L466
JDK 11+ use harfbuzz to do the layout, while 8 uses the older ICU code path. I was not able to trace the issue further than this.
11+:
```
/* Native method to invoke harfbuzz layout engine */
private static native boolean
shape(Font2D font, FontStrike strike, float ptSize, float[] mat,
long pFace,
char[] chars, GVData data,
int script, int offset, int limit,
int baseIndex, Point2D.Float pt, int typo_flags, int slot);
```
8:
```
private static native void
nativeLayout(Font2D font, FontStrike strike, float[] mat, int gmask,
int baseIndex, char[] chars, int offset, int limit,
int min, int max, int script, int lang, int typo_flags,
Point2D.Float pt, GVData data, long upem, long layoutTables);
```
Reproducer: see KhmerTest.java