On Fri, 23 Apr 2021 09:45:45 GMT, Toshio Nakamura <tnakam...@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?
>
>> 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 ?
-------------
PR: https://git.openjdk.java.net/jdk/pull/3619
