DSi持ってなくて涙目なのでiPhoneをポケコン化してみたよ

プチコンが話題沸騰してますね。

■プチコン
http://smileboom.com/special/petitcom/index_a40.html

「こんにちはマイコン」とベーマガをバイブルに育った当時の小学生の一人として、こういうお手軽プログラミング環境が出てきてくれるのはとっても嬉しいです。
少しでもプログラムをかじったことがある方なら同意してもらえると思いますが、日々のちょっとした課題（飲み屋で割り勘の計算が面倒になったとか）に直面したときに、パパっとコーディングできる環境がすぐ手元にあれば、とても便利ですよね。
（そういえば昔、ポケコンという素敵なマシンが私たちのこの夢を叶えてくれていました）

是非にでも手に入れねば！と思ったのですが、よく見たらダウンロード専用なんですね、このソフト…
私は残念ながらDS liteしか持ってないのです…無念。

DSiが無いならiPhoneで作ればいいじゃない

「まあ3DSも出たことだし、ここらで腹を括ってDSを新調しようかな〜」とも考えたのですが、ここで釣られるのも何だか負けたみたいで悔しい気分。
要はポケコンの代わりになるものが手に入ればとりあえず満足なんだし、普段持ち歩いているモノで何とか代用を…というわけでiPhoneに白羽の矢を立ててみました。


さて、ご存知のとおり、AppleはiPhone上でインタプリタ的な動作をするアプリの配布を禁止しています。マトモにBASICアプリを作ってApp Storeに申請してもrejectされるのは目に見えています。
（そもそもObjective-Cなんてナウい言語書けるなら苦労しないよ！というのが元ベーマガ世代）

ただし一つだけ、iPhoneにはデフォルトで組み込まれているインタプリタ環境があります。そう、SafariのJavaScriptエンジンです。今回は、コイツを使った簡易プログラミング環境を考えてみました。
名づけて「iぽけこん（iPocketCOM）」。

使い方

■iPocketCOM
http://dl.dropbox.com/u/460959/iPocketCom/index.html
上記ページにアクセスします。

編集画面


最初のページが編集画面になっています。テキストエリアの中に適当なJavaScriptを書いてみましょう。
下の「実行画面へ」ボタンを押すと、実行画面に移ります。

実行画面


「実行」ボタンを押すと、先ほど記述したJavaScriptが実行されます。一応、最低限のプログラミング環境らしき形にはなりましたね。

もうちょっとBASICらしく

これで最低限の目標はクリアしましたが、実行結果をダイアログにしか返せないのは不満が残ります。
実行画面のHTMLの内容を書き換えるようなコードを書けば永続的に結果を表示することはできますが、ちょっとBASICの気軽さとは程遠い感じになってしまいそうです。
そこで、往年のBASICのような対話型のインタフェース（コンソール画面）と、入出力用の関数を用意しました。ちなみにWebブラウザにはターミナルはありませんので、実行画面にテキストエリアを配置し、擬似的にターミナルっぽく使ってます。

icprint

BASICのPRINT文ライクにターミナルに文字を出力します。

icprint ("こんにちは！こんにちは！");

iccls

icprintで色々と書きこまれたターミナル画面をクリアします。プログラムの冒頭に書いておくといいかも。

iccls();

icinput

BASICのINPUT文ライクに文字を入力します。…というのがやりたかったのですが、面倒くさくなったので入力自体はpromptに投げてダイアログボックスを出すようにしてます。
一応、入力内容をターミナルにエコーするようにはしているので、表示結果だけはINPUT文ぽくなってます。

a = icinput("あなたのお名前は？ ");
icprint(a + "さんですね！");

プログラムのセーブ・ロード

ありません。編集画面のコードをコピペして、適当にメモ帳にでも貼っておけば充分でしょう。
HTML5のlocal storageとかで実装できたら面白そうですねポワワ。

仕掛けとか制限事項とかぼやきとか

  • お察しのとおり、入力した内容をevalに放り投げてるだけです。
  • サーバサイドの技術は一切使っていません。ソースもHTML1枚のみですので、セキュリティとかの心配は大丈夫だと思います（拾い物のコードを実行したりしなければ）。
  • エラー時は、例外の内容をそのままダイアログボックスに表示します。行番号とか表示されないのでデバッグは困難を極めますが、そもそもそんな長いコードを動かすことは想定していないので勘弁してください（適当）。
  • 無駄にjQuery Mobileとか使ってみました。簡単に擬似ページ遷移っぽいものが作れて便利ですね。
  • オフラインキャッシュとか使えばiPod Touchでもお外でコーディングが楽しめそう。
  • 実際にテストしている最中に気づきましたが、iPhoneのソフトウェアキーは記号が超絶入力しにくいです。心が折れます。
  • iPadで使うと画面が大きくて多少幸せかも。

