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

Closed
wants to merge 11 commits into 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

Reviewers

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 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 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 client-libs-dev@openjdk.org label Apr 22, 2021
@toshiona
Copy link
Contributor Author

toshiona commented Apr 22, 2021

/label add 2d

@openjdk openjdk bot added the 2d client-libs-dev@openjdk.org label Apr 22, 2021
@openjdk
Copy link

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 Pull request is ready for review label Apr 22, 2021
@mlbridge
Copy link

mlbridge bot commented Apr 22, 2021

Webrevs

@mrserb
Copy link
Member

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 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 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 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 commented Jun 14, 2021

@toshiona - is this PR dead ?

@toshiona
Copy link
Contributor Author

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 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 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 commented Oct 21, 2021

/label remove 2d,awt

@openjdk
Copy link

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 commented Oct 21, 2021

/label add client

@openjdk openjdk bot added the client client-libs-dev@openjdk.org label Oct 21, 2021
@openjdk
Copy link

openjdk bot commented Oct 21, 2021

@toshiona
The client label was successfully added.

@toshiona
Copy link
Contributor Author

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

@bridgekeeper
Copy link

bridgekeeper bot commented Feb 3, 2022

@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 commented Feb 7, 2022

Ok. approved. An improvement but maybe there'll be some tweaks needed later.

prrace
prrace approved these changes Feb 14, 2022
@openjdk
Copy link

openjdk bot commented Feb 14, 2022

@toshiona This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

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

Reviewed-by: prr, serb

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 186 new commits pushed to the master branch:

  • 6a3a7b9: 6218162: DefaultTableColumnModel.getColumn() method should mention ArrayIndexOutOfBoundsException
  • 5b78a82: 7017094: ParsedSynthStyle: parameter name "direction" should be changed to "tabIndex"
  • 8aba4de: 8249592: Robot.mouseMove moves cursor to incorrect location when display scale varies and Java runs in DPI Unaware mode
  • ff76620: 8282641: Make jdb "threadgroup" command with no args reset the current threadgroup back to the default
  • 70318e1: 8282884: Provide OID aliases for MD2, MD5, and OAEP
  • 6d8d156: 8280494: (D)TLS signature schemes
  • 5df2a05: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig()
  • d07f7c7: 8282665: [REDO] ByteBufferTest.java: replace endless recursion with RuntimeException in void ck(double x, double y)
  • 31ad80a: 8280902: ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame
  • 12693a6: 8282432: Optimize masked "test" Vector API with predicate feature
  • ... and 176 more: https://git.openjdk.java.net/jdk/compare/d7f31d0d53bfec627edc83ceb75fc6202891e186...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@prrace, @mrserb) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Feb 14, 2022
@toshiona
Copy link
Contributor Author

toshiona commented Feb 15, 2022

Thank you for your approval, Phil.

May I have a second reviewer?

while (start < length) {
int slot = (gV.getGlyphCode(start) &
CompositeGlyphMapper.SLOTMASK) >> 24;
sg2d.setFont(getSlotFont(gV.getFont(), slot));
Copy link
Member

@mrserb mrserb Feb 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to change the font for each glyph or we should do that only if the slot was changed? Or it is a common situation that each glyph will have its own slot?

Copy link
Contributor Author

@toshiona toshiona Feb 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mrserb Thank you for the comments.
Only if the slot was changed, we need to change the font. This may happen with multi-language situation.

mrserb
mrserb approved these changes Mar 10, 2022
@toshiona
Copy link
Contributor Author

toshiona commented Mar 10, 2022

/integrate

@openjdk openjdk bot added the sponsor Pull request is ready to be sponsored label Mar 10, 2022
@openjdk
Copy link

openjdk bot commented Mar 10, 2022

@toshiona
Your change (at version b623a12) is now ready to be sponsored by a Committer.

@toshiona
Copy link
Contributor Author

toshiona commented Mar 10, 2022

@mrserb Thank you for the review.

@mrserb @prrace Could you sponsor this fix?

@mrserb
Copy link
Member

mrserb commented Mar 16, 2022

/sponsor

@openjdk
Copy link

openjdk bot commented Mar 16, 2022

Going to push as commit 27fe3d7.
Since your change was applied there have been 236 commits pushed to the master branch:

  • bacfaa3: 8282414: x86: Enhance the assembler to generate more compact instructions
  • 1465ea9: 8282355: compiler/arguments/TestCodeEntryAlignment.java failed "guarantee(sect->end() <= tend) failed: sanity"
  • ac06bdb: 8282507: Add a separate license file for hsdis
  • 32f8437: 8283075: Bad IllegalArgumentException message for out of range rank from ClassDesc.arrayType(int)
  • 12dca36: 8283189: Bad copyright header in UnsafeCopyMemory.java
  • 05a83e0: 8283124: Add constant for tau to Math and StrictMath
  • 671b6ef: 8283143: Use minimal-length literals to initialize PI and E constants
  • f43ffe2: 8282633: jarsigner output does not explain why an EC key is disabled if its curve has been disabled
  • 4de7201: 8283122: [AIX, s390] UnsafeCopyMemory 'Mismatched' Tests Fail on Big Endian Systems
  • 2cddf3f: 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows
  • ... and 226 more: https://git.openjdk.java.net/jdk/compare/d7f31d0d53bfec627edc83ceb75fc6202891e186...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Mar 16, 2022
@openjdk openjdk bot closed this Mar 16, 2022
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Mar 16, 2022
@openjdk
Copy link

openjdk bot commented Mar 16, 2022

@mrserb @toshiona Pushed as commit 27fe3d7.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2d client-libs-dev@openjdk.org awt client-libs-dev@openjdk.org client client-libs-dev@openjdk.org integrated Pull request has been integrated
3 participants