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

[Toshio Nakamura]

On Mon, 14 Jun 2021 19:26:46 GMT, Phil Race <prr at openjdk.org> wrote:

>>> 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?
>> 
>> Hi Sergey, Thank you for the comments.
>> 
>> JTable is not directly related, but it has child JComponents under texts. It's the trigger to meet the conditions to call the function.
>> 
>> In this case, the font was specified as "LucidaGrande" or "Dialog" by L&F. Non English character to print is another condition.
>> sun.font.CFont creates a composite font by the standard Mac cascade list. In my environment, font[4] is Japanese font, even if it's CFont("LucidaGrande").
>> 
>> CTextPipe.doDrawGlyphs uses one strike pointer, which is for one font. To support composite fonts, I think CTextPipe needs to handle array of strikes, and to switch fonts by slot data. I don't think this is a right way.
>> 
>> CTextPipe.drawGlyphVector receives only GlyphVector data and no Unicode character data. So, we cannot use fallback methods.
>
> @toshiona - is this PR dead ?

@prrace 
I'm deeply sorry for the long delay.
I completely changed the patch to use a different layer (SwingUtilities2.java).

> The immediately next method in this file, drawGlyphVector(..) surely would have the same problem ?

Yes, I had to say the bottom methods (Core Graphics Framework's CGContextShowGlyphsWithAdvances and CGContextShowGlyphsAtPoint) seem no capability to handle multi fonts.

> And then the drawChars method too ?

No. If we can use Unicode codes, fallback mechanism can work.

> Does this not in fact affect all code points for which the slot != 0 ?

Yes. I believe all slot !=0 glyphs have the issue.

> Do we really want to print all code points from slot > 0 as shapes ? 

No, it's a kind of workaround. I thought the effects of the change can be minimized.

> 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 ?

The new version changed the branching conditions. If it's MacOS, that won't branch to the printing path, which uses Glyph codes.

Well, I still couldn't create an automate test.

I appreciate any advices.

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

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