ただのにっき

■ セキュリティの神話(John Viega)

一般に(と著者が考える)「セキュリティにまつわる常識」みたいな話の数々を、「神話にすぎない」と切って捨てるという体裁の本。いや、語り口は誠実で、そんな高飛車ではないけど。

ひとつひとつは頷ける内容だし、いい本だとは思うのだが、どんな読者をターゲットにしているのかよくわからない。専門用語をできるだけ排除しようとしているし、技術者なら当たり前のように神話にすぎないと考えるようなネタ(「Macは安全だ」とか)を多く取り上げているから、一般向けなのかなーと思うけど、ちょっと考えればわかるように、技術者でもない限りこんな本を手に取ることがあるとは思えない。難易度の高い話を削って、もっと短くまとめたものを新聞連載とかにでもしてみたら、想定している読者にリーチするんじゃなかろうか。

なにより、著者が現役のMcAfee社員で、しかも序文からしてMcAfeeの偉い人だったりするから、「バイアスかかっていそうだな」と読む前から身構えてしまう。実際、引き合いに出される事例の多くがMcAfeeで起きた話だったり、McAfeeが改善に取り組んでる話だったりするので、なんだかMcAfeeの宣伝資料を読まされている気分だった。そういうところを差っ引けば、悪くないと思うだけど。

技術者が、一般人に対してセキュリティについて説明するための「うまい説明のしかた」を学んだり(意外とこれ重要かも)するのには良いんじゃないかな。

セキュリティの神話
John Viega
オライリージャパン
￥200

オライリー直販ならこちら。もちろんEbookもある。幅15cmなのでKindleでもいける。

■ オライリー・ジャパンのEbookが「DRMフリー」になるぞ!

そうえいば上の本はオライリーの「被災者支援キャンペーン」で買ったものなんだけど(そしてDRMについてグダグダ書いたわけだけど)、このたび、めでたくEbookがDRMフリーになるというアナウンスが! これはめでたい。いやぁ、さまざまなハードルをクリアするための、中の人たちの尽力が目に浮かぶようだよ。素晴らしい。

さて、オライリーは読者であるわれわれ技術者を信頼してくれた。われわれはその信頼にきちんと応えることで「電子書籍にDRMはいらない」ということを証明してみせなければならないと思う。FAQにある以下の注意は肝に銘じようではないか:

オライリー・ジャパンが販売する書籍(Ebookも書籍だと考えています)は、コピー・フリーではありますがコピーライト・フリーではありません。日本国の著作権法による保護を受けており、著作権法で定められた範囲を超えた複製、頒布、送信などは、著作権法に抵触する恐れがありますのでご注意ください。

で、次はEPUBも(できればmobiも)、と期待したいところだが、さすがにこれは編集過程にまでメスが入ると思うので、当面PDFのみということで納得でしょう。複数フォーマットを低コストでサポートするには、オーム社みたいな先進的な仕組みを入れないといけないだろうし、けっこう大変だろうなーと思う。まぁ、オライリーは著者のリテラシも高いから、そういうことをやれる下地は十分にあると思うけど。

ところで今回の措置には、購入済みの(DRM付き)Ebookも近い将来アップデートしてくれるという太っ腹なおまけがついてくるわけだけど、気になるのは全ページに挿入されている購入者のメールアドレスである。あれも「(心理的)DRM」の一種なんだけど、「DRMフリー」というからにはこれもなくすんだろうか。個人的には別にあってもいいんだけど(どうせKindlizeするときに削っちゃうし)、アップデートのためにまたあの膨大な処理をやり直すのはアホらしい(し、電力のムダである)から、いっそやめた方がいいと思うんだけど。(追記: インサイダー情報によれば、メールアドレス埋め込みも撤廃だそうだ。Great!)

■ XMDF形式の電子書籍を「自炊」してみた

なんでこんなことをする気になったのかという話は後半に書くとして、SpaceTownブックスなどで販売されているXMDF形式の電子書籍をKindleで読めるようにしてみた。いわば「電子書籍の自炊」である。お惣菜を買ってきて、ひと手間加えるみたいな?

似たようなことを考える人は当然いるわけで、手法的にはXMDF形式の電子書籍を無理やり変換してkindleで読むに書かれているとおり。UWSCのスクリプトは少しパラメタをいじってこんな感じ:

dir = "PATH_TO_IMAGE_FOLDER" //保存フォルダ
page = 2000 //ページ数
wait = 0.2 //ウェイトタイム 0.2sec

