ATOK 

ATOKは2012へバージョンアップしたが、やはり標準辞書は使いもしない単語が大量に登録されていて気に入らない。特に人名なんか同じ音でたくさん候補出力されても嬉しくない。というわけで、大昔から育ててきているATOK辞書を変換して使い続けることにした。ちなみにシステム辞書とユーザ辞書の両方だ。

古いATOK辞書を、辞書ツールを使ってテキストで出力し、新しいATOKの辞書ツールを使って新規の辞書を作成、次にテキストを辞書ツールを使って新しい空の辞書に流し込んでやるだけ。何でかわからないけども、ATOK2012は辞書ツールを使って作成した辞書をユーザ辞書として使用できなかったので、ATOK2012の標準の辞書ツールを持ってきて中身を空にして、古いユーザ辞書の中身を登録した。

なんだか、Justsystemの頑張っているところの多くを捨てているはずなんだけど、まぁ、気持ちよく入力・変換できることが一番なのでいいでしょう。いやぁ、今まで使っていたATOK17って、発売が2004年2月27日か、もう8年前ですな。Windows7で使えると思えなかったのでバージョンアップしたので、特に困らない感じ? 色々な新機能があるらしいけど、説明を読んでもいないなぁ。かかり受けとかは学習して欲しいんだけど、その辺りどうなんだろう。マニュアル読め、ってことですか。

ととと、「きょう」で日付に変換する機能がうまく働かないぞ。時刻への変換も。「じ」で時刻、「に」で時刻を推測変換候補に出してくれるけど。使う辞書が違うからうまく変換できない模様。

標準辞書(ATOK25.DIC)を使うと変換できるが、沢山の不要な単語が登録されている。じゃぁ、ATOK25.DICから単語を削除すればいいじゃない、と思ったのだが辞書ツールを使っても単語がひとつも出力されてこない。ウィンドウ内に表示されないだけかな? テキストファイルへの一覧出力も試してみたが出力0。むーん、、、諦めるしかないか? おお、そうか、「きょう」や「いま」を変換するときだけ[F5]で変換して標準辞書で変換すればいいのか。ちっとばかり面倒くさいが、まぁ、そんな頻度が高くないだろうから良しとしよう。

THEORY / 164 feat. GUMI 

THEORY買った。

THEORY -164 feat.GUMI- (ジャケットイラスト:鳥越タクミ)【数量限定オリジナルストラップ付き】THEORY -164 feat.GUMI- (ジャケットイラスト:鳥越タクミ)【数量限定オリジナルストラップ付き】
(2012/03/07)
164 feat.GUMI

商品詳細を見る


ボーカロイドに歌わせて、という形が出てきているよね。今後ボーカロイドはもっと洗練されて品質が向上していくだろうから音楽業界も変わっていくよね、きっと。全部打ち込み系で、ボーカルはボーカロイドで、ライブとか出てくるのは踊ってMCする人、という形とか?

「かんなぎ」7巻 

武梨えりの「かんなぎ」7巻が発売予定(2012/04/27)になってるよ。わーい、嬉しいなっと。

bash補完のカスタマイズ 

bashでは[TAB]で補完が行われるが、この補完機能はプログラム可能らしい。「入門bash」の付録Dにて説明がある。

例えばgunzipを実行する時に、gunzipで解凍できるファイルだけを保管させたい場合には以下のようにしておくといいとのこと。(※CentOS6.2では、パッケージbash-completeがインストールされている事が必要で、インストールされていないと半端で不可解な挙動をするので注意。)

complete -A file -X '!*.@(Z|gz|tgz)' gunzip

こうしておくことで、*.Z、*.gz、*.tgzだけが補完候補にされるとのこと。

completeのオプションについては以下の通り。

-o OPTION    オプション
    default       補完仕様がマッチを全く生成しなかった場合に、readline のデフォルトの補完を用います。
    dirnames      補完仕様がマッチを全く生成しなかった場合に、ディレクトリ名を補完しようとします。
    filenames     補完仕様がファイル名を生成することを readline に伝え、readline がファイル名特有の処理(ディレクトリ名にスラッシュを加えたり、末尾の空白を削除したり、など)を行えるようにします。シェル関数と共に用いることを想定しています。
    nospace       ?

-A ACTION   アクションを指定する
    file        ファイルリストを補完する。
-X PATTERN  補完されないファイルのフィルタパターン。"!"は除外する。
            compgenに引数としてPATTERNを渡すとどのように補完されるかを確認できる。



Big Skyを見て、自分も使ってみることにした次第。perldoc-completeはgithub.comから入手。

.screenrc 

今の私の.screenrc。

