Hi, Could you review the fix? When non-English characters were printed from JTable on MacOS, CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, CTextPipe seems not support glyph with slot number of composite fonts.
The slot data mask of GlyphVector is 0xff000000. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn. This patch checks slot data of each character. If slot data exists, it will branch to GlyphVector's drawing path. Well, I couldn't create automatic test for this fix. This method seems to be called for printing only. I appreciate any advice. Tested java/awt and javax/swing on MacOS BigSur, and there was no regression. Regards, Toshio Nakamura ------------- Commit messages: - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled Changes: https://git.openjdk.java.net/jdk/pull/3619/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3619&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240756 Stats: 12 lines in 1 file changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3619.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3619/head:pull/3619 PR: https://git.openjdk.java.net/jdk/pull/3619
