[Question] Possible to (properly) implement simultaneous (custom) Kana-input layout?

[kirameister]

Dear Google mozc team,

I've been using Google IME and mozc for some time and would first like to express my appreciation for releasing them to the world.

Apart from the Roma-ji and Kana layouts, there are other (sadly not very well-known) layouts out there. One of such layouts is 新下駄配列, which is one of the simultaneous Kana-input layouts.

https://wpedia.goo.ne.jp/wiki/%E6%96%B0%E4%B8%8B%E9%A7%84%E9%85%8D%E5%88%97 (Japanese)

The idea is that one can type different Hiragana, when 2 keys are hit (almost) simultaneously. For example in 新下駄配列,

• 'k' => 'い'
• 'd' => 'か'
• 'dk' => 'れ' (when typed simultaneously, otherwise "かい")
• 'kd' => 'れ' (when typed simultaneously, otherwise "いか")

I've forked and modified the mozc source code and implemented the PoC version of this functionality: https://github.com/kirameister/mozc

Here's how it looks like when in practice :

• https://twitter.com/kirameister_ja/status/1412885637183721475
• https://twitter.com/kirameister_ja/status/1412886174398623748

I'm wondering someone in Google mozc team would be able to implement this functionality. I consider my implementation to be nothing more than PoC, and would greatly appreciate it if you could implement it properly.

Of course I'd be more than happy to provide any information required for the implementation.

Best regards, Akira K.

[hiroyuki-komatsu]

Hi Akira,

Thank you for your warm words. I'm glad that Mozc is used for your input method.

To understand the logic of 新下駄配列, please let me ask some questions.

Here are preconditions of the questions.

• [K↓:10] means 'K' key was pressed after 10 millisecond from the first event.
• 100 milliseconds is the time threshold.

How to determine whether the two keys are pressed simultaneously or not.

Would you tell me if the following cases are determined as simultaneous input or not, or either is fine.

1. [D↓:0][K↓:10][D↑:20][K↑:25]
2. [D↓:0][K↓:10][K↑:20][D↑:25]
3. [D↓:0][K↓:200][D↑:210][K↑:220] (over the threshold)
4. [D↓:0][D↑:10][K↓:20][K↑:30] (within the threshold, but not overlapped)
   • If this is a simultaneous input, Which is "DKD" treated as "れか" or "かれ"?

Time threshold

1. Is 100 milliseconds the default number?
2. How often is this changed from the default? (= Is it acceptable not to be customizable?)

Implementation

Honestly speaking, we would not officially support additional input styles. On the other hand, it'd be nice if it is possible to customize input styles by customizing romaji composing rules or by applying patches to the code in a straightforward way.

Thank you,

[kirameister]

Hello Hiroyuki-san,

I am super excited to have your reply! Please find my replies to your questions below.

How to determine whether the two keys are pressed simultaneously or not.

As far as I understood the mozc code, there's no key-code event sent to the mozc_server when the key is released (i.e., the client-server communication is done only when a key is pressed). Please correct me if that's not the case.

Having said that, following is the expected output at least from my implementation:

1. [D↓:0][K↓:10][D↑:20][K↑:25]
   • れ
