Gnumeric-0.99.1で日本語OK 19
ストーリー by Oliver
l10nではなくi18nという正しい道 部門より
l10nではなくi18nという正しい道 部門より
emerald 曰く、 "やや古い話になってしまうが、GNOME ProjectのスプレッドシートGnumericのバージョン0.99.1がリリースされている。gnome-devel@gnome.gr.jpの記事を読むまで気づかなかったが、いつの間にやら日本語入力も表示もパッチなしで問題ないらしい。試しにDebian sid + ATOK Xで日本語を入力・印刷プレビューで確認してみたが、問題なし。ただ、HelveticaやCourierがフォント指定されていては表示は化けてしまうので、東風フォントなどを指定する必要があるようだ。何はともあれ、これでまたUNIX上の日本語環境が一歩前進したことは間違いないだろう。"
入力システム (スコア:2)
そんなあなたにProject Heke [kmc.gr.jp]。 かな漢字変換エンジンAnthyはもうすぐベータリリースをしますが、 cvs.m17n.orgから最新のソースを入手することができます。
っていうか、今の状況はまずいと思いますよね？みなさま？ねぇ？
Re:入力システム (スコア:1)
これからチェックさせてもらいます。
ちなみに黒髪革命 [kurokami.net]なんて物もあります。プロジェクト開始からまだ1ヶ月くらいしか経過していませんが。
Re:入力システム (スコア:1)
外からだとプロジェクトの進行状況が見えにくいように思うのですが・・・。
現在どうなっているのかが、リリース毎ではなくて、
"リアルタイム"で分かるようにはなっていないのでしょうか？
#ソースだけではなくて
その方が新しい人が、興味を持ちやすいと思うのですが。
それとも、探し方が悪いのかなあ。
Re:入力システム (スコア:2)
しかし、開発をオープンにすると確実に労力がかかるのに対してプロジェクトがうまく進む保証はないのではないかという認識でいます。(αリリースの際もせっせと説明の文章を書いたのに、動作報告を送ってくれた人は一人もいなかった。(日記ページで高い評価をしてくださった人はいました))このような場合に理想的な方法は、誰かがプロジェクトをforkして別の開発スタイルでやってみるというのが考えられます。(やってみてくれませんか?)
んで、あちこちでチャンスがあれば言ってるのですが、真の問題はうちのプロジェクトがどうなっているかというよりも、日本語入力システム自体への関心の低さだと思います。
Re:入力システム (スコア:1)
で、本題
＞このような場合に理想的な方法は、
＞誰かがプロジェクトをforkして別の開発スタイルでやってみるという
＞のが考えられます。(やってみてくれませんか?)
個人的には、Qt3&KDE3の関係の作業が忙しいので、
入力システムの開発プロジェクトを始めるというのは無理かな。
でも、KDE/Qtでの動作テストと動くようにする作業なら、
積極的にやろうかと思っています。
#immoduleにも興味ありますしね
＞んで、あちこちでチャンスがあれば言ってるのですが、
＞真の問題はうちのプロジェクトがどうなっているかというよりも、
＞日本語入力システム自体への関心の低さだと思います。
確かに、それはあると思います。
ただ、既存のもの、例えばATOKやWnnで満足している人も多い
でしょうから、興味をひきつけるのは難しいとは思います。
Re:入力システム (スコア:1)
メーリングリストとかがあったら、もっと気軽に動作報告ができるんじゃないかと思うのですがいかがでしょうか。
と、それだけでおわるのはなんですので動作報告もつけておきます。;-)
テスト環境
Debian unstable
Xemacs21.5
今日cvs.m17n.orgからとってきたanthy。CVSの使い方がよくわからないので、versionはよくわからないです。DIARYには
--(1/1)
候補の評価のチューニング
と書かれてました。
特にconfigureオプションなどはつけずにコンパイルしてます。
結果：矢印キー、バックスペースキーなどは効かず。スペースキーとエンターキーは効きました。(予想通りと思われますが。)C-hとかC-b とかを使うと普通に動いていました。
あと、起動時にCannot open load file:anthy-dicといわれます。(これはemacsでも同じでした。)
それと、rootになってmake installしましたが、anthy.elが/usr/local/share/emacs/site-lisp/anthy.elにコピーされないようです。(xemacs -l src-utils/anthy.elとやって使いました。)
Re:入力システム (スコア:1)
ところで止ってるとどう不都合なんでしょうか?
開発止まってるかどうかも俺は知しやしない(不勉強でごめん>開発した人たち)んですが、
たしかこれって歴史あるものだと思ったけど、
今SKKってのを(windowsで(笑))使っています。
いいですねこれ。今までのイライラが嘘のようです。
日本語変換の名のもとに、ソフトウェアが猿知恵(フレームのもとか?)を振うようなものより、
ソフトができるだけ余計なことをしやがらない日本語変換ソフト、
人間からいかに豊富な情報をソフトに与えられるか?を考えたソフト、
のほうが、幸せが多く感じられます。
で、そういうソフトって、「これ以上改良する」必要が
あんまり無い、ってことが多いような気がします。
初期のアルゴリズム(?)が格好良いのが売りであり、
もう完成されてるっていうか。
それこそunixみたいなもんですね(笑)、と言ったらスラドの人々には理解して貰えるかな…
まあ、素晴しいものは、未来だけじゃなく過去にも有ることがある、ということで。
あ。Hekeってのがどんなものなのかは知りません。これまたごめん。
Re:入力システム (スコア:2)
SKKの利点としては
- おっしゃるとおり完成されたアルゴリズムを持っているので、メンテナンスされてなくても問題が少ない。(unix的な良さですね)
- しかし、いまでも活発にメンテナンスされている。
- 実装が容易である。
- 新しい単語の収集も行われているので、新しいバージョンになれば賢い。(コミュニティによってソフトウェアを育てるモデルが確立されている)
- 個人のデータはホームディレクトリに格納されるため、他のユーザに読み書きされる恐れが低い。
- クライアントサーバ方式と辞書を直接ロードする方式のどちらでもよいので柔軟性が高い。
- 辞書を直接ロードすれば、通信の盗聴を心配しなくてよい。
- サーバクライアントでも通信のデータはキャッシュされるので、盗聴の被害が少ない。
- サーバはシンプルかつroot権限を必要としないので、security holeが発生する可能性が低い。
- 使い易い!(主観的ですが)
確かにSKKは良いですねぇ。でも、連文節変換を使いたいという場合もあるわけでして、、、
そんな場合にFreeWnnやCanna、あるいはkinput2ではちょっと嫌だなという気がしませんか?
開発が止まっていることによる不都合ですが
- セキュリティやプライバシーなどへの要求が時代によって変化するのに対応する必要がある。
- (CPUパワーやメモリなども時代によって変化する)
- 関連ソフトウェアにしわよせがくる。(たとえばkinput2の欠点を直さずにmozillaの能力を抑制する設定とかでごまかすとか)
- オープンソースがその分野に対して無力だと認めるのがいや。
などが思い付きます。もっと真剣に考えればまともな理由が思い付くかもしれません。Re:入力システム (スコア:1)
あ。すみません。昔っから連文節とかの欲求があまり無い人なもので(^^;。
あとWnnは使ったこと無くCannaも少ししか無いです。
#さすがに風 [nifty.ne.jp]だけってのは無茶ですが(^^;
というか、イライラさせられる原因は、ソフトが頑張ったってどうこなるもんではない、と思っているもんでして。
これは今でも変わらない認識だなあ。
ATOK型(笑)の変換ソフトって、こっちから与える情報をケチって、
「よきにはからえ(ただしヘボなら許さんぞ)」という不毛な主従(ぉ)関係
を成しているわけで、そりゃイライラして当然じゃん、と。
こっちの意図を勝手かつ適切に察するなんていう神様みたいなことを求めるよりも、
こっちの意図をまずどれだけそのまま伝えるか?を工夫するほうが
未来は明るいんじゃないかと…。
で、そのことに既に先人は気付いていたわけで、と。
#ごめんね
>セキュリティやプライバシーなどへの要求が時代によって変化するのに対応する必要がある。
あ。たしかにこれはありますね。セキュリティパッチっすか。
まぁ開発といっても本筋じゃない部分をいじることになりますが。
>オープンソースがその分野に対して無力だと認めるのがいや。
ところでSKKみたいなものについてでしたら、これは該当しませんよね。
開発(改良)が止まったかどうかと、力が無いかどうかとは、連動しないわけで。
物語にはハッピーエンドだってあるわけです(^^;
Re:入力システム (スコア:2)
- 自分は連文節変換は使わないから、その分野はどうでも良い
- セキュリティホールがあってもLANの中でしか使わないから良い
- プライバシーが保護されないけど、他人がログインしない環境だから別に良い
などというのは、ごもっともな態度です。そういう態度をとる方はMicrosoft社の最新のOSをご利用になることをお勧めします。（入力システムに関しては設計、実装ともに優れたものであり、skkimeなどのフリーソフトウェアを利用することもできます）入力システムのセキュリティは、簡単なパッチをあてたら解決するなんてものではありません。
>>開発(改良)が止まったかどうかと、力が無いかどうかとは、連動しないわけで。
SKKの方式に関してはそうなんですが、実装に関してはそんなはずはありません。入力システムは単独で存在するものではないので ユーザインタフェースの世代交代にしたがって変化すべきです。
(以下フレームのもと)私としてはjserver,cannaserverの類はtelnetd同様に根本的な問題があり、ディストリビュータはそのようなものを標準では配布すべきではないと考えています。また、ディストリビュータは少なくともマイクロソフトがやる程度にはプライバシーの保護を気にして欲しいと思っています。
Re:入力システム (スコア:1)
え? 関係ないでしょ? なんでこの文脈でmsを薦めるんです?
たしかに俺も今winなんぞ使っていますが、それとこれとは別問題でしょ?
SKKは当然ですがunixにも有り、かつセキュリティについて
阿呆な態度をとるユーザーだって、unixを「使う」ことは(残念ですが)
出来てしまいます。その阿呆にとってはmsに乗りかえる理由は無い。
それともこれは「そういう人はunixを使うな」という主張でしょうか?
それならば理解(賛同は別として)します。
>セキュリティホールがあってもLANの中でしか使わないから良い
そういう点には俺は全然言及していません。
俺は連文節変換について俺の考えを書いただけです。
>入力システムのセキュリティは、簡単なパッチをあてたら解決するなんてものではありません。
簡単な、なんて俺は書いていません。「本筋ではない」とは書きましたが、
それはソフトの機能(目的)がセキュリティそのものではない以上、
当然のことであり、簡単云々とは関係ないわけで。
>(以下フレームのもと)私としてはjserver,cannaserverの類はtelnetd同様に根本的な問題があり
技術的にスッカラピンなので俺には事実関係は判りませんが、
もしそれが事実ならば、「フレームのもと」という自己評価自体が
大変な誤認ではないでしょうか?
すごく重要なことでしょそれ? 「参考になる」でなきゃおかしい。
むしろ第一段落のMS云々のほうがフレームっぽく思える:-P
俺へ変なことを言うのはフレームじゃなくて、
ディストリビュータへ変な(でもないのだが)ことを言うのはフレームなのですか?
それとも俺じゃなくどっかのステレオタイプへ向けての発言だったのですか?
ならば俺も一安心ですが。
>ユーザインタフェースの世代交代にしたがって変化すべきです。
うーん。ユーザーインターフェースなんでしょうか?
日本語変換ソフトとUIとの絡みってのは、フロントエンドの部分に限定された議論
となるべきものなのじゃないか?と思うのですが、どうでしょうか?
とは言え、どこまでをUIと呼ぶか?という切り口自体が、年々変化してはいるようですね。
実際には変化に追随するために日本語変換の本体まで手を入れないと
ならんってこともしばしば発生する、ってのは判ります。
そうですね。俺も、アルゴリズムについてはSKKは良いなぁと思えたけど、
UIについてはwinでもunixでも満足は出来てないです。
ローマ字かな変換だと、限定的 (スコア:1, 興味深い)
変換方式は汎用的じゃありません。
本当に大量の文章を入力する人には、
ローマ字かな変換はよろしくありません。
Re:ローマ字かな変換だと、限定的 (スコア:2)
Re:ローマ字かな変換だと、限定的 (スコア:1)
1：シフト押して大文字を入れる必要がある。
→シフト押す必要は有るけど、その結果としての一時的な表示形態が
英大文字である義務は、原理的には無いのでは?
2：仮名でいう1文字を、子音と母音に区切って(大文字小文字で区別して)入力する必要がある。
→それは単に、仮名入力では「できない(=欠点)」事柄を、要求されているというだけで、
じゃあ仮名使わないほうが良いよね、という話になるだけでは?
逆に、仮名入力という足枷(ぉ)を捨てない限りブレークスルーできない部分がある、ということかとも思えます。
そして、仮名とかの入力が済んだあとの作業も問題ですね。
意図した文字列に変換してくれるまで
目とキーボードを交互に使ってバタバタやる頻度が上ってしまえば、
トータルの入力速度はそっちが律速になるはずです。
変換がクドいシステムって、適切な言葉を選択する作業に思考が中断されるのも、
またその処理速度がどういう訳か(笑)いつの時代になっても
一瞬の遅さを感じさせられるのも、いらいらさせられています。
#日本語変換のためだけにリアルタイムOSが欲しくなったりする(笑)。
そのクドいものを回避することこそが、入力速度に貢献するんじゃないか?と思うもんでして。
>本当に大量の文章を入力する人には、
ああそうか。この前提条件ですか。
文章を入力する「だけ」じゃなく、文をその場で「考える」という使用形態ならば、
単にそういう速度だけ求めても辛いです。
Re:入力システム (スコア:1)
>ところで止ってるとどう不都合なんでしょうか?
最近、仕事で提供するはめになっていますが。思いっきり不都合ですよ。最近作られたと思われる新しいメカニズムに対応してないし、その旨質問メールしても、なしのつぶてだし。オープンなものですから、最後の最後は自分で何とかすれば良いということになりますが、それは本当の最後の手段にしておきたい。
やっぱり、ソフトも「いき」が大切なんです。
Re:入力システム (スコア:1)
フリーで公開されているんですが使っていらっしゃる方居ます？
http://www.ekotoba.com/
そのうちどっかで採用されるかと思っていたんですがなんの進展
もないので知らない方が多いのかな？
Re:入力システム (スコア:0)
こういう時は別途タレコミなさい。
フォントが問題 (スコア:2)
この手のオフィススートで一番の問題はフォントでしょう。
欧米圏では主要なフォントは大抵デフォルトでついてくるし、名前も決まってるけど、日本語フォントはまだまだ。
実用に耐えるフォントは買わなくてはいけないのはまだいいのだが、
商用フォントを指定していると、ドキュメントのポータビリティがない。
この辺りが、とりあえずMSゴシックやMS明朝を指定しておけばいいWindowsにくらべて弱いところ。
とりあえずこれ、みたいなフォント名をどっかで規定してくれればいいんだが…。
現状と東風フォントかなぁ。
フォントの抽象化とか、フォント名の一括変換とかでもいいんだが。
-- Che Che - Bye Bye
Re:フォントが問題 (スコア:2)
CSS の font-family みたいなものを導入するってのはどうでしょう。
既存OSのフォントの扱いも、かならずしも最良とはいえないと思います。