On Mon, 17 Feb 2025 14:06:53 GMT, Daniel Gredler <dgred...@openjdk.org> wrote:
> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters > are ignored when drawing text to a `Graphics2D` object. On macOS this is not > currently the case. > > See, for example, `CMap.getControlCodeGlyph(int, boolean)` or > `RasterPrinterJob.removeControlChars(String)`. > > This bug was found while running > `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS. > > The new test class passes on Linux, Windows and macOS. src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java line 138: > 136: return code == 0x0009 || code == 0x000a || code == 0x000d; > 137: } > 138: @prrace @gredler Following is an existing issue NOT related to the recent harfbuzz upgrade PR nor this issue fix but it is similar in nature so a separate JBS issue can be created to handle it. I wanted to discuss it before integrating the HB upgrade tomorrow. There seems to be similar issue on windows and linux where the hexcode - 0x2028 (line separator) and 0x2029 (paragraph separator) that are shown with a non-zero advance - `/java/awt/font/TextLayout/TestControls.java` **On Windows:** <img width="287" alt="image" src="https://github.com/user-attachments/assets/9eec9009-e3a5-49be-b505-619d041bfa3b"; /> **On Linux:** <img width="272" alt="image" src="https://github.com/user-attachments/assets/73a56d6d-53ec-4d6f-ad49-6fc13bdceea0"; /> If adding these codes (0x2028, 0x2029) to platform specific src code (I believe it is NativeGlyphMapper (linux) and WPathGraphics (windows)) fixes the above issue then should we consider moving isIgnorableWhitespace() to common class - `CharToGlyphMapper` instead of macOS specific src? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23665#discussion_r2074388646