おわりに

かなり以前から、「ケータイとかスマートフォンとか、昔のポケコンより断然ハイスペックなのに、どうしてユーザーが手軽にプログラミングできる環境がないんだろう？」と疑問に感じていました。今回、ちょっとショボイですが自前のコードを動かせる環境を用意できて、ようやく自分の中で溜飲が下がる思いです。

日本はケータイ普及率・利用率が高い国なんですから、すべてのユーザーがほんのちょっとでもプログラミングの基礎を学ぶ機会、そして手軽に自分のケータイから使える環境があれば、ITに対してもっと理解が深まるんじゃないかなぁ…などと思うのでした。
今の小学生、中学生の中から、プログラミングの楽しさに目覚める子が一人でも多く現れるために、私たちベーマガ世代のおっさんに何ができるか、これからも考えていきたいです。

Scansnapで「いかに効率良く」本を電子化できるか試行錯誤してみた（スキャン＆画像加工編）

前エントリからの続きです。

3.スキャン 10:27〜12:02（1時間35分）

いよいよやってきました本命作業、スキャンです。
いきなりスキャンといきたいところですが、まずは前準備。
生成されたスキャンデータを格納するための空フォルダを、あらかじめ用意しておきます。こんな感じです。

次に、Scansnap Managerでスキャンの設定を確認しましょう。私は以下のような設定を「コミック用」としてカスタム保存しています。

■アプリ選択

  • アプリケーションの選択：アプリケーションを起動しない

■保存先

  • イメージの保存先：（ローカルドライブのマイピクチャフォルダ）
  • ファイル名の設定：「自分で名前を付けます」「Aaa_」「連番3桁」

■読み取りモード

  • 画質の選択：スーパーファイン
  • カラーモードの選択：カラー
  • 読み取り面の選択：両面読み取り
  • 継続読み取りを有効にします：オフ
  • オプション：「文字をくっきりします」のみオン

■ファイル形式

  • ファイル形式の選択：JPEG

■原稿

  • 原稿サイズの選択：サイズ自動検出
  • マルチフィード検出：重なりで検出（超音波）

■ファイルサイズ

  • 圧縮率：1（圧縮率最弱、ファイルサイズ最大）

ポイントは保存ファイル形式にJPEGを選んでいることです。PDF形式であれば、スキャン後すぐに本単位でアーカイブされて手間入らずなのですが、いかんせんその後の整形処理や、別途二次加工したいとき（iPhoneやKindleといった読み取り装置に合わせたデータの最適化など）に手間がかかります。その点、JPEGは加工や変換といった後工程での取り回しが便利なのです。

能書きはさておき、スキャンしてみましょう。まずはカバーから。
「あれ、そういえばカバーを裁断していなかったような…」と思った方は鋭い。実は私、カバーを裁断せずに長尺で読み込んでしまってます。

この向きで、スキャンボタンを点滅するまで長押ししてスキャン。ベロの部分が巻き込まれやすいので、手で支えながら読み込んでください。
1枚目が白紙（カバーの裏）、2枚目に長尺でカバー全面がスキャンされると思います。1枚目の加工は後でしますので、取り敢えずここはこのままで。

続いて本文のスキャンです。斜行防止＆読取速度向上のため、横向きにスキャンします。

基本的に表紙から裏表紙まで順々にセットして読み込ませればOKなのですが、向きにだけ注意。「表紙を奥、向かって右手側が天になるように」（裁断面が上にくるように）セットしてください。この理由もあとで説明します。

今回スキャンしたAQUA/ARIAは各巻184ページ（カバー含む）でしたが、さすがにこの量を一気にセットするとScansnapが給紙できないので、2〜3回に分けてスキャンします（継続読取オプションをオフにしていますが、JPEGの場合、フォルダ内のファイルを見て、自動で連番を継続したファイル名で生成してくれるので問題なくスキャンできると思います）。

ちなみにどなたかも仰っていましたが、給紙されやすいように紙をずらしてセットすると、多少枚数が多くてもスムーズにフィードしてくれます。

スキャン速度はこのくらいです。

ちなみにスキャン時間に1時間半も要しているのには理由があって、Scansnap自体は1冊あたり1分強でスキャンできているのですが、スキャンで使用しているパソコンがかなりチープなため（CeleronM 1.5GHz、メモリ512MB…）ファイルが生成されるまでの待ち時間が同じくらいかかってしまっています。
なので、最近のWindows Vista/7が動くようなスペックのマシンをお持ちであれば、1時間程度でスキャンが完了するのではないかと思います。


