ePub3 on iBooks

最近めっきりePubを触っていなかったのですが、iOS5.0になってからCSS3のサポートが目覚ましく、ePub3.0の対応も縦書き時のページングさえ除けば概ね満足できるレベルまで来たので、拙著『ハムスターに水を』をePub3.0対応にしてみました。以下、その雑感です。

iBooks日本語組版対応でイケてる内容

iOS4の時点で「駄目だコリャ」と思ったていたものが改善されたケースが以下になります。

ルビ対応

これが今回個人的に一番重要だったものです。あくまで小説家としての意見ですが、ルビというのは見映え（ルビなんてカッコで書いときゃいいじゃん）やアクセシビリティ（低年齢向けに難しい感じは読みがなが振られるべき）の観点とは別に、「ルビそのものが表現の一種である」という意識があります。これから言及するそれ以外の改善点ははっきりいって見映え状の問題に過ぎないとさえ思うのですが、ルビだけは別格です。

ルビというのは、文字とそのメタ文字がバイリニアルに併記される世界的にも珍しい表記法であり、日本に印刷術が持ち込まれてからの最大の革命的副産物だと思います。聖剣エクスカリバーとかがそうだと思うのですが、単に「漢字をどのように読むか」というよりも、「ある言葉にどのような意味を付与するか」という遊びのような表現ですね。小説家としてここらへんは譲れないところがあったのですが、対応されて嬉しいです。まあ、詩人などからすると、改行位置を指定できないリフロー型がそもそも許しがたかったりするのでしょうが。

さて、そのルビ対応なのですが、以下のように書けば有効になります。

<ruby>聖剣<rt>エクスカリバー</rt></ruby>

ルビに対応していないブラウザ向けにrpというタグもありますが、めんどくさいので今回は割愛。あと、rbタグはCSS3のドラフトから削除されたっぽいので、書かなくてもいいんじゃないでしょうか。

rtタグのデフォルトサイズはよくわかりませんが、0.5emとかにしておけばそれっぽくなるんじゃないでしょうか。

テキスト両端揃え対応

テキスト両端揃えが対応されました。和欧入り交じった文章では「ひでーな」と思うこともままありましたが、両端揃えがサポートされたので、我慢できるレベルになりました。

p{
text-align:justify;
text-justify:inter-ideograph;
}

もしかしたら、設定 > iBooksで両端揃えで有効になるのかもしれません。

フォントをはじめとする上書き設定の無効化

iOS4.3ぐらいからだったと思うのですが、いつからかiBooks用のePub作成覚え書き（text-alignハックと明朝体とか）で得意げに書いた明朝体の指定が無効になっていました。「Apple様の指定したフォント以外使うなよこのクズ」と受け取り、半ば諦めていました。

iBooksはフォントの指定が一応できるのですが、なぜか日本語のフォントは一つも入っていません。結果として、すべての文字がヒラギノゴシックで表示されるようになってしまいました。

ところがどっこい、iBooks用のEPUBで埋め込みフォントを使うというエントリーに従って設定ファイルを追加することで、フォントの指定が有効になりました。

これでヒラギノ明朝を使うことができるようになりました。font-familyの指定はiOS5 の iBooks でフォントを指定する方法というエントリーをご覧下さい。

あと、このファイルを追加した副産物として、リンク色を指定できるようになりました。これまではa:linkとかa:visitedとかに色やテキスト装飾を指定しても無視されていたのですが、ちゃんと効くようになりました。もしかしたら、「この程度の情報にも辿り着けないアホはデザインすんじゃねーぞ」っていうAppleからのメッセージなのかもしれませんね。

圏点サポート

CSS3がサポートされたので、圏点もサポートされるようになりました。サポートのされ具合はtext-emphasis (CSS3 Text)をMobile Safariで見るとわかりやすいです。

iBooks日本語組版対応でイケてない内容

フォント指定

まだしっかり検証していない情報。フォント指定で以下のように書くことで和欧混植ができたのですが、なんとなく一つ目のフォント以外は無視されているような気がします。

font-family:georgia, 'HiraMinProN-W3', serif;

いつのバージョンだったか忘れましたが、PC版Safariがfont-familyをちゃんと読まないというバグがありました。他のブラウザは1番目のフォントがなかったら次のフォントという具合に読んでいってくれるので、上記の指定で和欧混植が出来たのですが、無理っぽいですね。

まあ、そのうち対応するでしょう。和漢混植が実現するのはいつのことやら……

縦書き

縦書きは表示されますが、ページングが逆になるみたいです。

その他

• ePub3.0になって、メタファイルがどう変わったのかを調べましたが、けっこうめんどくさかった。とりあえずイーストのサンプルをダウンロードしてことなきを得る。基本は変わってない。
• まだePub3.0対応のエディタはないっぽい。Sigilの対応に期待。基本的にはメタファイルのxmlタグ名や属性値なんて覚えたくないので、IDEの発展が待たれる。
• Androidのことはよくわからない。
• Adobe Digital Editionのプレビュー版があればPCでもそこそこ読める。

終りに

今回、旧作をアップデートしてみましたが、やはり沢山コンテンツがないと意味ないと思ったので、年内に2〜3本新作を追加してみたいと思います。あと、PDFも作ってると大変なので、しばらくは「iOS5端末を持っている人向けにePub3を出していく」という方針でいきます。

あと、立ち読みページなんかも作ってみましたので、まだ買っていない人は『ハムスターに水を』を見てみてください。。

Related posts:

1. iBooks用のePub作成覚え書き（ルビ、ジャスティフィケーションetc）
2. iBooks用のePub作成覚え書き（text-alignハックと明朝体とか）
3. 長編小説「ハムスターに水を」ePub版販売開始

Safariの裏地はこんなの

今このブログのリニューアルを検討していて、Photoshopをちまちまいじってます。その過程でちょっとした発見があったので、一応共有します。本当にあってるかどうか分かんないで、話半分に読んでください。

先日AppleからLionことMac OS 10.7が出ましたが、全体的にスクロールの挙動が変わり、ブラウザで限界までスクロールするとびよーんと動いて、ブラウザの裏地（という表現でいいのか）が見えるようになりました。

iOSのフォルダにも裏地

この裏地っぽいテクスチャはiOSでも使われていて、アプリケーションのフォルダを開くと見えたりします。これからAppleにとって「裏」とか「領域外」の表現はこれがスタンダードなのかなと。

僕もこれを真似しようと思ったんですが、なかなかこれだというのが見つからなかったので、自分で作ってみました。以下、そのやり方です。

一応、順を追って説明しますが、僕はデザイナーではないので、そのものズバリを再現するまでは行きません。「こんな感じ」というレベルです。

いったんテクスチャとして取得してしまえば、あとは乗算でブレンドするなり、強度を変えるなりして工夫すればそれなりに似たものはできると思います。

ステップ1. 裏地を観察する

パッと見、この裏地はなんかの布地なんじゃないかと思って、”Photoshop tutorial texture mac”で探したんですが、なかなか見つかりません。「テクスチャ」も「布地」も英語にしちゃうと一緒ですからね。

さらによく観察すると、これは布ではなく、引っかき傷みたいなものが縦横に走っているんだということがわかりました。引っかき傷といえば、Mac OS X 10.5まではアルミのすり切れたような表現（ヘアライン？）が随所に使われていました。あれからメタリックなてかりを覗いた感じですね。

ということで、「ヘアラインを垂直に重ねればできるんじゃないか」という考えに至りました。

ステップ2. ヘアラインを2つ作って重ねる

ヘアラインの作り方は以下のとおりです。

1. ランダムな点を描く
2. それを横に引き伸ばす
3. 終わり

では、やってみます。

1. 新規ドキュメントを作ったら、真っ白なレイヤーに「フィルター > ノイズ > ノイズを加える」を選びます。点々が入ります。

フィルタ > ノイズ > ノイズを加える

2. ノイズが入ったら、「イメージ > 色調補正 > 色相・彩度」で色味を抜かします。

イメージ > 色調補正 > 色相・彩度

3. 続いて、「フィルタ > ぼかし > ぼかし（移動）」で適当に値を調整します。ヘアラインっぽいものができます。

フィルタ > ぼかし > ぼかし（移動）