while True
   ifb GETKEYSTATE(VK_UP)
      for count = 1 to page
         id = GETID(GET_ACTIVE_WIN)
         SAVEIMG(dir+"/"+REPLACE(FORMAT(count, 4), " ", "0"), id, , , , , 1, 100)
         KBD(VK_LEFT)
         Sleep(wait)
      next
   endif
   Sleep(0.2)
wend

XMDFをWindowsで読むためのブンコビューアは、ウィンドウ幅を最小に、ウィンドウ高をできるだけ大きくとった上で、こんな感じの設定。このへんは使用しているディスプレイによって違ってくる:

• フォント: LC明朝、28ポイント(Bold)
• 文字間: 小
• 行間: 小
• 余白: なし

UWSCを走らせると、800枚超のjpgファイルができるので、それをjpgディレクトリの下に入れて、下記のスクリプトを(こんどはLinuxで)走らせれば、Kindle上でdot by dotなPDFファイル「out.pdf」ができる。-cropパラメタの値は削りたい余白に合わせて調整する:

#!/bin/sh                                                                                                 
for dir in png pdf; do
   if [ ! -d $dir ]; then mkdir $dir; fi
done

for jpg in jpg/*; do
   png=`echo $jpg|sed 's/jpg/png/g'`
   pdf=`echo $jpg|sed 's/jpg/pdf/g'`
   convert $jpg -chop 60x60 -gravity SouthEast -chop 15x60 -gravity NorthWest -resize 560 $png
   sam2p -j:quiet $png $pdf
done
pdftk pdf/* cat output out.pdf

Kindleに送るとこんな感じ。紙の文庫本を自炊したものより、字が大きめで読みやすい:

ただ、ちょっとフォントが美しくないんだよなぁ。明朝の横画の太さがまちまちで、例えば「日」の字なんて中央の横線だけ妙に太かったりするので、これはブンコビューアのレンダリングエンジンがショボいのだと思う。フォントを入れ替えれば多少はいいかと思い、青キン明朝に変えてみたら「っ」のような小さい字の表示位置がぶっ飛んでしまったのでボツ。シャープさん、もうちょっとClearTypeの研究をしてくらはい。

さて、なんでこんなことをしているかというと、Twitterで風穴さん(@windhole)と「どんな電子書籍なら買う気になるか」という話をしていたのよ。おれは「20年後にもちゃんと読める」という条件を掲げて、端末依存やアプリ依存、非公開フォーマットの電子書籍は買いたくないという話をしたんだが、風穴さんは「制限なしXMDF」は消極的に許容しているという。

XMDFは最近、制作ツールを無償公開するなど、オープン化に一歩踏み出しているものの、(おれの予想では)数年以内にEPUB3に負けると思う。おそらくXMDF→EPUB3変換ツールの登場は時間の問題だろう。それなら今からDRMのかかっていないXMDFなら買っておいてもいいかもね。

だいたい、縦書の書籍では選択肢がほとんどないわけで、紙の本を買ってバラしてスキャンするのに対して、XMDFをビューアごとキャプチャして画像PDFにまとめるのでは、手間も金額も段違いに少ない。おまけにゴミも出ないから環境にも優しい。なんだ、紙の本を買うんだと思えば、躊躇する必要なんてなかったんだ。

というわけで、試しに「プリンセス・トヨトミ」を買ってみたわけだ。普段はけっして買わないベストセラーだけど、他に読みたいのがなかったので。

プリンセス・トヨトミ (文春文庫)
万城目 学
文藝春秋
￥869

これで買える電子書籍の幅が広がって「よかったよかった」ということになればいいのだが、試しにSF棚を見て「おっ、ハヤカワ文庫があるじゃん」と思ってリストアップしてみるとほとんど全部が「グイン・サーガ」だったりして、はっきりいってお話にならない。早川・創元という日本のSF二大レーベルが一番電子書籍に及び腰ってのはどうなんだよ、え?

■ tDiary: Amazon.co.jpへのリンクを短縮URLに変換

Issue#32で議論していたように、amazon.rbが生成する長ったらしいURLをbit.lyを使って短縮する仕掛けを入れた……のは今日(5/17)なんだけど、これを書いているのは5/19だったりして。

amazon.jsはまだまだ手抜きだけど(少なくとも同一ページ内ではキャッシュくらいすべきだし、下スクロールだけじゃなくて上スクロールにも対応すべきだ)、それより重要なのは今までなんとなく存在していたjsディレクトリの使い方を規定したことかな。doc/HOWTO-make-plugin.htmlも更新しておいたので(5/19)、開発者の人は参照されたし。