version: mozc-0.13.464.102
target file: gyp/common.gypi
category: build fail
OS: FreeBSD 9-CURRENT / 8.1-RELEASE
CC: gcc 4.2.1 (FreeBSD default compiler)


FreeBSD needs /usr/local/include as include dir and /usr/local/lib
as ldflags. Please fix that.
(/usr/local/ is default apps path of 3rd party, but it should be 
flexible. Arbitrarily path should be treated)

Maybe this is not a bug,
but I don't think it's good for most users.

Type "nihonnouen" and press space => "日本応援"
Type "nihonnouen", press space, press shift + space => "日本のうえん"
(nihon'no|uen, 日本の|うえん)

I think it should be "日本応援" or "日本おうえん".

version: mozc-0.13.464.102
target file: unix/scim/scim.gyp
category: path management
OS: FreeBSD 9-CURRENT / 8.1-RELEASE
CC: gcc 4.2.1 (FreeBSD default compiler)


'pkg-config --variable=icondir scim' looks depending on path management
of pkg-config. Please consider another way of path management. OSes prefer 
to use their default icon pathes.

version: mozc-0.13.464.102
target file: server/mozc_server.cc
category: lack of feature
OS: FreeBSD 9-CURRENT / 8.1-RELEASE
CC: gcc 4.2.1 (FreeBSD default compiler)


server/mozc_server.cc needs termination treatment for FreeBSD and other
OSes. The 'abstract namespace' is Linux specific feature. So for any 
other OSes like FreeBSD, termination treatment is needed to delete 
unix socket file and remove user lock files.

I guess to add signals (SIGINT, SIGHUP and SIGTERM) and call 
g_session_server->Terminate() is good way.

unix/ibus/mozc.xml includes product_icon.png. But there is not this file to
source tree.
Please make product_icon.png.

I heard you are using 最小コスト法 for Mozc, and it's good for long 
kana-kanji conversion.
I think Mozc is better than Anthy for long sentenses.

But many people say Mozc is not good for short kana-kanji conversion.
e.g. Mozc doesn't show "午後" for "gogo".

I saw "パルックボールプレミアQ" at the local store -
http://panasonic.co.jp/corp/news/official.data/data.dir/jn080609-2/jn080609-2.ht
ml
電球形蛍光灯 is not bright on start up, so Panasonic added old 
白熱電球 for first few minutes.
http://www.lightstyle.jp/?cn=100026&shc=10000503
> 
パルックボールプレミアクイックとは、蛍光ランプ内に白��
�灯フィラメント内蔵で、
> ランプの立ち上がりが早いという優れもの。

And I've found Taku-san's tweet:
http://twitter.com/taku910/status/15560702282
> 
N文節最長一致は、文節単位で細かく入力する場合に限って�
��うまく働くような気がする。

That's it!
Is it possible to switch conversion engines?

if yomigana_length <= 10 characters
 mozc_engine = N文節最長一致
else
 mozc_engine = 最小コスト法
end

if yomigana == "ごご", Mozc use N文節最長一致.

What do you think about it?

> we'd like to appreciate it if you send us sentences or phrases moze failed to 
convert.

OK, Mozc-0.11.383.102 doesn't convert these strings properly.
You can close this issue after you release next Mozc.
(and someone will open new issue for the new Mozc.)

これはうれしいごサンです　うれしい誤算
これはダメだというシ
これはダメだと思うカラ
気心のしれ田中なので　しれた仲なので
改悟は本当にタイ編です　介護は本当に大変
凸メを送ったら　デコメ
読くんに頼みましょう　さとるくん
その子とカラもわかるように　その事から
日本チームの演技派この後すぐです　演技は
ボーリング上の近くです　場。「じょう」で切り直すと「��
�雨」になる
しょっぱい味が下　味がした
とんでもないやつが洗われた　現れた
申の鳴き声がすごい　猿
保守的な麺もあるね　面

version: mozc-0.13.464.102
target file: unix/ibus/path_util.cc
category: absolute path
OS: FreeBSD 9-CURRENT / 8.1-RELEASE
CC: gcc 4.2.1 (FreeBSD default compiler)


/usr/share/ibus-mozc and 'kInstalledDirectory + string("/") + icon_file;'
are absolute path. Please consider more portable way of path management. 
(e.g., Linux uses /usr/ as default top path of 3rd party applications.
FreeBSD uses /usr/local/ on that way. Other OSes use other path as their 
default apps top path).

What steps will reproduce the problem?
1.Open SCIM's settings
2.Choose Mozc

What is the expected output? What do you see instead?
It should display mozc's settings. However, the output is blank.

What version of the product are you using? On what operating system?
Latest mozc (0.13) and SCIM (1.4.9) on Arch Linux x86-64.
Also, I cannot use Mozc for ibus. The problem is similar.

I've developed Mozc module for uim at 
http://macuim.googlecode.com/svn/trunk/Mozc and I'm willing to contribute these 
code to Mozc.  And perhaps package distributors of Linux would prefer this 
module to be included in Mozc distribution IMHO.  Please consider to merge 
uim-mozc into Mozc repository if possible (actually this is an idea from 
matsuu-san from Gentoo Linux).

Cheers,

What steps will reproduce the problem?
1. Build and install mozc r36.
2. Start X.
3. Activate IM (ibus or scim).

What is the expected output? What do you see instead?
Mozc activation failed.
Message:
mozc 
"変換エンジンプログラムの起動に失敗しました。新しい 
Mozcを利用するためにコンピュータを再起動してください。"
.xsession-errors "** (xfwm4:5241): WARNING **: Unmanaged net_wm_state (window 
0x260000f, atom "_NET_WM_STATE_STAYS_ON_TOP")"