4. 新規レイヤーを作って、1と2をもう一度繰り返します。そして、3のぼかしに入る前にレイヤーを回転させてからぼかします。ぼかしが終わったら回転もう一度回転させます。

90°回転させてからフィルタ

5. できたら描画モードを「通常」から「乗算」に変更します。

とりあえず完成

これで一応完成です。そのものズバリという感じではありませんが、ノイズの量とかぼかしの強さをちょうせすれば、また色々と変わってくるかと思います。

ステップ3. テクスチャを調整する

色とグラデーションを入れたもの

これで一応テクスチャはできたわけなので、後はいろいろとやりようがあるんじゃないでしょうか。Appleのヤツのほうが、もっとメリハリがはっきりしてますね。

今のところはグレーなので、色の付いたものに重ねたりするといいでしょう。グラデーションとかで調整してください。

以上で終わりです。

Related posts:

1. 山梨開拓日誌〜TVのない正月編〜
2. デザイン力向上のために言われたことをやる(2)
3. MacをLion(10.7)にしても挫けなかったけどカラーピッカーで挫けた

• マウスのスクロール方向が逆。タッチパネルじゃないから違和感あるっちゃありますが、一生懸命やり方を覚えてます。
• Rosettaなくなる。僕はそんなに古いアプリを使っていないので、特に困りませんでした。Mac the Ripperが使えなくなったことぐらいですかね。でも僕は一度見た映像を何度も見ない人間なので、リッピングもあんまり必要ないです。
• Javaの公式サポートなくなる。Javaは「業務用」っていうイメージがあるので、別にいいかな。
• ExposéとSpacedがMisson Controlへと謎の統合を果たす。これも慣れてないから違和感ありますが、まあ別にいいです。今年の夏があんまり暑くならないことに比べたらどうでもいいですね。
• TimeMachineがAFP3.3しかサポートしない。おかげでI-OデータのNASがバックアップ用に使えなくなりましたが、そもそもI-Oデータにはあんまり期待してなかったので別にいいです。

縦書き対応したテキストエディット

悪いことばかり挙げましたが、いいところもたくさんあります。アニメーションのクオリティはさらに上がってますし、心なしかストレスが軽減されているような気がします。とりわけ個人的なビッグイシューだったのは縦書きのネイティブサポートです。iWorksは縦書きできませんが、あれだけいらない子だったテキストエディットが可愛く見えてくるほどです。

あと、Safari5.1のCSS3日本語サポートが改善して、text-justify:inter-ideographが有効になりましたね。Safari5.1でこのサイトを見ると、行末が揃っていることだと思います。

とまあ、困った事はいろいろ合ったんですが、僕はなるべく人のいいところを見つけて生きていこうと心がけているので、けっこう楽しんで使ってました。

そんな僕なんですが、たった一つだけ困った事がありました。

Macのカラーピッカーどうしてる？

DigitalColor Pickerって知ってました？

Web開発を行う人なら誰でもカラーピッカーというものを使うと思います。任意のＲＧＢカラーの番号を教えてくれる憎いヤツですね。FirefoxとかChromeならEyeDropperとかそういうアドオンがあって、無料で色番号を取れてしまいますが、ローカルの画像とかいちいちブラウザに読み込ませるのはめんどくさいです。僕はそういうとき、Macにデフォルトで入ってるDigitalColor Meterというアプリを使っていました。

これはアプリケーション > ユーティリティに入っていて（もしかしたらXcode入れないと存在しないかもしれません）マウスオーバーしたディスプレイ上の色を教えてくれるんですね。これまでは知りたい色があったら、Command + TabでDigitalColor Meterにフォーカスを当てて、カーソルを合わせ、Shift + Command + Cで色の16進数コピー完了でした。

僕はこれまで、「ププーッ！　この人、色番号を知るためだけにPhotoshopを開いているよ！」とか、「なんでAppStoreにカラーピッカーアプリが$5で売ってるんだよ、詐欺だろ」とかコッソリ思ってたんですが、Lionにしたことで衝撃的な結果が判明。

この状態でShift + Command + Cでよかった

なんと、このDigitalColor Meterさん、Lionになって色番号をコピーする機能を失ったんですね！　いったい何のために！　いまのところできることは、RGBで表示される255, 156, 221という番号を暗記して入力することぐらい。いったいなぜこの機能を削除してしまったのか、本当にがっかりしました。

AppStoreに並ぶカラーピッカー

色番号を取得してコピペできるようにするのがそんなに難しい技術だとは思えないので、たぶんAppStoreに並んでいるカラーピッカーアプリ開発者たちに気を使ったんでしょう。AppStoreに並んでいる85円の奴がどう見てもDigitalColor Meterを30°回転させたものにしか見えません。

まあ、3000円もしないOSなので、アプリ市場を活性化させて稼ごうっていう魂胆はわからないでもないですが、こんな細かいところまで気を使うのかと思ってちょっとびっくりしちゃいました。一応、AppleScriptでなんとかする方法もあるみたいなんですが、そこまでするんだったら85円ぐらい払ってもいいかなとか思っちゃいますね。終わり。

Related posts:

1. Mac用テキストエディタの最高峰CotEditorを入力補完できるまで設定する
2. iOSやMac OS Lionの布っぽいテクスチャをPhotoshopで作るチュートリアル
3. デザイン力向上のために言われたことをやる(2)

WordPressにはいくつかのエラーページがあります。

404エラー

これは該当するURLが存在しなかったときですね。テーマフォルダ内に404.phpを置いておけば大丈夫です。Codexにやり方が書いてあります。

データベース接続エラー

WordPressがデータベースに接続できなかったときに表示される画面です。表示されるタイミングとして一番多いのは、はてぶでホッテントリに入ったりYahooニュースに紹介されたりして大量のアクセスを食らったときでしょうか。今はどうか知りませんが、コリスさんとかIDEA*IDEAさんとかはたまになってましたね。これはdogmap.jp「WordPress のデータベースエラーページをカスタマイズ」にやり方が書いてあるので、そのとおりやればよろしいです。メンテナンスモード時の表示についてもドロップインというやり方で同じように変更できます。

wp_die

これが本題です。WordPressにはwp_dieという関数があります。WordPressが処理を行う上で、以上が発生した場合に呼び出される関数ですね。このカスタマイズ方法について説明します。

wp_dieのデフォルトの挙動

wp_dieで表示される画面

さて、wp_dieというのはPHPのdie関数と同じく、「もうこれ以上は処理しないよ」という緊急避難的な関数です。一応メッセージは表示されますが、いたってシンプル。関数の性質上、公開画面でも管理画面でも呼び出されるので、シンプルにしておいた方がいいという結論なんでしょうね。

この画面に遭遇するパターンは以下です。

• コメントフォームに何も入れないで送信しちゃった
• nonceが設定されていないログアウトのリンクを踏んだ

普通のブログとしてWordPressを使っている分にはお目にかかることも少ないのですが、Webアプリっぽくフォームをたくさん使っている場合はwp_dieが使えると便利です。使い方はこんな感じですね。

//なんらかの処理を行い、エラーがあった場合はwp_dieを実行
if($error){
     wp_die("エラー: 不正な処理がありました", "Internal Server Error: 私のブログ");
}
//これ以降は実行されない

wp_dieをカスタマイズする

wp_dieをカスタマイズするには、まず自作の関数を2つ用意します。一つ目はwp_dieで画面をレンダリングする関数名を指定する関数（my_wp_die_handlerとか）で、もう一つは実際にレンダリングをする関数（my_wp_die）ですね。まずは一つ目の関数を指定する関数を書いて、フィルターフックにひっかけます。テーマ内のfunctions.phpとかに書いておけばいいでしょう。

function my_wp_die_handler($function){
     //get_bloginfoが使えれば使う。
     //なければデフォルトのwp_dieを使う
     if(function_exists("get_bloginfo") && "" != get_bloginfo("template_directory")){
          return "my_wp_die";
     }else{
          return $function;
     }
}
add_filter("wp_die_handler", "my_wp_die_handler", 1000);

一応、テーマディレクトリを参照できるかどうかを確認して、できなければ通常のものを使うようにしています。なぜこんな風にしているかというと、wp_dieはその性質上、どこで呼び出されるかわからないんですね。場合によってはWordPressがテーマを取得する前に実行されるかもしれません。それを防ぐために一応チェックしてます。まあfunctions.phpに書いてあるなら大丈夫だとは思いますが、念のため。

