JDK-4710727 : Cannot type simplifed chinese period and comma using QuanPin
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt:i18n
  • Affected Version: 1.3.0,1.4.1
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_98,windows_2000
  • CPU: x86
  • Submitted: 2002-07-03
  • Updated: 2002-09-25
  • Resolved: 2002-09-25
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.
Other Other
1.4.1_01 01Fixed 1.4.2Fixed
Related Reports
Duplicate :  
Description

Name: dk106046			Date: 07/03/2002

1.4.1-rc-b16     


------------
(1) Compile the following sample code and run it.
 > javac test_punct.java
 > java test_punct

--------------- Sample Code: test_punct.java ------------------
/*
 * test_punct.java
 */
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class test_punct extends JFrame {
       Component c;
       public test_punct() {
              super("Single Frame --- Swing JFrame");
              c = new JTextArea("JTextArea component");
              MyKeyListener keyListener = new MyKeyListener();
              c.addKeyListener(keyListener);
              getContentPane().add(c);
              addWindowListener(new WindowAdapter() {
                     public void windowClosing(WindowEvent event) {
                            System.exit(0);
                     }
              });
              setSize(300, 300);
              show();
       }
       public static void main(String[] args) {
              new test_punct();
       }
}
class MyKeyListener extends KeyAdapter {
       public void keyPressed(KeyEvent event) {
              int code = event.getKeyCode();
              String name = event.getComponent().getClass().getName();
              System.out.println("KeyPressed => [" + event.getKeyText(code) + "] (" + code + ")  on " + name);
       }
       public void keyTyped(KeyEvent event) {
              char c = event.getKeyChar();
              String name = event.getComponent().getClass().getName();
              System.out.println("KeyTyped   =>  " + c + " (0x" + Integer.toHexString(c) + ") on " + name);
       }
       public void keyReleased(KeyEvent event) {
              ;
       }
}
----------------------- Code ends here ------------------------

(2) Turn on QuanPin IM and toggle chinese punctuation style in the JTextArea.
 Turn on QuanPin IM.
 Change punctuation style to chinese in language toolbar (or pressing Ctrl + .)

(3) Press comma and period keys.
 You cannot type comma and period in simplified chinese style.       <--- PROBLEM
 At this time, the sample program doesn't output any key event log of typing comma and period in standard output.

Expected Result:
  These chinese style punctuation marks should appear by typing comma key and period key.

======================================================================

Name: js137446	###@###.### 	2002-07-17

1.4.1-beta-b14

OS version:     MS Windows 2000 & Windows 98
PROBLEM:

  - Can't input Chinese punctuations (full-width punctuation) in Win2000
    and Win98 when using some frequently used Chinese input methods.
  - When using Intelligent ABC IME and MS PinYin IME, if the typing speed is 
    fast, then sometimes the input window will hang up, and user can't 
    continue his work. This problem occurs more frequently in Win98 than 
    Win2000.
  - The "soft keyboard" function doesn't work in many IMEs.
  - The behavior of "directly English input" feature in Intelligent ABC IME 
    is wrong. 

TEST CASE:

####################   test code begins here   ###################
/*
 * InputDemo.java
 *
 * Created on 2002����5����28����, ��������6:59
 */

package demo;
import java.awt.event.*;
import javax.swing.*;
import java.awt.*;

/**
 *
 * @author  billy
 */
public class InputDemo extends JFrame implements AWTEventListener
{    
    /** Creates a new instance of DEMO1 */
    public InputDemo() 
    {
       Toolkit.getDefaultToolkit().addAWTEventListener(this,
       AWTEvent.KEY_EVENT_MASK | AWTEvent.INPUT_METHOD_EVENT_MASK );
       JTextPane p = new JTextPane();
       p.setBounds(20,20,200,200);
       getContentPane().add(p);
       addWindowListener(new WindowAdapter ()
       {
           public void windowClosing(WindowEvent e)
           {
               System.exit(0);               
           }           
       });
    }
   
   public void eventDispatched(AWTEvent event)
   {         
       if(event instanceof KeyEvent)
       {           
           KeyEvent e = (KeyEvent)event;           
           char keyChar = e.getKeyChar();           
           System.out.println("event is:"+event);          
       }      
   }
    /**
     * @param args the command line arguments
     */
    public static void main(String[] args)
    {
        InputDemo d = new InputDemo();
        d.setBounds(200,200,400,400);
        d.show();
    }    
}
####################   test code ends here   ###################


Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.1_01 mantis FIXED IN: 1.4.1_01 mantis INTEGRATED IN: 1.4.1_01 mantis mantis-b03
14-06-2004

EVALUATION It seems that in the problem case, the QuanPin input method consumes the '.' WM_KEYDOWN message. Instead of that it posts two WM_CHAR messages with 0xa3 and 0xa1 in the character code field, that makes Chinese full stop. In the current JDK AWT implementation does not expect such a WM_CHAR sequence and it just ignores them. We need to add some code to handle them. ###@###.### 2002-07-17 Since the basic behavior of the input method is posting ANSI multibyte character using a series of WM_CHARs containing each byte of the character, this problem should automatically go away if we move to Unicode AWT implementation. ###@###.### 2002-07-18 This actually is the problem in those IMEs, since they don't generate WM_IME_CHAR message for those fullsize punctuations beforehand. In the MS Platform SDK documentation, there is the following remark in the WM_IME_CHAR reference: -- excerpt start -- For a non-Unicode window, if the WM_IME_CHAR message includes a double-byte character and the application passes this message to DefWindowProc, the IME converts this message into two WM_CHAR messages, each containing one byte of the double-byte character. -- excerpt end -- I would add an workaround for this problem. ###@###.### 2002-09-17
17-09-2002