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