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. OK, it looks like we've got a constant conflict between Java's `INVISIBLE_GLYPH_ID` and HarfBuzz's `AAT::DELETED_GLYPH`, both of which are `0xFFFF`. This conflict only really matters when using an AAT font with a `morx` table, at which point `hb_ot_substitute_post` calls `hb_aat_layout_remove_deleted_glyphs`, which mis-identifies our invisible glyph as a deleted glyph which needs to be removed from the buffer. I'm not sure where to take it from here. Java has been using `0xFFFF` for quite some time to indicate invisible glyphs, so a change to the Java constant seems dangerous. There might be some wiggle room to use `0xFFFE`, since the comments in `CharToGlyphMapper` seem to indicate that it should also be treated as an invisible glyph? The glyph removal in HarfBuzz is wrapped by an `#ifndef HB_NO_AAT_SHAPE`, so I supposed we could disable AAT shaping in HarfBuzz, but that also seems drastic. Suggestions welcome! https://github.com/openjdk/jdk/blob/5cd4fe63768715ec7be32e248e05e611ea9b557d/src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java#L45 https://github.com/openjdk/jdk/blob/5cd4fe63768715ec7be32e248e05e611ea9b557d/src/java.desktop/share/native/libharfbuzz/hb-ot-shape.cc#L961 https://github.com/openjdk/jdk/blob/5cd4fe63768715ec7be32e248e05e611ea9b557d/src/java.desktop/share/native/libharfbuzz/hb-aat-layout-common.hh#L458 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2707061961