# stop resize when screen is execed or attache
termcapinfo xterm 'is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l'
#
#
#maxwin 100000
#defencoding eucJP
defencoding utf-8
#
# ^U
#escape ^UU
escape ^U^U
#escape ^@^@
#escape oo
#escape ^@^@
#escape ^w^w
#escape
#escape ^1^1 not work
#
#
#backtick 0 0 0 ${HOME}/.screen/backtick.pl
#backtick 1 0 0 ${HOME}/src/perl/screen/backtick.pl
#backtick 0 0 0 /bin/hostname
#
#
#hardstatus always
#hardstatus on
#hardstatus off
#hardstatus alwayslastline
#hardstatus alwayslastline "%w"
hardstatus alwayslastline "[%02c] %`%-w%{=b bw}%n %t%{-}%+w"
#hardstatus alwayslastline "%H %`%-w%{=b bw}%n %t%{-}%+w"
#hardstatus on
#hardstatus alwayslastline
#hardstatus string "%{.bW}%-w%{.rW}%n %t%{-}%+w %=%{..G} %H %{..Y} %m/%d %C%a "
#
#DUST
#hardstatus alwayslastline I%wI
#hardstatus alwayslastline "[%02c] %`%-w%{=b bw}%n %t%{-}%+w %0"
#
#
#
#
# command memo
#
# :encoding {eucJP|utf-8|sjis}
#logfile /home/hagiwara/tmp/app/screen/logfile%Y%m%d%c.%n
logfile /home/takuro/tmp/app/screen/logfile%Y%m%d%c.%n
deflog on
#
#
defscrollback 20000
#defscrollback 200000 # need many memory!


さくらのVPS/アップグレード 

さくらのVPSで、今CentOS 5.7を使っているのだけど、これをCentOS 6.xにしたい。アップグレード出来るのだろうか? それとも構築し直し?

少し検索で調べてみたのだけれど、データを引き継いでアップグレードする方法はなさそう。まぁ、そうだよね。
ファイルのバックアップをしてからOSの再インストールを行うことにするか。

自炊/必要十分な解像度 

UDONCHANの日記で書かれていたのだけど、高い解像度のディスプレイで表示すると自炊データにも高い解像度が要求されるということなのね。自炊する時にはどれだけの解像度を確保しておけば十分なのだろうか?

まず、前提としてスキャンする時に解像度を上げると何が起こるかといえば、(1)スキャン時間が長く掛かる、(2)データサイズが大きくなる、のふたつだと思う。

(1)のスキャン時間が長くなるという点がかなりクリティカルで、我慢出来ないほど長くなるのでむやみに解像度を上げられない。エントリークラスのドキュメントスキャナだと、400dpiがせいぜい限界だろう。400dpiでどのくらい時間が掛かるかというと、コミック1冊10分だ。1時間かけて6冊取り込むのが精一杯だ。これが200dpiになるとどうかというのを試したことはないのだけど、単純にデータサイズで考えると10×0.5×0.5=2.5で2分半で1冊スキャン出来、1時間で24冊取り込むことが出来る。
ちょっとお高い(10万円位?)ドキュメントスキャナを使用すれば、スキャン時間を短縮出来る。どのくらい早くなるのかはメーカの公称数値を元に想像してみて欲しい。

(2)のデータサイズはきっと大したことではなくて、400dpiでコミックを1冊データにすると大体100MBytes程度。100冊取り込んでも10GBytes、1000冊でようやく100GBytesだ。10000冊頑張っても1TBytesにしかならないのでこちらは「でかいHDD買えばいいじゃない?」今の10倍取り込む頃にはHDDが10倍の容量で同じ値段以下になっているよ、という感じだろうね。

で、どれだけの解像度でスキャンしておけばいいのだろう? これはスキャンの時間やデータサイズにはあまり関係のない話で、高い解像度のディスプレイで粗が見えない程度の解像度というのはどれだけか、という話だよね。iPad3(名前は何になったんだろう?)は、どうやら2048x1536で264ppiということだそうで、264dpiより高い解像度にしないといけないということは分かるね。想像だけど、ドットのつぶれやらを考慮してもきれいに表示するためには264dpiの2倍以上の解像度でスキャンしておいた方が良いんじゃないだろうか。

ということが今現在の話。将来ディスプレイサイズが同じでも解像度が高くなれば当然ppiの数値が大きくなる。それを見越した解像度でスキャンしておかないと、将来がっかりな自炊ということになるのかも。

そもそも、人間の目が通常の状態でどれだけの解像度を持っているのか、ということを基準にするべきかもしれないね。それはほぼ恒久的に使えるスキャンの解像度の基準になるんじゃないかな。つまり、本を読む時にどれだけ目と本を離していて、どれだけの情報を区別して識別出来るか、ということを調べればいい訳だね。

まず、人間の目の識別出来る詳細さがどれだけであるか、というのはこのページを見ると、角度にして1分=1/60度という事らしい。目と本との距離を20cmというちょっと近くにした時に、どれだけ短い距離の情報を区別出来るのかを計算してみる。

20×tan(π/(180*60)) = 0.0058 [cm]
0.0058 [cm] = 0.00229 [inch]

0.00229インチに1ピクセルという解像度だから、単位を[dpi]に直すと

1/0.00229 = 436.6 [dpi]

437dpiの解像度しかないということが分かる。(ほんとかな?) 案外、小さな解像度で済むね。これだけの解像度でスキャンしたデータならばディスプレイ側が高精細になっても粗が見えないきれいなデータであるということになるんだろうね。大抵のスキャナでは600dpiというのがきりの良い数字だから、この数字を使うんだろう。

だから、ドキュメントスキャナはいいものを使わないとやっていられないはず。エントリークラスのドキュメントスキャナでは400dpiでコミック1冊スキャンするのに10分として、600dpiではその1.5×1.5倍で22分30秒掛かる計算になる。1時間かけても3冊スキャン出来ない。これはかなりきつい。

ということで、自分は今まで400dpiでスキャンしてきたのだけど、将来を見越して600dpiでスキャン出来ないか今度試してみよう。

とはいえ、スキャンデータの解像度よりも、原稿の斜行の方がずっと気になるんで、そっちをどうにかして欲しいけどね。