Re: [OpenJDK 2D-Dev] RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
On Mon, 14 Jun 2021 19:26:46 GMT, Phil Race 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
>> 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
Re: [OpenJDK 2D-Dev] RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled [v2]
> Hi, > > Could you review the fix? > When non-English characters were printed from JTable on MacOS, > CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, > CTextPipe seems not support glyph with slot number of composite fonts. > > The slot data mask of GlyphVector is 0xff00. In my environment, Japanese > font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, > unexpected glyph was drawn. > > This patch checks slot data of each character. If slot data exists, it will > branch to GlyphVector's drawing path. > > Well, I couldn't create automatic test for this fix. This method seems to be > called for printing only. I appreciate any advice. > Tested java/awt and javax/swing on MacOS BigSur, and there was no regression. > > Regards, > Toshio Nakamura Toshio Nakamura has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - 2nd proposal - Revert previous change - Merge branch 'master' into 8240756 merge master - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled - Changes: - all: https://git.openjdk.java.net/jdk/pull/3619/files - new: https://git.openjdk.java.net/jdk/pull/3619/files/9d99458c..c2910791 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3619=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3619=00-01 Stats: 1152276 lines in 9449 files changed: 556262 ins; 566916 del; 29098 mod Patch: https://git.openjdk.java.net/jdk/pull/3619.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3619/head:pull/3619 PR: https://git.openjdk.java.net/jdk/pull/3619
Re: [OpenJDK 2D-Dev] RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
On Fri, 23 Apr 2021 09:45:45 GMT, Toshio Nakamura 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
> 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
Re: [OpenJDK 2D-Dev] RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
On Thu, 22 Apr 2021 09:21:20 GMT, Toshio Nakamura wrote: > Hi, > > Could you review the fix? > When non-English characters were printed from JTable on MacOS, > CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, > CTextPipe seems not support glyph with slot number of composite fonts. > > The slot data mask of GlyphVector is 0xff00. In my environment, Japanese > font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, > unexpected glyph was drawn. > > This patch checks slot data of each character. If slot data exists, it will > branch to GlyphVector's drawing path. > > Well, I couldn't create automatic test for this fix. This method seems to be > called for printing only. I appreciate any advice. > Tested java/awt and javax/swing on MacOS BigSur, and there was no regression. > > Regards, > Toshio Nakamura The immediately next method in this file, drawGlyphVector(..) surely would have the same problem ? And then the drawChars method too ? Does this not in fact affect all code points for which the slot != 0 ? Do we really want to print all code points from slot > 0 as shapes ? 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 ? - PR: https://git.openjdk.java.net/jdk/pull/3619
Re: [OpenJDK 2D-Dev] RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
On Fri, 23 Apr 2021 06:49:10 GMT, Sergey Bylokhov 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 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.
-
PR: https://git.openjdk.java.net/jdk/pull/3619
Re: [OpenJDK 2D-Dev] RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
On Thu, 22 Apr 2021 09:21:20 GMT, Toshio Nakamura wrote: > Hi, > > Could you review the fix? > When non-English characters were printed from JTable on MacOS, > CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, > CTextPipe seems not support glyph with slot number of composite fonts. > > The slot data mask of GlyphVector is 0xff00. In my environment, Japanese > font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, > unexpected glyph was drawn. > > This patch checks slot data of each character. If slot data exists, it will > branch to GlyphVector's drawing path. > > Well, I couldn't create automatic test for this fix. This method seems to be > called for printing only. I appreciate any advice. > Tested java/awt and javax/swing on MacOS BigSur, and there was no regression. > > Regards, > Toshio Nakamura 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? - PR: https://git.openjdk.java.net/jdk/pull/3619
[OpenJDK 2D-Dev] RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
Hi, Could you review the fix? When non-English characters were printed from JTable on MacOS, CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, CTextPipe seems not support glyph with slot number of composite fonts. The slot data mask of GlyphVector is 0xff00. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn. This patch checks slot data of each character. If slot data exists, it will branch to GlyphVector's drawing path. Well, I couldn't create automatic test for this fix. This method seems to be called for printing only. I appreciate any advice. Tested java/awt and javax/swing on MacOS BigSur, and there was no regression. Regards, Toshio Nakamura - Commit messages: - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled Changes: https://git.openjdk.java.net/jdk/pull/3619/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3619=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240756 Stats: 12 lines in 1 file changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3619.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3619/head:pull/3619 PR: https://git.openjdk.java.net/jdk/pull/3619
