Rotmos
January 14, 2022, 5:52pm
1
I’m on Pop Os! writing in japanese characters using ibus with mozc and it works great. Anki it playes nicely with anki, but when adding and editing notes my ibus crashes as soon as i write anything and i have to switch to my default input method for it to reset.
Any idea why this would exclusive to ankis note fields? All other inputfields, i.e the search bar, works just fine. Another wierd thing is that it sometimes doesn’t chrash if there already is some japanese text in the field before writing.
Which Anki version are you using?
dae
January 16, 2022, 6:22am
3
Please make sure you always hit enter to remove the underline/popup before clicking into a different field/adding a note/etc, as performing actions while there’s a pending string can cause the toolkit to bug out. You could also try the latest qt6 beta version to see if it helps at all. https://betas.ankiweb.net/
mvf
January 21, 2022, 2:01pm
4
Sounds like a mozc issue that was fixed a while back. Not sure of the exact fix version, but updating to mozc 2.26.4472.100 should do the trick.
Relevant GitHub issues:
opened 02:43AM - 27 Jun 21 UTC
closed 02:31PM - 03 Jul 21 UTC
c.f https://bugs.launchpad.net/ubuntu/+source/anki/+bug/1931554
When I start ty… ping hiragana into an "add card" window in the anki flashcard app on Ubuntu an uncaught C++ exception is thrown from mozc_engine.cc:207.
Steps to reproduce are:
1. Open anki and start adding a card to a deck
2. Type aimasu
Expected behaviour: あいます appears, and other options such as 会います are presented as a dropdown
Actual behaviour: あmasu appears ("i" is dropped), the dropdown freezes until I switch to english and back to japanese, and ubuntu records a crash of the ibus-engine-mozc process
Anki is essentially a python program using a QT widget set. I'm still not 100% sure whether the problem is fundamentically in the widget providing wrong information to the input method or whether the input method is failing on its own. I haven't found any other cases of the input method malfunctioning outside of this text entry field. This happens both with the standard ubuntu packaged version of anki and the version available for download directly from https://apps.ankiweb.net/
The code is attempting to assign the text from the end of the current selection to the end of the string to the info->following_text variable. Based on my debugging I think that the surrounding_text string is empty, but the selection region appears to be starting at 1 instead of 0. Not knowing much about how this code is supposed to work I've not been successful yet in identifying the root cause, but this used to work correctly before I upgraded recently to Ubuntu 21.04, so it seems likely that this is due to a change that has happened some time in the last 12 months either in anki, QT, or mozc.
Stack trace snippet from gdb:
10 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::assign<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, void>(__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >)Python Exception <class 'gdb.error'> value has been optimised out:
Python Exception <class 'gdb.error'> value has been optimised out:
(__last=, __first=, this=0x7ffc45391578)
at /usr/include/c++/10/bits/basic_string.h:1471
#11 mozc::ibus::(anonymous namespace)::GetSurroundingText(_IBusEngine*, mozc::ibus::SelectionMonitorInterface*, mozc::ibus::(anonymous namespace)::SurroundingTextInfo*) [clone .part.0] [clone .constprop.0]
(engine=<optimised out>, selection_monitor=<optimised out>, info=0x7ffc45391530) at ../../unix/ibus/mozc_engine.cc:207
#12 0x000056510ef5e7c8 in mozc::ibus::(anonymous namespace)::GetSurroundingText
(info=0x7ffc45391530, selection_monitor=<optimised out>, engine=0x56510fc2c410) at ../../unix/ibus/mozc_engine.cc:170
#13 mozc::ibus::MozcEngine::ProcessKeyEvent(_IBusEngine*, unsigned int, unsigned int, unsigned int)
(this=<optimised out>, engine=<optimised out>, keyval=<optimised out>, keycode=<optimised out>, modifiers=<optimised out>)
at ../../unix/ibus/mozc_engine.cc:377
opened 09:08AM - 17 Jun 21 UTC
closed 11:21AM - 17 Jun 21 UTC
Since I upgraded ubuntu to 21.04 I am seeing what appears to be a bad interactio… n between the Japanese input method and anki or QT, I'm not sure. Japanese hiragana input works by typing the roman characters that make up a word. After typing a few characters you'll get suggestions for the correct Japanese text.
For example, I type the characters for "aimasu", which will appear on screen as あいます, with the suggestion that I probably meant 会います which I can select from a drop-down.
Since upgrading when I type the first character into the anki "Add card" dialog I see the first hiragana あ appear correctly, the "i" character appears to be ignored and maybe is the place things fail, followed by the roman characters for "masu". In other words, aimasu appears on the screen as あmasu as opposed to the correct あいます. The drop-down I would normally expect to see appears only for the あ character and then gets stuck on the screen until I switch back to an English input method and back again to Japanese. I can't enter the full Japanese text, although my web browser and terminal window are able to accept Japanese text without any issues. I can also type normally into the search box within anki for browsing cards, so it seems to be something special about the add card dialog that is causing issues.
My input method shows in the UI as "Japanese (Mozc)" with input mode "hiragana".
c.f. https://bugs.launchpad.net/ubuntu/+source/anki/+bug/1931554
1 Like
Rotmos
January 25, 2022, 11:31am
6
Seems like that version isnt available as an ibus package yet, guess i’ll just have to wait for the nex update from my ppa. (don’t want to compile it for myself)
mvf
January 26, 2022, 11:08am
7
You could switch to fcitx-mozc or fcitx5-mozc. I did some years ago and never looked back. It has a different look (highly customizable if you hate it), but I never once had any issues or glitches with it. IBus seems to be less reliable across updates with Qt apps in particular, presumably since the IBus IME plugin is part of Qt itself, whereas Fcitx is its own IME.
If you want to stay on IBus and can get ahold of old packages, mozc <=2.23.2815.102 is not yet affected by this issue. Old mozc versions also have the advantage of handwriting input support via tegaki-zinnia.
1 Like