On Fri, 21 Feb 2025 21:13:16 GMT, Daniel Gredler <dgred...@openjdk.org> wrote:

>> When a string contains zero-width characters, `LineBreakMeasurer` calculates 
>> line breaks incorrectly.
>> 
>> The root cause appears to be that `LineBreakMeasurer` eventually calls into 
>> `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from 
>> the glyph IDs. However, HarfBuzz's default treatment of zero-width 
>> characters is to provide the glyph ID of the space character (`U+0020`) 
>> combined with an artificial zero advance (not the font's space glyph 
>> advance). Unaware of HarfBuzz's sleight of hand, 
>> `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the 
>> space glyph (since that was the glyph ID returned) and provides these back 
>> up the call chain to `LineBreakMeasurer` et al.
>> 
>> I think the correct fix is to use `hb_buffer_set_invisible_glyph` to 
>> register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching 
>> `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).
>> 
>> I haven't seen any unwanted side effects, but there is a risk, since this is 
>> changing the global HarfBuzz configuration.
>> 
>> For more information on HarfBuzz's behavior in this area, see: 
>> https://harfbuzz.github.io/setting-buffer-properties.html
>
> Daniel Gredler has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Update copyright year

I am seeing an existing test fail on macOS with this change
java/awt/font/GlyphVector/NLGlyphTest.java

java NLGlyphTest 
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 0 
out of bounds for length 0
        at 
java.desktop/sun.font.StandardGlyphVector.getGlyphCode(StandardGlyphVector.java:311)
        at NLGlyphTest.main(NLGlyphTest.java:46)

I don't know why, but it seems like this 
          char[] chs = { '\n' };
          GlyphVector lgv = font.layoutGlyphVector(frc, chs, 0, 1, 0);
results in a GV with zero glyphs

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

PR Comment: https://git.openjdk.org/jdk/pull/23603#issuecomment-2705084008

Reply via email to