JDK-8015556 : [macosx] surrogate pairs do not render properly (show up as boxes or incorrect glyphs)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-03-20
  • Updated: 2014-11-19
  • Resolved: 2013-05-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u40Fixed 8 b94Fixed
Description
FULL PRODUCT VERSION :
java version  " 1.7.0_07 " 
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
OS X 10.8.2
Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64


A DESCRIPTION OF THE PROBLEM :
While testing using surrogate pairs we found a number of jvm bugs. This one is specific to OS X (works under Window 7) and possible Windows XP. It seems like it's not using the correct font to render glyphs for surrogate pairs. They either show up as boxes or as an incorrect glyph.

After patching BasicTextUI to fix pasting, usually they are boxes or incorrect glyphs, but when using the Character Viewer to enter in surrogates from CJK Unified Ideographs Ext. B (20000+) you see really odd behavior like it's interpreting each character as individual ascii char (I've seen things like it does a backspace, regular ascii chars, select all, delete).

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
After fixing the bug in BasicTextUI related to importing (paste/drop) surrogate paris...

Try using the Character Viewer to enter in surrogate pairs (20000+) in JTextComponents (JTextField, JTextArea in particular, but all need to be validated).

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Characters should display like they do in Text Edit
ACTUAL -
Characters do not show up properly

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Use Windows 7 for testing. Most of our development staff is on OS X and it's frustrating to not be able to test surrogate pair issues on the mac due to glyph issues.
Comments
Some things "seem" to work but the code that does caching of the mapping is really ignorant of supplementary chars - the first look up of a pair will work, but then it caches the 'high' char as the key to look up the glyph. So subsequent calls for any char with the same high char, no matter the low char, will map to whatever was found in the first call. The glyph in the position of the low char should be mapped to the invisible glyph but isn't. - the implementation of charToGlyph(int) downcasts the arg to a char thus resulting in a garbage look up. These problems are all in the Mac OS X CCharToGlyphMapper. I've tried to keep the spirit of its implementation, which goes to a native call to do the lookup, as otherwise we'd need to change a lot more and make sure we supported dfonts. However this code is a lot slower than the way we do it on Windows. I'm now passing down more to native as I don't attempt to remove duplicates which was a complication in the code but as it was the number of native calls that hurt this isn't making the performance worse as far as I can tell.
30-05-2013