Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


石原 です

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

分けて考えないと、実装は不可能でしょう、 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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.