さて、あとはmy_wp_dieをfunctions.phpに書けばいいんですが、エラー処理などけっこう書くことが多いです。もともとwp_dieのレンダリングに使われていた関数_default_wp_die_handler（wp-includes/functions.phpに定義されてます）はこんな感じです。

長いですね。IE用におまじない（IEはエラーページの容量が小さいとブラウザが勝手に表示を変える）を書いているのが泣けます。これと同じのを書くのはめんどくさいですし、間違ってしまうかもれません。しかし、多くの人が変えたいのは見た目だけだと思いますので、まるまるコピペして、関数名をmy_wp_dieに変更した後、<html>〜</html>の中だけこんな感じで変えます。

<html xmlns="http://www.w3.org/1999/xhtml" <?php if ( function_exists( 'language_attributes' ) && function_exists( 'is_rtl' ) ) language_attributes(); else echo "dir='$text_direction'"; ?>>
<head>
     <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
     <title><?php echo $title ?>::<?php bloginfo('name'); ?></title>
     <link rel="stylesheet" href="<?php bloginfo("stylesheet_url"); ?>" type="text/css" />
     <link rel="shorcut icon" href="<?php bloginfo("template_directory"); ?>/images/favicon.ico" />
<?php endif; ?>
</head>
<body id="error-page">
     <div class="head">
          <h1>
               <a href="<?php bloginfo('site_url'); ?>">
                    <img src="<?php bloginfo("template_directory"); ?>/images/header-logo.png" alt="<?php bloginfo("name"); ?>" />
               </a>
          </h1>
          <p class="description"><?php bloginfo('description'); ?></p>
     </div>
<?php endif; ?>
     <div class="message">
          <?php echo $message; ?>
     </div>
</body>
</html>

要はCSSのパスだけ自分のテーマのものに変えて、ロゴとかを出しただけですね。ちなみに19行目に謎のendif;がありますが、これは管理画面でヘッダーを出力したあとにwp_dieが呼び出されるケースがあるようなので、消さない方がいいです。もちろん、その場合、headセクションは出力されないので見た目をコントロールすることはできません。ともかく、これでwp_dieがカスタマイズできました。よかったですね。

カスタマイズされたwp_die

おまけ1: 関数の定義元をどうやって見つけるか

WordPressや昨今はやりのオブジェクト指向フレームワークは膨大な量のコードがはじめっから書かれているので、どこでなにがどうなっているのか、細かくはわかりません。

そういう場合、関数の定義元を探る必要があります。僕はAptana Studioというのを使っているので、「なんだこの関数は？」と思ったら関数にフォーカスしてF3を押してます。そうすると、定義元に飛べるんですね。ある程度のIDEなら普通は備わっている機能です。他にもフォルダ単位で文字列を検索したりする機能もよく使います。しょぼいテキストエディタや古いDreamWeaverを使っている人はこれができなくて人生を損している可能性があるので、色々と考えなおしてみてください。ちょっと古いですが、参考リンクを挙げておきます。EC Studio 技術ブログ「テキストエディタからPHPEclipseへ移行した決め手」

おまけ2: エラーページのデザイン

WordPressに限った話ではないのですが、デザイナーさんで何も言わなくてもエラーページを作ってくれる人がいます。これは大変ありがたいのですが、3カラム構成のサイトでメインカラムにエラーメッセージを表示しただけのデザインのときがあります。

エラーにもいろいろあって、404とかは本気のエラーじゃないんでそれでもいいですが、500とかはわりと本気のエラーなので、いろんなコトできないんですね。サイトの他の部分で当たり前に出力されていたもの（グローバルナビとか）が出力できなかったりします。

なので、本気のエラーページをデザインするときは極力シンプル（基本はエラーメッセージだけで、できれば1カラム）で、あきらかにエラーとわかるデザインだと嬉しいですね。Twitterのくじら画面みたいな。

あと、エラーメッセージはプラグラム側でpタグにくるんで出力されることが多いので、「どう考えてもこれvertical-align:middleじゃないと駄目だろjk」みたいなデザインはイヤです。マークアップ上の工夫がいらないシンプルな奴が嬉しいですね。

まあ、500エラーとかまできちんと作りこんでいるサイトはあんまりないですし、IISのエラー画面とかApacheの403 Forbiddenとかはよく見るので別にいいっちゃいいんですが。というわけで、終わり。

Related posts:

1. WordPressのテーマちょびっとカスタマイズ
2. WordPressでbloginfoなくしてもDB負荷は減らないんじゃないかという話
3. WordPressのiPhone用テーマをカスタマイズ

基本3キャリア限定です。PCサイトと携帯サイトの両方に対応するような場合を想定しています。あと、基本はDoCoMo902以降の端末で、非公式サイトを想定しています。

使用するプラグイン＝ktai-style一択

http://wppluginsj.sourceforge.jp/ktai_style/

ktai-styleをWordPressをガラケー（スマートフォンじゃない携帯電話）に対応させるプラグインです。これ以外の選択肢はほとんどありませんし、なんらかの理由で使わないのであれば、WordPress以外も検討してみたほうがいいです。

ドキュメント（html）がプラグインに同梱されているので、熟読しましょう。フィルターとかフックもかなり用意されているので、プラグイン作成の方法を学ぶにも勉強になります。

公式情報

1. 作ろうiモードコンテンツ | サービス・機能 | NTTドコモ
2. KDDI au: EZfactory
3. Softbank MOBILE CREATION

各キャリアとも、公式CPの場合だけ見られる素敵なドキュメント群（大量のPDF）がありますが、公式サイトのことは割愛します。NDAとかもあったような気がするので。

アプリの作り方、Flash Liteの仕様などもこちらに載っていますが、公式の情報だけを鵜呑みにせず、ネットを検索しましょう。

シミュレータ

FireMobileSimulator

Firefoxのプラグイン。なんとなく画面の雰囲気を掴みたいときはこれ。絵文字とかも再現してくれる。他にも幾つかありますが、これだけで十分だと思います。

iMode simulator Ⅱ

DoCoMoの公式シミュレータ。UAはなしだった気がする。あと、バージョンが古い。

Softbank ウェブコンテンツヴューア

発音が難しい、Softbankの公式シミュレータ。いくらなんでもバージョンが古すぎる。

Openwave SDK6.2K

au用のシミュレータ。しかし、なぜか配布が終了されているので、インターネットアーカイブからがんばってダウンロードするのが吉。このURLなら多分大丈夫。法的にOKかどうかは知らない。

ダウンロードできなかったら、Internet Archiveで以下のURLを検索してください。2006〜2007年ぐらいまで遡ればまだあります。

http://developer.openwave.com/ja/tools_and_sdk/openwave_mobile_sdk/SDK62K/index.html

公式のシミュレータはどれもバージョンが古いので、「持ってると安心」ぐらいの感覚でいましょう。ちなみに、すべてWin XPじゃないと動かないと思います。MacユーザーはVMwareとかを買いましょう。Combo Boxというのは無料らしいです。Virtual Boxでしたソフト一個買って足が出るような仕事なら断っちゃって下さい。

有用な非公式（？）情報源

• ke-tai.org ケータイプログラマのためのコミュニティサイト
• モバイルサイトデザイン集のモバイルデザインアーカイブ
• 携帯サイトをつくろう（デザイン変わった？）
• ウノウラボ（携帯情報源というわけではないですが、良質な携帯関連情報が多いです）
• 村上福之の「ネットとケータイと俺様」（面白いから）

携帯で制作する上での注意点

キャリア間差異の吸収

携帯はキャリアごとにかなりの差があります。基本的にはktai-styleに備え付けの機能をうまく使った方が楽に開発できますし、アップデートにも対応可能です。

文書構造

文書構造が各キャリアで違います。また、WordPressでxhtmlとして動かしたい場合、xmlヘッダーを吐かなければDoCoMoが受け付けてくれないので、その点注意してください。

<?php
header("Content-Type: application/xhtml+xml; charset=Shift_JIS");
?>

とか。ktai-styleはそこらへんをよしなにやってくれます。同梱のテーマファイルのheader.phpをよく読みましょう。

HTMLタグ

