kindleとibooksで指定のしかたや表示が違ってたのでメモ…ていうか今さら。

kindleでは意図通りの表示だったのに、ibooksだと画像のサイズ指定が効かなくてでろ〜んと大きな画像となってしまっていた。もちろんepubcheckではエラーなどない真っ当なepub3ファイルだ。

1ページに1枚の画像だけ、というのはkindleもibooksもほぼ問題はない。同じhtml、cssで意図通りの同じ表示となる。

ところが、本文中に画像が入るケースがよろしくない。

画像のサイズ指定が意図した通りに伝わらず、でろ〜んな画像となってしまった例。

iTunes connectのヘルプページにあるibooksの要件（iBooksAssetGuide5.1Revision2_JPN.pdf）にリフローでの画像の指定例が載っていて。

・画像のサイズは画像をくるんだ要素の方(ラッパー、コンテンナ)に指定する

・画像はwidth:100%

てことなので、これはもう随分前から

こんなhtmlとcssを使ってたんだけど…ところが、幅（width）の指定が効いてくれていないっぽい。

ということで、リフローで雑誌＝写真も多数入りこんでいて、クオリティに定評のある電子雑誌『トルタル』をダウンロードしてibooksで拝見したところ、綺麗にレイアウトされている。さすがです。

ダウンロードしたepubファイルを解凍して中身を確認したところ、このiTunes connectの要件PDFと書き方はほぼ同じ。

わたしのファイルと縦横が違うだけやなあ…というところで、もしやといじってみたらほぼ意図通りの画像サイズとなった。

なんのこたない。

横で幅（width）指定が効くんだから、縦は高さ（height）指定だろうと。CSS（image-wrap）に幅25%で指定していたところを高さ25%で指定しただけ。

ところが、同じファイルをkindle previewerに読みこませると、これ、高さ25%以上はあるよなあ…。

スタイルシートを個別に対応させると管理が大変なので（間違いの元なので）インラインでスタイルを書くか、と思ったらば、どうやらibooksはインラインのスタイルを見てくれない。致命的でもないので、kindleはこれでOKとする。

無料販売本に既刊案内ページをつけるのに、やっぱ表紙画像はあったほうがいいよなあ、ということでゴソゴソやっていて、kindleとibooksのリフローでの画像の違いに気づいた。

kindleはmobiに変換する時に「よきにはからって」幅指定でも大丈夫だったので気づかなかった。

実用書などは横書きばかりなので幅指定で問題なく意図通りとなっていた。

ibooksやkoboでもらう本文中の画像はむしろ小さいもの＝原寸表示ばかりだったので縦書きでも指定が効いてないことに気づかなかった。

今まで「たまたま」うまく行ってただけ、という事実に我ながらアキレタ。

[06/02 16:35:51]追記。

kindleはインラインのスタイルが生きるので、そっちで調整。

画像に関しては端末やアプリでの差分吸収が面倒くさいでござるなあ。

しょせん素人、個人レベルのネタだけど、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」が出たら改竄されている可能性がある、ということぐらいはわかる、かな。

法的な実効力はともかく。

とりあえず、少しぐらいはコピー流出の歯止めになるかな、と思う。

なんかよく分からん説明になったけど。

メールアドレスを書いたタブ区切りのファイルを用意するだけでそれっぽいものを作ります。

[更新]2014-07-19 08:46:38

いや、本当に。先日も同じことを書いたんだけど、jquery mobileを使えば、ほとんど何も考えることなくスマホ対応できる。スマホアプリと見た目も変わらないんじゃないか、これ。

フレームワークというと、phpだとcakePHPとかsymphonyとか、perlもCatalystとか、定評のあるフレームワークがあって webアプリ開発のコスト軽減になっている。という話。たしかに規則・お作法さえ理解して、その通りにスクリプトを書いていけば、あえて書かなくてもいいことがたくさんあるっぽい。ひとつのことを決めて書けば、それに付随するもろもろまで書いたことになる。

で、この jquery.mobileだ。

先日ちょっと触っただけで、踏み込んだことは言えないんだけど、自作のブログ（http://t2aki.doncha.net/mobile.pl）とお言葉データベース（http://t2aki.doncha.net/mobile_books.pl）をスマホへの移植に使ったレベルで言うと。

これはデザイナーのかわりをしてくれる、デザインのフレームワーク。

わたしは、データをごそごそ加工したり引っ張り出したりする部分に関しては、好きだし面白くて、データをあれこれいじってる時は時間を忘れてやってる、いわばデータヲタク。さらに、シムシティじゃないけど、使う側のことを考えて、サイトの動線やUIを考えて想像するのも楽しい。

サイトを作っていてうんざりするのが、そこから先。

ボタンが1pxズレてる？んなぐらい、いいじゃん。

アイコンがジャギってる？んなの気にしないって。

どうしてロゴの位置はここなの？なんとなくだ。

というのは、まるでダメ。

デザインの神さまは細部に宿るし、デザインはいちいちちゃんと説明できる理屈がある。データとかサイトの動線などとは別のレイヤー・別次元。そこんとこ、苦手なんだよねえ。

漫画でいうと、データを用意する・サイトの動線などの骨格・設計を決めるところは、絵コンテ、下書き。これでは完成してないし、読者は見向きもしてくれない。ここから先、デザインワーク＝ペン入れ、仕上げがあって初めて希求力のあるサイトになる。

