RFR: 8350203: [macos] Newlines and tabs are not ignored when drawing text to a Graphics2D object [v3]

[Alexey Ivanov]

On Mon, 12 May 2025 16:33:59 GMT, Harshitha Onkar <honkar at 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