RFR: 8208377: Soft hyphens render if not using TextLayout

[Daniel Gredler]

On Tue, 24 Dec 2024 19:51:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> @prrace, @alisenchung Thanks for your comments!
>> 
>>> What automated checks?
>> 
>> You're right, I had vastly overestimated the scope of the automated tier1 test runs on GitHub. I'll keep that in mind.
>> 
>>> you will need to find machines to run all the tests yourself, across all platforms
>> 
>> I was able to get my hands on a Mac, and have updated the Mac-specific code as well. I'm now covered on Linux, Windows and Mac. But if I ever need to test on AIX, I'll know I took a wrong turn somewhere.
>> 
>>> One thing this fix does is change the logic which we have today [...] TO Never mind what the font says, these are always invisible and zero width
>> 
>> Correct, this is the core of the issue in this bug: there are fonts containing glyphs for e.g. soft hyphen, but these glyphs should not be displayed because these characters are never displayed in and of themselves. This seems to match how HarfBuzz behaves, but the current Java logic does not mirror it, leading to inconsistent results depending on the internal code paths used to render or measure text.
>> 
>> See the Unicode description of "default-ignorable" characters (http://www.unicode.org/L2/L2002/02368-default-ignorable.html):
>> 
>>> Default-ignorable code points are those that should be ignored by default in rendering (unless explicitly supported). They have no visible glyph or advance width in and of themselves, although they may affect the display, positioning, or adornment of adjacent or surrounding characters. [...] This does not imply that default-ignorable code points must always be invisible: an implementation can show a visible glyph on request, such as in a "Show Hidden" mode. A particular use of a "Show Hidden" mode is to show a visible indication of "misplaced" or "ineffectual" formatting codes. [...] There are other characters that have no visible glyphs: the white-space characters. These typically have advance-width, however. The line separation characters such as CR do not clearly exhibit this advance-width since they are always at the end of a line, but  in most GUIs show a visible advance width when selected.
>> 
>> The `FontUtilities.isDefaultIgnorable` function matches the HarfBuzz classification, including a few exceptions made for the sake of Uniscribe compatibility:
>> 
>> https://github.com/openjdk/jdk/blob/b2811a0ccd9664d11770980c47424ab6723cbbc9/src/java.desktop/share/native/libharfbuzz/hb-unicode.hh#L128
>> 
>>> you added 0x200B
>> 
>> Correct, zero-width space is defined as having the Defa...
>
>> I did have one thought that I wanted to run by you guys: it could be argued that FontUtilities.isDefaultIgnorable should be native and should just delegate to HarfBuzz's is_default_ignorable. That's not the approach I decided to take, but let me know if you disagree.
> 
> ah I guess that's what the hb related comment was about. It wasn't clear.
> 
> 
> FYI  I won't be able to finish reviewing this until January.

@prrace Gentle reminder that this review is still pending. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/22670#issuecomment-2605570014