<AWT Dev> RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled

Phil Race prr at openjdk.java.net
Thu May 6 21:26:51 UTC 2021

On Thu, 22 Apr 2021 09:21:20 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

> 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

The immediately next method in this file, drawGlyphVector(..) surely would have the same problem ?
And then the drawChars method too ?

Does this not in fact affect all code points for which the slot != 0 ?
Do we really want to print all code points from slot > 0 as shapes ? 

And if this code isn't expecting to handle composite fonts, how did we get here with one ?
Or maybe the problem is that the printing path code needs to handle this downstream not upstream ?


PR: https://git.openjdk.java.net/jdk/pull/3619

More information about the awt-dev mailing list