This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 14549 - I18N - visual feedback to user on inputting multibyte, the intermediate words are not underlined.
Summary: I18N - visual feedback to user on inputting multibyte, the intermediate words...
Status: RESOLVED FIXED
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker with 4 votes (vote)
Assignee: issues@editor
URL:
Keywords: I18N
: 37032 (view as bug list)
Depends on:
Blocks:
 
Reported: 2001-08-17 17:25 UTC by Ken Frank
Modified: 2007-11-05 13:44 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
sample project for how to get text attribute of composed text (11.59 KB, application/octet-stream)
2007-08-27 04:04 UTC, Masaki Katakai
Details
screenshot of imsample (36.16 KB, image/jpeg)
2007-08-27 04:07 UTC, Masaki Katakai
Details
patch to use InputMethodHighlight to determine UNDERLINE or REVERSE, not from TextAttribute (2.52 KB, patch)
2007-08-30 06:11 UTC, Masaki Katakai
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2001-08-17 17:25:50 UTC
When entering multibyte thru the native OS input
methods system, the visual feedback to the user
is not the same as it is in other parts of FFJ
or other OS applications that allow text input

1. switch to Japanese input mode
2. enter multibyte characters in editor - they
are not highlighted or underlined as are in
other parts of FFJ or in native OS apps like
notepad on windows
4. On windows, hit spacebar twice for lookup
window giving choices of which words
(type "toro" and space/space)
5. The letters are not underlined with a bold
line like they are in other parts of FFJ.

6. There are Java APIs that allow interfacing
with the native input system, and other parts of FFJ
that can obtain text input perform as do native applications

7. This was seen on Solaris and Linux, however on Solaris, some modes
of input do not show choice boxes on space/space.
Comment 1 Jan Chalupa 2001-11-27 12:26:58 UTC
Target milestone -> 3.3.1.
Comment 2 Marek Grummich 2002-07-22 09:48:24 UTC
Set target milestone to TBD
Comment 3 Marek Grummich 2002-07-22 09:52:45 UTC
Set target milestone to TBD
Comment 4 Jan Kovar 2003-01-22 14:56:49 UTC
I compared the JDK and IDE behaviour and I found one main 
difference: when inputting the text the intermediate words 
are not underlined. 
Ken are there any other significant differences?

Now for underlining:
I checked the code and after the discussion with Mila we 
found out that indeed its an error.
The problem is connected with a fact that currend IDE 
implementation is not keeping an info (flag) about 
composed text. Then the draw mechanizm cannot underline 
proper characters.

Easiest way how to solve it is to follow standart JDK way 
and store the composed/non composed flag for all 
characters. Then the standart JDK mechanizm will take care 
about the rest. However this would require significant API 
changes in editor which is not very preffered.

Anyway there is a solution (not so solid and stable but 
probably acceptable):
1. Enhance the element information by defining the start 
and the end of a composed text
2. Enhance draw mechanizm to mimic standart JDK 
functionality

So basically copy and mimic JDK functionality in the IDE.

Now question for Ken: how is this bug important for I18N 
team? Should we try to fix it for Sierra/Nevada or its 
acceptable to postpone it?
Comment 5 Ken Frank 2003-01-22 17:16:09 UTC
I think only difference is the underlining and hiliting of
intermediate words.

I think it acceptable that this could be fixed as suggested
in netbeans trunk later; since Nevada is so soon. We can then
verify it in netbeans 3.5, for example.

Ken
Comment 6 Martin Roskanin 2003-02-28 15:34:49 UTC
At this time only P1s and P2s are allowed to be integrated into newly
created branch "release35". Changing target milestone to 4.0
Comment 7 psuk 2004-04-20 18:08:21 UTC
Changing the milestone to promoD.
Comment 8 Roman Strobl 2005-01-10 13:13:21 UTC
Changed target milestone to TBD.
Comment 9 Miloslav Metelka 2005-01-31 11:45:09 UTC
Not sure when we will be able to improve the situation regarding this.
Setting TM to future for now.
Comment 10 Keiichi Oono 2006-02-08 08:27:36 UTC
Please let me change Summary field to describe this issue.