個体識別番号の取得方法やmarqueeタグの属性値が違ったりします。ktai-styleにはコンディショナルタグがあるので、キャリアを判別してくれる関数を書いておくと楽です。Web上にまとまった携帯用HTMLタグ辞典みたいなものがないので（携帯サイトをつくろうさんぐらい）、一冊ぐらいレファレンス持っていた方がいいかもしれません。

CSS

CSSは事実上インラインCSSしか使えないと思っておいた問題ないです。難しいことはほとんどできないので、文字装飾と背景色ぐらいでしょうか。文字色変えるタグを関数化しておくといいと思います。

<?php
//functions.phpに記載 cがバッティングしたらごめんなさい。
function c($str, $hex = "ff0000"){
    echo "<span style=\"color:#{$hex};\">{$str}</span>";
}
?>

Javascript

使えません。iModeブラウザがバージョンアップして使えるようになったとのことですが、ある事件をきっかけにとんと聞かなくなりました。いま携帯専門Web屋さんたちの間ではどういう扱いになってるのか非常に気になります。

絵文字

絵文字は各キャリアで独自の仕様があります。ktai-styleに共通絵文字を出力するタグがあったはずなので、それを使ってください。

<img localsrc="68" alt="" />
<!-- スマイルマークを出力 -->

共通の絵文字はドコモ絵文字コード・タイトル（意味）一覧などの一覧表で把握してください。

文字コード

携帯はformのPOST情報がShift_JISで飛んで来たりするので、頑張って変換してください。

<?php
//無名関数を使っているのでphp5.3限定。
//POST変数のすべてに対してエンコーディング変換してextractする
extract(array_map(function($var){
   return mb_convert_encoding($var, "utf-8", "sjis-win");
}, $_POST));
?>

画像形式

i-modeはpngダメです。テーマの場合はGIFまたはJPEGに固定することで問題ないかと思うのですが、投稿データにpngを入れてしまっている場合は注意してください。一応、ktai-styleには投稿内の画像を自動で変換してくれる機能があります。

携帯端末が1ページあたりうけとれるデータは100kb以内なので、画像サイズにも注意してください。最大でも1つ25kbというのがauの制限だったような気がします。ちなみにktai-styleは投稿内の画像をすべてリンク文字列に変換します。これが嫌だという場合、画像を縮小する関数を自前で作ったほうがいいでしょう。

解像度

携帯の標準的な解像度は横240px（QVGA〜WQVGA）ですが、最近は横幅480pxの高解像度端末も増えており、キャリアから「高解像度にも対応してください」というアナウンスが出ています。ここら辺はクリエイティブと天秤にかけて対応してください。めんどくさかったら、開き直って横240px固定にしちゃうのもアリだと思います。

対応する場合はGDなどの画像操作系関数でサムネイルを作成して対応することになるのですが、問題は解像度の取得。DoCoMo端末はUser Agentなどから解像度を取得することはできません。auおよびSoftbankはUAに画面解像度が入っているんですが、ブラウザなの解像度だったり違ったり、いまいち信用できない値になっています。

PEARにNet_UserAgent_Mobileというのがあるのですが、2009年で更新が止まっており、DoCoMoの最新端末情報が反映されていません。したがって、現実的な方策は以下のとおりです。

1. 上述のNet_UserAgent_Mobileを拡張して自分で管理する（DoCoMoの公式サイトに解像度のデータが載っています）
2. k-tai.orgの携帯電話スペック一覧などのデータをカスタマイズして判別機能を作成する

という感じになるでしょうか。携帯はIPアドレスによるホワイトリスト方式とか、常にデータをUpToDateに保たないといけないことが多くてめんどくさいです。

SSL

SSLにきちんと対応するためにはVerisignのじゃないとダメだったと思います。Global Signなどのちょっと安めの証明書でも新しい端末ならオーケーです。

実機での検証について

実機で検証を行うに越したことはないのですが、SOHOや小さい会社だと難しい場合が多々あります。公式CPなら検証センターというのを使えるので、すべての端末で確認できるのですが、なかなかそうもいかないでしょう。

自分で作ったサービスならアズイズでいいですが、クライアントワークの場合は「動作保証をテーマ開発要件に含めない」方が無難です。普通のWeb制作でも対象ブラウザを限ったりするものですが、携帯もそれと同様です。一応、各端末で検証してくれるサービスもあるので、その費用を「検証費用」として請求すればクライアントも納得するでしょう。

適当に「大体の端末で見れますよ」みたいな感じにしちゃうと、クライアントがディズニー・モバイルなどの特殊な携帯を使っていた場合に悲劇です。僕は前職でクライアントが株を確認できる携帯を使っていたためにヒーヒー言ったことがありました。

その他、参考書籍や心構えなど

携帯用の技術本は結構たくさんあるので、どれでもいいと思うんですが、わりと読みやすいのがコレでした。ちと古いかもしれませんが、携帯サイトとは何かがユーザビリティの観点からまとまって書いてあるので、すぐ読み終えられます。

PC中心のWeb制作者にありがちなことですが、そもそも自分ではスマートフォン使ってたりして、携帯サイトをあんまり見ないということが往々にしてあります。PCのデザインに慣れたデザイナーも要注意ですね。「なんでアメブロの芸能人はあんなに改行しまくってんだ」と疑問を感じていたり、女の子から来たメールにハートの絵文字が入っていただけで「この娘、俺のこと好きなんじゃないか」と思ってしまうあなたは特にご用心です。あまり自分の感覚を信用しない方がいいでしょう。書籍やWebサイトなどの情報を頼りにして作成していくのがいいかと思います。

そういう意味で、携帯サイト開発は女性に向いているのかもしれませんね。女の人ってデコメ好きだったりしますし。

あと、コンテンツ適正（閲覧に適した文章量、地方の人が閲覧することが多い、対象ユーザーの年齢層がPCと異なる、家でゆっくり見るとは限らないetc）というのもあるので、あまりワンソース・マルチユースを過信しないことも大切です。

おまけ：Macユーザーのための携帯シミュレータ利用法

Macだと公式キャリアのシミュレータが動かないので、VMWareなどの仮想化ツールでWindows XPをインストールして利用します。持ってない人は買ってください。

WordPressで開発を行っているなら、MampやXamppでlocalhostを立てていることでしょう。できれば、VMWareに入れたWindows XPからもこのホストを参照したいものです。そのための方法をご紹介します。

1. Macのホストを追加

普通にApacheをインストールすると、http://localhostが127.0.0.1を向くようになっています。127.0.0.1はループバックアドレスといって、自分自身を示すIPアドレスなのですが、このままだとVMWareのWindowsから参照できません。Windowsのシミュレータにhttp://localhost/と入れると、VMWare上で動いているWindows自身を指すことになってしまいます。

そこで、Macが自分のホストを参照しつつ、Windowsからも参照できるような名前を作ります。

まずはアプリケーション > ユーティリティからターミナルを開いて以下のコマンドをコピペ。

sudo open -t /etc/hosts

管理者のパスワードを入れたらテキストエディットが立ち上がります。以下のように追記してください。

127.0.0.1     localhost
127.0.0.1     mac #←追記

ブラウザを立ち上げたら、http://macでローカルホストに行くかどうか、確認して下さい。

2. MacのプライベートIPを取得

引き続きMacのターミナルで以下のコマンドを入力してください。

ifconfig

そうするとズラッと文字列が出てくると思いますが、en0かen1の欄にinetという項目があると思います。192.168.0.*とか、172.16.0.*とかの文字列ですね。これをコピペしてブラウザに入力し、http://macと同じ画面が出たらそれがMacのプライベートIPアドレス確定です。

GUIが良かったら、システム環境設定 > ネットワーク > 表示:内蔵Ethernetで確認できると思います。

3. Windowsからhttp://macを参照できるようにする

今度はVMWareにインストールしたWindowsに移動してください。で、C:\WINDOWS\system32\drivers\etc\hostsというファイルをノートパッドで編集して下さい。Macの時と同じく、ホストを追加します。

127.0.0.1       localhost
192.168.0.5    mac #←MacのプライベートIPとホスト名を追記

仮想WindowsマシンからMacのサーバを見る

保存したら、ブラウザにhttp://macと打ち込んで、Macの画面が出ることを確認してください。

これでシミュレータでのチェックとMacでの開発を同時に行うことができます。

