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