Would you please think about implementing fixing for this issue? We can't see
which characters are intermediate, and which characters have been committed.
We still have this issue in 5.0. It does not have be same as JDK standard, but I
would like to request to implement to display which characters are intermediate.
Comment 11 Ken Frank 2006-02-08 15:46:59 UTC
I agree with it being moved to p2 and hope finally it can be fixed. We do
have more and more users in asian and other locales now even that when
issue originally filed.

And since it seems from dev comments that problem situation is understood,
it seems fix could be done for 5.5 release ?

ken.frank@sun.com
Comment 12 Vitezslav Stejskal 2006-10-13 01:28:57 UTC
*** Issue 37032 has been marked as a duplicate of this issue. ***
Comment 13 Miloslav Metelka 2007-05-21 15:28:58 UTC
I will attempt to make a HighlightsLayer implementation for the offset range of
the input method.
Comment 14 Ken Frank 2007-06-08 07:42:55 UTC
Feedback from l10n team customers, who also are aware of how other users expect
it to work,, is very hopeful that this can finally be fixed in nb6; there is now
the big
implementation of project encoding for nb6, and it would be great if this one
could be fixed as well after all this time.

Can dev team see if it can happen ?

ken.frank@sun.com
Comment 15 Petr Hrebejk 2007-08-03 16:49:34 UTC
Waiver request: We will not be able to implement this for 6.0
Comment 16 Vitezslav Stejskal 2007-08-22 16:12:50 UTC
Should be fixed now. When entering multibyte characters the input text is highlighted with inverted colors (ie. the
background/foreground colors are swapped). Ken, could you please test it and give us some feedback? Is it working as
expected? Should the text be highlighted in some other way? What about different color schemes, is swapping bg/fg the
right approach? Thanks

