RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled [v3]

[Toshio Nakamura]

On Thu, 21 Oct 2021 00:57:47 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.
>
> Toshio Nakamura has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
>  - revert previous proposal
>  - Merge branch 'master' into 8240756
>  - 2nd proposal
>  - Revert previous change
>  - Merge branch 'master' into 8240756
>    merge master
>  - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled

Let me explain the fix a little bit more.
The native API for drawing with glyph vector, `CGContextShowGlyphsAtPoint()`, cannot set multiple fonts.
So, the latest fix (c52a9f) switches the target font by Java code side, when 'slot' data is not 0, which means non-default font is used.
This is completely changed from my previous proposals.

Also, I could finally create an automated test case. It compares drawing results by `SunGraphics2D.drawGlyphVector()` and `SunGraphics2D.drawString()` under `OSXOffScreenSurfaceData`. Since drawing positions can be different between these methods even if English characters, it tries to compare pixel counts. This can detect to use different glyphs.

I appreciate any comments.

-------------

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