• 同様の方法でIETesterも使えるので、設定しておくと楽です。
• MacのプライベートIPは再起動時などに変わることがあります。固定したい場合は「プライベートIP 固定 mac」でググってください。
• 当然ですが、これを実現するためにはWordPressのインストール時のアドレスをhttp://localhost/ではなく、http://macにする必要があります。

Related posts:

1. WordPressのテスト環境と本番環境を同期する時に使えるSQL文
2. WordPressのiPhone用テーマをカスタマイズ
3. WordPressテーマplaintxtBlogの日本語リソース作った

マウスオーバーによるドロップダウン

現在受託案件で細々と食いつなぎつつミニコme!開発という絶望街道まっしぐらで気分が塞ぎがちなので、先ほど考えたことを書きます。

一つのWebサイトでどれだけ多くの閲覧環境に対応するかというのはWeb制作業界人がこぞって悩んでいるところだと思いますが、今日はグローバルナビゲーションとドロップダウンメニューについて考えてみます。

iPadのみに対応するということ

「閲覧環境が様々」とはいえ、無限のパターンに対応するのは現実的ではないなので、基本的に想定されているのはざっくりわけて以下の四つだと思います。

1. PC
2. タブレット型PC
3. スマートフォン
4. ガラケー

今回はiPadに代表されるような、「タッチスクリーンを持ったタブレット型PC」に限定して話を進めます。マウスVSタッチスクリーンというわけです。

スマートフォンはスマートフォンで、「画面解像度」という大きな違いがあるので、UI設計の段階から考えていかなければならないと思います。ガラケーはいわずもがな。ガラケーとスマートフォンは多少のコストをかけてでも専用のViewを作って対処すべしと僕は考えています。

さて、iPadは画面解像度が結構高く、960px幅で作られたWebサイトならそのまま表示できます。本文サイズが12pxとかでなければ、ストレスなく閲覧できるでしょう。あとはFlashを使わないとかですかね。

「何もしなくてもタブレット型PCには対応できる」し、別言すれば、「特別なことをしなくてもPCと同じWebサイトを見られる」のがタブレット型なわけです。ただ唯一異なる点が、ホバーアクションがないという点です。

ホバーアクション不在のUI

ホバーアクションというのは、マウスがある特定の要素に乗っかっることですね。Javascriptならmouseoverイベントがありますし、CSSでも疑似クラスとして:hoverがサポートされています。

ただし、これはマウスの存在を前提としているため、地点Aから地点Bまで移動するのに必ずしも軌跡を描かないタッチスクリーンの場合はあんまり役に立ちません。ホバーした瞬間にはクリックしている可能性が高いです。

ちょっと話はずれますが、「タブレット型PCに対応する」という前提の元では、たとえばCSSのリンク装飾についても一考の余地ありですね。

まれにインラインリンクのアンダーラインをつけないで:hoverで凝ってみせるデザイナーさんがいますが、これはタッチスクリーンの場合あんまりよろしくないと思います。確実に「これは押せる！」というデザイン（下線がついてる）にした方がよいでしょう。ここら辺はApple デブセンのiOS ヒューマンインターフェースガイドとかに書いてあるかもしれません。（うろ覚え）

他にも個人的に好きじゃない例を挙げると、はてなダイアリーのキーワードリンク機能ですかね。はてなダイアリーははてなキーワードに登録されている言葉がブログ記事中に存在すると自動でリンクを張る機能を持ってるんですが、iPadやiPhoneで読んでいるときに間違って踏んでしまうことが多いです。これも「スクロールはマウスホイールで行う」ことを暗黙裡に前提としている設計のせいかな、と。

要するに、タッチスクリーンはマウスと違って、「ポインタが画面を動き回ることはないが、クリックされることは多い」ということになりますね。

タッチスクリーンの鬼門、グローバルナビゲーション＋ドロップダウン

で、本題です。グローバルナビゲーションをドロップダウンにするというのはよくやる人もいると思います。WordPressのテーマ等でもそのようになっているものは多いです。ただこれ、iPadだと下層メニューの表示ができないんですね。ホバーがないからです。

「フッターにもリンクがある」などの代替手段があれば致命的なことにはならないとは思いますが、そもそもグローバルナビゲーションはそのサイトにとってもっとも重要な要素をまとめたものですので、そのリンクへ移動できないというのは考えものです。では、「PCサイトをiPadにも対応する」ためにはどうすればいいのかという案を3つ挙げてみます。

1. ドロップダウンを廃止する

Appleのナビゲーション

そういやそもそもiPadの製造元であるAppleはどうなってんのかとサイトを見てみたら、そもそもドロップダウンなんか使ってないですね。これはAppleらしいです。

グローバルナビをクリックするとカテゴリーのページへ移動し、サブナビゲーションが表示されます。Mac, iPhone, iPodという強力なブランドを持つAppleならではとも言えますが、サイトの構造をしっかりわけるのがデザイン上でも有効になるパターンですね。

あと、後述しますが、ドロップダウンを自分で作れない人（Javascriptの知識がない人）はこのアプローチを検討してみるとよいかと思います。

2. タッチスクリーンの場合だけドロップダウンの挙動を変える

Amazonは地味に挙動を変える

これはAmazonが採用しているアプローチなのですが、AmazonはiPadで見た場合、左にあるサイドメニューがホバーアクションではなく、タッチで開くようになります。Javascriptが得意な方はこれでもいいと思います。

ただし、Amazonのサイドバーのプライマリーボタンは元々リンクになってないですね。PCで閲覧した場合、「本・漫画・雑誌」をクリックしてもなにも起きません。ホバーすることで展開される下層メニューである「本」「洋書」「漫画」「雑誌」「古本」をクリックしないと下層に移動しません。これは「ナビゲーションのトップレベルはページへのリンクではない」ことが条件となります。

したがって、「トップレベルもページであり、下層もページ」というパターンには対応できないんですね。要するに、下のようなのは駄目ってことです。

3. ドロップダウンじゃなくて、Explorer風にする

WordPressの管理画面

こういうメニューをなんと呼ぶのか知りませんが、WordPressの管理画面にあるようなやつだとどっちがきても大丈夫です。

ボタンもあって、リンクでもあるというデザインですね。CSS的にちょっとめんどくさいですが、まあいいものを作ろうと思ったらこれぐらいはしょうがないんですかね。

ドロップダウンメニュー考察まとめ

というわけでつらつら書きましたが、要するに「モバイルコンピューティングの時代、ホバーアクションはおまけにすぎない」ってことです。マウスもキーボードと同じで機械に身体を従わせるようなところがあるので、時代に合わせて身体を作り替えていくニュータイプ向けWebサイトならともかく、一般ユーザーに広く使ってもらうためには人間の素直な身体をベースにした方がよさそうですね。

もともとこの記事を書いた発端は、ミニコme用に買ったWordPressテーマが件のドロップダウンだったからイラついたっていうだけなんですけど。

Related posts:

1. iBooks用のePub作成覚え書き（ルビ、ジャスティフィケーションetc）
2. iBooks用のePub作成覚え書き（text-alignハックと明朝体とか）
3. 【目指せePub出版】Webkitでtext-align:justifyに挑戦する

新しいスマートフォン向け画面

まだ完全に検証を終えたわけではないのですが、スマートフォンで買えるようになったと思います。

特にiPhoneはiOS4.2からePubファイルをSafariで直接ダウンロードしてiBooksで開けるようになったので、これまでのようにパソコンからiTunes経由で同期しなくてもよくなりました。これは大きな進歩です。

やはり電子書籍というのは「欲しいと思ったときにすぐ買える」というのがポイントだと思うので。

WordPressでスマートフォン対応

iPhoneっぽいストライプ

今回は見映えもiPhoneっぽくして、パーツなども極力近づけました。かなりめんどくさかったです。

このサイトではiWPhoneというプラグインを使っています。これはiPhoneかiPod Touchでサイトを訪れたときにテーマを切り替えるだけなのですが、これをちょっとカスタマイズし、Androidケータイで来たときも切り替えるようにしました。いまのところXperiaを持っている知人に頼んで確認しただけですが、デフォルトブラウザを使っている限りは表示できると思います。

Androidのローテーション挙動でハマる

iPhoneは縮尺固定

