epubcheckがバージョンアップ
今日気がついた。
５月31日にepubcheckのver4.0.0がプレ公開されていた（今日時点の正式リリースは3.0.1）4.0.0というメジャーバージョン番号がひとつ上がるということは大幅な機能追加のバージョンアップだろうと思うんだけど、よくわからなかった。メッセージを詳細にするというぐらいなら3.0.2でいいような気がする…素人のわたしにはわからない部分で大幅な機能追加がされたんだろうか。
https://github.com/IDPF/epubcheck/releases
素人のわたしは身体で覚えるタイプなので、とりあえず今までの3.0.1と今度の4.0.0で同じファイルをチェックしてみた。
3.0.1だとエラーも警告もなかった。
4.0.0だとナビゲーション文書のHTMLにインラインでスタイルを指定したところが警告となっていた。
残念なことに最近仕事でEPUBファイル制作はご無沙汰なんだけど（お仕事お待ちしております＝切望）スクリプトの該当部分を修正しておいた。
ということは、今まで作ってすでに販売されているファイルは新たなepubcheckでは警告が出ることになる（こういうところも電子書籍ならでは、というヤツだなあ）
「こうあるべき」というのはその通りだ。
でも現実的には。お客さんにしてみれば、EPUBCHECK？ナニソレ？んなことより早くkindleに並べてよibookstoreはどうなってるの、あの本じゃやってるじゃないどうしてできないの、だろうしなあ。
EPUBCHECKでエラーはもちろん警告も出ないことが最低条件・必須条件なんです、と言ってもエラーや警告が出てるものが現実に店頭に並んでいたりするし、ibookstoreの公式サンプルはEPUBCHECKにかけるとエラーまみれだったような…。
だいたい。EPUBCHECKでエラーや警告がなくてもストアごとのレギュレーションに引っかかるケースがある。
電子書籍に限った話じゃなくて。正論・べき論vs現実・現物合わせは悩ましいところだ。
商売になるのは現物合わせの方なのでそちらに流れるんだけど、正論・べき論でモノ作りをしていった方が関わるみんながラクできて幸せになれるような気がする。
メールアドレス埋め込み電子書籍の堂々巡り
昨日の記事。メールアドレスなどをEPUBファイルに埋めこむ仕組みの導入。うーむ、いろいろ面倒というか難しい。ソーシャルDRMとしてそれっぽくメールアドレスやtwitterアカウントを埋め込んでフリーで配る準備はいいけれど、それってどうなの？というところ。
気軽手軽に手に取ってもらいたいという意図なのに。
メールアドレスやtwitterアカウントを埋め込むためには、読者にアクションをしてもらう必要がある。これはハードルが高いんだよなぁ。
その1（自動生成）
・メールアドレスを登録してもらってEPUBファイルを作る
・登録してもらったメールアドレスにダウンロードURLを返信する
・メール記載のダウンロードURLにアクセスしてもらってダウンロード
その2（一部手作業）
・メールをもらってEPUBを作る
・もらったメールにEPUBファイルを添付して返信する
メールアドレスの実在を確認するためには上記のパターンどちらかだろう。
その1は以前、電書フリマでやっていた方法。これはリアルの場、温度の高い場所・人だからその場の勢いというものがあったからうまく行ったんだと思う。
ウチでまったりネットを見ていて、その1もその2も
「え？メール？登録してからダウンロード？ 面倒くさいからいいや」
となる。
メールなりの確認をしないということにするとソーシャルDRMの意味がないし、迷惑メールとして使われる状況も考えられる。
そもそもEPUBファイルをもらったとしても何も考えずにダブルクリックで読めるのはMacユーザー限定(今日時点)だし、それならiBookstoreで無料販売すれば済む話。mobiファイルにしたところでダブルクリックしても何も起らない。パーソナルドキュメントとしてkindleで読むというのはおそらく知られていないしやっぱり面倒くさい。
素直にiBookstore、google play、koboといった無料販売のできるストアを利用させてもらうのが、読者・ユーザーにとって一番とっつきやすいだろうという結末。これを堂々巡りという。
とりあえず、有料本を買ってくれたひとに
・オマケとして無料本をメールで送る・贈る
・ストアが潰れても大丈夫ですよというメッセージ
というプラスアルファな使いかたならイメージできるかも。ただ、上記したように広く周知するため・宣伝のための使いかたは思いつかない。ビジネス脳がないんだよなあ。おれ。
メールアドレス埋め込みを機能追加
しょせん素人、個人レベルのネタだけど、EPUB3ファイルにメールアドレスを埋め込めるようにした。
「かんたんEPUB3作成easy_epub」http://t2aki.doncha.net/easy_epub
なんでこんなことやってんのか。
ヤマダ電機じゃないけど、電子書籍のストアがサービス停止になったりそもそも倒産したりすると、そのストアで買った本は読めなくなる（これはDRMで管理しているどのストアでも同じこと・念のため）読者・ユーザーとしてはなんじゃそりゃの話。
ただ、最近の動きとしては。
読者救済のために、潰れてしまったストアの読者の購入履歴を引き継いでくれるストアもある。
また、版元がストアが潰れたらファイルを提供するというケースも出てきた。
かなり健全。あるべき姿に近づいてるということだろう。
まったく違う文脈だけど「読書権」読書をする権利という言葉もある。
本を読みたいと思った時、手に入らないとかなくなってるというのはどうなのということでもある（というか、これの本来の意味は、本を読む権利は万人に開かれているべきであるという趣旨。誰もがアクセスできるべきであるということだったように思う）
とはいえ。前から言ってるようになりすましにパクリが横行する電波が問題。
読者が不便を感じないである程度コピー流出の抑止に繋がるであろうというところで「購入者・所有者のメールアドレス埋め込み」という選択（DRMもしょうがないと思ってんだけど、ここではその話はなし）
タイトルと奥付に購入者・所有者のメールアドレスを埋め込む…の他にちょっと細工があるんだけど内緒にしておかないと意味がない。ソースでわかるひとは読んでみてください（大したことはしてないけど、分かりにくい感じになってると思う）
想定している使い方としては。
・読者からどこぞのストアが潰れて読めなくなったんだけどなんとかならんか。
・同人誌イベントの販促物や献本の一環として使えないか。
の二点。
てことで、メールアドレスの管理は必要になるとして。
まずはメールアドレスを埋め込みたいEPUB3電子書籍ファイルを作成する。
その状態で、メールアドレスを埋め込むためにエクセルから別名保存したファイルを使って、各々メールアドレスを埋め込んだ電子書籍ファイルを作る、という手順。
パソコンを買えばほぼオプションとしてついてくる、誰もが使わざるをえないエクセルで管理。
emailのところ以外は見てないのであとはテキトー。
これを「別名で保存」→「テキスト（タブ区切り）」にする。文字コードはshiftjis。
この、メールアドレスをつけたファイルを作ったら
・perl easy_epub.pl email-regist EPUBFILE EMAILFILE
コマンドラインで「email-regist」というキーワードに続けてメールアドレスを埋め込みたいEPUBファイルとEMAILアドレスを書いたファイルを指定する。
メールアドレスのついたEPUB3ファイルができればOK。
EPUBファイルの整合性チェックは
・perl easy_epub.pl email-check EPUBFILE EMAILFILE
で、エクセルに書かれているemailアドレスとepubに書かれているemailをチェック。
「email-check」というキーワードの後ろにチェックしたいepubファイルと上記のメールアドレスを書いたエクセルからのテキストファイルを指定する。
なぜか出回っている電子書籍を開くとメールアドレスがタイトルと奥付に記載されているので、それを見れば出処はわかる。また、追跡用に暗号化したものも書き込んでるのでそれもチェックしていて、上記のコマンドラインですべて「ok」なら問題はないけどひとつでも「ng」が出たら改竄されている可能性がある、ということぐらいはわかる、かな。
法的な実効力はともかく。
とりあえず、少しぐらいはコピー流出の歯止めになるかな、と思う。
なんかよく分からん説明になったけど。
メールアドレスを書いたタブ区切りのファイルを用意するだけでそれっぽいものを作ります。
EPUB3固定レイアウトにテキスト絶対値配置
漫画や写真集など画像一枚がページ一枚というシンプルな固定レイアウトのEPUB3ファイルは、画像がすべてで、画像さえしっかりしたものを作ればクオリティの高いものができる。
画像とテキストを組み合わせた固定レイアウトを作りたい場合どうすんの？と思っていたので少し調べてみた。
結論としては、テキストを絶対配置（position:absolute） で置いて行けばOKのようだ。
リフロー型EPUB3の場合、たとえば１ページいっぱいに挿絵など画像を置いても上下左右にマージン（余白）ができてしまう。画像をディスプレイいっぱいに表示したい場合は固定レイアウトのEPUB3で作る以外に方法が（今のところ）ない。
（そのうちハイブリッド型がリーダーで実装されれば問題は解決するんだけど）
絵や画像を見せたいコンテンツの場合（画像で勝負するものの場合）無用な余白は作品を損なうこともあるので、固定レイアウトはここが最大の魅力、かな。
ただ、ibookstoreの場合、固定レイアウトでテキストがあるものは検索可能でないと審査ではねられるらしい（漫画のネームはいいのにねえ）
https://twitter.com/rokusanjin/status/441022674903392256
ということは「レイアウトデザイン重視で紙の本・雑誌を忠実に再現する必要がある」などの場合、底本のPDFデータをそのまま画像化するしかないんだけど、それだとibookstoreでは通らない。
一から作り直しとなる。これはかなり面倒な作業。１ページずつ絶対配置でテキストを置いてレイアウトを確認してさらに位置調整デザイン調整。当然そこに画像位置も絡んでくる。
テキスト絡みの固定レイアウトを作るのはすべて手作業ということになるなあ。こいつを仕事としてやるにはページ１万円でも安いかもしれん。
iBooksもkindleも同じEPUB3ファイルで試した。表示は同じに見える。リフローより端末やアプリ間での差は少ないのかな…。
Mac iBooks
Kindle Previewer
iBooksで検索ができることを確認。
Mac iBooks
ページのXHTML
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" lang="ja">
<head>
<title>和猫～Japanese Bob Tail</title>
<link href="../style/reset.css" rel="stylesheet" type="text/css" />
<link href="../style/default.css" rel="stylesheet" type="text/css" />
<meta name="viewport" content="width=900， height=1270" />
</head>
<body>
<div>
<svg xmlns="http://www.w3.org/2000/svg" version="1.1"
xmlns:xlink="http://www.w3.org/1999/xlink" width="100%" height="100%" viewBox="0 0 900 1270">
<image width="900" height="1270" xlink:href="../images/contents001.jpg" />
</svg>
<div class="text-box" id="page001">
<p>眩しい…</p>
</div>
</div>
</body>
</html>
インラインSVGで画像を指定。
テキストは絶対値で位置を指定。
スタイルシート
div.text-box{
position:absolute；
padding:0.5em；
background:rgba(255，255，255，0.5)；
line-height:170%；
text-align:justify；
font-family:serif；
font-weight:bold；
border-radius:20px；
box-shadow:1px 1px 2px ＃000；
}
＃page001{ top:1100px； left:400px； font-size:40px；}
＃page002{ top:720px； left:350px； font-size:40px；}
＃page003{ top:400px； left:220px； font-size:40px；}
＃page004{ top:880px； left:120px； font-size:60px；}
EPUB電子書籍のDRMその２
電子書籍のサービス終了や停止、死屍累々。
@ryou_takanoさんのブログ記事（2014/5/29）
「ヤマダイーブック閉鎖時の対処を記憶に焼き付けるとともに「事前の救済策」でユーザーの信頼を勝ち取ろう」
http://www.wildhawkfield.com/2014/05/Closure-of-Yamada-eBook.html
が、まとまっていてわかりやすい。
この中で取り上げられているケースでは、救済処置（購入した本の引き継ぎ・購入分をポイントで還元）はそれなりにやってるみたいだけど。このあたりのドタバタがSNSやニュースで流れるたびに
「なんだ電子書籍ってサービスが終わったら読めなくなんのかよ」
ということになる…ってもともと電子書籍はDRM（デジタル権利管理）によって販売サイトと結びついている。ユーザーは本を買うのではなくて「読む権利」を買うだけなので、乱暴に言ってしまうと長期間の貸本屋で本を借りるようなもの。この手の話はさんざん既出。
（「これだから電子書籍は紙の本と違って」うんぬん、と言われ…そこ比較するところじゃないよなあ）
んじゃ、どうするのがいいの？というのもすでにあちこちで語られている。
実現可能かどうかはともかく。
・電子書籍もすべて一意のコードで管理する
・書店横断のDRMにして買った本のダウンロードはどの店でもできる
というのが理想かなあ。
（誰が本のコード管理するのか、購入履歴の管理はどうなるのか、配信コストの負担をどうするのか、…などなど思いつかないけど）
そもそもDRMに関して、わたしは「不要論」
ユーザーに不便を強いるだけのシロモノだし、しょせんいたちごっこでいつまで続けるの？と思う。
…なんだけど、前にも書いたようになりすましやパクリなどの電波なひとに対応するのは大変。弁護士だ裁判だともろもろひっくるめたコストを考えると個人だとやってられないので、コピーガードとしてのDRMは残念ながら現状はまだ必要。
という既出のネタでの長い前書きがやっと終わって、今日のネタは以前書いた記事の続き。
「EPUB電子書籍のDRM」 (2013/1/15)
「EPUB3にメールアドレス埋め込み」 (2013/1/16)
ソーシャルDRMとかソフトDRMとか言われるもの。
・購入者のメールアドレスをEPUB3ファイルに埋め込む。
・コピーが流出したら「おいおい、それオレが流したってバレちゃうじゃん」というストッパーにする。
EPUB3はZIPファイル。解凍して中を覗けばメールアドレスが埋め込んであるところがわかってしまうので、個人レベルでできることなどネタにしかならないのは重々承知で。
（電子透かし（表紙画像などコピーしても簡単には消えないようにメールアドレスを埋め込む）がいいのかと思いつつ難しそうなのでパス）
・メールアドレスを書誌情報ファイルに書き込む
・本文の扉や奥付、スタイルシートに書き込む
のが前回までのあらすじ。
これにメールアドレスを暗号化した文字列を入れておく。発行したメールアドレスを管理する必要はあるけど、暗号化されたメールアドレスと登録管理しているメールアドレスを照合すればどういう経路で流れたのかがわかる。
もちろん、暗号化されたメールアドレスを削除されたらそれで終了だけど、ナマの可読性のあるテキストより全然わかりにくい。EPUB3ファイルに関して熟知してるひとがみれば一発だけど、そこまでするなら買った方が早いと思うひとの方が多いだろう。
どこかで機能追加してみるかな。
ここんとこ「電子書籍＋DRM+解除」が検索ワードに増えてきてる。
それもこれも「サービスが終わったら読めなくなるってか！？だったらハードディスクに保存しよう！」だろうなあ。