JDK-6937895 : Japanese character probs caused by unexpected default font in TextArea/TextField
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_2.5.1
  • CPU: sparc
  • Submitted: 2010-03-24
  • Updated: 2011-04-01
  • Resolved: 2011-04-01
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
7Resolved
Related Reports
Duplicate :  
Relates :  
Description
OPERATING SYSTEMS
-----------------
Windows 7 Professional (Japanese)
Windows Server 2008 Enterprise x64 SP2 (Japanese)

FULL JDK VERSION
----------------
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b85)
Java HotSpot(TM) Client VM (build 17.0-b10, mixed mode)

DESCRIPTION
-----------
On Japanese Windows, an unexpected font is loaded in the TextArea/TextField component. It seems that the TextField component loads the "MS Sans Serif" font instead of "MS Gothic" by default.

This causes the following issues (see recreation instructions below):

1. Font size is smaller than Java6's TextArea/TextField
2. On TextArea, cannot use OnTheSpot Input Style, floating IM window is
   displayed
3. On TextArea, if Japanese characters are inputed by MS-IME, font
   glyphs are overlapped
4. On TextField, cannot use OverTheSpot Input Style, floating IM window
   is displayed
5. On TextField, Unicode Extension B Japanese characters (like U+2000B)
   font height is larger than standard Japanese characters
6. On TextField, U+3099(Combining Katakana-Hiragana Voiced Sound Mark)
   and U+309A(Combining Katakana-Hiragana Semi-Voiced Sound Mark) are
   not displayed at the correct position

These issues are not seen with Java 6 (tested with 6u18).

REPRODUCTION INSTRUCTIONS
-------------------------
Issues (1)(2)(3)(4):
1. Compile and run above test program
2. Turn on MS-IME on TextField and TextArea component
3. Type "aiueo"

Issue (5):
1. Compile and run above test program
2. Turn on MS-IME on TextField and TextArea component
3. Type "2000B", press F5, select Japanese character

Issue(6):
1. Compile and run above test program
2. Turn on MS-IME on TextField and TextArea component
3. Type "304B", press F5, select "Hiragana KA"
4. Type "3099", press F5, select Combining Katakana-Hiragana Voiced
   Sound Mark

TESTCASE SOURCE
---------------
import java.awt.*;
import java.awt.event.*;

class TextTest extends Frame {
  TextTest(Component comp) {
    setTitle(comp.getClass().getSimpleName());
    add(comp);
    setSize(300,200);
    setLocationByPlatform(true);
    addWindowListener(new WindowAdapter() {
      public void windowClosing(WindowEvent event) { System.exit(0); }
    });
    setVisible(true);
  }
  public static void main(String[] args) {
    new TextTest(new TextArea());
    new TextTest(new TextField());
  }
}

Comments
EVALUATION The part related to font rendering etc. not reproduced anymore with the 6943487 fix. IM part is covered in 6853146 so I'm closing this with duplicate substatus.
01-04-2011

SUGGESTED FIX Fixed by http://sa.sfbay.sun.com/projects/java2d_data/7/6943487/
01-04-2011

EVALUATION The input method problem is a duplicate of 6853146. So, this CR remains for (6).
04-01-2011

EVALUATION - The input method symptom is reproducible from b55. - (5) is not reproducible at all. - For (6), the composed Kana character is correctly displayed. However, an extra space is seen after the Kana character in a TextArea. But the extra space isn't displayed in a TextField.
04-01-2011

EVALUATION This is about input methods on AWT heavyweight components. I can't think how any 2D changes could have brought this about. I'm assigning to I18N to verify the problem and to see if its an I18N or AWT change that's responsible.
21-12-2010

SUGGESTED FIX IBM has provided us with the following suggested fix. Note, this does not address the IME issue mentioned in the report. ------------------------------------------------------------------- Index: src/share/classes/sun/awt/PlatformFont.java =================================================================== --- src/share/classes/sun/awt/PlatformFont.java (revision xxx) +++ src/share/classes/sun/awt/PlatformFont.java (working copy) @@ -44,6 +44,8 @@ import sun.java2d.FontSupport; import java.nio.CharBuffer; import java.nio.ByteBuffer; +import sun.font.FontManager; +import sun.font.FontManagerFactory; public abstract class PlatformFont implements FontPeer { @@ -69,7 +71,7 @@ protected static String osVersion; public PlatformFont(String name, int style){ - GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); + FontManager ge = FontManagerFactory.getInstance(); if (ge instanceof FontSupport) { fontConfig = ((FontSupport)ge).getFontConfiguration(); } -------------------------------------------------------------------
27-04-2010