What version of the product are you using? On what operating system?
* mozc r36
* Arch Linux (x86_64)
* Xfce 4.6.1

Please provide any additional information below.
Mozc r35 has no problem.

version: mozc-0.13.464.102
target file: base/mutex.h
category: build fail
OS: FreeBSD 9-CURRENT / 8.1-RELEASE
CC: gcc 4.2.1 (FreeBSD default compiler)


FreeBSD needs to define follow line as the same as OSX:

#define PTHREAD_MUTEX_RECURSIVE_VALUE PTHREAD_MUTEX_RECURSIVE

follow line leads build fail.

#define PTHREAD_MUTEX_RECURSIVE_VALUE PTHREAD_MUTEX_RECURSIVE_NP

Please fix that. thanks

What steps will reproduce the problem?
1. Type "いんすとーるごはどうなるんだろう" and press space.
2. We can see the words "インストール|ごは|どうなるんだろう".
3. Press right and check other candidates for "ごは".
4. We can't find "後は".

5. Split "ごは" to "ご|は".
You'll see "後" as the 11th candidate (it's too late), and 
"は" will be converted to "②" automatically (it's too soon).

version: mozc-0.13.464.102
target file: base/util.cc
category: absolute path
OS: FreeBSD 9-CURRENT / 8.1-RELEASE
CC: gcc 4.2.1 (FreeBSD default compiler)


/usr/lib/mozc is absolute path. Please consider more portable way 
of path management. (e.g., Linux uses /usr/ as default top path of 3rd
party applications. FreeBSD uses /usr/local/ on that way. Other OSes 
use other path as their default apps top path).

What steps will reproduce the problem?
1. Open ibus-mozc's GUI setup tool
2. Change input mode
3. Click "OK" button

What is the expected output? What do you see instead?

A message "Romaji/Kana setting is enabled from new applications." is displayed 
in a popup window when switching input modes between romaji and kana by GUI 
setup tool, though this setting can be applied to existing applications by 
restarting IBus. I think this message should be changed as "Please restart IBus 
to apply Romaji/Kana setting to existing applications.".

What version of the product are you using? On what operating system?

I use ibus-mozc r28 in Ubuntu 10.04.

Please provide any additional information below.

Japnese translation of my suggestion is 
"ローマ字・かな入力の設定を既存のアプリケーションに適�
��するために、IBusを再起動して下さい。".

What steps will reproduce the problem?
1. Change a key binding to use Ctrl+i for "PredictAndConvert"
2. Type some hiragana characters in gedit so that a suggestion window appears
3. Push Ctrl+i to select a candidate in the window

What is the expected output? What do you see instead?

The suggestion window unexpectedly disappears by pushing Ctrl key. In this 
case, however, the input state is still kept, so pushing i makes the window 
redisplayed and starts selecting the suggestion. I think such a behavior is 
very confusing.

What version of the product are you using? On what operating system?

I use ibus-mozc 0.13.464.102 in Ubuntu 10.04 .

Please provide any additional information below.

Alt key also causes the same problem.

version: mozc-0.13.464.102
target file: gui/about_dialog/about_dialog.cc
category: absolute path
OS: FreeBSD 9-CURRENT / 8.1-RELEASE
CC: gcc 4.2.1 (FreeBSD default compiler)


'new QImage(":/product_logo.png")' looks depending on path management
of Qt. Please consider another way of path management. OSes prefer to
use their default icon pathes.

時間に負われている　追われて
禁じ手　(候補なし)
女子高生　(候補なし)
ダックスフントはたん速です　短足、せめて嘆息
終を迎えた 「おわり」で「終わり」にならない
カネノナルキだ　金のなる木
笑点　(候補なし)
別途シーツを交換した　ベッドシーツ。「ベッド」の優先��
�が低い
岩瀬月　言わせるな。「そんなことを言わせるな」はOK。
ナラには　「奈良」の候補なし
介護完成　下位互換性。「下位」がなかなか出ない。
「上位互換性」はすぐ出る

> ナラには　「奈良」の候補なし
I think the new Mozc dictionary has a critical bug.

Sorry! I've asked question in Japanese.
- お使いのプラットフォーム (Windows か Mac OS X)
　Ubuntu10.04　Mozc (dev 0.12.422.102)
- 不具合の内容およびその際の状況
　先日まで問題なく日本語変換・入力出来ていたものが、��
�ップデートしたら上記メッセージが出現し再起動しても入�
��出来なくなった。

- 再現手順
　PCを再起動しても同じメッセージの繰り返し

- 問題発生時にお使いの他のアプリケーション
　Fire-Foxほかテキストエディタでも

・非常に便利で助かっていた日本語変換エンジンでした。IM
Eからのユーザー辞書の引越しも用意でありなくてはならな�
��ソフトです。
残念ながらアップデート後に使えなくなり、困っています��
�
　フォーラムを見ているとWin版の改訂の後にオープンソー��
�版に不具合が出ているようですので解決方法を教えていた�
��けると助かります。

*************************************************************************
Google工藤です

/tmp/.mozc.*.session

を消去してみてください。本来生成されるべきでない ipc 
のファイルが残っているために、起動に失敗することがあ��
�ようです。

% killall -KILL mozc_server
% rm -f /tmp/.mozc.*.session

なお、オープンソース版Mozcのバグ報告は、下記のMozcのサイ
トへ送っていただけると助かります。

http://code.google.com/p/mozc/issues/list

よろしくお願いいたします。
*************************************************************************

早速の回答ありがとうございます。
指示通り

% killall -KILL mozc_server
% rm -f /tmp/.mozc.*.session

を端末で行うと、.mozz.******************.sessionの隠しファイルは
消え、インプットメソッドの再起動後にはこの用に日本語��
�変換できるようになります。
しかし、再度PCを再起動するとまた、上記質問の内容と同じ
エラーメッセージが出現し、其の度に指導いただいた操作��
�しなくてはなりません。

残念ながらStressfulな利用となってしまっています。

質問：　”ｉｐｃのファイル”＝”.sessionファイル” 
ということでしょうか？
要望：　”.sessionファイル”をわざわざ消さなくても使える
ようなる方法を教えていただきたい！

宜しくお願いします。

version: mozc-0.13.464.102
target file: build_mozc.py
category: build fail
OS: FreeBSD 9-CURRENT / 8.1-RELEASE
CC: gcc 4.2.1 (FreeBSD default compiler)


FreeBSD use make as BSD make. BUILD_COMMAND of build_mozc.py should be
'gmake'. Please fix that.

I use ibus-mozc r25 in Ubuntu 10.04.

I found the engine name is still "mozc-jp" though the keyboard layout
other than Japanese can't be selected in this revision and the engine
longname was changed to "Mozc".

It seems strange that the name is longer than longname!

I attached a patch for this bug.

What steps will reproduce the problem?
1.Start the AdobeAIR application(TweetDeck)
2.mozc to start(Alt+grave)
3.Japanese tweet does not appear on TweetDeck with mozc input. It turns out to 
be blank.

What is the expected output? What do you see instead?
TweetDeck, or Ubuntu (Lucid) has been published in the repository for the 
AdobeAIR runtime is also likely to have problems.

What version of the product are you using? On what operating system?
OS:Ubuntu 10.04 (Lucid "Japanese Remix")
Linux Kernel:2.6.32-24-generic (#43-Ubuntu SMP Thu Sep 16 14:17:33 UTC 2010)
GNOME:2.30.2 (Ubuntu 2010-06-25)

IBus:1.2.0.20091215
mozc:Mozc-0.13.481.102

AdobeAIR runtime:2.0.3.13070-0
TweetDeck:0.35.1.1 for Linux

Please provide any additional information below.
Instead of always being generated, is also unknown Condition.
Resolved in most cases will IBus restart, and rarely TweetDeck IBus may crash 
with a companion.
The crash was away to enter it as two characters repeatedly reboot, GNOME may 
be healed and once to end the session without logging off.

In related to the previous issue #13, please consider using statically linking 
with protobuf even for the Linux version of Mozc.

I request this because of the design of protobuf not to handle "bundle modules 
linking with protobuf" by dlopen(3) decently (related to issue #128 of 
protobuf).  Specifically for mozc_tool in Linux, which uses Qt4 library as a 
GUI frontend and of course linking with shared protobuf library, it loads 
bundle modules with dlopen(3) when creating a input context.  And as input 
module of uim for Qt do dlopen uim-mozc bundle (which is also linking with 
shared protobuf library dynamically) at that time, it will cause crash of 
protobuf as follows.

    libprotobuf ERROR google/protobuf/descriptor_database.cc:56] File already exists in database: session/config.proto
    libprotobuf FATAL google/protobuf/descriptor.cc:857] CHECK failed: generated_database_->Add(encoded_file_descriptor, size):

