石原 です > 「生のふりがな」の取得とは明確に分けて考えたほうがよいと思います。
分けて考えないと、実装は不可能でしょう、 ImmGetCompositionString 関数は、変換/逆変換を行うだけですので、 最初の変換前文字列の収得は、日本語入力ルーチンに割り込んで、セルに関連付けたログを残す必要があります。 この様な実装を行うのなら、手操作での修正が必須です、Calc でのふりがなのリクエストは名前のふりがなです、 （読み方が判らない当て字があり、辞書にも入っていなかったりします） 特殊な読みを入力する場合は、正しい読みでの入力では無く、一文字づつ入力することがほとんどです、正しい読み方で、 入力が行われるとは、限らないのです。 又、特殊な文字は、文字一覧（文字コード表）から入力する場合があり、この場合その文字の読み方は欠落します。 つまり、まずふりがなを（手操作で）編集（と表示が）できる実装を行い、その後にそこに（入力時の）変換前文字列を、 保存するようにして、最後に、これを読み出す関数を用意しないと、 （修正出来ない事に対する）エンドユーザーからの「EXCELでは〜」といった苦情が殺到してしまうのです。 ぶっちゃけた話、EXCELなんてどうでもよく、Writer との（GUIの）整合性の方が重要です。 2012年8月19日 1:15 co <[email protected]>: > coです。 > > 日本語の入力時、変換前後の内容を「生のふりがな」と「変換結果」として同時に取得し、文字列と隠し属性として両者を記録する。 > Windowsではこれが可能で、MS-Office系アプリでは自然な形でこの情報を活用しています。 > > 現状のLibreOfficeのWindows版はIME/TSF側が渡してくれる「生のふりがな」の情報を見ていません。 > この「生のふりがな」情報はいちど捨ててしまったら生半可な処理では復元できません。 > > > バグとかでは無くて、変換結果が残念な状態ですね、 > > 「生のふりがな」情報を持たせてもらえなかったドキュメントを救うアプローチとしては、とても良い方法だとは思いますが、 > 後からふりがな(ルビ)を追加することに関しては、「生のふりがな」の取得とは明確に分けて考えたほうがよいと思います。 > > -- > co > -- Unsubscribe instructions: E-mail to [email protected] Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/ja/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