待ち時間は、ほかの漫画を読んで時間潰し。ついつい読み耽ると作業が停滞するので気を付けましょう。

1冊スキャンが終わったら、最初に作っておいたフォルダにJPEGファイル一式を移します。横着してそのまま2冊目のスキャンに入ると、1冊目から継続の連番ファイル名が振られてしまい、泣ける事態になるのでご注意を。

ここでお腹が空いたので、45分ほど昼休み。続く加工作業に備えて、データをバックアップしておきました。
（この時点では1冊230MB、14冊合計で3GBほどのサイズでした）

ちなみに私の場合、これ以降の工程は別マシン（Macbook：Core2Duo 2.0GHz、メモリ4GHz）を使ってます。理由は、続く画像加工工程が半自動化できているため、マシンを2台使うことでスキャンと画像加工を並行して進められるからです（パイプライン処理みたいなもんです）。そこまで本気出して作業することは滅多にないですが。

4.画像加工 12:45〜13:44（59分）

！注意！
ここでご紹介するやり方は効率重視のため、かなり「自分向け最適化」に走ってます。
内容的に稚拙なところもありますし、なにより汎用性をまったく考慮していません。
もし参考にされる方がいれば、丸ごと真似するのではなく部分部分の「エッセンス」を汲みとって頂ければ幸いです。

いきなりエクスキューズから入ってすみません。ひととおり書き出してみたら、あまりにわかりにくかったので…
画像加工するソフトは、WindowsでもMacでも豊富にありますので（代表的なのは「藤-resizer-」とかでしょうか）、ご自分のやりやすいツールで同じような処理をすればよいと思います。


では、本題。
スキャンしたデータを、扱いやすいように加工します。大まかに言うと、次のような作業があります。

  • 表紙ページの切り出し
  • 白黒ページのグレースケール化
  • ファイル名のリネーム
  • リサイズ
  • 回転
  • 圧縮率の調整

このうち、「表紙ページの切り出し」は手作業が必要なのですが、残りの作業はほぼ機械的に処理できるので、スクリプトの力を借りることにします。
「スクリプト」とか書くと凄いモノを期待されそうで恐縮なのですが、自分は四半世紀前の8ビットマイコン時代にBASICをいじっていたロートル世代なので、最近の高級言語とかさっぱり付いていけてません。
今回はそんな自分でも何とか扱えそうなPerlとImageMagickをチョイス。MS-DOSのバッチファイルに毛が生えた程度の低クォリティでお届けします。

まずは表紙の切り出しから。
先程カバーを長尺でスキャンしたデータが「Aaa_002.jpg」というファイルに入っていると思いますが、その中から表紙部分だけを切り出し、白紙だった1ページ目「Aaa_001.jpg」と差し替えます。
（大抵のリーダーソフトでは、1ページ目がサムネイルとして扱われるため、表紙が入っていると都合が良いのです）
使用するソフトは何でも構いませんが、私はWindowsのIrfanviewを使ってます。

切り抜いた表紙を180度回転させて「Aaa_001.jpg」として保存。これを全冊分繰り返します。
「何かめんどくさいなぁ」という気がすると思いますが、裁断機できっちり表紙を裁断するのも結構神経を使うので、私はこの方法が気に入っています（デジタルですから何度でもやり直せますし）。
今回は14冊分で10分程度の作業でした。

さて、残りは自動化…といきたいところですが、もう一つだけ手作業があります。グレースケール処理を自動化するにあたり、カラーページと白黒ページの区別が付くよう、何らかの目印を付けてやる必要があるのです。
私の場合、安直ですがファイル名で区別するようにしました。

  • 「Aaa_xxx.jpg」カラーページ
  • 「aaa_xxx.jpg」白黒ページ

…何だか危険な香りがしますが、取り敢えずこれで何とかなっちゃってますので良しとしましょう。

先程スキャン時に設定したプレフィクスは「Aaa_」ですから、このままだと全ページがカラーページという扱いですね（カラー→白黒は不可逆なので、ミス防止のため敢えてこうしています）。
なので、Windowsならエクスプローラの「縮小表示」などの機能でざざっと全ページを眺めて、白黒ページのファイル名を「aaa_」にリネームしてやります。
といってもほとんどが白黒ページですから、1ファイルずつ手でリネームしてたら日が暮れてしまいます。ここは文明の利器に頼ります。

◆rename.pl

#!/usr/bin/perl
use utf8;
use Encode;
use Encode::Guess qw/euc-jp shiftjis 7bit-jis/;

$snum = $ARGV[0];
$enum = $ARGV[1];
$flag = $ARGV[2];
if ($snum eq '' || $enum eq '') {
	die ('no argument.');
}

