On Tue, 24 Dec 2024 19:51:38 GMT, Phil Race <p...@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 Thanks, and understood. @alisenchung Is there anything else from your end? If not, can you approve? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22670#issuecomment-2613382354
