[ja-discuss] Re: [ja-discuss] Re: [ja-discuss] CalcのPHONETIC関数やふりがな機能について

石原 です

> 「生のふりがな」の取得とは明確に分けて考えたほうがよいと思います。

分けて考えないと、実装は不可能でしょう、 ImmGetCompositionString 関数は、変換/逆変換を行うだけですので、
最初の変換前文字列の収得は、日本語入力ルーチンに割り込んで、セルに関連付けたログを残す必要があります。

この様な実装を行うのなら、手操作での修正が必須です、Calc でのふりがなのリクエストは名前のふりがなです、
（読み方が判らない当て字があり、辞書にも入っていなかったりします）
特殊な読みを入力する場合は、正しい読みでの入力では無く、一文字づつ入力することがほとんどです、正しい読み方で、
入力が行われるとは、限らないのです。
又、特殊な文字は、文字一覧（文字コード表）から入力する場合があり、この場合その文字の読み方は欠落します。

つまり、まずふりがなを（手操作で）編集（と表示が）できる実装を行い、その後にそこに（入力時の）変換前文字列を、
保存するようにして、最後に、これを読み出す関数を用意しないと、
（修正出来ない事に対する）エンドユーザーからの「EXCELでは〜」といった苦情が殺到してしまうのです。

ぶっちゃけた話、EXCELなんてどうでもよく、Writer との（GUIの）整合性の方が重要です。

2012年8月19日 1:15 co <cogood@gmail.com>:

> coです。
>
> 日本語の入力時、変換前後の内容を「生のふりがな」と「変換結果」として同時に取得し、文字列と隠し属性として両者を記録する。
> Windowsではこれが可能で、MS-Office系アプリでは自然な形でこの情報を活用しています。
>
> 現状のLibreOfficeのWindows版はIME/TSF側が渡してくれる「生のふりがな」の情報を見ていません。
> この「生のふりがな」情報はいちど捨ててしまったら生半可な処理では復元できません。
>
> > バグとかでは無くて、変換結果が残念な状態ですね、
>
> 「生のふりがな」情報を持たせてもらえなかったドキュメントを救うアプローチとしては、とても良い方法だとは思いますが、
> 後からふりがな(ルビ)を追加することに関しては、「生のふりがな」の取得とは明確に分けて考えたほうがよいと思います。
>
> --
> co

-- 
Unsubscribe instructions: E-mail to discuss+help@ja.libreoffice.org
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