[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garb
From:       Toshio Nakamura <tnakamura () openjdk ! java ! net>
Date:       2021-06-17 9:29:08
Message-ID: ggQJztCX7uUW2RXvz_c0B7OANyJMn_FHCHjnEwbq7Yo=.bc94ec7c-2d94-4031-b13b-3c2f0542894d () github ! com
[Download RAW message or body]

On Mon, 14 Jun 2021 19:26:46 GMT, Phil Race <prr@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


[prev in list] [next in list] [prev in thread] [next in thread]