United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6636983 Japanese text does not display correctly in a JEditorPane
JDK-6636983 : Japanese text does not display correctly in a JEditorPane

Details
Type:
Bug
Submit Date:
2007-12-04
Status:
Resolved
Updated Date:
2011-01-19
Project Name:
JDK
Resolved Date:
2008-03-25
Component:
client-libs
OS:
solaris_9
Sub-Component:
javax.swing
CPU:
sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0u14
Fixed Versions:
6u10 (b20)

Related Reports
Backport:

Sub Tasks

Description
The customer say we are currently localizing our product, using Java 1.5.0_11, to run within a Japanese environment.  We have a rich text editor, which is essentially using a JEditorPane and an HTMLDocument, and we found in testing our localization changes that whenever we edit a document that contains pre-existing content, if we type Japanese text (using the Windows Japanese Input Method Editor (IME)) at the beginning of any of our lines, the text will not display to the end user until it has been committed (i.e. 'Enter' is pressed).  Inputting Japanese text anywhere else but the beginning of the line will display properly (each character appears as you type it, even though it is still 'uncommitted').  Also, if you create a new line in your edit session, the text is displayed properly when entered, so the problem seems limited to the beginning of lines that existed prior to your editing session.

This issue is reproducible on Solaris and Windows with 5.0 u11 and u14 and with 6.0 u2 and u3 with slight differences.

1.5 == Beginning of line issue described above
1.6 == Overstrikes chars -- does not shift chars to right

The customer reports it is not a problem with their code. The way I was able to determine that it wasn't a problem with our code (and probably the easiest way for you to recreate the problem) was to test it within the demo program provided within the JDK.  Within the
SwingSet2 demo, there is an HtmlDemo which uses a JEditorPane and an HTMLDocument in read-only mode.  I edited the HtmlDemo.java class to make the document editable, recompiled and re-inserted it into the SwingSet2.jar, and then ran the demo.  Now, when I try to insert Japanese text into the document at the beginning of any line, the text is not displayed until I press 'Enter'.  Then, comparing that to the behaviour of inserting text somewhere in the middle of a line, I can see the characters as I type them.  The final thing to note is that if you go to the end of the document, press enter to create a new line, it behaves properly.
Steps to reproduce the problem on Windows XP

**NOTE** I have not been able to input Japanese chars on Solaris so
I have not been able to reproduce on Solaris. Howver customer
can since they have a japanese keyboard.
**
The way I was able to determine that it wasn't a problem with our code
(and probably the easiest way for you to recreate the problem) was to
test it within the demo program provided within the JDK.  Within the
SwingSet2 demo, there is an HtmlDemo which uses a JEditorPane and an
HTMLDocument in read-only mode.  I edited the HtmlDemo.java class to
make the document editable, recompiled and re-inserted it into the
SwingSet2.jar, and then ran the demo.  Now, when I try to insert
Japanese text into the document at the beginning of any line, the text
is not displayed until I press 'Enter'.  Then, comparing that to the
behaviour of inserting text somewhere in the middle of a line, I can see
the characters as I type them.  The final thing to note is that if you
go to the end of the document, press enter to create a new line, it
behaves properly.
**

To get the Microsoft IME working (this is how to do it on XP, but I'm
sure it will be similar for whatever flavour of Windows you're working
with):

There's two steps:
1. Install the Language files
- open Control Panel 
- open Regional and Language Options 
- go to the Languages tab 
- check the box that says "Install files for East Asian languages".  You
will probably need a Windows CD for this, as it will need to install
some files that are probably not already on your machine.  After this,
it will ask you to restart for the installation to complete.

2. Enable the Japanese IME
- open Control Panel 
- open Regional and Language Options 
- go to the Languages tab 
- click on the "Details ..." button in the "Text services and input
languages" subsection 
- click the "Add ..." button to add a new language input
- select "Japanese" in the "Input Language" dropdown, and it should
default to "Microsoft IME Standard 2002 ver 8.1" (or something similar)
in the "Keyboard Layout/IME" dropdown
- you should now see the language bar in your taskbar

When you want to type using Japanese characters, simply put your cursor
into the text field, click on the language bar to change between "EN"
and "JP", and change the input mode (third button over) from "Direct
Input" to "Hiragana" (Note: Japanese characters are usually created by
typing a consonant followed by a vowel).

If your language bar is too small, you may not see it.  To make it
bigger, you can hit the restore button (small icon on the top right of
the language bar with tool tip text = "restore), and that should bring
it out of the taskbar and make it full size (all buttons will be
visible).

The button you want looks like a very tall capital letter 'A'.  If you
hover over the button, it should give a tool tip text of "Input Mode".
Clicking on this button will bring up a list of a number of Japanese
dialects (I believe they're dialects ... not to sure about this.  All I
know is that we want Hiragana).

To reiterate, the full language bar should have 11 buttons on it when in
Japanese mode (4 of which are only half the height of the bar) - whereas
when in English mode, there are only 4.  The only two buttons you need
to worry about are the English/Japanese selector and the Input Mode
buttons.

The Input Mode button is also on the language bar.

                                    

Comments
EVALUATION

The reason for the erratic display is that in certain cases (when inserting composed text at the point after "\n" in a document) character attributes for the composed text are inherited from the nearest content element which has the "CR" attribute defined. Later GlyphView which is created out of such element checks for the presence of this attribute and if it is set, the view is considered to have zero x-span. The layout code therefore doesn't move the insertion point for that view which leads to erratic output.

The visual effect for this bug differs in 1.5 and 1.6 because in 1.5 views that have zero x-span didn't get painted at all, and in 1.6 they are painted anyway because a view may contain a sole combining accent character for example (which has zero x-span) but still need to be drawn.

The solution for the problem is simple, just assure that the attribute set for composed text doesn't contain the CR attribute.
                                     
2008-01-30
EVALUATION

Another source for the similar visual effect is that the run element from which the composed text inherits character attributes may be actually some special element, like <BR>, and composed text inherits its name (which is stored in one of the element's attributes.)  Later the wrong kind of view is created out of composed text element.

To fix this the composed text element should be forced to have the proper name, ie, AbstractDocument.ContentElementName.
                                     
2008-02-13
SUGGESTED FIX

Webrevs: http://sa.sfbay.sun.com/projects/swing_data/6u10/6636983.3
                                     
2008-03-05



Hardware and Software, Engineered to Work Together