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.
Summary: | I18N - visual feedback to user on inputting multibyte, the intermediate words are not underlined. | ||
---|---|---|---|
Product: | editor | Reporter: | Ken Frank <kfrank> |
Component: | -- Other -- | Assignee: | issues@editor <issues> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jf4jbug, jkovar |
Priority: | P2 | Keywords: | I18N |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
sample project for how to get text attribute of composed text
screenshot of imsample patch to use InputMethodHighlight to determine UNDERLINE or REVERSE, not from TextAttribute |
Description
Ken Frank
2001-08-17 17:25:50 UTC
Target milestone -> 3.3.1. Set target milestone to TBD Set target milestone to TBD 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? 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 At this time only P1s and P2s are allowed to be integrated into newly created branch "release35". Changing target milestone to 4.0 Changing the milestone to promoD. Changed target milestone to TBD. Not sure when we will be able to improve the situation regarding this. Setting TM to future for now. 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. 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 *** Issue 37032 has been marked as a duplicate of this issue. *** I will attempt to make a HighlightsLayer implementation for the offset range of the input method. 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 Waiver request: We will not be able to implement this for 6.0 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 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. 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.) 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? 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 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. Created attachment 47425 [details]
sample project for how to get text attribute of composed text
Created attachment 47428 [details]
screenshot of imsample
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. See issue #113844. 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. 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. 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. 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. 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 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 Created attachment 47784 [details]
patch to use InputMethodHighlight to determine UNDERLINE or REVERSE, not from TextAttribute
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. 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 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. it works fine on osx. thank you, Vita!! 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. 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? |