for ( $i = $snum; $i <= $enum; $i++ ) {
	$i3 = substr('000'.$i,-3,3);
	$oldname = 'aaa_'.$i3.'.jpg';
	$newname = 'Aaa_'.$i3.'.jpg';
	if ($flag ne 'r') {
		rename($oldname,$newname);
		print $oldname." => ".$newname."\n";
	} else {
		rename($newname,$oldname);
		print $newname." => ".$oldname."\n";
	}
}

お猿さんが書いたようなコードですね。いいんです。動くんだから。
使い方は、ターミナル（コマンドプロンプト）を起動し、リネームしたい本のフォルダ下にカレントを移して以下のコマンドを。

perl rename.pl 5 180 r

第1引数から第2引数までの連番ファイルを対象にリネームします。
（上の例だとAaa_005.jpg〜Aaa_180.jpgが対象）
第3引数の「r」を付けると「Aaa」→「aaa」、付けないと「aaa」→「Aaa」です。もう少し何とかならんかったのか、この仕様…


さて、無事にリネームが完了したら、いよいよ自動加工です。以下の内容を全冊／全ページに対して一括処理します。

  • グレースケール化：ファイル名が「aaa」の場合、実施
  • リネーム：「aaa」の部分をフォルダ名と差し替え
  • リサイズ：横最大2000、縦最大1142（※）でリサイズ（縦横比は維持）
  • 回転：奇数ページを左90度、偶数ページを右90度回転
  • 圧縮率の調整：圧縮率90%のJPEGで生成

※Kindle DXのスクリーンサイズに合わせています。お好みで調整可。

◆rotate.pl（要ImageMagick）

#!/usr/bin/perl
use utf8;
use Encode;
use Encode::Guess qw/euc-jp shiftjis 7bit-jis/;

$rflag = $ARGV[0];
if ($rflag eq 'r') {
	print "Rotate:ON\n";
} elsif ($rflag eq 'nr') {
	print "Rotate:OFF\n";
} else {
		die ('no rotate option (r or nr)');
}

@indirs = glob "*";
foreach (@indirs) {
	$dirname = $_;
	if ( -d $dirname) {
		$dirname2 = $dirname;
		$dirname2 =~ s/(\[)/\\\[/;
		$dirname2 =~ s/(\])/\\\]/;
		@infiles = glob $dirname2."/*.jpg"; 
		foreach (@infiles) {
			$filename = $_;
			$filename2 = $filename;
			$filename2 =~ s/aaa/$dirname/i;
			$deg = 90 - (substr($filename,-5,1) % 2)*180; #even=>90, odd=>-90
			if ($rflag eq 'r') {
				$rotate = ' -rotate '.$deg;
			} else {
				$rotate = '';
			}
			if ($filename =~ /Aaa/) {
				$gray = '';
			} else {
				$gray = '-type GrayScale ';
			}
			$str = 'mogrify'.$rotate.' -geometry 2000x1142 -quality 90 '.$gray.$filename;
			system $str;
			rename($filename,$filename2);
			print $str." => ".$filename2."\n";
		}
	}
}
print $filename."\n";
print substr($filename,1,1)."\n";

…21世紀にもなって、ここまで汚いコードをかける人間もなかなかいないんじゃないでしょうか、ええ。
使い方ですが、各本のフォルダの上位フォルダ（ここでいうとマイピクチャ直下）で、次のコマンドを叩きます。

perl rotate.pl r

第1引数のrオプションは必須です。代わりにnrを指定すると、回転処理だけを抑止できます（縦向きにスキャンした場合のために用意してます）。

全冊一気に処理するので、さすがにかなり時間がかかります（今回は35分）。完全自動ですので、30分アニメを一本見るなり、お風呂に入るなりして気長に処理を待ちましょう。寝る前にセットしておくのもいいですね。

ちなみにリサイズと圧縮のおかげで、ファイルサイズは1冊226MB→47MBまでダイエットできました。この位のサイズであれば保存場所に困ることはなさそうです。

5.アーカイブ 13:44〜13:47 （3分）

いよいよ最終工程、アーカイブです。
バラバラのJPEGファイルのままでも実用上問題ないんですが、1ファイルにアーカイブされていた方が扱いやすいので、無圧縮ZIP形式にまとめます。

使用するツールは何でも構いませんが、色々試してみたところシェアウェアのWinRARが便利そうです。

  • 複数フォルダを選択し、フォルダ単位で一括アーカイブ可能
  • 変換設定をプロファイルに記録し、エクスプローラの右クリックメニューから呼び出し可能

もちろんほかのツールでも構いません。
ただし、Mac環境のzipコマンド等で圧縮すると、Windows環境でファイル名が文字化けしてしまうようなので気をつけてください（おそらくファイル名がShift-JISかUnicodeかの違いが問題のようです）。