I think this can be solved by using mozc_tool with protobuf library linked 
statically.

Cheers,

What steps will reproduce the problem?

 1. setup ibus-mozc/ibus-engine-mozc and mozc_server (you can reproduce with Debian packages style
  and normally built, if you use ubuntu, install ibus-mozc and mozc-server).
 2. enable ibus in any applications
 3. type "Shift" + any alphabet(e.g. type 'Apple' ; type [Shift]+"a", release [Shift], type 'pple' ).
 4. ibus-engine-mozc segfaults.

Jul  5 16:00:17 antares kernel: [ 3796.020201] ibus-engine-moz[2026]: segfault 
at 30 ip 0805e747 sp bf8dbe50 error 4 in ibus-engine-mozc[8048000+a5000]


What is the expected output? What do you see instead?

 Expected inputs: "Apple"
 Actual inputs: Application is crashed out with ibus-engine-mozc.

What version of the product are you using? On what operating system?

 mozc  0.12.402.102 / Ubuntu 10.04.

Please provide any additional information below.

 If you install with mozc_tool(package name: mozc-utils-gui), this behavior will be not reproducible.

version: gyp-r832
target file: gyp/generator/make.py
category: build fail
OS: FreeBSD 9-CURRENT


Background:
    Right now FreeBSD getting change of system default sed and grep.
  Legacy FreeBSD uses GNU sed and GNU grep as their system default
  commands. But now, their are developing BSD sed and BSD grep, and
  unfortunately, some feature is not in their implementation.
  FreeBSD 9-CURRENT use BSD sed and grep.