Androidに関してはほぼiPhoneと同じようなレイアウトを実現できた（CSS3をサポートしてるから）のですが、一点だけ困ったことがありました。それは、画面を横にしたときの挙動の違い。

iPhoneでは画面を横にしたとき、そのままの縮尺で拡大されます。また、内部的にも同じ画面幅を保つようです。

//ローテーションさせたときのイベントリスナー(MooTools)
window.addEvent('resize', function(e){
	console.log(window.innerWidth);
	//縦でも横でも320を出力
});

新しいレイアウトでは「目次」ボタンをクリックするとナビゲーションが左からゾロっと出てくるようにしてあるので、これは大変ありがたい仕様でした。

Androidでナビゲーションがかぶった

しかし、Androidの場合は横にしたとき画面のサイズが変わる様子。レイアウトが間延びしてしまうのはしょうがないとして、左に隠れているはずのナビゲーションがコンテンツにかぶってしまうのは困りました。

とりあえず、resizeイベントで一々サイズを調整することでかぶるのは回避。

一応Androidエミュレータはダウンロードしてあるんですが、なぜかネットにつながらないので、デバッグできません。やっぱAndroid端末買わないとダメですかね。

アプリケーションキャッシュ動かず

以前のエントリーで偉そうにアプリケーションキャッシュのやり方について書きましたが、なぜか上手くいかなかったので、外しました。上手く行っているときはメチャクチャ早いので、ぜひ導入したいのですが…

スマートフォン対応の雑感

というわけで、色々試行錯誤することとなりました。疲れました。アメリカではすでにAndroidのシェアがiPhoneを上回っていると聞きますし、結局、ブラウザ戦争と同じことが起きる可能性は100%ですね。僕はもう「早く戦争が起きないかしら」っていう気分ですよ。

Related posts:

1. 【目指せePub出版】Webkitでtext-align:justifyに挑戦する
2. WordPressのiPhone用テーマをカスタマイズ
3. iBooks用のePub作成覚え書き（ルビ、ジャスティフィケーションetc）

これまでもさんざ検索してきましたが、まだePubのCSSに関する情報は探すのムズいですね。

まだ情報が少ないというのもあるのですが、色んなプレイヤーが色んなこと書きまくってる印象です。

これまでのCSSについて何かを書く人なんて、Web制作業についている人か日曜Webクリエイターか情報系の大学生のどれかだと思うんですが、ePubに関してはこれに加えて出版関係の人とブログは嫌いだけど本は出したい人がいりまじっててわけがわかりません。

特にInDesignから云々みたいな話題が多過ぎて、探すのが大変です。これもAdobeのフォーラムが検索結果にほとんど挙がってこない仕様のせいでしょうか…

明朝体問題

さて、「ハムスターに水を」のePubは本文をiPadにのみインストールされているヒラギノ明朝にしようと思っていたんですが、挫折していました。

で、これがTwitter上で@HowManyFilesさんとやりとりしたおかげで原因判明。

/*ダメ*/
body{
	font-family:'HiraMinProN-W3', serif;
}
/*オーケー*/
body{
	font-family:'ヒラギノ明朝 ProN W3', 'HiraMinProN-W3', serif;
}

ヒラギノ明朝で表示

この通り、美しい明朝体で表示されるようになりました。

要するに、日本語で指定しなきゃダメってことですね。

なお、@HowManyFilesさんははてなダイアリーでePubのテンプレートファイルを公開されています。

他にもルビとかテキスト寄せとか圏点とか色々と追求されているので、一度見てみることをお勧めします。

テキスト寄せ問題

中央寄せにならない

これは以前書いたテキスト両端揃えができないというのとは別の問題で、「テキスト寄せの指定が無視される」というものです。

「ハムスターに水を」のトップページでは名前と扉辞を中央寄せするつもりだったんですが、これがなぜかできませんでした。

.author_name{
  text-align:center !important;
}
.author_epigraph{
  text-align:center !important;
  margin-top: 2em;
}

iBooksの「両端揃え」設定

さんざんググった結果、Beating iBooks Bugsという心強いタイトルのブログ記事がヒットし、解決。この人はあれですね、ePubの関係者さんなんですかね。

このブログの要旨は以下の通り。

• iBooksの設定で「両端揃え」がオンになっていると、すべてのpタグのtext-alignプロパティがjustifyに上書きされる。
• とりあえずtext-alignの指定を変えたいpタグの中にspanタグを追加するとcssに書いた指定が適用される
• iBooksはdivやpやspanにfont-familyの指定を許していないが、これもpタグの中にciteタグを追加してそこにcssを記入することで解決する

おっしゃる通り、以下を追記してみました。

HTML

<p class="author_name"><span>高橋 文樹</span></p>
<p class="author_epigraph">
    <span>この物語をすべての非正社員と<br />
    すべてのヤリマンに捧げる。</span>
</p>

CSS

.author_name span{
  font-size:1.5em;
}
/*この指定が必要かわかりませんが、一応*/
.author_epigraph span{
	color:#000000;
}

spanタグで中央寄せ成功

これで解決。ちゃんとセンター寄せになりました。

興味深いのはePub関係者らしきLizさんがこうした記事を書いたことに異議を唱える人がいたことです。

確かにCSSハックというと、Web制作者の間では悪手の極みみたいな捉え方をされているので、こうしたことを当事者が言っていいのかってのもありますね。

spanはともかく、citeタグは「引用元を示す」という意味があるので、font-familyを適用するため（見栄えを調整するため）に使うのは間違っています。

Web2.0でさんざ言われたように、テキストはセマンティック（意味的である＝適切な意味を持つ）でなければならないはずですからね。

興味のある方は当該記事のコメント欄を読んでみてください。

個人的には歴史は繰り返す、一度目は悲劇として、二度目は喜劇としてという言葉をciteタグ使いつつ思い出します。この言葉便利ですよね〜。

というわけで、主に2つのトピックについて書いてみました。

次回予告：そうはいっても電子出版はやさしい(2)

前回は次回予告とかいっておきながら、全然違うことを書く結果となりましたが、こうしてePubを出版してみて色々思うところがありました。こんな感じ。

• PDF作ってみたけど「このまま小説を書くことなく人生が終わっていくのでは？」というぐらい大変だった。一時データがInDesignのままではブレークスルーは訪れないと思う
• iBooksの仕様上、アプリみたいなアップデートは行えない？　だったらアプリの方がいいかも
• Lulu.comの決済画面が英語というのは厳しすぎるし、ファイルも追加できないので、自前で決済システム作るか？

こうした雑感をそのうちどこかでまとめる予定です。

破滅派七号では電子出版奮闘記みたいなものも載りますので、お楽しみに。

Related posts:

1. iBooks用のePub作成覚え書き（ルビ、ジャスティフィケーションetc）
2. iBooks用のePub作成覚え書き（ePub3.0とかフォント指定とか）
3. TextlayoutFrameworkやFlash.text.engineで埋め込みOpenTypeフォントを使う方法

結論を短くまとめると以下の通りです。HTML、CSS、JavaScriptおよびePubの知識がないと意味がわからないと思います。

1. 縦書きは現時点（2010/10/15）無理
2. テキスト両端揃えはできないことはないが、メモリが足りないので使い所注意
3. ルビはまあできないことはない
4. ルビやテキスト両端揃えに対応した時点で、Adobe Degital EditionsやKindleに対応するのは難しくなる。
5. 圏点はできる

というわけで、つらつら書いていきます。

iBooks向けのePubを作る際に押さえておきたいこと

まず、iBooksというアプリケーションはWebkitベースで作成されています。iPhone SDKをちょっとでもいじった人はわかると思うのですが、UIWebViewというWebkitベースの巨大なViewクラスがあって、それがベースだと思います。iPhoneに入っているSafariもこれを拡張したものだと思います。

同じ会社が作っているものなので、当然リソースは共有されるでしょうし、基本的な開発順序は以下のようになっているはずです。

1. PC用のSafari
2. Mobile Safari
3. iBooks

事実、PC用のSafariではすでにWeb-fontやルビがサポートされていますが、iBooksはまだ（SVGフォントじゃないと駄目）です。

他の電子書籍リーダーについても同じことがいえます。

AdobeのDegital EditionsはおそらくAIR + TextLayoutFrameworkでしょうし、開発リソースはAdobe社のものが優先して使われるはずです。