おわりに

ここまで読みにくい文章にお付き合いいただき、ありがとうございました。皆さんの蔵書スキャン作業の一助になれば幸いです。

Scansnapと付き合い始めてまだほんの数カ月ですが、自分にとってはもはや欠かせないマシンになっています。
蔵書の電子化は、収納スペースの節約というのが一番目に見えやすいメリットなんですが、「思い立ったらすぐに読める」「紙とは比較にならないくらい大量のコンテンツを持ち歩ける」という二つが大きな嬉しさなんじゃないかと、個人的には思っています。ちょうど、iTunesやiPodが音楽の楽しみ方を大きく変えてくれたのと同じですね。
（Appleも電子書籍の販売に乗り出すみたいですが、「本のシャッフル再生」みたいなアバンギャルドな機能が付いてくれないかなー、とちょっと期待しています）


今回スキャンしたデータを表示。MacはComicViewer、iPhoneはiComicを使ってます。

それでは、楽しい読書ライフを。

Scansnapで「いかに効率良く」本を電子化できるか試行錯誤してみた

Scansnapによる蔵書の電子化、流行ってますね。
私もブームに乗せられて最近購入したスキャン初心者なのですが、既に多くの先人たちがブログや2ch等で様々なノウハウを公開してくださっていて、非常に助かっています。


そこで恩返しというわけではないのですが、自分なりのやり方をここにまとめておきます。
こだわりのポイントは、タイトルにも書いた「いかに効率良く」という部分。
私は所謂サラリーマンで、スキャンに費やせる時間は土日だけです。
そこで、「手間をかけず」「短時間で」本をスキャンするにはどうすればいいか、色々と知恵を絞りました。


スキャン三種の神器。裁断機PK-513、パソコン、Scansnap S1500。

本の電子化、その全工程

ではまず、電子化の工程を確認してみましょう。
ご存知のとおり、本の電子化には、スキャン以外にもさまざまな前／後処理が必要です。

  1. 不要物の除去（オビ、カバー等）
  2. 裁断
  3. スキャン
  4. 画像加工（リサイズ、回転、グレースケール化）
  5. アーカイブ

ざっとあげるとこんなところでしょうか。
で、効率化するために私が考えたのは作業の「均質化」「大量処理」「自動化」です。

◆均質化
なるべく同じ種類の本をまとめて処理しましょう、ということです。判型、ページ数、本の作り（カラーページの有無など）が似通ったものをまとめて処理することで、個別の例外作業を極力減らすということですね。例外作業が多くなると、作業効率が上がりませんし、ミスの元になります。

◆大量処理
単純作業に関していえば、一つの作業に集中する方がスピードアップが図れます（工場のライン業務とまったく同じ考え方ですね）。なので、上記の5工程を1冊ずつ処理するのではなく、なるべく沢山の本をまとめて処理してしまおう、というものです。

◆自動化
一度スキャンして電子化してしまえばしめたものです。ツール等を活用して徹底的に自動化し、なるべく人間の時間を拘束しないようにしましょう。

…なんだか、どこぞの生産現場の「カイゼン」のようなノリになってきましたが、気にせず続けます。

今回のお題


AQUA（全2巻）、ARIA（全12巻） (c)天野こずえ／マッグガーデン
「均質化」という点で、シリーズ物のコミックや小説は格好の題材です。カバーのデザインや口絵のカラーページの枚数なども揃っているので、作業もはかどるでしょう。
それでは、作業スタートです。土曜日の朝10時から取り掛かったのですが、所要時間も計ってみたので参考にしてください。

1.不要物の除去 10:00〜10:08（8分）

まずはスキャンの邪魔になる本のオビを外します。

また、間に挟まっているしおりやアンケートはがきなども取り除いておきましょう。余計な紙が挟まっていると、ダブルフィードを起こすだけでなく、ジャムが発生し最悪原紙がグシャグシャになってしまう恐れもあります。少し時間をかけても丁寧に見ていきましょう。

次は表紙カバーです。まとめて裁断できるよう、これもまとめて外します。

カバー下におまけの描き下ろしが！ちょっとトクした気分。

この状態で作業完了です。

2.裁断 10:08〜10:27（19分）

さて、いよいよ裁断です。アナログ、かつ不可逆な作業（失敗したらやり直し不可）ということで、ある意味一番神経を使う工程です。

PK-513の場合、LED光でカットラインが確認できるので、まずは本の端に光を合わせ、そこから目盛りを見つつ裁断幅分だけ奥に本を押し込みます。


今回は裁断幅を5mm（13.0→12.5mmまで押し込み）にしました。

