On Fri, 22 Aug 2025 18:59:05 GMT, Daniel Gredler <dgred...@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
