RFR: 8361381: GlyphLayout behavior differs on JDK 11+ compared to JDK 8 [v3]

[Volker Simonis]

On Fri, 22 Aug 2025 18:59:05 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Great write-up. I haven't followed all of the rabbit trails linked, but I think I understand the overall issue.
> 

Thanks :)

> Regarding testing --
> 
> My understanding is that including any open source fonts in the tests requires a long licensing approval process and is best avoided. An alternative is to script the creation of a custom test font (see e.g. `GlyphVectorGsubTest`), but it might be tricky to get right in this case, where we're dealing with an unfamiliar language and so many substitutions.
> 
> One idea for testing would be to find all physical fonts which support Khmer at runtime (see e.g. `FormatCharAdvanceTest.getPhysicalFont(int)`, but with a `canDisplayUpTo` for the Khmer chars). Then for each supporting font, use the `LineBreakMeasurer` at a range of text widths (e.g. 100 - 500 pixels, at 10 pixel increments), and make sure that regardless of text width the measurer never leaves a single character on any line (except the last line, which would be OK). I know it's a bit hand-wavey, and quite black-box-ish, but it might be a good way to verify that the user-visible misbehavior that we're trying to fix is gone and doesn't resurface.

I think this is a little too simplistic. Single characters on a line may be fine, as long as they don't break a cluster. Without language knowledge and/or potential internals like HarfBuzz's [HB_GLYPH_FLAG_UNSAFE_TO_BREAK](https://harfbuzz.github.io/harfbuzz-hb-buffer.html#HB-GLYPH-FLAG-UNSAFE-TO-BREAK:CAPS) flag (which isn't exported to Java in OpenJDK) it will be hard to get this right.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26825#issuecomment-3221397959