FAQ
Cover
\
Build
\
Source
\
Bugs
\
Reference
\
Libraries
\
Tools
The bugs database has moved
here
.
Bug 854 : implement input method support for Japanese (and other languages)
Last modified: 2010-02-16 13:49
P
roject:
processing
trash
Version:
unspecified
Co
m
ponent:
android
book
core
libraries
pde
reference
tools
web
Status:
RESOLVED
Resolution:
FIXED -
Pr
i
ority:
P2
Severity:
normal
Platform
All
O
S:
All
Windows
Mac OS
Linux
Other
Reporter:
franklin
Assigned To:
Takachin
Attachment
Type
Created
Size
Actions
Fix for Japanese input problem for Mac OSX
patch
2010-01-29 11:05
6.98 KB
A capture image works on Mac OSX with Japanese inline input support.
image/png
2010-01-29 11:08
40.04 KB
Fix for exception when hitting space key first time.
patch
2010-01-31 08:08
518 bytes
Update for Japanese Input method.
patch
2010-02-14 08:14
40.97 KB
Description
: Opened: 2008-07-22 19:57
In 0135, you can input japanese characters into a pde file in the
processing env by just switching to japanese mode and then typing in your
characters. Now in 0142, this doesn't seem to work. Instead the romanji
(english) is typed out in the file. I'm using OSX 10.4.11. PowerPC G5.
It is strange because 0142 should support unicode better.
It looks like this on 0135: 私の問題
and it looks like this on 0142: watashinomondai
Additional Comment
#1 From fry 2008-07-23 14:48
Hm, I had written an entire response to this that seems to have been lost.
You're right, 0142 should be much better. However the change you're seeing
is that Apple is doing something differently in Java 1.5 versus Java 1.4
with regard to setting the input method. Release 0136 and later use Java
1.5, and we've not changed anything with regards to the text editor between
these releases. Perhaps check in Apple's Java release notes?
If you find anything, please let us know so that we can help out others
with the same problem. Thanks.
Additional Comment
#2 From fry 2008-08-16 15:30
No followup for three weeks, closing bug. I assume this is a change in how
Apple is handling input methods in more recent Java releases. (So it's an
OS setting, not a Processing bug.)
Additional Comment
#3 From Takachin 2010-01-29 11:05
edit
]
Fix for Japanese input problem for Mac OSX
Hi, I made a patch for this problem.
On Mac OSX 10.4, Java Input Methods specifications were changed.
(Please see Radar #4527629 in
http://developer.apple.com/mac/library/releasenotes/Java/Java104R5RN/ResolvedIssues/ResolvedIssues.html
)
Due to fix of Radar #4527629 by Apple and Processing runs on JVM 1.5, PDE does
not receive Japanese input method event. So Japanese input did not work on
Processing 1.0 on Mac OSX.
To escape from this problem, I needed to Java implement Input Method Framework.
(Please see Input Method Framework
http://java.sun.com/j2se/1.5.0/docs/guide/imf/
)
Therefore, I implemented it for PDE. It works well for OSX. As a byproduct, I
supported inline input for Japanese input method. Latest Processing is not
inline with Japanese. But this patch will give us more comfortable Japanese
input not only Mac OSX, but also maybe Windows.
I checked it work on Mac OSX 10.5.8 with Processing SVN 6040.
But not checked on Windows environment.
If you assign this problem to me, I'll check it on Windows.
Could you please reopen this bug and accept this patch ?
Moreover, I am a Japanese so I would like to take this bug :)
Additional Comment
#4 From Takachin 2010-01-29 11:08
edit
]
A capture image works on Mac OSX with Japanese inline input support.
Additional Comment
#5 From fry 2010-01-29 11:22
thanks for the patch!
i'm getting the following error when typing on my snow leopard machine:
(this is after typing 'roppongi', and in the midst of it trying to finish
the replacement)
java.lang.reflect.InvocationTargetException
at apple.awt.CToolkit.invokeAndWait(CToolkit.java:1119)
at apple.awt.CToolkit.invokeAndWait(CToolkit.java:1093)
at apple.awt.CInputMethod.attributedSubstringFromRange(CInputMethod.java:513)
Caused by: java.lang.IllegalArgumentException: Invalid substring range
at
java.text.AttributedString$AttributedStringIterator.<init>(AttributedString.java:739)
at java.text.AttributedString.getIterator(AttributedString.java:566)
at apple.awt.CInputMethod$1.run(CInputMethod.java:532)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
at apple.awt.CToolkit$CPeerEvent.dispatch(CToolkit.java:1175)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:633)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
however there is hopefully something small that's causing it. i wouldn't be
surprised if there are problems with how it interacts with the
EditorListener class, because it's not expecting words to change from
underneath it.
i've checked the code into the subversion repository, so please debug when
you have time, and we'll have this in the next release.
thanks again for your help!
Additional Comment
#6 From Takachin 2010-01-29 11:30
Thank you for accepting my patch !
But you got an error... It's uncool for me :(
I'll also fix it as soon as I can.
Additional Comment
#7 From fry 2010-01-29 11:48
i tried turning off the EditorListener but that didn't fix it, so it might
actually be in JEditTextArea too. it seems that it's caused by hitting the
space bar (perhaps related to the menu coming up?) i'm also not adept with
japanese, otherwise i would try to help more.
thanks again for your help, it's very much appreciated.
Additional Comment
#8 From Takachin 2010-01-29 16:42
it maybe caused by composing text lengths is different.
When you typed "roppoingi" this text length is 9. But after hits spacebar,
this text will change into "???" and the length of "???" is 3.
So "Invalid substring range" error happen.
This text length is managed by "committed_count" variable in InputMethodSupport class.
But it's variable will return wrong number. I'm not care the changes of this length :(
I'll fix it and attach additional patch soon.
Additional Comment
#9 From Takachin 2010-01-31 08:08
edit
]
Fix for exception when hitting space key first time.
I fixed this problem when composing and hits space bar.
You can input "roppongi" in Japanese.
I attached a patch to fix. Please see moreFix_01.patch
But I don't fully understand why this code can work correctly.
I need to more understanding how JEditTextField works.
Moreover, I found a problem with my implementation.
When composing and inserting some characters in mid-sentence with Japanese,
behind characters are hidden... So I need to more fix in InputMethodSupport
class.
It maybe three or four days because I will do it after I come home from work.
Is this OK ?
So if this change will take more time and affect to your release schedule,
Could you please revert these changes before applying patch ?
Additional Comment
#10 From fry 2010-01-31 08:14
Yes, just let me know when you have a newer version. I don't anticipate
doing a public release this week, so that's not a problem. Thanks again for
your help!
Additional Comment
#11 From Takachin 2010-02-14 08:14
edit
]
Update for Japanese Input method.
I just updated Japanese input method patch. (Sorry for a few weeks late!)
This patch will fix previous mid-sentence insertion problem.
This patch is tested on Mac OSX 10.5.8(JRE1.5) and WindowsXP JRE1.5.
Details about implementations are written in Javadoc comment.
Especially, please check workaround code of TextAreaPainter's paintLine.
If there are some problems or questions, please feel free to contact me.
Additional Comment
#12 From fry 2010-02-16 13:49
thanks so much. i've now integrated the code into svn and you can see how
it's working.
i'll now close this bug and mark it as fixed. if there are bugs that appear
in the code, please just file new reports for them so that they can be tracked.
thanks again!!