United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-8015556 [macosx] surrogate pairs do not render properly (show up as boxes or incorrect glyphs)
JDK-8015556 : [macosx] surrogate pairs do not render properly (show up as boxes or incorrect glyphs)

Details
Type:
Bug
Submit Date:
2013-03-20
Status:
Resolved
Updated Date:
2013-12-17
Project Name:
JDK
Resolved Date:
2013-05-31
Component:
client-libs
OS:
Sub-Component:
2d
CPU:
Priority:
P3
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:

Sub Tasks

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.
                                     
2013-05-30
URL:   http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0a17344d074e
User:  prr
Date:  2013-05-31 16:27:36 +0000

                                     
2013-05-31
URL:   http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/0a17344d074e
User:  lana
Date:  2013-06-11 18:41:37 +0000

                                     
2013-06-11



Hardware and Software, Engineered to Work Together