※本サイトは、アフィリエイト広告および広告による収益を得て運営しています。購入により売上の一部が本サイトに還元されることがあります。 AUGM KOBE 2016において、トークショー参加のため会場にいた元Appleシニアマネージャーの木田泰夫氏に、backspace.fmのポッドキャストインタビューを行い「Danbo-side #001: Appleの日本語環境を支えた、これまで語られなかった20年」として配信されています。 Podcast「backspace.fm」は、iOSアプリ「Podcast」で、Mac/Windowsでは「iTunes」などで視聴出来ます。 1988年に発売された、ASCII配列のキーボードをベースにした「Apple Keyboard II JIS」（1990年にescape、capslock、controlキーの位置が現スタイルに変更される）は、木田氏が考えた
WWDC 2015で発表になった『OS X El Capitan』。もうアップルのWebでもプレビューが始まっているので、その中身をさっそくチェック中……という人もいるはずだ。 でも、Webページを読んでみると、WWDC 2015のキーノートでも触れられていない情報がけっこうある。特に日本のユーザーとして気になるのは、“新しい日本語の入力方式”という一文。 え、なにそれ？ 現地での取材で、その動作と狙いがちょっとわかってきたので、解説を行なってみたいと思う。これがなかなかに驚きの手法なのだ。 ■“文節区切り”の正しさが日本語入力の命 日本語入力といえば、基本はみなさんもよくご存じのとおりだ。ローマ字なり、カナなりで入力された文を、PC上で動作している“日本語入力ソフト”が漢字かな交じり文に変換していく。その際には、文章のどこがどういう単語で構成されているのか、という情報、すなわち“文節区切
モードレスとは？ みなさんは普段、日本語の入力と英語の入力をする時にIMEをON/OFFを切り替えているのが大多数だと思います。このON/OFFの切替をせずに英語と日本語を入力していくことを「モードレス」と呼びます。実際動いている動画は以下になります。 EmacsでMozcを利用してできるということなので、さっそく試してみるため環境を構築しました。 mozc_emacs_helper込みでmozcをmacでビルド 基本的にはac-mozc.elの開発者である@igjit氏が公開している手順をベースにして手動で変更手順を加えています。 mozcのソースなどを一式揃える $ cd ~/ $ svn co http://src.chromium.org/svn/trunk/tools/depot_tools $ export PATH=`pwd`/depot_tools:"$PATH" $ mk
iBus 1.5がクソすぎる
Ubuntu 13.10へのアップデートが、問題なく終わった。問題は、iBusが1.5にアップデートされてしまったことだ。 iBus 1.5は、去年の年末にリリースされた。リリース直後から、IRCでは怨嗟の声が絶えなかったが、今になって、ようやくその意味がわかった。iBus 1.5はひどい。ひどいなんてものじゃない。クソだ。いや、クソですら上品過ぎる。iBusは超超超超超・・・残念ながら、まだiBusを罵るべき言葉が発明されていないが、とにかくその超なにかだ。 UNIX風システムでは、伝統的に、日本語入力は、かな漢字変換を担当するIMEと、IMEと文字入力を受け取るアプリケーションの間の橋渡しをするIMに分離されている。ユーザーから見えるIMの役割としては、IMEの有効無効を切り替えることだ。 筆者はこれまで、IMとしてiBusを、IMEとしてMozcを使っていた。 iBusはIMである。
iBus 1.5はバグがあるからクソなのではない。設計上クソなのだ
先日、iBus 1.5がクソすぎると書いたが、以下によって、iBusをクソと罵るのではなく、貢献をしろという主張がなされている。貢献とは、ひとえにパッチを書いて送ることのみをいうのではない。問題の指摘や、使用した感想を報告するといった比較的軽いものも貢献に含まれると、そう主張している。 誰がオープンソースソフトウェアを酷いものにしてしまうのか - 人生が二度あれば もちろん、それはそうだ。ソフトウェアは使われるというだけで貢献になる。利用感を報告すればなお良いし、開発に参加すればさらによい。しかし、それは貢献が受け入れられるならばの話だ。そのような貢献を受け入れる機会は10ヶ月もあったが、依然としてiBusの上流で受け入れる気配はみられない。貢献が受け入れられなければ、貢献は貢献にならないのだから、貢献をするのは無駄だ。 iBus 1.5の問題は、バグではない。設計上の問題である。そして、
私はこんにゃく新世代日本語入力プログラムを使用してこのブログのエントリを書いています。 今日、Mootoh こんにゃく 0.2 をリリースしました。 mootoh/Konjac @ GitHub Motohiro Takayama - Google+ - Konjac 0.2 をリリースしました。 変更点: - バックスペースキーを有効にし、実用に耐えるように -… (追記) さすがに乱暴すぎたのでちょっとだけまともに日本語入力して追記。 バイナリーはここからダウンロードできるので、興味ある方はぜひお試しくださいませ。 宴会芸並くらいには楽しめますw ある日、私たち （Mootoh、Niw、私は） Skype のチャットでした。Mootoh 突然新しい日本語入力プログラムのアイデアに触発。このアイデアは、日本語入力変換エンジンとして Google やビンビン(Bing)の tranlate
Sekka(石火): SKK like Japanese input method Sekka(石火)はkiyokaが開発中のSKKライクな日本語入力メソッドです。現在はEmacs専用です。 特徴 モードレス Sekkaには日本語入力モードという概念がありません。Emacsのカーソル位置のローマ字を(Ctrl+J)キーで直接、漢字変換できます。 SKKライク 入力するローマ字表記ルールはSKKに近いルールを採用していますので、SKKユーザーは簡単にSekkaで文章を入力することができるでしょう。 ミスタイプ許容 ローマ字表記の揺れ(siとshi、nとnnなどの混在)や少々のローマ字のミスタイプは曖昧辞書検索によって救済されます。 Kanji => "漢字" Kannj => "漢字" Funiki => "雰囲気" fuinki => "雰囲気" Shizegegosor => "自然言語
Google CGI API for Japanese Input Google CGI API for Japanese Input は、日本語変換をインターネット上で実現するための、CGI サービスです。 リクエスト http://www.google.com/transliterate に対して HTTP リクエストを発行します。GET メソッドを使ってください。以下の CGI パラメータを (URL エンコードした上で) 指定します。 langpair=ja-Hira|ja text=(変換したいひらがな列) text のひらがな列は UTF-8 でエンコードします。例えば、「へんかん」をリクエストする場合は、 http://www.google.com/transliterate?langpair=ja-Hira|ja&text=%E3%81%B8%E3%82%93%E3%81
前回もお伝えしたように，そもそも TSF の話を急いでする必要はなくなりました． Windows Vista で当初私が懸念していた Full IME-aware applications の UI ウィンドウ制御に関する互換性問題は，DirectX SDK のサンプルに存在していたバグが原因であり，Vista 開発陣は IMM32 の互換機能をきちんと実装していること 現在いくつかの MMORPG 等で発生している Windows Vista での日本語入力に関する問題は，もし上記 DirectX SDK のバグと同じコードが使用されているのであれば，非常に簡単に修正可能であること 今後 Legacy IM が TSF で置き換えていく流れが確実になっているとはいえ，これで当面急いで TSF に乗り換える必要は無いと思います． そういうわけでしばらく時間をおいてもいいのですが，いったんま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
