2011年8月28日日曜日

LionでR

(ふと、昭和軽薄体を思い出したのだが気にせず流す)

Rの現行安定バージョンは、2.13.1(2011年7月8日リリース)だ。ちょうどLionが出る少し前である。ソースからビルドしている人はどうなのかわからないが、Lionユーザは公式のpkgではなく、http://r.research.att.com/ からバイナリをダウンロードせよという指示があった。行ってみると「Patched」な2.13.1のuniversal binaryが置いてある。pkgでも、tar.gzでも結果は同じようだ。

さらに、同じページの下にある「Mac OS X GUI」の「R-GUI-5895-2.13-leopard-Leopard64.dmg」を落としてApplicationsに入れてやる。これでひとまずGUIでRが使えるようになる。

作業ディレクトリがホームなので、適当に文書の下にRなどというフォルダを作って、そこを作業ディレクトリに設定するなどお好みで。GUIメニューから設定できる。

利用目的がRMeCabなので、MeCabのインストールとRMeCabの組み込みを公式ページに従って行う。ただし、Lionは完全64bit化されているので、わざわざ32bit版バイナリを選択する必要はない。64bit版を選ぶこと。

あとはlibrary(RMeCab)すればいいわけだが、QuartzにせよX11にせよ、どうも日本語が文字化ける(白抜きの四角になる)ようだ。これは2008年から指摘されていることのようで、~/.Rprofileにフォントの設定をしてやることで解決するらしい。(設定方法が記述されたページ

2.14の公式版が出る頃にはこれらが統合されていることを期待するけれども、端境期で戸惑う人がいるかもしれないと思って、ここにメモしておく。

2011年8月25日木曜日

LionユーザはChrome Betaチャンネルへ移行すべき

現行の正式バージョンGoogle Chrome 13.0.782.215はLion上ではメモリ管理に問題が生じているように見える。

Late 2010のMacBook Airでは特に意識することはないが、Mid 2009のMac miniでは明確にロードアベレージの上昇、プロセス数の増加(タブを消しても減らない)、アプリケーション終了時のクラッシュなど、メモリまわりが疑われる不具合が見られる。

そこで、ベータチャンネル版(14.0.845.109)に切り替えたところ、すべての問題が解消した。また、Lionの全画面・リストアなどに対応しており、Safariと同等の使い勝手となる。

Chrome 14が正式版になれば、安定版に戻してもよいだろうが、いまLion上でChromeを使用している人は、いちどベータチャンネル版を試してみるとよいと思う。

なお、Google IMEもLion上で入力をしばらく受け付けなくなり意図しない文字があとからあとから入ることがある。また、フォーカスが外れ、インライン変換できなくなる問題もある。使用状況が常にGoogleに送信される点が気になるが、開発版に入れ替えると安定しているように見える。

2011年8月24日水曜日

Acrobat Xの日本語ClearScanの問題

自炊本の文字認識で、Acrobat 9から導入されたClearScanが面白いという話を読んだ。

そこで試してみたのだが、なかなかよい。文字認識と同時に、文字のアウトラインを拾って新たなフォントのようにスキャン画像を置き換えるのだ。確認はしていないが、同じ文字と認識されたものは同じアウトラインを使っているように見える。処理結果が、なんとなく揃った文字のように見えるのだ。

英文書籍で試したところ、たいへん素晴らしい結果を得た。もとからアウトラインフォントで文字組みをしたかのような結果になる。

一方、日本語の文書に関しては必ずしもうまくいかない。

なにより問題なのは、「Acrobatは縦書きを知らない」ということだ。富士通のScanSnapは縦書き文書も縦横混在もうまく分解してそれぞれ適切に処理してくれるし、大昔のスキャナ添付のOCRでも縦書き文書の読み取りは(領域を指定すれば)できていた経験がある。特許の問題があるのかもしれないが、MacのOCRが壊滅的であることもあり、Adobe頼みであるからがんばってほしい。

そして更に今日遭遇したのは、文字認識処理が中断されるページがある、ということだ。これは困る。

このとき、Acrobat Proはこのようなダイアログを出して、いままでの文字認識結果を捨ててしまう。


「Paper Capture認識サービスのエラー」ということだが、せっかく認識した結果まで捨てて欲しくない。

そして、「この文書に今後発生するエラーを無視する」のチェックを入れてもかまわず、何度でもこのダイアログを出して停止してしまうのだ。何のためのチェックボックスなのかわからない。

同じ本で何度も出るため、このエラーを発生させる疑わしい例がなんとなくわかってきたような気がする。いま想定しているのは、以下のような場合だ。


つまり、グレーの背景に白抜きの文字があったとき、アウトラインの生成に失敗するのではないかと疑っている。背景の濃さによって通る場合もあるので、特定の条件で生じるものと思われる。なかにはこうした部分全体を図として、文字認識の対象としない場合もあるので、実験により現象の再現も可能かもしれない。

念のため、以上、ここに記しておく。

なお、動作環境は、Mac OS 10.7.1 Lion上のAcrobat Xバージョン10.1.0。Paper Captureプラグインのバージョンも10.1.0(日付10/10/26 6:34:15)だ。

追記:
Adobeの不具合報告フォームで本ページを報告した。

また、うまくいったケース(文字認識を断念して画像とした場合)を示しておく。

周囲の文字はアウトライン化されているが、網掛け白抜きの部分はビットマップのまま処理されている。

追記2:
類似の例で、テキストとして認識されているものを示す。

これは、Previewで表示して文字選択した場合。画像ではなくテキストになっているので、部分的に選択できる。

2011年8月12日金曜日

LionでEmacs 23.3a

Lionのフルスクリーンモードに対応したパッチが出ているということで、Emacs.appの最新版を自前でビルドしてみることにした。

まずは普通にオリジナルEmacs (Cocoa Emacs)にインラインIMEパッチを入れて作成。
先達の教えに従って、homebrewのRubyスクリプトを参照しながらパッチを集めてうまくビルドできた。C-\でのMacのIMEの切り替えも良好。

しかし、一方で「Emacs Mac Port」という、Carbon Emacsに実装されていたけれどもCocoa版に入っていない機能を組み込む別のパッチもある。ところがこれにインラインIMEパッチをあてても機能しない。"MacOSX"というインプットメソッドがない、といわれるわけだ。

理由は簡単で、インラインIMEパッチはCocoa Emacsに相当する、nextstepを意味するns関係のファイルに手を加えているから。例えばnsterm.h, nsterm.m, nsfns.m, ns-win.elなどだ。一方、Emacs Mac Portは独自にmacというシステムを追加し、独自に表示部分を実装していて互換性がない。どうしてもやりたければ、macfns.m, macterm.h, macterm.m, mac-win.elなどを調べて、必要な変更を加えなければならない。

この違いを確認するのは簡単で、window-systemをevaってやれば、Cocoa版ならnsが返るしEmacs Mac Portならmacが返る。

使い比べてみると、Emacs Mac Portはかなりがんばっていて、好感度が高い。ただ残念なのはうっかりC-\を押すとquailの貧弱なIMが起動して悲しいことになる。

必要性のある人が根性を出すのが正しいのだろうが、いかんせん手がまわらない。当面は、Cocoa Emacsの環境整備でごまかしていくつもり。

2011年8月8日月曜日

Propeller久しぶりで苦闘

夏風邪で1週間身動きできなかった。

ようやくPropeller(Spin言語)の続き。といっても、OSもLionになったし、そもそも基板の使い方も忘れているような調子で、ほとんど、単に思い出すだけで終わってしまった。

とりあえず、bst(開発環境)はLionでも問題なし。5月ぐらいの最新版にしておいた。

だが、USB給電ではPropeller chipは動かないことに気づくまで30分以上苦闘して、やっとACアダプタが必要だったことを思い出した始末。

続いて、単なるLチカが動かず、ほんとにVDDが出てるのかどうか、テスタをあちこち当てながら調べる始末。情けない。

ひとつだけ、Gadget Gangsterのテキストで、入力ピン番号を物理的ピン番号で指定しているが、論理ピン番号が正しいようだ。彼らの開発基板特有のことなのかどうなのか、わからない。少なくともParallaxの開発ボード(やPE Kitなど)では論理番号が正解のようだ。