United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6830423 Unified Ext B character not displayed with Dialog font
JDK-6830423 : Unified Ext B character not displayed with Dialog font

Details
Type:
Enhancement
Submit Date:
2009-04-15
Status:
Closed
Updated Date:
2010-10-15
Project Name:
JDK
Resolved Date:
2009-12-23
Component:
client-libs
OS:
windows_vista
Sub-Component:
java.awt:i18n
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Backport:

Sub Tasks

Description
The following is the report from SAP AG development.
________________________________________________________________________
Summary:

CJK Unified Ext B characters in text of Swing UIs are not displayed
(blank square) using "Dialog" font.

Steps to Reproduce:
Run attached program:
java -cp CJKUnifiedExtB.jar CJKUnifiedExtB.CJKUnifiedExtB
The jar contains both .class and .java file. The character in the sample
is U+23F80.

First line displays the correct character as a png for comparison.
Second line displays the character on JLabel and JTextEdit using
"Dialog" font.
Third line displays the same, but using "PMingLiU-ExtB" font.
(Please change the "native" font in the sample according to the

availablity of appropriate fonts in your environment.)

Expected Results:
JLabel and JTextEdit should display the same correct character both with
"Dialog" and the "native" font.

Actual Results:
JLabel with "Dialog": blank square
JTextEdit with "Dialog": blank square
JLabel with native font: correct character
JTextEdit with native font: correct character

Regression:
Happens both with JSE 5 and 6 on Windows Vista Enterprise, other Windows
versions and OSes might be affected as well.

Choosing a native font is not a helpful workaround for a Unicode
environment, since it causes characters from other languages/scripts not
being displayed. We have customers with Unicode environments requiring
this working with "Dialog" font.
One of them has a Unicode project on hold because of this, therefore the
high prio.
________________________________________________________________________

                                    

Comments
EVALUATION

The "PMingLiU-ExtB" font is new in Vista and is the only font on Windows
(including Windows 7 beta) that fully supports the "CJK Unified Ext B" range.
JDK doesn't reference this font in its logical fonts because it is new.
Adding that support is an RFE, not a bug. Since the other supported windows
versions (2000 (for JDK6), XP, 2003) don't have this font it would mean
creating a slew of new font properties files, which  may increase testing
burden. We should consider this RFE for JDK7.

Note that the font is in a TTC and it in fact contains PMingLiU-ExtB
and MingLiU-ExtB. ie proportional and non-proportional as well
as MingLiU_HKSCS-ExtB. So the updating is a little more complex as
we'd want to use each of these in the appropiate composite fonts and locale
configurations corresponding to where we already use the existing
non "ExtB" MingLiU font.
                                     
2009-04-15
EVALUATION

Since this is a supplement to the fonts, rather than a different set, then
rather than creating new fontconfig files, its likely enough to just
augment the one we have now. Its already necessarily resilient against files
not being present, as is the case if you didn't have any CJK fonts installed.

Also the syntax in the fontconfig files for monospaced to proportional font
mapping for the MingLiU->PMingLiU should be implemented for the Ext-B fonts.
                                     
2009-04-15
EVALUATION

I notice there's also a SimSun-ExtB I'd overlooked.

One complication that just occurred to me is that if these fonts are added
as a "core" font for the various logical fonts in chinese locales, rather
than just picking one of them to use in the fallback list, then they'll be
in the list theoretically available for AWT heavyweight controls, but
since AWT won't have a CHARSET for this, it won't be available. This
isn't likely to be important, so long as the result is just missing
glyphs being displayed.
                                     
2009-04-15



Hardware and Software, Engineered to Work Together