同じ情報を画面上に表示しても、1pxにこだわったサイトと、そこがぬるいサイト（たとえば、ページを移動したら1pxだかで画面が揺れるとか）では、「ぱっと見」の印象が違う。この「ぱっと見」は大事で、WEBを見ていて、そのサイトを「読む」に値するかどうかを判断するのは「ぱっと見」（そこまで、こだわるんか、というのは、なにをサイトに要求するのか、てことなので、また別の話。ここでは、そこ、こだわるところだろ、て話）

てことで、jquery.mobileだ。こちらが書いたラフ画を、一気に仕上げまで持って行ってくれるスグレモノで、感謝感動。専属のデザイナーをひとり雇ったようなもの。スクリーンショットのページなんて、わたしはなにもしていない。テキストをセンタリングするために1行～3行ほどcssに書いただけ。これをいちから書いたら、と思うとぞっとする。リストの区切り線とか、ボタンの影とか、テキストの位置とか、こんなのをcssで書けとか言われたら、いらいらしながら一週間がかり。jquery.mobileのおかげで、移植は各々実質1日で、なおかつ、スマホネイティブアプリのような画面のできあがり、となる。

で、javascirpt は、油断してたらすっかり主流でこんなことまでできるのか！？という存在感。クライアント側でなにをやったところで、信用できないし、結局はサーバー側でやるよね、と思ってたわたしが悪かったすまんかった。

html5になると、web storageとか。javascript がデータベースまで手に入れてるらしい。すごく今さらだけど、javascriptも勉強しなきゃいけないんだなあ。うううむ。

もしかすると体調がおかしいのか。金曜の夜に澤乃井の原酒、シメイ、あたりをへらへら飲んでたら土曜は夕方までトイレにはりついて吐きまくる。だいたい土曜は月イチ恒例の内科で、朝は普通に医者にいって「大丈夫ですね」と聴診器を当てられて帰ってきたのだ。気分が悪くなったのはその後、昼前あたりから。もう薮疑惑。

どうやら気持ちも切れかけの悪寒。うーむ、いや、おもしろくないことばかり。青空所属に帰ることを真剣に考える。

なもんで、ひたすら現実逃避に、日曜はlolipopでamazon ECS4.0のデータをいじるスクリプトをごにょごにょ。規約を読むと、AWSの登録IDはメールアドレスに対してひとつ、てことなんで、lolipopのメールアドレスで新たにひとつ取得。稼働中の読書snsに影響したくないし。

気合入れて調べるとチュートリアルもあって、パラメータもだいたい見当がつけられる。読書snsでは最低限のデータのしか使ってないんで考えることは少ないんだけど、用意されてるものをみると組み合わせが多いんで、ちょっと面倒、かな。

規約によると、価格などのデータは常に最新のものを使う必要がある。キャッシュしても一時間。

lolipopでmysqlにamazonから取得したデータを一時保存して、アクセスがあったらデータ取得時間をまずチェック。一時間以上前のだったらも持ってるデータを破棄して改めてamazonにデータ取得しにいく。

て、たかだかこれだけのことにハマる。mysqlのtimestampがよくわからず…。さんざん検索しても

current_timestamp-取得した時刻（timestamp型）> ’1 hours’

てな、postgresqlでさくっとわかりやすい計算方法がでてこない。

このクソ野郎が低能がと、ひととおり罵って、perlのtimelocalで計算させることにした。…なんでやねん。

ついでに、ウチのポンコツサーバーから一時間毎にアクセスするようにしたのでアマゾン一時間ルールは大丈夫。

これで、アマゾンへのリンクをつければ手抜きお手軽アフィリエイトサイトのいっちょあがり。なんだけど、それじゃつまらないんで、リモートショッピングカートをつけてから公開してみよう、と。

扱うブツとしては。手元のデータも活用できるんで、まずはハードボイルド系ミステリを中心に品揃え。自分の好きな本だけが並ぶ、ってだけで俄然おもしろくなってきたから単純な性格だ。

とはいえ、読書snsのリニューアルが止まったんじゃ話にならんので、サイトはあっさりしあげよう。このために改めて画像を作ったりせず、手間はかけない方向で。

一応タグづけはそれなりにやっておいて、サイトができたらgoogleさまに登録ぐらいはやってみる、か。

ちなみに。アフィリエイトサイトで、まともな収入があるところなんて聞いたことがない。アフィリエイトで毎月ン万円、なんて本がにょきにょき出てる時点で、万馬券連発の馬券必勝本と同じですな。

しっかし、ほんと、なんだか、いろいろ調子悪いなあ。

[更新]2013-05-18 11:44:46

いや、前にも書いたけど検索エンジン。

「趣味 SNS」で検索したらグーグルもヤフーも１ページ目。へたするとトップのポールポジションなのだ。「趣味 読書」でも２ページ以内にはいってる。

やはり何度も言うように。

検索にひっかかってる読書SNSについては、ちょっとSEO対策を考えて見出しタグを使って作ってるけどボリュームのないページだし、どこからもリンクされていない。これが検索に上位にくるってことは、ライバル不在、以外のなのものでもない。現に「読書 SNS」で飛んでくるひとなどわずかなものだ。だれも趣味に読書なんか求めてないってこと。

どんなジャンルでも、小説って本当におもしろい上等な娯楽なんだけどなあ。