したがって、各社の端末および電子書籍リーダーは様々な実装のレベルを持つため、一つのePubでどの端末でもまともな見栄えを保つというのは、かなり難しいでしょう。

実際、「ハムスターに水を」はルビを表示できるようにしたため、Degital Editionsではルビの部分が消えてしまうことになりました。

小室哲哉がTwitterを始めた電子書籍元年においても、やはり標準化は「届きそうで届かないイチゴ」なのでした。

1. iBooksで縦書きは無理っぽい

縦書きですが、現状のCSS3ではサポートされていません。CSS3の仕様にはwriting-modeとして含まれる予定のようですが、CSS3を実装するePub3.0は2011年5月に標準勧告予定なので、実装はまだ先になると思います。上手く行けばAppleが先行実装してくれるかもしれません。

1ページだけ縦書きを実現するのはそんなに難しくない（涅槃とか竹取JSを使う）ですが、普通の長編小説や雑誌等はもっと長いので無理だと思います。「くっ、メモリが足りない！」となってあっさり落ちます。

またもっとも致命的なのはiBooksでは「綴じ方向」の概念がないことです。このため、次のページは必ず右側にあります。

これを変えることができれば縦書きでの実装も可能だと思いますが、いつになるかはよくわかりません。もしかしたらもう作ってるのかな。

「Helvetica」という映画に詳しいのですが、スティーブ・ジョブズは大学時代にタイポグラフィの授業に感動して、Mac開発時にライノタイプ社に突撃、Macの豊かなフォント環境を準備したそうです。同じ情熱を日本語に対してもぶつけてくれると嬉しいのですが…まあ、無理か。

追記＠2010-10-17　ちなみに、iPadにはヒラギノ明朝がインストールされていますが、CSSで指定しても反映されません。くわしくはnovi’s pageさんの「iBooks で好きなフォントを使用する」をご覧下さい。追記＠2010-10-20 やっぱりできました。

2. テキスト両端揃え

以前のエントリーで書いた通り、やろうと思えばできます。両端揃えしたい段落のすべての文字の間に幅0かつ半角スペースが入っているspanタグ（活版印刷に敬意を表してintelというクラス名がいいと思います）を挟んでやればいいのです。

<p class="justify">私は心天をいやらしい意味に捉えていました。</p>
<!-- ↓こうする-->
<p class="justify">私<span class="intel"> </span>は<span class="intel"> </span>心<span class="intel"> </span>天<span class="intel"> </span>を<span class="intel"> </span>い<span class="intel"> </span>や<span class="intel"> </span>ら<span class="intel"> </span>し<span class="intel"> </span>い<span class="intel"> </span>意<span class="intel"> </span>味<span class="intel"> </span>に<span class="intel"> </span>捉<span class="intel"> </span>え<span class="intel"> </span>て<span class="intel"> </span>い<span class="intel"> </span>ま<span class="intel"> </span>し<span class="intel"> </span>た。</p>

これはひどいマークアップですね…

/*両端揃えにしたいpタグ*/
.justify{
	text-align:justify;
}

/*挿入用spanタグ*/
.intel{
	width:0;
	font-size:0;
	overflow:hidden;
}

理想としては、レイアウト用の余計なタグは入れたくないので、Javascriptによって動的に挿入していくことなのですが…これがうまくいきません。

1,2ページの文章ならいいのですが、「ハムスターに水を」のような長編小説にJavascriptによるDOM操作をやると、前回書いた通り、iBooksが落ちたり、ページネーションが壊れちゃいます。理由は以下の2つです。

1. iBooksはJavascriptをサポートしているが、JSによってDOMを変更した場合、再描画がうまくいかない。っていうか再描画しようとさえしてなくない？
2. Javascriptで使えるメモリは凄く少ないので、ものすごく時間がかかるか、落ちる。

ちなみにMobile Safariだと上記の問題はおきず、上手くいきました。

これは単なる予想ですが、iBooksはUIWebViewにラッパーかぶせてるだけじゃなくて、UIWebViewを継承して激しくオーバーライドしてるんじゃないですかねー。Objective-Cはぜんぜん詳しくありませんが。

iBooksは最初にファイルを読み込んでからキャッシュを作成するようなので、そこら辺の実装がMobiel Safariよりも動的なレンダリングを苦手とする要因のように思えます。

とにかく、テキスト両端揃えを実現するには、動的にspan.intelを差し込んでいくのではなく、あらかじめファイルに入れておく必要があります。これにより、テキストが奇麗にジャスティファイされます。

これを実現するためのPHPクラスintel-injectorをGistに上げておいたので、PHPerの方は勝手に使ってください。DOMってるだけです。

ただし、全文に対してspanタグを入れると、フォントサイズ変更時に十中八九メモリを使いきって落ちます。また、起動も死ぬほど遅くなります。

したがって、ピンポイントで使う必要があり、全文をテキスト両端揃えすることはいまのところあきらめた方がよろしいです。

iPadならいけるんですけどねー。

使いどころに関しては次項のルビと併せてご覧下さい。

3.ルビは実現可能

ルビは早い話、実現可能です。

gistにソースを上げておきましたが、マークアップをこんな風にすれば大丈夫です。

<p>私は<span class="ruby"><span class="rb">心天</span><span class="rt">ところてん</span></span>をいやらしい意味に捉えていました。</p>

なぜrubyタグではなくspanタグを使っているかというと、iBooks自体はrubyタグでもオッケーなんですが、僕がiBookStoreへの出品を申し込んだLulu.comというサービスのバリデーション（Threepress Consulting Inc.のバリデータと同じ）でrubyタグが通らなかったんですね。

一応、xhtml1.1にはrubyタグが拡張モジュールとして入っているはずなんですが、なぜか駄目でした。したがってspanタグにしています。

僕のように出品するのではなく、直接ダウンロードなどで配信するだけならば、以下のようなマークアップでも大丈夫です。

<p>私は<ruby><rb>心太</rb><rt>ところてん</rt></ruby>をいやらしい意味に捉えていました。</p>

で、肝はCSSです。

.ruby{
	overflow:hidden;
	width:auto;
	display:inline-table;
	line-height:2.2em;
	vertical-align:text-bottom;
	border-collapse:collapse;
	border-width:0;
	padding:0;
	margin:0;
	text-indent:0;
}
.rb {
	line-height:1.1em;
	text-align:center;
	vertical-align:baseline;
	display:table-row-group;
	text-indent:0;
	margin:0;
	padding:0;
	border-width:0;
}
.rt {
	font-size:0.5em;
	display:table-header-group;
	text-align:center;
	text-justify:distribute-all-lines;
	line-height:1.1;
	text-indent:0;
}

全部が必要な指定というわけではないですが、おまじない的に書いておきました。これでもベースラインより少し下に下がってしまいますが、まあ現状では我慢ですね。

iBooksのキャッシュは相当強力なので、CSSの微調整は絶望的に面倒です。追記＠2010-10-17 　メタ情報のIDを変更することでキャッシュ関係無しに最新のデータが表示されますが、iTunesに取り込む作業が面倒過ぎて死にます。

rubyの後の1文字の空白

さて、これでrubyが実現できて嬉しーとなるのですが、衝撃的な問題が発生します。それは、「ルビの後に謎のスペースが出たり出なかったりする」です。

スペースができるのは以下の条件が重なったときです。

1. rubyがその行内に存在する
2. その行が段落の最後ではない（＝禁則処理が行われる）

要するに、最後の行以外にルビがあると謎のスペースが出現するんですね。ePubはリフロー型なので、「ルビが必ず最後の行に来る」ということは確証しづらいですよね。

出現条件はわかりましたが、なぜこうなるかはさっぱりわかりません。やはりinline-tableは高度なのでしょうか。

試行錯誤の末、上記で紹介したテキスト両端揃えを適用すると直るということがわかりましたので、「ハムスターに水を」ではルビの入っている段落だけspan.intelを挿入しています。

幸いというか、あえてそうしたのですが、「ハムスターに水を」は登場人物名ぐらいにしかルビが使われていません。しかし、総ルビの作品なんかはメモリが足りなくなると思います。

4.ルビや両端揃えを実装すると他の端末で見られないかも

今回の「ハムスターに水を」はiBooksを利用できるユーザーを想定して作成しました。