同じ判型の本であれば、一回のアジャスト作業で済むので効率的です。なお、今後類似の本をスキャンするときに備えて、セット位置をメモしておくと良いと思います。

あとは運を天に任せて切ります。

裁断後は、切り口面を良くチェックします。裁断幅が足りなくて糊が残ってしまっていると、スキャン時にジャムって悲惨なことになるので、丁寧にチェックしていきます。

特にカラーページや表紙／裏表紙の前後がしっかり糊付けされていることが多いので、要チェックです。

切れてないとこうなります。定規などを差し入れて、そっと糊を剥がしましょう。

切った本は、カバーでくるんで保存します。

これで作業完了です。くれぐれも山に蹴躓いて崩したりしないように。数千枚のページがシャッフルされて、この世の地獄を見ます。

裁断後に残る背表紙…こればっかりは使い道がないので捨てます。南無。

長くなったので、続きます。

KOJINSHA PMシリーズとsigmarion IIを比較してみた

巷で話題のKOJINSHA PMシリーズ。

初めて見た瞬間に「シグマリオンみたいだなぁ」と思ったので（ブコメで書いていた方もいました）、実際どんなものかスペックを比較してみました。

◆PMシリーズ 仕様
http://jp.kohjinsha.com/models/pm/specification/index.html

◆sigmarion2 仕様（公式が消滅していた模様なので下記あたりから引用）
http://www.sofmap.com/product_detail/exec/_/sku=40776297/-/gid=UD05030000
http://www.dennobaio.jp/asp/cgi-bin/shop.php?forward=gds_inf&back_screen=gds_srh&stock_no=51CE0101G2500203

モデル名 PM1WX16SA sigmarion II
OS Windows XP Home Edition(SP3) Handheld PC 2000(WindowsCE 3.0)
プロセッサ Atom Z510(1.10GHz) VR4131(200MHz)
メインメモリ 512MB 32MB（ストレージと共有）
ストレージ SSD 16GB RAM 32MB（メインメモリと共有）
ディスプレイ 4.8型ワイドTFTカラー液晶 6.2インチ HPA透過型カラー液晶
解像度 1,024×600（約1,619万色） 640×240（65536色）
通信機能 無線LAN IEEE802.11 b/g
Bluetooth Ver.2.0+EDR		 なし
スピーカ 内蔵モノラル 内蔵モノラル
カメラ 130万画素 なし
外部インターフェース microSD、マイク
miniUSB2.0、専用ステレオイヤホン		 CFカードスロット（TypeII）
携帯電話/PHS接続コネクタ
FOMA端末接続コネクタ
シリアルポート
赤外線通信ポート（IrDA1.0準拠）
ステレオイヤホン
駆動時間 約7時間
（カメラ、無線LAN、Bluetoothの各電源オフ時）		 約4.5〜10時間（非通信時）
約3〜5時間（通信時）
消費電力 最大時 約24W
通常時 約6W		 4W
外形寸法 158×94.2×22(mm) 189×107×27(mm)
質量 約345g 約500g
価格 ￥59,800（税込） ￥59,800（税込）

こうして比較してみると、スペックは勿論のこと、サイズや重量でもPMシリーズの方が優れているんですね。
そして何の因果か値段までピッタリ同じ…いやはや、技術の進歩とは恐ろしいものです。。。

Googleマップで都立潮風公園の位置が間違っている件

先週、話題の「お台場ガンダム」を拝みにいったのだが、iPhoneのGoogleマップを頼りにしていったらとんでもない目に遭った。


いやそれ、「台場公園」ですから。
おかげでリア充やセレブたちが日光浴する場違い空間を延々彷徨う羽目に。くそう。

結局「海浜公園のサイトを検索」→「正しい住所をマップに再入力」→「こっちかよ！」ということで事なきを得たのだが、炎天下を歩き回らされたのは参った。

ようやくご対面。


で、Googleマップの修正依頼はここからできるらしい。

■住所の間違いについての報告 - マップ ヘルプ
http://maps.google.co.jp/support/bin/request.py?contact_type=incorrect_location

早速依頼してみた。私のような被害者が増える前に早急に対応いただけることを願おう。

OSXでエロゲをプレイするためのTips

Intel macなら、Bootcampを使って素直にWindows環境を構築するのが清く正しいエロゲユーザー。
しかし敢えて「OSX上で」エロゲを動かすという不毛なチャレンジをしてみたのでメモに残しておきます。

ちなみにこちらの記事を全面的に参考にさせて頂きました。多謝。
■Darwine 1.1.1を試す

