On Mon, 12 May 2025 16:33:59 GMT, Harshitha Onkar <hon...@openjdk.org> wrote:
>> Yeah, I think right now `\t` `\r` `\n` handling is done separately for each >> platform, and I think also separately for screen display vs. printing. >> >> As an example, this fix addresses the screen display side of things for >> macOS, but printing on macOS needs to be fixed separately (as can be seen >> when you run `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java`). I had >> a quick look at the corresponding macOS printing issue a few months ago and >> the fix wasn't obvious, especially given how that part of the code is >> organized (not really 1-to-1 with the other platforms). >> >> So I think `\t` `\r` `\n` handling is repeated quite a bit, and if we wanted >> to handle `0x2028` and `0x2029` exactly like we do `\t` `\r` `\n` then we'd >> need to change multiple places right now. >> >>> should we consider moving isIgnorableWhitespace() to common class - >>> CharToGlyphMapper instead of macOS specific src >> >> That sounds like it could be a good idea, but I don't have a sense of how >> likely it is to cause breakage elsewhere -- it'd be a matter of "do it and >> check for test regressions". Maybe you have a better gut feel for the >> likelihood of unintended side-effects? >> >> Note these two characters (`0x2028` and `0x2029`) are not default-ignorable, >> though. It sounds like we just don't want to render their glyphs, if they >> have any (similar to `\t` `\r` `\n`, which are also not default-ignorable). >> >> Over on PR #24412 Nikita has suggested an interesting change to >> `CharToGlyphMapper` and subclasses which might make this change easier, but >> I'd like some feedback from a reviewer or two before moving forward. The PR >> is complete from my POV, but we need some design direction (good as is, or >> needs tweaks, or need to use a different approach entirely, etc). > > Created a new JBS to track the issue on windows and linux - > [JDK-8356803](https://bugs.openjdk.org/browse/JDK-8356803) - Test > TextLayout/TestControls fails on windows & linux: line and paragraph > separator show a non-zero advance > There seems to be similar issue on Windows and Linux where the hexcode - > 0x2028 (line separator) and 0x2029 (paragraph separator) are shown with a > non-zero advance - `/java/awt/font/TextLayout/TestControls.java` Are these characters new? I can't remember there were any characters with non-zero width on Linux and Windows. I ran this test (or its previous version) on each HarfBuzz update. No, they were these characters are part of the existing test. I cannot reproduce this problem with 21.0.6. Nor is it reproducible with 21.0.7, the latest GA version of Java 21. Yet I the same picture as you attached on Windows on a recent build of mainline. If that's the case, it seems to be regression rather than an existing issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23665#discussion_r2085275529
