GNOME Bugzilla – Bug 737582
Fix Kotoeri text entry for Japanese
Last modified: 2018-05-24 14:44:01 UTC
Created attachment 287339 [details] Kotoeri working in LO Kotoeri is the default IME on OSX for Japanese, it offers, amongst other things, Latin to Kana/Kanji conversion. This is what should happen: 1 Go to settings and add Japanese as a language, ensure that under input sources for kotoeri "Romaji" (i.e. Latin) is selected for typing method (unless you have a Japanese keyboard) 2 Open any program (I tested the Google search box in Firefox and LibreOffice) 3 Top right of screen, change the UK/US/whatever flag to Japanese (will show a Hiragana あ) 4 Start typing. It should convert Romaji to Kana/Kanji automatically e.g.. shamisen > 三味線 sushi > すし (for testing just pick any Japanese terms off wikipedia if you don't read Japanese) In the staging version (http://download.gimp.org/pub/gimp/v2.8/osx/staging/) of GIMP, the conversion does not work, it simply enters the Romaji i.e. Latin letters. I have attached 2 screenshots of what should happen and what actually happens in Gimp.
Created attachment 287340 [details] Kotoeri not working in Gimp
Hi, When you say it does not work in the staging version, do you mean it does work in any previous release? As said on the mailing list, this may just be a bad configuration of the GTK+ build in recent builds. GKT+ has to be build with --with-included-immodules=yes
Just tried using the current release, similar problem. 1) Romaji > Hiragana/Katakana conversion is not displayed, the user has to hit enter and hope the top suggestions is correct. 2) Romaji > Kanji conversion partly works but is off to the bottom left corner of the screen similar to the Pinyin problem (Bug 737583).
> 1) Romaji > Hiragana/Katakana conversion > [...] > 2) Romaji > Kanji Ok so you are saying that there is a suggestion window for Kanji (simply badly placed, cf. bug 737583), but there is a different mode for hiragana and katakana? And in these other modes, there is no suggestion box? Well in this case, I guess that's normal. There is a 1-1 correspondence between "romaji" and hiragana (as well as between "romaji" and katakana). So if this IME proposes specific modes for these 2 sillabaries, then no suggestion box is needed. Only for kanji (or a mode for the whole Japanese language, including the 3 character types) is a suggestion box needed, which is apparently what happens according to your point 2.
No, it is the same mode. It is used to convert the latin letters on a non-Japanese keyboard to either Kanji or Kana as appropriate. So if you type s-u-s-h-i it will offer you - Hiragana すし - Kanji 寿司 or sometimes a mix, depending on, so if you type k-a-e-r-i-m-a-s-u you get - かえります (all Hiragana) - 帰ります (one Kanji plus Hiragana)
Well ok. We'll need to get a dev with OSX and caring about Japanese IME to check this then. Unfortunately this may take quite a while, so don't hold your breath. For my own, I don't own an OSX machine. Someone else could confirm this issue please and maybe has some input on the cause of it?
When configured with --with-included-immodules=yes gtk 2.24.24 doesn't build on OS X 10.9.4 (Xcode 5). The build breaks on imquartz.c. It seems that the cpp flag -xobjective-c is missing.
ok, I've added --with-included-immodules=yes to INCLUDES and the compile went fine. I followed the above steps... still doesn't work.
Hi Simone, To be sure there is no misunderstanding, when you say "still doesn't work", you mean you don't have the suggestion window, whereas you have one when using the same input method in another software? If so, I'm not sure how that would work for OSX. Maybe some specific third-party packages are needed, similar to an ibus-gtk package as we have on Linux, but instead of ibus, something else of course (quartz-gtk?). Well if anyone has the answer, this would be welcome. By the way, for the build break on imquartz.c that you reported, did you fix it with some patch? If so, I think the GTK+ project would appreciate the patch. Thanks.
Jehan, could this be fixed by your latest IM fixes?
I don't have access to any OSX machine, otherwise I would be happy to check. I assume that if GTK+ supports OSX's IME, it should work. Nevertheless in the screenshot (comment 1), one can see that just nothing happens. If the GTK+ IME API returned a preedit text, even with old code, it should have at least been displayed in our old-fashioned overlay box, and the ASCII text should not have been inputted in the text box. So my guess is that either GTK+2 support for OSX IME is broken, or there is a build option/dependency problem. Which means probably this is not fixed. But once again, I cannot test.
I've just tested GIMP 2.8.16 on a MacBook Air. The problem is partially solved. It seems that if the suggestion contains at least one Kanji, it is displayed. If the solution contains only Hiragana or Katakana, the suggestion is not displayed (though if I just hit enter, it seems to input the combination I was hoping for), i.e. if I type s-u-s-h-i, nothing is displayed but if I hit Enter, I get すし (Hiragana only). If I type k-a-e-r-i-m-a-s-u I see 帰ります (1 Kanji + 3 Hiragana), if I hit enter, I get the かえります (all Hiragana) option which had not been displayed, if I click on 帰ります, the suggestion is entered correctly. It seems we're on the right track but not quite there yet.
Michael Bauer > Thanks for the input. In GIMP 2.8, I see only a commit in 2014 which was fixing the placement of the preedit window. So maybe all what the problem was (and still is partially) could be that the preedit window was like so wrongly placed that it can't be seen (i.e. out of the screen for instance)? If this is the case, yes my fixes may have dealt with the problem. Would you have the possibility to build GIMP from the master branch and test it on OSX?
Created attachment 329485 [details] window placement You're welcome :) I don't think it's the window placement somehow. I created a new file and put the text window right in the middle. Also, when I try the Pinyin entry method for Chinese (which uses a lot more space vertically), behaviour is as expected. Also, if it was a window placement issue, then it should affect all three Japanese scripts, not just Kana i.e. why should it display k-a-e-r-i-m-a-s-u I see 帰ります but not s-u-s-h-i すし without me moving the window or anything? I'm afraid I'm not enough of a dev (I mainly a localizer) to build but if someone else does a build, I'm more than happy to install it and test it.
> I don't think it's the window placement somehow. I created a new file and put the text window right in the middle. You may never know what funky bug may be hidden sometimes! The fact you have a window right in the middle does not mean our code may not place the window in the wrong area. ;-) Part of the changes in 2.9 are that we don't have this ugly overlay window/popup/bubble anymore. Preedit text is displayed directly inside the text tool UI (here for a screenshot: https://twitter.com/LILA_asso/status/739829519272554500). So *if* (I am still not sure this is the issue) this was a problem of placement for this preedit text, it may be fixed in master. Actually your screenshots are very weird because I don't even see any preedit text at all, only the suggestion list. Are you saying that the third image (bottom) in your attachment is what is expected? Maybe OSX don't show any preedit text at all?… > I'm afraid I'm not enough of a dev (I mainly a localizer) to build but if someone else does a build, I'm more than happy to install it and test it. I think we will soon have a 2.9.4 dev release. I don't know if an OSX build is planned there, but if it is, you'll be able to test.
LOL a bit like acupuncture - headache? Sure, "2 needles in your big toe and one in the left elbow should fix that Sir". I never got any preedit text in Gimp, only LO when testing Kotoeri. I'll keep an eye on the releases then and when 2.9.4 is announced on the list, I'll give it a whizz if there's one for OSX. Feel free to prod me :)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/593.