用意するもの

  • Darwine（OSX上で動作するWine）
    こちらにビルド済みのものが公開されていたので拝借。
  • Windows用の日本語フォント(msmincho.ttc、msgothic.ttc）
    Windowsの動作している実機からコピー*1
  • エロゲのインストールディスク。

セットアップ手順

  1. Darwineをインストールする。
    dmgをマウントして、ドラッグアンドドロップするだけ。
  2. 日本語フォントを組み込む。
    Windowsからコピーしてきたttcファイルを、/Applications/Darwine/Wine.bundle/Contents/share/wine/fonts/ 配下にコピー。
    ※Finderからは辿れないので、素直にターミナルからコマンド叩いてコピーするが吉。
  3. エロゲをインストールする。
    CD/DVD-ROMからsetup.exe等を直接ダブルクリック。
    （既に*.exeにDarwineが関連づけられているので、自動的にWindowsアプリとして認識される）

ぶっちゃけ3.が一番鬼門。
インストーラー自体がWindowsアプリケーションなので、こいつが動いてくれないことには話になりません。運悪くインストーラーでこけてしまった場合の対処については後述。

インストール先は、wineのディレクトリ配下のdrive_cというフォルダが仮想のCドライブ扱いになる模様。
wineのディレクトリもFinderから直接見れないので、冒頭の参考サイトにあるようにシンボリックリンクを張るなどして見えるようにしておくと便利。

なお、Webで公開されているフリーのノベルゲームなどで、インストーラーが用意されていない場合はもっと話が簡単です。
アーカイブを解凍した中身を適当な場所（デスクトップでも可）に置くだけで準備完了。

いよいよ起動

ゲームの実行ファイル（*.exe）をFinderからダブルクリックして起動。運が良ければ二次元の嫁たちとご対面できるはず。

■動作イメージ（ソフト名：ナルキッソス２ (c)ステージなな）

…すいません。エロゲじゃないですね。

インストールがうまくいかない場合のTips

  • とりあえず再起動してみる。
    X11が変な落ち方をして、リトライしてもウインドウ生成エラーしか返さなくなった際、再起動したら直ったことがありました（ゴミプロセスが残っていた？）。
  • 超強引だが、一旦Windowsマシンにエロゲをインストールし、展開されたファイル群をDarwine環境にコピーするという荒技。
    起動時にレジストリ等を細かくチェックしている場合はアウトですが、案外すんなり動作することもあるので諦めずに試してみる価値はあり。

ちなみに私は元々Bootcamp使いで、内蔵HDDにWindows XP環境（エロゲ専用）も同居しているのですが、XP環境にインストールしておいたエロゲをOSX側からDarwineで起動したらそのまま動いた！というケースもあり驚きました（OSXからは書き込みできないNTFSで、しかもドライブレターすら合ってないのに…）。
Windows環境をお持ちで、最後の悪足掻きをしたい方はどうぞ。素直にWindowsで楽しんだ方が早いですが。

気になるパフォーマンスは？

Windowsネイティブ環境と比較すると、やはりグラフィックやサウンドの負荷が高い印象。
ソフトによりますが、画面切り替え系のエフェクトがもっさりしたり、音楽の切り替えにワンテンポ詰まったりすることがあります。
Remote Desktop越しでプレイするよりはマシ…という覚悟でいると幸せになれるかもしれません。

どうでも良いけどParallels Desktop使えばいいんじゃね？

……ですよねー。
強いて負け惜しみをいうと、

  • ネイティブアプリケーションとして動作するので、省リソース（のはず）
  • Windowsはフォント取得用に1本あればいいので、95やNT4.0など（エロゲの動作環境を満たさない）古いバージョンしか持ってなくてもOK*2
  • 無料で試せる
    エロゲ充のためだけにParallels購入するのはちょっと…と躊躇う御仁向け。

というわけで、Macでも手軽に素敵なゲームライフを。

*1:この時点でWindows実機環境は必須なわけで、そもそもWindowsのライセンス持ってないよ！という方には涙を飲んでいただくしかありません。

*2:本当にライセンス的にOKかと言われると微妙ですが…

同人誌の表紙から読み解く「とらドラ！」アニメ版ロゴの凄さ

本日、冬コミで買い逃した本をサルベージしようと、アキバのとらのあなを散策していたときのこと。
「今年はやっぱり『かんなぎ』と『とらドラ！』が強いなあ……」と同人誌の棚を眺めていると、ふとあることに気づきました。
あのマーブルチョコのようにカラフルなアニメ版「とらドラ！」のタイトルロゴを真似たデザインの表紙が異様に多いんです。

※ホントかよと思った方、こちらの通販ページから何冊か表紙が参照できるのでご確認ください。
■【とらのあなWebSite】カテゴリ別商品一覧（とらドラ!）　※18禁
http://www.toranoana.jp/mailorder/cot/genre/6/872_01.html

いかがですか？
結構な割合で、「1文字ずつカラフルな円に囲まれている」ないしは「1文字ずつ異なるカラフルな色づかいをしている」ロゴが採用されているのがわかると思います。これは明らかにアニメ版「とらドラ！」の影響ですよね。

もちろん同人誌は原作へのリスペクトから生み出されるものですから、タイトルロゴを真似していても不思議はありません。でも、今までここまで真似されたロゴってちょっとないよなあ…と違和感を感じるくらいでした。

そこで、なぜこれほどまでにこのデザインをみなさんが揃って採用しているのか、ちょっと自分なりに理由を考えてみました。
（注：自分はデザインや配色に関しては素人に毛の生えた程度の知識しかありません。なんかアホなことを言っていたら指摘してやってください）

インパクトがでかい

このロゴ、とっても目立ちます。
どのくらい目立つかというと、何十冊という新刊がずらずら陳列されている同人ショップの店内にあって、ざーっと表紙を眺めているだけで「お、ここにとらドラ！本がある！」とわかるくらい目立ちます。
ご存じのとおり、同人誌は描き手の方によって絵のタッチがまちまちですから（当たり前だ）、ぱっと表紙だけ見てすぐに「大河だ」「亜美ちゃんだ」と認識できないこともあるんですよね。もちろんショップが原作名などを書いたタグを見本誌に付けてくれたりもするのですが、結構小さい文字で書かれていて、いちいちチェックしきれるものではありません。
でもこのロゴを採用している表紙は、初見一発でとらドラ！本だと気づくことができます。

デザイン自体は単純（素人でもそれっぽく作れる）

カラフルな丸（これ自体はカラーピッカーか何かでオリジナルの色を抜いてくれば簡単に真似できますね）の中に細めのフォントで白抜き文字。
複雑な画像編集テクニックはいりません。頑張ればペイントでも描けるかも（暴言？）。
それに比べて、他のアニメ作品のロゴは、凝っている分真似するのが大変なものが多いような気がします。フォント自体が特徴的だったり、複雑なグラデーションがかかっていたり。
どんなに素敵なデザイン、かっこいいデザインでも、真似するのが難しければ採用する人は一握りですよね。その点、「とらドラ！」のロゴは敷居が低いわけです。

どんな表紙と組み合わせても大体なんとかなる

このロゴ、デザインが非常にシンプルですっきりしています。（グラデーションや抜き文字などを使わず、ベタ塗りでパキっとしたイメージです）
また、比較的彩度の高い色を中心に使っているので、背景のキャラクターなどと重なってもそれほど見にくくなりません。また色相で見ても、特定の色に偏らず、全体的にまんべんなく色を使っているので、表紙全体の色のバランスを崩すことも少ないと思います。

比較に出して恐縮ですが、涼宮ハルヒの憂鬱のロゴ（これもインパクトがありますね）のように、ある特定のキーカラー（ハルヒの場合は赤）を採用していると、背景のデザインによっては色がぶつかりあってしまうことがあるため、ロゴの配置を工夫したり、場合によっては色遣いを変えるなどの工夫が必要になります。
（実際ハルヒの同人誌では、キーカラーを青などほかの色に置き換えた形で使用しているケースを何冊か見かけました）
これに対して「とらドラ！」ロゴの場合は、えいやっと表紙絵の上に置いても、大体の場合それなりの見栄えに仕上がるようになっていると思います。


こうしてみると、このアニメ版とらドラ！のロゴ、なかなか凄いデザインだということに気づかされます。
「インパクトがあって」
「誰でもすぐ書けて」
「どんな背景とも相性が良い」
ロゴデザインの理想を満たしていますよね。

このように優れたロゴは、様々な媒体に掲載する際に便利に活用できるわけですが、二次創作としてデザインを拝借させていただく同人作家にとっても恩恵を受けられるわけですね（もちろん、作った側も使う側も、そこまで意識しているわけではないと思いますが）。

そんなわけで、とりとめがなくなりましたがこの辺で。

おまけ：
このロゴデザイン、二次創作で利用する上での欠点もあると思います。
一番の問題は「長いタイトルとはもの凄く相性が悪い」こと。1文字ごとに1色用意しなければならないので、色数が増えれば増えるほど大変なことなります。
（「恋する妹はせつなくてお兄ちゃんを想うとすぐHしちゃうの」的な長文タイトルに当てはめようとすると、配色を考えるだけで死ねそうです）
逆に短いタイトル、特に4文字で収まってくれたりするとオリジナルの配色をそのまま使えてリーズナブルです。
そういえば同人誌のタイトルって、なぜか短いものが多いですよね。ひらがな数文字とか…あれはなぜなんだろう。