ただ、僕が販売先として選んだLulu.comではなぜかAdobe Degital Editionのマークがでかでかとあるので、それで見るものだと勘違いしてしまう方も多かろうと思います。しかし、実はiBooks専用です。

さんざんiBooksの悪口を行ってきましたが、HTML+CSSのレンダラーとしてはDegital EditonsよりWebkit（Cocoa Touchフレームワーク？）の方がはるかに高度です。

Degital Editionsだとinline-tableが使えないうえ、入れ子になったspanタグもrubyのように認識されないタグも消えます。

これはTextLayoutFrameworkがそういう仕様なので、どうしようもありません。みんなAdobeのTLFフォーラムで戸惑ってます。

また、ePuber（そんな言葉ある？）の @naokisatoname さんが検証してくれたのですが、kindlegenでこのePubを変換しても崩れるようです。

というわけで、iBooksに併せて色々とやると他の端末で見られなくなるというブラウザ戦争の悲劇がここでもまた繰り返されていますね。

どうして世の中から戦争はなくならないの…?　僕は悲しいです。

5.圏点はできる

圏点はけっこう簡単です。こんな感じです。ゴマっぽい画像を用意してください。

<p>ヘーゲルの本では<strong>世</strong><strong>界</strong><strong>内</strong><strong>存</strong><strong>在</strong>という言葉に圏点がついている</p>

strong{
	height:2em;
	display:inline-block;
	vertical-align:baseline;
	padding:0;
	line-height:2em;
	text-indent:0;
	background:url(../Images/dot.png) center top no-repeat;
	font-weight:normal;
}

また気持ち悪いマークアップになりましたが、しょうがないですね。

もしiBooksが動的なDOMいじりに対応してくれれば、こんなことにはならないのですが…

次回予告：そうはいっても電子出版はやさしい

というわけで、制作の部分について自分が困ったことを記してみました。

他はあんまり困らなかったというか、ググれば出てくると思います。Sigliとか使えばDreamWeaverっぽくできますし、InDesignからの書き出し実験をしている方も多いです。

ただ、本を出すだけではしょうがないので、色々と試行錯誤して売ってみたいと思っています。

その結果については12月の文学フリマで出る破滅派七号やこのブログでの続報をお楽しみに。

Related posts:

1. iBooks用のePub作成覚え書き（text-alignハックと明朝体とか）
2. iBooks用のePub作成覚え書き（ePub3.0とかフォント指定とか）
3. 【目指せePub出版】Webkitでtext-align:justifyに挑戦する

近いうちに破滅派からePub長編小説を出版すべく、ISBNを取ったり、ePubの作り方を調べたりしています。

明日には原稿の校正を終え、あとはePubファイルを作るだけという状況です。

Appleに無視されてるテキスト両端揃え

iPhoneだと右端が揃わない

さて、今回のネタはAppleスタンダードから無視されている日本語Web組版の一助となるような内容のはず。すでに誰かがやっていた場合は無視してください。

HTML5+CSS3日本代表（？）である村上真雄さんが書いている通り、「SafariやChromeの元になっているWebkitではtext-align:jutifyが効かないので、両端揃えができない」のですが、これは電子書籍問題としてとてもまずいです。

Javascriptでjustify

というわけで、今回はJavascriptを用いて強引にそれっぽくしてみました。詳しくは写真をどうぞ。

基本的なアイデアとしては、以下の通りです。

1. Webkitでtext-align:justifyを指定することはできるが、text-jutifyプロパティがないので、半角スペースの部分でしか字間を調整してくれない。
2. 日本語は基本的に半角スペースによる分かち書きをしない（してる人も少しいる）ので、Webkitが半角スペース(inter-word)以外でも字間を調整してくれようになるのを待つしかない。
3. それは嫌なので、とりあえずすべての字間に幅0の半角スペースを突っ込みまくって調整させればよくない？

ということです。Javascriptで実装したのは、Webkitがtext-justifyプロパティに対応した場合、すぐ外せるからです。getComputedStyleメソッドとかでプロパティの有無を調べてから実行する形式にするともっといいかもしれません。

ソースはこんな感じです。

css

.kusabi{
	width:0;
	font-size:0;
	overflow:hidden;
}

Javascript(MooTools利用)

window.addEvent("domready", function(e){
	//字間を調整しない文字のリスト。要更新。
	var list = /[a-zA-Z0-9／「」〈〉《》￥［］〔〕,.""ヶッゞ。、・ー]/;
	//時間調整用のspanタグ。半角スペースのみを含む。
	var s = "<span class=\"kusabi\"> </span>";
	//対象となるpタグに対して反復処理。
	//ここではpタグが含むテキストに対して処理を行っているが、
	//本来はテキストノードに対して処理を行うべき。
	//xPathとか使うと吉かも。
	$$("#content p").each(function(elt, index){
		var text = elt.get("text");
		var newText = "";
		var textArr = text.split("");
		textArr.each(function(t, i){
			//ここのアルゴリズムは適当。
			if( textArr[i + 1] && !t.match(list) && !textArr[i + 1].match(list) ){
				newText += t + s;
			}else
				newText += t;
		});
		elt.set("html", newText);
	});
});

ポリシーとしては今のところこんな感じです。

• 句読点、拗音、発音、促音の前にはスペースを入れない
• 半角英数の単語の間にはスペースを入れない

文字が小さいと字間が目立つ

ちょっとやってみたところ、まあいい感じなのですが、最後にわずかなスペースが入ってしまうのと、やはりスペースのサイズが完全に0にはならないので、妙に文字間が間延びしていることでしょうか。

文字サイズが大きい場合はそれほど気になりませんが、文字サイズを小さくするとやけに目立ちます。

とはいえ、Webkit限定ということを考えれば、色々と工夫の余地はあると思いますので、今後も引き続き検証してく予定です。乞うご期待。

一応、現時点でのソースをgistに上げておきます。iPhoneで見てる人はデモで確認してみてください。

追記＠2010-09-16

実機に転送してみたところで次の問題発生。

• iPhoneのJavascript実行時間は10秒だったはずなので、forループでスタック。TimerEventに変更してトライ→SafariではOK。
• 星海社のサービスからCSSをパクってRubyを実現。inline-tableを使えばいいらしい。

というわけで、ちょっとずつ問題を解決していきましたが、どうしても解決できなかったのがiBooksでの検証。

2ページ目以降が表示されない(iPhone)

iBooksでは一応Javascriptを実行できるはずなのですが、appendChildとかで要素を追加すると、レンダリングがぶっ壊れるみたいです。

今回修正したアルゴリズムでは、setIntervalに応じてジャスティフィケーションをほどこした文字を一個ずつ追加していくというものだったのですが、2ページ名以降がなぜか表示されないんですね。

一回回転すると直る(iPad)

で、色々試行錯誤した結果、Javascriptによる処理を終えた後（これが結構時間かかる）に画面をローテーションさせると2ページ目以降も読めるようになるんですが… ページの一番下にあるページネーターが表示されなくなるんですね…

これは単なる予測にすぎませんが、Mobile Safariの描画エンジンとiBooksの描画エンジンでは、描画のタイミングがちょっと違うっぽいですね。

普通はページの下にページネーターが(iPad)

Webkit(というか、普通のブラウザ）はJavascriptでなんかやるたびに描画されますが、iBooksはそうではないようです。

パッと見た感じ、通常のDOMの上にもう一個ラッパーみたいなのをかぶせてから制御しているんじゃないでしょうか。

というわけで、結局iBooksでJustificationには挫折した訳ですが、今回やってみて気づいたことが一つ。

iBooksやiPhoneアプリはやはりAppleのためのエコシステムという感じがします。

この軛から逃れるには、Webの世界に逃れていく（つまり、Mobile Safariだけをターゲットにする）という選択肢しかないような気がします。

iBooksの魅力は「ビューアー作らなくていい」と「決済システムいらない」の2点に尽きるわけですが、現状のMobile SafariとiBooksの差を見ていると、iBooksサイコー！って言いづらいですね。

というわけで、愚痴でした。

Related posts:

1. iBooks用のePub作成覚え書き（ルビ、ジャスティフィケーションetc）
2. WordPressのiPhone用テーマをカスタマイズ
3. 長編小説「ハムスターに水を」ePub版販売開始