cvs server: scheduling file `ComposedTextHighlighting.java' for addition
cvs server: use 'cvs commit' to add this file permanently
Checking in editor/libsrc/org/netbeans/editor/GuardedDocument.java;
/cvs/editor/libsrc/org/netbeans/editor/GuardedDocument.java,v  <--  GuardedDocument.java
new revision: 1.22; previous revision: 1.21
done
Checking in editor/libsrc/org/netbeans/editor/BaseDocument.java;
/cvs/editor/libsrc/org/netbeans/editor/BaseDocument.java,v  <--  BaseDocument.java
new revision: 1.145; previous revision: 1.144
done
Checking in editor/libsrc/org/netbeans/editor/BaseDocumentEvent.java;
/cvs/editor/libsrc/org/netbeans/editor/BaseDocumentEvent.java,v  <--  BaseDocumentEvent.java
new revision: 1.27; previous revision: 1.26
done
Checking in editor/lib/apichanges.xml;
/cvs/editor/lib/apichanges.xml,v  <--  apichanges.xml
new revision: 1.9; previous revision: 1.8
done
Checking in editor/src/org/netbeans/modules/editor/impl/highlighting/HLFactory.java;
/cvs/editor/src/org/netbeans/modules/editor/impl/highlighting/HLFactory.java,v  <--  HLFactory.java
new revision: 1.4; previous revision: 1.3
done
RCS file: /cvs/editor/src/org/netbeans/modules/editor/impl/highlighting/ComposedTextHighlighting.java,v
done
Checking in editor/src/org/netbeans/modules/editor/impl/highlighting/ComposedTextHighlighting.java;
/cvs/editor/src/org/netbeans/modules/editor/impl/highlighting/ComposedTextHighlighting.java,v  <-- 
ComposedTextHighlighting.java
initial revision: 1.1
done
Checking in editor/lib/nbproject/project.properties;
/cvs/editor/lib/nbproject/project.properties,v  <--  project.properties
new revision: 1.21; previous revision: 1.20
done
Comment 17 cahrens 2007-08-22 16:27:16 UTC
I think the standard way to show this is with a dotted underline (that's how it shows up in a Java text component such 
as JTextArea).  It would be nice if NetBeans was consistent with this.  As you are moving through possible 
replacements, the characters that would be replaced should also be highlighted.
Comment 18 Ken Frank 2007-08-22 16:41:20 UTC
Vitezslav,

I'll look at it.

one comment - since this issue was filed, I believe jdk has implemented or refined its api and functionality
as to how to interact with os specific input servers and tools of different languages - 
thus I think best solution could be to use those api and to have the behavior be the
same as would be for user using other tools on that specific OS.

and even for each locale, there are a variety of input tools and methods, and using the jdk api
can help ensure behavior will follow user expectations of those.

and as mentioned in other comment, it mentions about a dotted underline, which I think is for windows - 
on solaris I see a full underline; but I think by using the way other parts of nb does it,
that the solution can be consistent within nb and also with other applications/tools of a given OS.

ken.frank@sun.com

(I am assuming rest of nb uses this approach but not sure.)
Comment 19 Vitezslav Stejskal 2007-08-22 17:44:46 UTC
The problem with underline (dotted, solid, wave, etc) is that there are already many cases where underlining is used for
indicating various things in the editor, eg. errors, warnings, hyperlinks, etc. I don't think that having yet another
type of underlining for entering multibyte characters would help users to distinguish what is going on.

I know nothing about input methods and related jdk APIs, could you please point me to some docs? How much is this
actually relevant to this problem? What I think we only need is a reliable way of recognizing that some text entered in
a document is multibyte. This is currently indicated by a special attribute sent from swing (JTextComponent I assume) to
the document's insertString method. IMO this is all we need and the way how this is done in JTextComponent is up to
swing/jdk, right?
Comment 20 Ken Frank 2007-08-22 18:37:14 UTC
good point about the underlining and possible conflict with other notations.

here are some ptrs to input api and docs:

http://java.sun.com/javase/6/docs/technotes/guides/intl/overview.html#inputmethod

http://java.sun.com/javase/6/docs/technotes/guides/imf/index.html

http://java.sun.com/javase/6/docs/technotes/guides/imf/overview.html
with intro, api and tutorials

http://java.sun.com/javase/6/docs/api/ - class InputMap and related classes with that name

ken.frank@sun.com


Comment 21 Masaki Katakai 2007-08-27 03:54:40 UTC
It's the great first step!

The visual feedback consists of some feedbacks type e.g. underline and highlight, not just highlight.

I think we can use AttributedCharacterIterator to represent the text during composing.

	http://java.sun.com/javase/6/docs/technotes/guides/imf/overview.html#Input%20Method%20Support%20in%20Other%20Frameworks

We can get the text attribute of composed text as AttributedCharacterIterator

	http://java.sun.com/javase/6/docs/api/java/text/AttributedCharacterIterator.html

through InputMethodListener

	http://java.sun.com/javase/6/docs/api/java/awt/event/InputMethodListener.html

1. Add InputMethodListener to Editor
2. Get AttributedCharacterIterator in the listener

        AttributedCharacterIterator text = evt.getText();

3. Use "text" to draw the composed text
4. Disable syntax analysis during the composing
5. Once composed text is entered(committed), restart syntax analysis

I attach a simple project that demonstrates how to get the AttributedCharacterIterator and how go get the text attribute.
See jTextArea1InputMethodTextChanged(). Is it possible to use AttributedCharacterIterator text for drawing the text?
The "text" can be used in drawString() directly but I'm not sure if it can work in NetBeans in this case.

	http://java.sun.com/javase/6/docs/api/java/awt/Graphics2D.html#drawString(java.text.AttributedCharacterIterator,%20int,%20int)

> The problem with underline (dotted, solid, wave, etc) is that there are already many cases where underlining is used for
> indicating various things in the editor, eg. errors, warnings, hyperlinks, etc. I don't think that having yet another
> type of underlining for entering multibyte characters would help users to distinguish what is going on.

As I mentioned above, please try to use the text attribute of AttributedCharacterIterator as they are.

Then, please try to disable syntax analysis (and rendering errors, warnings, hyperlinks stripe) *during* composing.

"composing" means that the text is not entered yet into the editor, so we should not start syntax analysis and should
not draw such stripes with the composed text.
Once the text is entered (composing is finished and text is inserted), let's restart the syntax analysis.

Comment 22 Masaki Katakai 2007-08-27 04:04:24 UTC
Created attachment 47425 [details]
sample project for how to get text attribute of composed text
Comment 23 Masaki Katakai 2007-08-27 04:07:34 UTC
Created attachment 47428 [details]
screenshot of imsample
Comment 24 Vitezslav Stejskal 2007-08-27 13:44:37 UTC
Hi Masaki, thanks for your suggestions and code sample. We will see what more we can manage to do in Nb6, but I am
afraid the change would not be that simple. I'll open a new enhancement request to make sure that we don't forget it.
Comment 25 Vitezslav Stejskal 2007-08-27 13:49:50 UTC
See issue #113844.
Comment 26 Masaki Katakai 2007-08-27 15:05:52 UTC
Hi vstejskal,

Thank you for evaluation, but I didn't say it's working. It's still not working,
there is no workaround and it's really serious for users. The text attribute for
both highlight and underline need to be provided for users to distinct which
part is current target for conversion or not.

Please see the screenshot,

http://www.netbeans.org/nonav/issues/showattachment.cgi/47428/imsample.jpg

The first 4 characters are displayed in highlight, which means it's current target
for conversion. Other 2 characters are displayed with underline, which means
it's not current target but it's still being composed.

We have to understand the difference by the visual feedbacks.

With the latest daily build, these whole 6 characters are displayed in highlight.
It's not possible to distinct which part is target for conversion, which part
is still remaining.

I'd like to ask you to reopen this bug report. I understand it's not simple fix too,
but I think the this bug report should be used because it's still not working.
Or if you want to use issue #113844, it should be changed to DEFECT from ENHANCEMENT
and priority should be P2, because it's not enhancement request.

Comment 27 Vitezslav Stejskal 2007-08-28 10:14:06 UTC
Oh, I see, I must have misunderstood your previous comment. I'm sorry for that. Obviously opening the new RFE makes no
sense if this defect has not been fixed properly.
Comment 28 Vitezslav Stejskal 2007-08-28 14:21:40 UTC
Masaki, could you please tell me what keys (on the normal US keyboard) I should press to get the characters from your
example?

I think I found a way of passing the attributes to our (Netbeans) DrawEngine, but all I have been able to get so far was
the underline event. No input method event with the highlight event. The way I'm talking about does not use G.drawString
so there might be some discrepancies between Netbeans and other java applications (ie. the highlights and underlining
might look slightly different), but the main concept should work.
Comment 29 Masaki Katakai 2007-08-28 15:49:58 UTC
Hi Vita,

If you could login to desktop and start NetBeans IDE in proper Japanese locale,
Ctrl+SPACE should enable composing mode.
then, try to type
masakikatakai
and hit SPACE key. Some of them should be displayed in highlight, others with underline.
Comment 30 Vitezslav Stejskal 2007-08-28 16:19:51 UTC
Hi Masaki, I've just committed another fix that should now do pretty much the same as what your demo (JTextArea) does.
Could you please try it and let me know if it is acceptable?

Since our DrawEngine does not use G.drawString I had to translate the highlights used by the input methods to the
highlights understood by the DrawEngine. Therefore the appearance is not exactly the same as in JTextArea, but should be
close enough.

If you find that something is wrong, could you please run Netbeans with
-J-Dorg.netbeans.modules.editor.impl.highlighting.ComposedTextHighlighting.level=300 and attach the log file here (or
send it to me directly). It should contain highlights from the input methods and how they were translated. Thanks


Checking in HLFactory.java;
/cvs/editor/src/org/netbeans/modules/editor/impl/highlighting/HLFactory.java,v  <--  HLFactory.java
new revision: 1.5; previous revision: 1.4
done
Checking in ComposedTextHighlighting.java;
/cvs/editor/src/org/netbeans/modules/editor/impl/highlighting/ComposedTextHighlighting.java,v  <-- 
ComposedTextHighlighting.java
new revision: 1.2; previous revision: 1.1
done
Comment 31 Vitezslav Stejskal 2007-08-29 10:48:13 UTC
Some useful links from Ken:

How to setup english windows to run in other locales:
http://devtools.sfbay/teams/DeveloperTools_I18N/windows.usingasianlocales.html

How to setup solaris to run in other locales:
http://devtools.sfbay/teams/DeveloperTools_I18N/setuplocale.solaris.part1.html
http://devtools.sfbay/teams/DeveloperTools_I18N/setuplocale.solaris.part2.html
Comment 32 Masaki Katakai 2007-08-30 06:11:14 UTC
Created attachment 47784 [details]
patch to use InputMethodHighlight to determine UNDERLINE or REVERSE, not from TextAttribute
Comment 33 Masaki Katakai 2007-08-30 06:23:34 UTC
Hi Vita,

It's great!! It almost works!! The syntax analysis is also disabling during the composing! Super!!

I found one issue that some visual feedbacks are not working properly with one commercial Japanese Input Method engine
on Windows.

The engine seems to use two types in underline.

	TextAttribute.UNDERLINE_LOW_DOTTED
	TextAttribute.UNDERLINE_LOW_GRAY
	
In these cases, it always returns highlightUnderlined from below,

   if (styleAttrKey == TextAttribute.INPUT_METHOD_UNDERLINE) {
	LOG.fine("Underline ... " + imh); //NOI18N
	return highlightUnderlined;
   }

So I can not see the difference. 

But these are the exact text attributes on screen that may depend on platform and engine. So let's use abstract
attribute of InputMethodHighlight. We don't need to use the exact text attribute here. We are using just two types -
underline and reverse.

I understand it's enough for us to prepare just two styles. I know GTK2 has only underline and reverse. Mozilla/Firefox
is also using just two styles. It should be OK.

We can use InputMethodHighlight to determine underline or reverse, like

if (imh == InputMethodHighlight.SELECTED_CONVERTED_TEXT_HIGHLIGHT) {
    return highlightInverse;
} else if (imh == InputMethodHighlight.SELECTED_RAW_TEXT_HIGHLIGHT) {
    return highlightInverse;
} else if (imh == InputMethodHighlight.UNSELECTED_CONVERTED_TEXT_HIGHLIGHT) {
    return highlightUnderlined;
} else if (imh == InputMethodHighlight.UNSELECTED_RAW_TEXT_HIGHLIGHT) {
    return highlightUnderlined;
}

I attached the patch. Please review and integrate.

I tested the patch with available input method engines here on Solaris, Windows and MacOS X. Once the patch is
integrated and binary is ready, I will ask local community folks for testing.
Comment 34 Vitezslav Stejskal 2007-08-30 11:14:47 UTC
Hi Masaki, thanks for the patch. I think that when using just InputMethodsHighlight the code can be even simpler, just
using IMH.isSelected() to determine if the highlight should be 'underline' or 'inverse'. It's simpler and should work
even  with future IMH constants (if there are any new at all). I'm marking this as fixed, but please reopen it if you
find some problems during the community testing. Thanks.

Checking in ComposedTextHighlighting.java;
/cvs/editor/src/org/netbeans/modules/editor/impl/highlighting/ComposedTextHighlighting.java,v  <-- 
ComposedTextHighlighting.java
new revision: 1.3; previous revision: 1.2
done
Comment 35 Masaki Katakai 2007-08-30 13:53:21 UTC
I'm checking hudson-trunk-2895, now it works perfectly for me :-) Great!! Thank you very much!!

Once we get new nightly build, I'll ask testing to local community folks.
Comment 36 takakura 2007-09-03 14:04:54 UTC
it works fine on osx.
thank you, Vita!!
Comment 37 Masaki Katakai 2007-09-04 11:13:33 UTC
One issue has been reported from community, I filed as bug 114595.

  114595 : I18N: Underline can not be rendered properly when editor font is customized

After he customized the Editor font to one Japanese font, underline can
not be rendered properly.

It seems that underline can not be rendered generally when we use
the font on NetBeans Editor. See the bug report. I have verified the
same problem happens on NetBeans 5.5.1. It means the issue is not
related with this fix, but unfortunately it's happening when we use input method.
Comment 38 Masaki Katakai 2007-09-05 08:12:40 UTC
Hi Vita,

I filed an another problem for caret rendering.

bug 114712 : I18N: caret is not rendered at all during composing Japanese

Do you have any idea?