<AWT Dev> RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
serb at openjdk.java.net
Fri Apr 23 06:52:25 UTC 2021
On Thu, 22 Apr 2021 09:21:20 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:
> 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.
> Toshio Nakamura
As far as I understand it is not directly related to the JTable and the bug is reproduced if some specific font is used when any text is printed? Did you check why the CTextPipe does not support it directly? It looks like the JavaCT_DrawGlyphVector uses pure core graphics, which I think should support this font?
More information about the awt-dev