Issues and suggestions:
  gyp uses GNU sed and GNU grep in their scripts (or it looks like so).
  And that script it not compatible with BSD sed and grep. There is 2 ways
  to fix that.

  1) Change sed and grep pattern to get for both GNU and BSD.
  2) Change command name and path of sed and grep on FreeBSD.
    sed --> gsed
    grep --> /usr/local/bin/grep
       (there is a little confusion. /usr/bin/grep is BSD grep and
       /usr/local/bin/grep is GNU grep.)

Thanks

version: mozc-0.13.464.102
target file: build_tools/mozc_version.py
category: build fail
OS: FreeBSD 9-CURRENT / 8.1-RELEASE
CC: gcc 4.2.1 (FreeBSD default compiler)


build_tools/mozc_version.py lacks of FreeBSD support. This is the
same issue of patch-build_mozc.py.

Is IPAdic becoming the base of the dictionary of mozc a base in 
http://sourceforge.jp/projects/naist-jdic/? 
Or based on http://sourceforge.jp/projects/ipadic/? 
I don't understand which it is because there is not a license of IPAdic. 
Would you add it?

version: mozc-0.13.464.102
target file: build_mozc.py
category: absolute path
OS: FreeBSD 9-CURRENT / 8.1-RELEASE
CC: gcc 4.2.1 (FreeBSD default compiler)


/usr/local/Trolltech/Qt-4.6.3 is absolute path. Please consider more 
portable way of path management. (e.g., Linux uses /usr/ as default 
top path of 3rd party applications. FreeBSD uses /usr/local/ on that 
way. Other OSes use other path as their default apps top path).

What steps will reproduce the problem?
1. Open gedit text editor
2. Set color scheme to 'Oblivion', which have dark background color
3. Start preediting with ibus-mozc

What is the expected output? What do you see instead?

Highlighted region in preedit text should be displayed with a dark 
foreground color because the background color is a light color (#0xD1EAFF), 
but both foreground and background color become light (See screenshot). For 
highlighted region, mozc engine seems to specify only background color.

What version of the product are you using? On what operating system?

I use rev. 23 in Ubuntu 10.04.

Please provide any additional information below.

version: mozc-0.13.464.102
target file: base/process.cc
category: absolute path
OS: FreeBSD 9-CURRENT / 8.1-RELEASE
CC: gcc 4.2.1 (FreeBSD default compiler)


/usr/bin/xdg-open is absolute path. Please consider more portable way 
of path management. (e.g., Linux uses /usr/ as default top path of 3rd
party applications. FreeBSD uses /usr/local/ on that way. Other OSes 
use other path as their default apps top path).

Mozc doen't check x86_64 header files,
so we can't build Mozc on x86_64.
This patch will fix it.

I use mozc.el in r47.

When preedit state is "Composition", I sometimes move cursor backward to modify 
some typo. However, mozc.el always shows cursor at the end of preedit text, so 
I lose track of the editing position.

I attached a patch of simple solution for this problem. This patch modifies 
mozc.el to highlight cursor position in preedit text if moving it backward.

version: mozc-0.13.464.102
target file: ipc/unix_ipc.cc
category: build fail
OS: FreeBSD 9-CURRENT / 8.1-RELEASE
CC: gcc 4.2.1 (FreeBSD default compiler)


1)

  FreeBSD needs "sys/ucred.h". Please add it.

2)

  In socket, FreeBSD uses the same way of MacOSX. Please add FreeBSD
  as the same as OSX.

3) 

  Follow lines look strange.

----
   if (!IsAbstractSocket(server_address_)) {
     // Linux does not use files for IPC.
     ::chmod(server_address_.c_str(), 0600);
   }
   if (::bind(socket_, reinterpret_cast<sockaddr *>(&addr), sun_len) != 0) {
     // The UNIX domain socket file (server_address_) already exists?
     LOG(FATAL) << "bind() failed: " << strerror(errno);
     return;
   }
----

    Is it should be as follow?

----
   if (::bind(socket_, reinterpret_cast<sockaddr *>(&addr), sun_len) != 0) {
     // The UNIX domain socket file (server_address_) already exists?
     LOG(FATAL) << "bind() failed: " << strerror(errno);
     return;
   }
   if (!IsAbstractSocket(server_address_)) {
     // Linux does not use files for IPC.
     ::chmod(server_address_.c_str(), 0600);
   }
----

    At least in FreeBSD, this code change is needed.

version: mozc-0.13.464.102
target file: unix/ibus/gen_mozc_xml.py
category: absolute path
OS: FreeBSD 9-CURRENT / 8.1-RELEASE
CC: gcc 4.2.1 (FreeBSD default compiler)


/usr/libexec/ibus-engine-mozc and /usr/share/ibus-mozc/product_icon.png are
absolute path. Please consider more portable way of path management. 
(e.g., Linux uses /usr/ as default top path of 3rd party applications.
FreeBSD uses /usr/local/ on that way. Other OSes use other path as their
default apps top path).

Mozc doesn't have "credits_ja.html".
ibus toolbar => "About Mozc" =>
Click 
"Mozcは[オープンソースソフトウェア]を利用しています。" =>
We can't find libdir/mozc/documents/credits_ja.html.

What steps will reproduce the problem?
1. Start X session with Metacity window manager
2. Open ibus-mozc keymap editor
3. Click the keymap table twice to open keybinding editor

What is the expected output? What do you see instead?

Keybinding editor should be raised and focused, but it appears behind
the keymap editor and isn't focused. This behavior is very annoying
because we must click the keybinding editor every time to bring up it.

What version of the product are you using? On what operating system?

I use ibus-mozc r25 in Ubuntu 10.04.

Please provide any additional information below.

I think the keybinding editor must send a client message
"_NET_WM_STATE = _NET_WM_STATE_ABOVE" to the root window when using
Metacity window manager.

Hi, thank you for publishing such a good product!!

Now I can run mozc on Nokia N900, maemo linux based smartphone. I can build 
mozc on your instruction, but if I can, I would like to set install prefix, 
such as /opt/aaa/usr ...

Could you tell me how to set install prefix? And if it is not a issue, sorry 
for posting such a stupid question:-P

Best Regards.

kenya888

What steps will reproduce the problem?
1. Launch mozc (press "半角/全角・漢字")
2. Check the input mode.
3. Press "ALT" + "カナ/かな・ローマ字".
4. The input mode doesn't change.

What is the expected output? What do you see instead?
The input mode should be changeable when "ALT" + "カナ/かな・ローマ字" 
are pressed.

What version of the product are you using? On what operating system?
0.13.464.102

I found that mozc.el uses 'last-input-event' in 'mozc-handle-event' to obtain 
key event. In a tty frame, however, this variable keeps useless value when 
typing f1 - f12 keys, while 'last-command-event' keeps proper symbol such as 
'f1', 'f2', etc.

Basically, commands like 'self-insert-command' should use 'last-command-event' 
rather than 'last-input-event'.

So I wrote patch to use 'last-command-event', and confirmed the function keys 
work correctly for me. Please check it.

version: mozc-0.13.464.102
target file: ipc/ipc_path_manager.cc
category: build fail
OS: FreeBSD 9-CURRENT / 8.1-RELEASE
CC: gcc 4.2.1 (FreeBSD default compiler)


follow line is a Linux specific feature that FreeBSD and other OSes 
don't support.

   (*ipc_name)[0] = '\0';

Please add avoiding code of above line for FreeBSD.

What steps will reproduce the problem?
1.compiled mozc
2.I can't HENKAN zip code to address.
3.found dictionary.gyp is not correct

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
Debian sid amd64

Please provide any additional information below.
when using vliables in .gyp file, if strings include $, strings will be 
double-quoted.
so better to not using valiables if strings may include $.

attaching example of patch. please look at this.

version: mozc-0.13.464.102
target file: 
category: build fail
OS: FreeBSD 9-CURRENT / 8.1-RELEASE
CC: gcc 4.2.1 (FreeBSD default compiler)


mozc and gyp have no support of FreeBSD. Please add FreeBSD support
or make FreeBSD as one of Linux distribution.

JFYI, in any cases, FreeBSD goes the same way of Linux, but in some 
way, FreeBSD behave as OSX. 

What steps will reproduce the problem?
1.Start mozc dictionary tool via mozc toolbar
2.Click "追加(tsuika)" button
3.Click "よみ(yomi)" or "単語(tango)" column
4.Hit IM trigger key(control + space or something)

What is the expected output? What do you see instead?
Cannot activate ibus.

What version of the product are you using? On what operating system?
mozc 0.13.499.102

My environment is:
Debian GNU/Linux unstable amd64 - all packages are up to date
Qt4 4:4.6.3-3

Please provide any additional information below.
Can activate ibus when start mozcdictionary tool from command line
like /usr/lib/mozc/mozc_tool --mode=dictionary_tool.

version: mozc-0.13.464.102
target file: base/iconv.cc
category: build fail
OS: FreeBSD 9-CURRENT / 8.1-RELEASE
CC: gcc 4.2.1 (FreeBSD default compiler)


base/iconv.cc build fails on FreeBSD because of follow line:

     if (iconv(ic, reinterpret_cast<char **>(&ibuf), &ilen, &obuf, &olen)

follow line is acceptable.

     if (iconv(ic, (const char **)(&ibuf), &ilen, &obuf, &olen)

Please change that line or fix it in another way.

What steps will reproduce the problem?
1. Focus out and wait for several ten minutes
2. Focus in and turn SCIM on
3. Start preediting

What is the expected output? What do you see instead?

For example, when typing "tesuto", the preedit text must be "てすと". 
However, the first character "t" might become direct input so the preedit text 
is "えすと".

What version of the product are you using? On what operating system?

I'm using scim-mozc r29 via scim-bridge in Ubuntu 10.04

seems mis-spelled word exists in src/session/config.proto 

attached diff fixes it.

version: mozc-0.13.464.102
target file: gui/about_dialog/version_image_widget.cc
category: path management
OS: FreeBSD 9-CURRENT / 8.1-RELEASE
CC: gcc 4.2.1 (FreeBSD default compiler)


'new QPixmap(":/update_uptodate.png")' looks depending on path management
of Qt. Please consider another way of path management. OSes prefer to
use their default icon pathes.

Hi, 

The following files cannot be re-distributed.
  data/unicode/JIS0201.TXT
  data/unicode/JIS0208.TXT
  data/unicode/JIS0212.TXT
  data/unicode/SHIFTJIS.TXT

#   Copyright (c) 1991-1994 Unicode, Inc.  All Rights reserved.
#
#   This file is provided as-is by Unicode, Inc. (The Unicode Consortium).
#   No claims are made as to fitness for any particular purpose.  No
#   warranties of any kind are expressed or implied.  The recipient
#   agrees to determine applicability of information provided.  If this
#   file has been provided on magnetic media by Unicode, Inc., the sole
#   remedy for any claim will be exchange of defective media within 90
#   days of receipt.
#
#   Recipient is granted the right to make copies in any form for
#   internal distribution and to freely use the information supplied
#   in the creation of products supporting Unicode.  Unicode, Inc.
#   specifically excludes the right to re-distribute this file directly
#   to third parties or other organizations whether for profit or not. 

There might be problem because CP932.TXT doesn't have the rule concerning
the re-distribution either. 
Could you check it?

Best regards,
  Nobuhiro

What steps will reproduce the problem?
1. M-x set-input-method to japanese-mozc
2. repeat some times toggle to disable im and input chars then enable im and 
input some chars


What is the expected output? What do you see instead?

 Keyboard inputs are discard with beep and display errors bellow:

         let: Arithmetic overflow error: "13871560800961468065"

 (the number will be changed randomly)

 backtrace is attached.

What version of the product are you using? On what operating system?
 * Debian GNU/Linux sid amd64 (64bit envirumnent)
 * emacs23_23.2+1-4
 * mozc svn trunk (0.13.481.102/r40)

What steps will reproduce the problem?
1.Start Mozc.
2."かおもじ" type conversion.
3.Suggest ideas Tab space and the cursor keys to scroll and select, such as...
「Mozcエラー(Dev 0.13.464.102) 
互換性のない変換エンジンプログラムに接続しています。��
�しい 
Mozcを利用するためにコンピュータを再起動してください。�
��題が解決されない場合は、お手数ですが一度アンインスト
ールしてから再インストールしてください。」
The crash error message will appear.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
OS:
Ubuntu 10.04(lucid "JapaneseRemix")
GNOME:2.30.2 (Ubuntu 2010-06-25)
Kernel:2.6.32-24-generic (#42-Ubuntu SMP Fri Aug 20 14:24:04 UTC 2010)
IBus:1.2.0.20091215
Mozc:Mozc-0.13.464.102

Please provide any additional information below.