2. [D↓:0][K↓:10][K↑:20][D↑:25]
   • れ (but key-event sequence is exactly the same as 1.. Perhaps that's a typo?)
3. [D↓:0][K↓:200][D↑:210][K↑:220] (over the threshold)
   • かい
4. [D↓:0][D↑:10][K↓:20][K↑:30] (within the threshold, but not overlapped)
   • れ (what counts is the 3rd event [K↓:20], which is below 100 threshold.

• If this is a simultaneous input, Which is "DKD" treated as "れか" or "かれ"?
  • I understood this as something like [D↓:0][D↑:10][K↓:20][K↑:30][D↓:40][D↑:50]. If so, the output would be "れか" (and "か" would be stored in pending_ in Entry::Entry instance).

There are existing solutions for such simultaneous kana input. But (as far as I'm aware) none of them is implemented within the IME (therefore the timing when the key is released may need to be considered). In our context, we have the luxury to "update" what has already been rendered ("pending" vs. "result").

Time threshold

• Is 100 milliseconds the default number?
  • In my implementation, I've created another slot in the protocol where this time threshold is stored. The number 100 just came from my intuition, nothing more.
• How often is this changed from the default? (= Is it acceptable not to be customizable?)
  • I'm afraid it should be kept up to each end-user. Some may be fine with 50, others may need 200 (although I personally feel anything above 500 would do more harm than good, even for those who just started simultaneous kana input).
  • I was rather thinking of making the time-threshold for each simultaneous combination customizable (by adding anther column in the custom romaji-composition table -- more onto this point under Implementation below).

Implementation

I think I understand your position. On the other hand, I'm wondering following implementation-strategy would be feasible (in a sense if it could be accepted as "straightforward" patch):

1. Add one column in custom romaji-composition table (let's call it as prev_pending_limit), which is expected to be empty, or contain 0 or more integer value (if not qualified, the value will be discarded).
2. table.cc must be updated so that those values from the new (4th) column would be taken (so internally, Entry class would have another internal value to store).
3. As long as the prev_pending_limit of the entry is empty (or 0), or the elapsed time (from previous key-stroke) is equal or less than the value of prev_pending_limit, process goes as usual.
4. However, when the prev_pending_limit exists in entry and the elapsed time is greater than the value of prev_pending_limit, what was in the pending_ would be appended to conversion_ and then pending_ will be cleared. After that, process goes as before.

The advantages of above approach are:

1. The amount of changes in the internal data structure is kept minimal (e.g., protocol doesn't need to be changed).
2. We can let the end-user decide how much time (s)he would like to set as simultaneous threshold (for each combination!).

With that, the end user would need to update the custom romaji-table as following:

input	output	pending	prev-pending-limit
k		か
d		い
かd	れ		100
いk	れ		100

I hope this makes sense. From the outset, the content of the table may look a bit odd, but the existing romaji-table could be kept as is (and nothing would be different for those romaji-input users).

If any of my text above is unclear, or if you have anything you'd like to clarify, please let me know. Above implementation proposal is actually different from how I implemented it in my forked version. But if you'd think above is acceptable change (to the google/mozc repo), I'd be more than happy to do the implementation myself (although you'd most likely be faster and I'm most certain that your code would be cleaner than mine).

Best regards, Akira K.

[hiroyuki-komatsu]

Thank you for the detailed descriptions. They are very helpful.

How to determine whether the two keys are pressed simultaneously or not.

As far as I understood the mozc code, there's no key-code event sent to the mozc_server

Correctly speaking, mozc.commands.KeyEvent.ModifierKey has KEY_DOWN and KEY_UP. https://github.com/google/mozc/blob/master/src/protocol/commands.proto#L223

That's true that you don't need care about release events though.

1. [D↓:0][K↓:10][D↑:20][K↑:25]
2. [D↓:0][K↓:10][K↑:20][D↑:25] れ (but key-event sequence is exactly the same as 1.. Perhaps that's a typo?)

3rd and 4th events are swapped. I think the result is れ anyway.

[D↓:0][D↑:10][K↓:20][K↑:30] (within the threshold, but not overlapped) れ (what counts is the 3rd event [K↓:20], which is below 100 threshold.

If this is a simultaneous input, Which is "DKD" treated as "れか" or "かれ"? the output would be "れか" (and "か" would be stored in pending_ in Entry::Entry instance).

It's good to know. So the missing part is basically time threshold.

Time threshold

I was rather thinking of making the time-threshold for each simultaneous combination customizable (by adding anther column in the custom romaji-composition table -- more onto this point under Implementation below).

How much do you customize the time for a single simultaneous input? If it is possible would you share your configurations for the reference?

Implementation

Romaji-composition table already has 4th column, named as 'attributes'. https://github.com/google/mozc/blob/master/src/composer/table.cc#L423

You can probably use this 4th column for prev-pending-limit.

By the way, there is another way to make simultaneous input, if it is ok to use a single time threshold for all combinations.

Implementation with STOP_KEY_TOGGLING.

You might want to use the STOP_KEY_TOGGLING command. https://github.com/google/mozc/blob/master/src/protocol/commands.proto#L452

This command was introduced for the toggle input on mobile devices.

• If you tap "あ” twice within 1 second, "ああ" becomes "い".
• If you tap "あ" twice slowly longer than 1 second, "ああ" remains "ああ".

To achieve the above behavior, mozc_client for mobile sends a STOP_KEY_TOGGLING command to mozc_server after 1 second if no event happens.

The composing rule can be a reference. https://github.com/google/mozc/blob/master/src/data/preedit/toggle_flick-hiragana_intuitive.tsv

Strings inside {} are invisible. {!} indicates the STOP_KEY_TOGGLING command. The rules for you would be something like as follows. (I haven't confirmed them though).

input	output	pending	attributes
k		か	NewChunk
かd	れ
か{!}	か

Thanks,

[kirameister]

Hello Hiroyuki-san, Thank you very much for your reply!

Again, I'll try to put my thoughts one by one..

How to determine whether the two keys are pressed simultaneously or not.

Correctly speaking, mozc.commands.KeyEvent.ModifierKey has KEY_DOWN and KEY_UP. https://github.com/google/mozc/blob/master/src/protocol/commands.proto#L223

Ah, you're right! Apologies for missing those lines!

[D↓:0][K↓:10][D↑:20][K↑:25] [D↓:0][K↓:10][K↑:20][D↑:25] れ (but key-event sequence is exactly the same as 1.. Perhaps that's a typo?)

3rd and 4th events are swapped. I think the result is れ anyway.

Ah, again apologies for having missed that.. And yes, the expected output is "れ", which is determined on the 2nd event already.

Time threshold

How much do you customize the time for a single simultaneous input? If it is possible would you share your configurations for the reference?

Please find the following TSV file. Please notice that those lines with 4 columns (3 tab chars); those are the combinations where the top row of the keyboard (usually consisting numbers) is involved.

https://github.com/kirameister/mozc/blob/simul_kana_minimal_change_poc/src/data/preedit/shingeta.tsv

Please note that the value 200 is rather artificial; it may be that 150 may be enough. From my own experience (when I implemented simultaneous kana input in the past, before getting my hands onto the IME/mozc), I find it difficult to simultaneously type those keys, when one of them was on the top row, and thought it'd be nice to be able to customize the simultaneous threshold for each combination. However, it is nothing but "nice to have" feature and may not even be needed by most of the (potential) simultaneous kana-input users (at least I'm not aware of any existing solution, such as DvorakJ and やまぶきR where such a fine-grained configuration is possible). Personally, I'd be fine with not having this level of customizability, but being able to set a single threshold.

Implementation

You can probably use this 4th column for prev-pending-limit.

Yes, I thought of that when I was implementing my first PoC, and realized that it's been used with set of values (and that adding a new set of values may have unintended side-effect).

...However, now that I think of it again, one may actually update the existing set of values with much higher number, such that anything below those numbers would not have any impact on existing functionalities (i.e. updated internal representation would look something like the following):

enum TableAttribute {
  NO_TABLE_ATTRIBUTE = 1024,
  NEW_CHUNK = 2048,
  NO_TRANSLITERATION = 4096,
  DIRECT_INPUT = 8192,
  END_CHUNK = 16384,
};

Would you think it would work? One could set some sort of sanity-check (so that any value (even when it's numerical) below 1024 will be discarded. https://github.com/google/mozc/blob/master/src/gui/config_dialog/roman_table_editor.cc#L182

Implementation with STOP_KEY_TOGGLING

Thank you very much for your pointer! I never thought of using the mobile-device functionality, but this may be more straightforward solution.

I've tried what you suggested by updating the custom romaji-table (in original mozc package, not my modified version) with {?}か{!} [tab] か and か{!} [tab] か on the 3rd row. Unfortunately neither worked (it always ended up in "/kd/" => "れ" no matter how long I waited before typing 'd').

Which implementation-approach would be more acceptable?

The big question for me is which implementation-approach would be more likely to be accepted into the google/mozc codebase. I've actually started implementing my suggested approach, and my very personal preference is to continue my path with extra column in roman_table_editor.cc (as I understand the STOP_KEY_TOGGLING approach involves the client side, which will involve multiple platforms and I would not be able to test on every platform).

However, if you think STOP_KEY_TOGGLING has higher chances to be accepted into google/mozc, I'd be more than happy to change my course and start looking into the relevant code.

cf. https://github.com/kirameister/mozc/tree/simul_kana_minimal_change_poc/src

Best regards, Akira K.

[hiroyuki-komatsu]

(My reply would be next weekend or later. Sorry for your inconvenience).

[kirameister]

Understood && Thank you very much for leaving this note!

In the meanwhile, I'll try to do my homework by implementing my suggested version of implementation-approach, which I hope to be able to present before this weekend.

[kirameister]

Hello Hiroyuki-san ,

I've done yet another PoC implementation based on the approach that I proposed above (which is to add 4th column in the custom roman table, and use it for storing prev-pending limit by using the TableAttribute). You could see the list of the changes compared against the latest version of master branch of google/mozc:

https://github.com/google/mozc/compare/master...kirameister:simul_kana_minimal_change_poc?expand=1

And following is the STDOUT/STDERR output I observe by running the unit-test (command just copied from the instruction:

$ cd ~/src/mozc/src
$ bazel test base:util_test --config oss_linux -c dbg
bazel test base:util_test --config oss_linux -c dbg
INFO: Build option --compilation_mode has changed, discarding analysis cache.
INFO: Analyzed target //base:util_test (7 packages loaded, 846 targets configured).
INFO: Found 1 test target...
Target //base:util_test up-to-date:
  bazel-bin/base/util_test
INFO: Elapsed time: 50.267s, Critical Path: 5.30s
INFO: 310 processes: 126 internal, 184 linux-sandbox.
INFO: Build completed successfully, 310 total actions
//base:util_test                                                         PASSED in 0.0s
INFO: Build completed successfully, 310 total actions

From the outset, things seem to be working as expected. I'd greatly appreciate it, if you could tell me whether or not above changes could be considered as straightforward patch, which could reside within google/mozc codebase.

Best regards, Akira K.

PS: For now (until you'd become available this weekend or later), I'll keep using it and see if there's any bug / unexpected behavior I missed.

PPS: As for the other approach (to use STOP_KEY_TOGGLING), I'll try to see how this could be utilized, but cannot promise how much progress I'd be able to make before the weekend, as I'm not even sure which part of the source-code files are responsible..

[hiroyuki-komatsu]

Hi again, sorry for my late response. My future replies would be also on weekends only. Thank you for your understanding.

Time threshold

Thank you for the reference settings and background. I understood the simulation more. As the initial version, I'd like to minimize the modifications and the complexity. So I'd like to start from the version with a single threshold.

(Implementation)

This is not applicable, because I'd like to use a single threshold. It's just FYI.

In this case, I'd prefer adding key=value attribute and modifying the parser of the 4 column, rather than changing the enum value.

NewChunk TimeThreshold=100 NoTransliteration

Implementation with STOP_KEY_TOGGLING

I've tried what you suggested by updating the custom romaji-table (in original mozc package, not my modified version) with {?}か{!} [tab] か and か{!} [tab] か on the 3rd row. Unfortunately neither worked (it always ended up in "/kd/" => "れ" no matter how long I waited before typing 'd').

This requires to modify the client code to send the STOP_KEY_TOGGLING command.

Which implementation-approach would be more acceptable?

I'm still considering the best way to provide better customization (including simple code modification) minimizing the code complexity and the maintenance costs.

My current ideas are:

• Use a single time threshold.
• Base on the mechanism of STOP_KEY_TOGGLING.
• Add a new field of timestamp to CharChunk and KeyEvent.

(If I was able to start from the scratch, the ideas would be different from the above.)

I will try to add the timestamp fields to CharChunk and KeyEvent.

Unittests

base:util_test is a test for the base/ directory.

In this case, please check cc_test_mozc rules in composer/BUILD.bazel and composer/internal/BUILD.bazel.

For example:

bazel test composer:composer_test composer/internal:char_chunk_test --config oss_linux

If I overlooked some of your questions/comments, please feel free to let me know. Thank you,

[kirameister]

Hello,

I'm completely fine with only-on-weekend communication, as long as move towards the implementation. Thank you for taking your time on this issue!

I understand that approach with STOP_KEY_TOGGLING will be more realistic approach (i.e., less maintenance costs). While I understand, I still have few questions:

1. Does "single time threshold" mean a fixed time threshold? Given that code snippet you wrote above, that seems like the case. If that's indeed the case, I wonder if I could ask to set the fixed time threshold to 50 (milliseconds) -- after playing (typing) around with the other implementation, I felt 100/200 milliseconds were too relaxed (i.e., leading to more typos) and 50 would be more realistic value.
2. Who will be implementing this? I read that you intend to implement this feature with STOP_KEY_TOGGLING approach. If that's the case, I am absolutely grateful! Of course, I'd be willing to contribute to the implementation, but I still feel lost how exactly the implementation would be done with STOP_KEY_TOGGLING (so it'd most likely take considerable amount of time for me to get it done).

Best regards, Akira K.

PS: Thank you for pointing out about the scope of unit-test. There seems to be just a lot for me to learn :-)

[hiroyuki-komatsu]

Hello,

Does "single time threshold" mean a fixed time threshold? Given that code snippet you wrote above, that seems like the case. If that's indeed the case, I wonder if I could ask to set the fixed time threshold to 50 (milliseconds) -- after playing (typing) around with the other implementation, I felt 100/200 milliseconds were too relaxed (i.e., leading to more typos) and 50 would be more realistic value.

The default time threshold is probably 1000 msec. This is the current default value of STOP_KEY_TOGGLING used for the mobile input.

• I think the patch to change it 100 msec should be straightforward.
• It is still possible to customize the default in future, but please let me keep the current value while updating the code.

Who will be implementing this? I read that you intend to implement this feature with STOP_KEY_TOGGLING approach. If that's the case, I am absolutely grateful! Of course, I'd be willing to contribute to the implementation, but I still feel lost how exactly the implementation would be done with STOP_KEY_TOGGLING (so it'd most likely take considerable amount of time for me to get it done).

I or some of the Mozc team will implement it. I truly appreciate your PoC and kind offer for the implementation, however due to the internal policy, the files and directories we may accept pull requests are limited.

We start from refactoring of the composer/ directory. That refactoring changes perhaps break your patches first, but I believe it eventually improves code complexity and maintainability.

Thank you,

[kirameister]

Hello,

It is still possible to customize the default in future, but please let me keep the current value while updating the code.

Understood. I'm fairly certain the configurability of the threshold will be demanded once people start using it, but I'm completely fine with having the simultaneous input functionality at first, and worry about the time threshold configuration later.

I or some of the Mozc team will implement it.

Thank you so much!

due to the internal policy, the files and directories we may accept pull requests are limited.

I was/am aware of this policy. However, I felt somewhat obliged to provide with the code (just to show the code, letting alone the pull request), as I was the one who brought up this question (which one may consider more like a feature-implementation request) in the first place.

本当にありがとうございます。

Best regards, Akira K.

[hiroyuki-komatsu]

The commit 07c694e is a code refactoring. No behavior changes are expected yet.

The next commit (maybe next week) will add actual changes.

due to the internal policy, the files and directories we may accept pull requests are limited. I was/am aware of this policy. However, I felt somewhat obliged to provide with the code (just to show the code, letting alone the pull request), as I was the one who brought up this question (which one may consider more like a feature-implementation request) in the first place.

Indeed, it made me think of a good way to support the request.

本当にありがとうございます。

My pleasure :) Thanks.

[kirameister]

Thank you so very much! I'm already excited to see your next commit :-)

I wonder if this feature would be implemented (reflected) on the Google IME (Google 日本語入力) as well. If so, I assume the potential impact to the society as a whole would be non-trivial.

Best regards, Akira K.

[hiroyuki-komatsu]

Hi, the commit 296620c enables the simultaneous input with some configurations.

I hope new tests in composer_test.cc are helpful for you to see the necessary configurations. https://github.com/google/mozc/commit/296620c04addd2fded7e1196f1051e867318a678#diff-2929ed83234fe579e57c1bf6c7808894abd80d1b8c36dbcd854f413b68f508d7

The configurations consist of two things:

• Set 50 (ms) to Config.composing_timeout_threshold_msec
• Create a composing table with "{!}", which represents timeout.

We do not have a plan to make a GUI for those configurations at this moment.

I wonder if this feature would be implemented (reflected) on the Google IME (Google 日本語入力) as well. If so, I assume the potential impact to the society as a whole would be non-trivial.

We cannot promise any things about Google Japanese Input here, although most code is shared each other. Thank you for understanding.

If you have questions or problems for the configurations, please let me know. Thank you :-)

[kirameister]

Dear Hiroyuki-san,

Thank you very much for your implementation! Indeed, I still have few questions to ask..

1. Looking at the following lines, it seems that both timeout_threshold_msec and composing_timeout_threshold_msec are set to 0 by default (in the non-testing source code). I wonder if that was intentional.

• https://github.com/google/mozc/commit/296620c04addd2fded7e1196f1051e867318a678#diff-06ca74cb8922d274a2f1c4cd892a3488688462ce31cad30fa8c760046667a196R284
• https://github.com/google/mozc/commit/296620c04addd2fded7e1196f1051e867318a678#diff-c91e2c88434e76c14c3bdb5fc142dcd5730068ef3b61618d2eca2b7f61f0e0b6R322

2. I've locally modified above values to 50 and played around a bit (after importing the TSV file, of which the part of content is shown below). While the simultaneous-key logic seems to be working, I see "strange" chars inserted before the 1st char to appear in the preedit (pre-composition) (as shown in the attached screenshot).

q       ー
ー{!}    ー   
w       に
に{!}    に   
e       は
は{!}    は   
...
i       こ
こ{!}    こ   
d       か
か{!}    か   
...
かk  れ   
いd  れ   

Please note that the key-sequence is something like the following (both lines are practically the same; the 1st line is just to show what the output would look like after typing "Enter"):

[D↓:0][K↓:100][D↑:120][K↑:125] [D↓:200][K↓:210][D↑:250][K↑:260]

I wonder if there's something I've missed (wrong insertion of STOP_KEY_TOGGLING, for example..).

Best regards, Akira K.

[hiroyuki-komatsu]

Hello Akira-san,

Looking at the following lines, it seems that both timeout_threshold_msec and composing_timeout_threshold_msec are set to 0 by default (in the non-testing source code). I wonder if that was intentional.

Yes, this is intentional. If this value is 0, any behavior is not changed from the previous version. So we decided to keep it zero.

I see "strange" chars inserted before the 1st char

Ah, that's true. Please add the following line like toggle_flick-hiragana_intuitive.tsv

key	value	pending	attributes
{!}			NoTransliteration

I perhaps update the code not to require the above line later.

[kirameister]

Dear Hiroyuki-san,

Thank you very much as always for your reply!

Looking at the following lines, it seems that both timeout_threshold_msec and composing_timeout_threshold_msec are set to 0 by default (in the non-testing source code). I wonder if that was intentional.

Yes, this is intentional. If this value is 0, any behavior is not changed from the previous version.

May I ask if there's any way to modify the [composing_]timeout_threshold_msec value(s) without modifying the source code (for example, by manually updating a file under $HOME/.mozc/)? I'm asking this because..

• not being able to configure this value (apart from source-code update) would (most probably) introduce an extra hurdle for anyone (including myself, actually) to use this functionality.
• it would be a bit tricky to file a bug report -- when you get a bug report, you'd probably expect it to be filed with a version that was officially released, instead of a version of which the source code was locally modified; but this may not be such a big issue, as the number of codes to be updated should be 2 (with current status of codebase).

Ah, that's true. Please add the following line like toggle_flick-hiragana_intuitive.tsv

I presume you meant to append such a line in the TSV file (of which I showed the snippet in previous comment) and import it within "Romaji table". However, I didn't observe any change in behavior after doing that. Looking at the roman_table_editor.cc and generic_table_editor.cc, it seems to me that the attributes (or 4th) column is not read at all. I do see the lines of code to read the attribute(s) from the stream in src/composer/table.cc (within Table::LoadFromStream(std::istream *is)). Did you mean to add the line with NoTransliteration within the code, such that it'd be included as part of custom_roman_table?

We cannot promise any things about Google Japanese Input here, although most code is shared each other. Thank you for understanding.

Understood. I'll keep my fingers crossed that this functionality will be part of the Google Japanese Input in the future :-)

Best regards, Akira K.

[kirameister]

Dear Hiroyuki-san,

Just FYI, I've added a few lines to src/composer/table.cc (towards the bottom of Table::LoadFromStream(std::istream *is)) to artificially insert additional table entry with NoTransliteration and the strange behavior I described above seems to have disappeared.

Best regards, Akira K.

[hiroyuki-komatsu]

Hi Akira-san,

May I ask if there's any way to modify the [composing_]timeout_threshold_msec value(s) without modifying the source code (for example, by manually updating a file under $HOME/.mozc/)?

$HOME/.mozc/config1.db contains both Romaji table and composing_timeout_threshold_msec. The file format is binary protocol buffer. config/config_hander.cc is the code to access config1.db. (Note, the location may be $HOME/.config/mozc/config1.db).

There are some ways to modify config1.db.

Modify the GUI tool for config1.db.

As you previously modified it, you can add the composing_time_threshold_msec field to the GUI tool, and make the romaji table editor to append the special line of NoTransliteration on saving the data. The generated config1.db should be able to be usable on other environements.

Modify the config1.db file directly.

config1.db file is a binary protocol buffer. You can convert it to text protocol buffer, which is humanreadable format. After you modify the text protocol buffer, you can convert it to config1.db in binary protocol buffer.

To convert text and binary protocol buffer formats each other, you can write a script in C++, Python and other languges.

• https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.text_format
• https://googleapis.dev/python/protobuf/latest/google/protobuf/text_format.html

In C++, please check PrintToString and ParseFromString functions.

In either way, you do not need to modify Mozc's main binaries. Once you create config1.db, you do not need even the modified GUI or scripts.

Please free feel to ask questions if you encouter additional questions. Thanks,

[kirameister]

Dear Hiroyuki-san,

Thank you very much for navigating me through the process to modify config1.db. I went with the path to update the file directly and it's working on my end!

Just for the record, I didn't actually have to call specific functions per se. Rather, it was a matter of decoding and encoding the binary file. FWIW following is what I've done after installing protoc:

cd $HOME/src/mozc
cat $HOME/.mozc/config1.db | protoc --proto_path=src/protocol --decode="mozc.config.Config" src/protocol/config.proto > temp_config.txt
UPDATE temp_config.txt such that "{!}\t\t\tNoTransliteration\n" is appended at "custom_roman_table" and add a new key-value pair "composing_timeout_threshold_msec: 50"
cat temp_config.txt | protoc --proto_path='src/protocol' --encode='mozc.config.Config' 'src/protocol/config.proto' > $HOME/.mozc/config1.db

I actually have 1 (most likely last) question:

From the outset, it seems that config1db binary file is platform-independent. In other words, could the modified config1.db still be used in macOS or Windows environment, even when the file was modified in Linux environment? It seems this is the case from the outset, but I wonder if you could confirm that.

Thank you very much for taking care of this request and guiding me through this journey. I hope/wish this functionality would be made available at Google IME (and I'd be checking the version number of my local (development-version of) Google IME, if the build value would be equal to or higher than 4450.

Best regards, Akira K.

[kirameister]

Actually, the overview page of the Protocol Buffers clearly states that it is platform neutral (which, I think, is equivalent to platform-independent). https://developers.google.com/protocol-buffers/docs/overview

So all my questions have been answered. Thank you very much for your time and effort for interacting with me and implementing this functionality! May mozc live long and prosper!

Best regards, Akira K.

[hiroyuki-komatsu]

I'm glad to hear that you succeeded the configuration.

I will close this issue after:

• Update the document about config1.db
• Consider how to handle {!} \t \t NoTransliteration.

It was a nice time to discuss this feature with you. Thanks,

[kirameister]

Dear Hiroyuki-san,

My apologies for the delayed reply. Yes, I have no objection in closing this ticket. I'm very much thankful for those two points (to be done before closing the tickets) as well. Thank you again very much!

Best regards, Akira K.

[hiroyuki-komatsu]

Hi Akira san,

It's no problem. I still action items to close this issue.

• 0a1d96f402f72e312d30d276924db1848de6f312 is the update of the document about config1.db.
• Handling {!} \t \t NoTransliteration has not been done yet.

[hiroyuki-komatsu]

I recently added two changes related with this topic.

• https://github.com/google/mozc/commit/446c5ba9ad3e9200e71b2cbf03cabc5c5801dd01 : The GUI remains invisible configurations (i.e. composing_timeout_threshold_msec)
• https://github.com/google/mozc/commit/fe61216b768752bfe69b8b6a86d150303d273079 : The composer handles special characters like {!} without the fallback entries like {!} \t \t NoTransliteration.

FYI, if you want to make three key combinations keeping intermediate two key combinations, using special keys might be helpful (although I haven't tested it).

key	value	pending
a		あ
あb		あ{c}
あ{c}c	あい
あ{c}{!}	あ

[kirameister]

Hello Hiroyuki-san, Thank you very much for your follow-up!

I have few questions..

• Combining those 2 bullet-point items, do I understand it correctly that the only missing piece in the puzzle (for realizing the simultaneous layout) is the GUI component to specify composing_timeout_threshold_msec?
• How likely do you see such GUI component to be made available for mozc (and eventually in Google IME)?

The 2nd point is somewhat crucial for me. As you may have seen, I've created a Google Colab page to make this simultaneous feature more widely (and easily) available. But I'm hoping I could someday make this page part of the history.

My personal agenda was to come back to you with this request (to extend the current GUI settings) once this feature becomes known to some people (i.e., there would be obvious amount of people who would benefit from this feature), but if there is already a plan to do that, it'd really be great :)

I haven't tested what you suggested with {c}. Is c in {c} fixed, of it is {c} simply because it's followed by c for "あい" in the 3rd row?

Akira K.

[hiroyuki-komatsu]

Combining those 2 bullet-point items, do I understand it correctly that the only missing piece in the puzzle (for realizing the simultaneous layout) is the GUI component to specify composing_timeout_threshold_msec?

I hope yes. Please let us know if there are some other missing items.

How likely do you see such GUI component to be made available for mozc (and eventually in Google IME)?

The current implementation is a reuse (and expansion) of the existing supported feature (i.e. toggle input for mobile), and we have not decided supporting this simultaneous input. If we add it to GUI, it means we have finalized the specifications and start supporting the feature for all users with the current implementation.

So at this moment, we would like to keep it as an experimental feature without GUI support. I appreciate your understanding.

Regarding {c}, {c} can be any special keys (e.g. {x}). However, I noticed there are some unexpected behaviors in the current implementation (2.28.4990). I'm investigating it now.

Thank you,

[hiroyuki-komatsu]

Related with this topic, we recently added an experimental feature that enables using function keys (e.g. F1, Henkan, etc.) in the romaji customization table.

Here are steps to use Henkan to type あ.

1. Set Henkan to InsertCharacter in the keymap
   • Open preference
   • Select "Customize…" of Keymap style
   • Export the setting to a file.
   • Modify the file to append the following rules
   • Import the file.

Mode	Key	Command
Composition	Henkan	InsertCharacter
DirectInput	Henkan	InsertCharacter

2. Add the following rules to Romaji table

Input	Output	Next input
{henkan}	あ

With this feature, you can make keymaps of simultaneous input with function keys :-)

Note:

• This is an experimental feature. We may not provide a GUI and we may remove this feature.
• You might need to restart the Ibus Mozc client to apply the keymap rules for the DirectInput mode.
• Some IMF clients might not support the customization of the DirectInput mode.
• The names of the function keys: Add GetSpecialKeyString · google/mozc@6f2be66
• Test cases as example: Add test cases for simultaneous input. · google/mozc@5fa3558

[kirameister]

Hello Hiroyuki-san,

Thank you very much for this update! I myself an not an Oyayubi-typer (and I don't think I'd ever be), but there may be people out there who are interested.

I'll ask around if people may be interested in this functionality, and I may be trying this out myself if/when I'd have enough bandwidth.

If I may say my honest opinion, however, I'm not too convinced if this is something that should be supported by an IME. To me, there should be a clear distinction between function keys and letter-keys (let's call those non-function keys); if one would like to assign a function keys to a letter key, he should be able to do so via other means (key-code hacks, firmware update, etc..). I'm a bit concerned that introducing this functionality could result in some sort of an abuse (although I cannot really pinpoint what exactly such an abuse would be). Nonetheless, I very much appreciate this new functionality (and hope that there would be more people interested in "alternative" layouts :)

Best regards, Akira K.