Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled #3619

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

@toshiona
Copy link
Contributor

@toshiona toshiona commented Apr 22, 2021

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 0xff000000. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3619/head:pull/3619
$ git checkout pull/3619

Update a local copy of the PR:
$ git checkout pull/3619
$ git pull https://git.openjdk.java.net/jdk pull/3619/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3619

View PR using the GUI difftool:
$ git pr show -t 3619

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3619.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Apr 22, 2021

👋 Welcome back tnakamura! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

@openjdk openjdk bot commented Apr 22, 2021

@toshiona The following label will be automatically applied to this pull request:

  • awt

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the awt label Apr 22, 2021
@toshiona
Copy link
Contributor Author

@toshiona toshiona commented Apr 22, 2021

/label add 2d

@openjdk openjdk bot added the 2d label Apr 22, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Apr 22, 2021

@toshiona
The 2d label was successfully added.

@toshiona toshiona marked this pull request as ready for review Apr 22, 2021
@openjdk openjdk bot added the rfr label Apr 22, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Apr 22, 2021

@mrserb
Copy link
Member

@mrserb mrserb commented Apr 23, 2021

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?

@toshiona
Copy link
Contributor Author

@toshiona toshiona commented Apr 23, 2021

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.

@prrace
Copy link
Contributor

@prrace prrace commented May 6, 2021

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 ?

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Jun 3, 2021

@toshiona This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

@prrace
Copy link
Contributor

@prrace prrace commented Jun 14, 2021

@toshiona - is this PR dead ?

@toshiona
Copy link
Contributor Author

@toshiona toshiona commented Jun 17, 2021

@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.

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Jul 15, 2021

@toshiona This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Aug 12, 2021

@toshiona This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

@bridgekeeper bridgekeeper bot closed this Aug 12, 2021
@toshiona
Copy link
Contributor Author

@toshiona toshiona commented Oct 21, 2021

/label remove 2d,awt

@openjdk
Copy link

@openjdk openjdk bot commented Oct 21, 2021

@toshiona The label 2d is not a valid label. These labels are valid:

  • serviceability
  • hotspot
  • hotspot-compiler
  • ide-support
  • kulla
  • i18n
  • shenandoah
  • jdk
  • javadoc
  • security
  • hotspot-runtime
  • jmx
  • build
  • nio
  • client
  • core-libs
  • compiler
  • net
  • hotspot-gc
  • hotspot-jfr

@toshiona
Copy link
Contributor Author

@toshiona toshiona commented Oct 21, 2021

/label add client

@openjdk openjdk bot added the client label Oct 21, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Oct 21, 2021

@toshiona
The client label was successfully added.

@toshiona
Copy link
Contributor Author

@toshiona toshiona commented Oct 21, 2021

/open

@openjdk openjdk bot reopened this Oct 21, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Oct 21, 2021

@toshiona This pull request is now open

@toshiona
Copy link
Contributor Author

@toshiona toshiona commented Oct 21, 2021

Sorry for the long interruption.
I completely revised the fix. The new proposal could be combined the modifications into MacOS specific class.
Please review the latest version.

Tests: tier1, java/awt, and javax.swing on MacOS (BigSur)

@toshiona
Copy link
Contributor Author

@toshiona toshiona commented Nov 2, 2021

@mrserb @prrace
Could you review the latest patch, please? I believe it's more reasonable than previous proposals.

@toshiona
Copy link
Contributor Author

@toshiona toshiona commented Nov 19, 2021

Let me explain the fix a little bit more.
The native API for drawing with glyph vector, CGContextShowGlyphsAtPoint(), cannot set multiple fonts.
So, the latest fix (c52a9f) switches the target font by Java code side, when 'slot' data is not 0, which means non-default font is used.
This is completely changed from my previous proposals.

Also, I could finally create an automated test case. It compares drawing results by SunGraphics2D.drawGlyphVector() and SunGraphics2D.drawString() under OSXOffScreenSurfaceData. Since drawing positions can be different between these methods even if English characters, it tries to compare pixel counts. This can detect to use different glyphs.

I appreciate any comments.

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Dec 17, 2021

@toshiona This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

@toshiona
Copy link
Contributor Author

@toshiona toshiona commented Dec 22, 2021

(Adding comment to keep this PR active.)
This fix tries to fill a gap between a native API and Composite font, since the native API can work for a single font with GlyphVector. This fix switches an appropriate font from the font list of Composite font of Java codes.
I appreciate any comments or advices.

@prrace
Copy link
Contributor

@prrace prrace commented Jan 4, 2022

Did this bug appear in some release, or do you think it never worked ?

Although I don't expect 255 slots your code like
if (gv.getGlyphCode(i) >= 0x1000000)

and
int slot = gV.getGlyphCode(i) >> 24;

will break if they are ..

The logic in drawGlyphVector where both initial slot != 0 and the final slot are handled
specially make this code more complex than desirable. Can you make the logic cleaner ?

The test relies heavily on internals. I'm not sure how long it will last.
"Pixel" (not Pixcel) count is an indicator that the rendering is the same, but why not
direct pixel to pixel comparison ?
Also it isn't actually testing that Japanese is rendered. It is testing that the images are the same
so if they are both "wrong" the test will still pass.

Did you ever look into why drawString did not need fixing too ?

Have you run other printing tests besides the new one to verify this all works ?

More importantly what on-screen testing have you done ?
Or have you proved CTextPipe is only used in printing ?

@toshiona
Copy link
Contributor Author

@toshiona toshiona commented Jan 6, 2022

Thank you for the comments, @prrace

Did this bug appear in some release, or do you think it never worked ?

I think it never worked.

Although I don't expect 255 slots your code like if (gv.getGlyphCode(i) >= 0x1000000)
and int slot = gV.getGlyphCode(i) >> 24;
will break if they are ..

Fixed. Thank you for pointing out.

The logic in drawGlyphVector where both initial slot != 0 and the final slot are handled specially make this code more complex than desirable. Can you make the logic cleaner ?

Revised the logic.

The test relies heavily on internals. I'm not sure how long it will last.

I agree. But, without using OSXOffScreenSurfaceData class, printing test is required. I think it's hard to create automate tests.

"Pixel" (not Pixcel) count is an indicator that the rendering is the same, but why not direct pixel to pixel comparison ? Also it isn't actually testing that Japanese is rendered. It is testing that the images are the same so if they are both "wrong" the test will still pass.

I'm sorry for misspelling. I revised the testcase. I realized that fallback fonts are different between CoreText library and Java side. So, now the test will check the drawing bounds of test string by drawGlyphVector. Also, if there is no capable font, it will be skipped.

Did you ever look into why drawString did not need fixing too ?

I'm not fully understanding CoreText library, but CTLine object picked up automatically fallback fonts by Unicode data.

Have you run other printing tests besides the new one to verify this all works ?

Yes. We've tested some printing based on J2Ddemo and SwingSet2 with non-ASCII characters.

More importantly what on-screen testing have you done ? Or have you proved CTextPipe is only used in printing ?

I wasn't able to find the way to call the method except the scenario in the original report, which is to print JTable with non-ASCII characters. If this method had been used more, more people would have found it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants