
でも、scim-anthy は注目文節の前後しか区切り位置が分からず、うっかり確定すると、実は変なところで区切られてて、それを学習してしまったために変換結果が悪化する、ということが起こる。

と、そう思われてると思いますが、というか、実際そうなんですが、実は、scim-anthy でも、文節区切りが表示されることがある。

これは、Firefox 内のテキストボックスで入力した時のものですが、文節の切れ目で下線が切れてます。
(Firefox 内なら、検索ボックスでもどこでもこうなるらしい)。
scim(-anthy) も、実は文節の切れ目を表示してる?
それともこれは Firefox 側で何かやってるんでしょうか?
よく分かりませんが、今の所、scim-anthy で文節の切れ目が表示されるのは、自分の知る限り、Firefox だけで、他は Thunderbird でもダメでした。
また、Firefox でも、ibus の場合は切れ目は表示されませんでした。
うーん、謎。
【関連する記事】
ただし、アプリケーションに対して「下線を表示しろ」と指示する属性は文節ごとにつけてます(たぶん、大抵の実装ではどれも同じはずです)。
レンダリング処理の微妙な違いで、たまたまそれが見えてしまっているかいないかだけの違いだと思います。
そうですか、たまたまでしたか。
下線の表示はアプリ側でやってるんですね。
「ならば、なぜ Thunderbird では切れ目が見えないんだろう? レンダリングは Firefox と同じじゃないのかな?」という疑問はありますが、自分には歯が立たない疑問のようなので、ここまでにします。
教えて頂き、感謝です。
G-HAL 氏のコメントより。
※すみませんが、コメント欄がないので勝手にこっちに引用します
> 当てずっぽうで言ってみると。
> フォントサイズの違いで、
> 文字間に 1pixel 以上の隙間ができた場合は文節区切りが見えて、
> 文字間が密着した場合は文節区切りが見えない。
> とか言ってみる。
> 「_」や「_」や「 ̄」などを複数続けて書いた場合
> 「___」「___」「 ̄ ̄ ̄」に、
> 隙間ができたりできなかったり謎だったのですが、
> 結論はフォントサイズの違いで
> 文字間に隙間が入ったり入らなかったりが原因でした。
> もしかしたら、それと同じ原因かも……。
一応フォントの文字間隔の違いは疑ってみて、色々フォントやフォントサイズを変えてみたんですが、試した限りではやはり Firefox では常に区切りが表示され、他のアプリ(Thunderbird を含む)ではつながって表示されました。
上のスクリーンショットのフォントサイズが大きいのは、見やすいように敢えて大きくしたからで、Firefox だと 6px でも区切りが判別できました。
他にも、「Firefox は "各文節それぞれ" に対して下線を表示しているのに対して、他のアプリは変換中の "文全体" に対して下線を表示しているという違いがあるのかな」と思って、
<ins>この</ins><ins>本は</ins><ins>面白い</ins>
というのを Firefox で表示させてみましたが、これは表示上
<ins>この本は面白い</ins>
と同じになるようなので、「Firefox は各文節それぞれに対して下線を表示している」というわけでもないのかな、という気がします。
まぁ、HTML の下線表示と変換中文字列の下線表示とは違うのかも知れませんが。
あんまりちゃんと確かめたわけではないので、違ってるかも知れませんが、今の所「Firefox だけが特殊」という結論です。
訂正。
ashie さんのコメントに
> 「下線を表示しろ」と指示する属性は文節ごとにつけてます
とあるので、どのアプリでも一応「文節ごとに下線を引いてる」のでしょう。
やはり、レンダリングの違いなのかな。
同じ Firefox で同じフォント&フォントサイズでも、scim-anthy では区切りが表示されて、ibus-anthy では区切りが見えないのは何故?
Firefox のレンダリングによるものなら、ibus-anthy でも区切りが見えても良さそうなものなのに。