yasuo hirose: 2011年1月 アーカイブ

　"MP4" の videoファイルを "HTML5" 対応の "iPad" 向け "ePub" に組み込む検証をしてからというもの、ブラウザ上で "MP4" videoファイルの設定をしてみるなど、"MP4" videoファイル自体に関心が向いている。
　以前にも、videoファイルをブラウザ上で表示することに関心はあったものの、ファイル容量が馬鹿にならない点や、"IE" での煩わしいコード、タグ記述（ ex. "object" , "embed" ......）という点などから、自然に遠のいていた。

　今回、再び関心を持つに至ったのは、これらの難点を "MP4" videoファイルの場合にはクリアしているかに思えたからであった。
　とにかく、ネット環境での "メディア処理" については、"簡便" であることが何よりだと思える。そうであればこそ、最も主眼とされるべき新しいコンテンツを、タイムリーにかつ多頻度で "アップ" することができるというものだからである。 "アップ" するのに何かと手間や負荷が掛かるのでは、足が遠のくというものであろう。

　あくまでも "ついでに" ということだが、昨日、"MP4" の videoファイルを、"HTML5" 対応の "iPad" 向け "ePub" に組み込むことをレポートしたので、今日は、ブラウザ上で "MP4" の videoファイルを表示する方法を披露しておきたい。
　先ずは、以下のとおりであり、controller のプレイボタンをクリックすれば動画表示となるはずである。( フリーソフトで画面サイズを縮小したため、そのベンダーのロゴが表示されることとなってしまった...... )

　この間、"HTML5" の仕様による "iPad/iPod" 向けの "ePub 電子書籍" に再生可能な "audio" を組み込む検証を行ってきた。
　これらに、概ね問題がないことを確認してきたわけだが、では "video" の再生についてはどうなのかという課題が残されていた。
　そこで、現在最も一般化している "video フォーマット" の "MP4" ファイルを使って検証してみることとした。
　先ず "Web ページ" を作成する。コードについては "audio" に関してこの間紹介してきた構造のままでＯＫである。もちろん、"audio" と入力した部分を "video" と改めるのは当然のことだ。
　また、"ePub 変換" の手順は、これもまた、"audio" の際に解説したところの "eCub" を使った手順のままで問題ない。

　以下、とりあえず実現されたことを、レポートしておきたい。
　なお、ブラウザ Firefox のePub リーダーでは、"MP4" ファイルは "未対応" のようである。他の "video フォーマット" ならば可能だと思われるが、今日のところは、パスしておきたい。
　"iPad/iPod" での "(MP4)video" の再生は、画質も良く、また "画面拡大" がスムーズなこともあり快適に鑑賞が可能である。 "ePub 電子書籍" 制作上で、様々なニーズに対応できそうだとの意を強めることができた。

　言うまでもなく "iPad" の大きなセールスポイントは、操作が簡単な "タッチパネル" であろうし、また "Wi-Fi接続、3G接続" で "ネット接続" も手軽な点であろう。
　こうした便利なツールを活用して、深まりゆく "高齢化時代" の難問に貢献してはどうだろうかと思った。

　今、全国各地で、"買い物難民(弱者)" という問題が話題となっている。

＜......近所にスーパーなどがなく、ふだんの買い物に困っている独り暮らしのお年寄りなどのいわゆる買い物弱者は、過疎化や高齢化の影響で全国で６００万人に上ると推定されています。関係者によりますと、ＮＴＴ東日本とセブン－イレブン・ジャパン、それにＵＲ＝都市再生機構は、こうした人たちを対象に、画面に触れるだけで簡単に操作できる専用のタブレット型端末を使って、コンビニに注文した商品を自宅まで届ける宅配サービスに共同で乗り出します。......「買い物弱者」を対象にした宅配サービスに大手企業が共同で乗り出すことで、ほかの企業にも同じような動きが広がりそうです。＞（＜"買い物弱者"新宅配サービス／NHKニュース＞）

　"ePub 電子書籍" や "Webページ" に "HTML 5" の仕様に則った "audio/video" を埋め込むニーズは小さくない。
　確かに、埋め込まれた "audio/video" は、"ePub 電子書籍" や "Webページ" に大きなアクセントを付けて、それなりのインパクトを与えるものだ。
　ただ問題は、さほどの手間が掛からずに組み込めることや、組み込むメディアによる負荷が大きくないことが可能かどうかであろう。
　そうした点から、"HTML 5" の仕様が期待されるのであろう。

　先ず、今回作成した自作の "audio埋め込み型 ePub 電子書籍" のページを参照していただきたい。

　"ePub 編集・変換" ソフト "Sigil" に、"Chapter Break" ( = split / ファイル分割、章単位分割 )機能のあることはよく知られている。
　"ePub 電子書籍" では、意図的にページ区切りを設定しない限り、ダラダラとページが連なって表示されるため、"章ごと" に "頭出し" することができる "章単位分割" ( "Chapter Break" )の機能は貴重である。

◆ 参照　＜失敗しない"Sigil"での "表紙ほか画像" 挿入と"Chapter Break"の手順完全図解！（当日誌 2010.12.20）＞

　これは、一般的なシステム用語風に言えば、"File Split(分割)" 機能のことである。
　とすると、"File Split(分割)" 機能があれば、"File Merge(=合併)" 機能があっても然るべきだと考える。
　よく調べてみると、"Sigil" には、しっかりと "File Merge(=合併)" 機能も備えられていたのである。

　まず、下の図の＜(1) "eCub"の表紙作成ツール "Cover Design" で仕上げた表紙＞をご覧ください。
　昨日ご紹介した手順にて、自前の "Web ページ" を "ePub 電子書籍" 化したものに付けるための、その "表紙" を作ってみました。
　"eCub"の表紙作成ツール"Cover Design" は、操作が比較的簡単なので、ルンルン気分ででっち上げることができました。

　"eCub" も "Sigil" と同様に、使い込んでゆくとその機能の懐の深さに気づかされる。　今回は、その "eCub" に備えられた "ePub Book" 用の "表紙デザイン" ツールの操作方法を、自前のサンプルを使って解説してみたい。
　 "eCub" の "ePub Book" 用の "表紙デザイン" には、数枚の "Template" が置いてあり、便利にこれを流用することも可能ではある。
　しかし、せっかくの自前の "ePub Book" であれば、やはり自前の "オリジナルの表紙" とするのが自然なのではなかろうか。
　もちろん、"オリジナルの表紙" 制作については、"画像ソフト" を活用して作ることも十分に可能である。ただ、"eCub" のこのツールは、半端な "画像ソフト" よりも優れた部分をいくつも含んでいる。一度は使ってみる価値がある。そして、使い慣れれば、もはや "ePub Book" 用の "表紙デザイン" で悩むことはなくなりそうだ。

　"ePub 電子書籍" に "audio/video" を付加するアプローチについては、この何日かに渡ったレポートで "コツ" が掴めたのではないかと思う。
　ところで、"ePub 電子書籍" 上ではなくて、ブラウザ上での "audio/video" の付加について再認識をさせられたことがあったので、ついでに記載しておきたいと思う。

　先日の＜"eCub"アプローチを使って、既に自作した"ePub 電子書籍" に "audio" を埋め込む！（当日誌 2011.01.21）＞で、ブラウザ上で "サンプル audio" を公開したのだったが、＜( ブラウザは、 "Firefox" で Play する。但し、なぜだか autoplay="false" が効かずに "autoplay" されてしまうようだ...... )＞ととりあえず書いた。
　この時は、"ePub 電子書籍" にのみ関心が向いていて、ブラウザ上での事情は二の次であった。確かに、下記のスクリプトで、"iPad/iPod" 上での "ePub 電子書籍" については何ら問題がない。

　くどくどしいという感じも無きにしもあらずであるが、今回、確認するのは、以下の点となる。
　"audio 埋め込み型 ePub 電子書籍" 制作に実際着手する場合、本体を "Sigil" で作成して、"audio 埋め込み" のみで "eCub" を活用するというアプローチが "有効かどうか？" という点なのである。
　これは、"XHTML" の規格と "HTML5" の規格との "親和性(?)" の問題でもある。
詳細はおくとして、もし、"Sigil" で作成した "ePub" のスクリプトが、"audio/video" のタグ部分以外はそのまま "活きる" とするならば "ありがたい" はずであろう。
　この点を検証してみたが、手順さえ間違えなければ、 "ＯＫ！" であることが確認できた。昨日の検証も全く同じことなのであるが、今日は、念のため以下のような手順で実行してみた。

　この間レポートしてきた "eCub" を使った "audio 埋め込み型 ePub 電子書籍" 制作アプローチの紹介もひとまず今回で締め括りとなる。
　そこで、既に自作した "ePub 電子書籍" に "audio" を埋め込むトライを紹介することにする。
　先ず、自作サンプルの "audio" 素材の実際を、ブラウザ上で例示する。( ブラウザは、 "Firefox" で Play する。但し、なぜだか autoplay="false" が効かずに "autoplay" されてしまうようだ...... 。＜autoplay="false"＞部分を外したら、＜controls＞が正常化！　但し、 "iPad/iPod" 向けの "ePub ファイル" ではこの除去は不要。 )

　"iPad/iPod" 向け "audio ePub" のプロトタイプを、"ePub 変換ソフト：eCub" で作成してきた。 "二つの狙い" があった。
　一つは、 "ePub" 規格が未対応の "XHTML5" 水準の "audio/video" に、"iPad/iPod" は対応しているため、それを実現するアプローチを検証してみること。
　二つ目は、このアプローチ実現には、純粋な "ePub 編集・変換" のソフトである "Sigil" では叶わないために、"ePub 変換ソフト：eCub" を駆使しようという点。そのために、ソフト "eCub" の使い勝手を会得してしまおう、という点である。
　これらを、いわば "並行" してマスターしてしまおうというのが、この＜"eCub"の使い方完全図解！シリーズ(?)＞の目的だったのである。

　で、今回は、着手していた "iPad/iPod" 向け "audio ePub" のプロトタイプに "修正編集" を施して、このアプローチの拡張を図ろうという算段なのである。差し当たって今回は実に "マイナー" な編集で"画像の付け足し" に留まりはした。
　しかし、この "修正編集" を踏まえれば後は "力仕事" 以外ではなくなると考えている。ただ、"iPad/iPod" におけるこの辺りの "スクリプトへの厳密さ" は結構ナーバスかと思われた。いい加減な殴り書きではリジェクトされてしまう......。
　以下は、取りあえず "成功" に辿り着いた手順のトレースであるので、参考にしていただきたい。

　"ダークホース" の "eCub" により馴染むために、今日は、昨日の "ビデオ・オーディオ埋め込み EPUB 電子書籍" 制作の過程で、"表紙" を付け足す手順を "完全図解！" することとした。
　大したことではないのだが、昨日の作業手順の "おさらい" としてはおもしろいかもしれない。自作の "表紙" を付ける作業もほんの隣り合わせである。
　不慣れな "ソフト" に慣れるためには、あれやこれやと使ってみることに勝る方法はない。このソフトも、"Sigil" と同様に＜"WYSIWYG"＞方式となっており、スクリプトの編集も可能であるため、使い込むならば価値が増すソフトだと思える。

　昨日記載分の "続き" という位置づけである。事情が見えない場合は、昨日分に目を通していただくのがいいかと思う。
　今日記載するのは、せっかく良いフリーソフトでありながら、その使い方が分かりにくいという "eCub" の完全図解である。
　あえてこれを記載するのには "ワケ" があり、その事情を昨日は書いたつもりであった。現行では、"iPad/iPod" がせっかく "iBooks" で "audio,video" などという "XHTML5" 水準の機能に対応していても、 "ePub" 規格が "XHTML5" には未対応のため、"ビデオ・オーディオ埋め込みEPUB電子書籍" は制作しにくい状況なのである。
　そこで、盟友の "Sigil" からちょいと離れて、ダークホースとも言うべき "eCub" を利用してこの辺の問題をクリアしようというわけなのである。
　自分なりの解説は、画像中の "青字" 部分で行ったつもりなので参考にしていただければと思う。自分も既に、この方法での "ビデオ・オーディオ埋め込みEPUB電子書籍" の制作を始めている......。

　"iPad/iPod" 向け "ePub 電子書籍" に、"オーディオの埋め込み" を実現したいと望んでいた。コンテンツに関する解説の音声などを盛り込みたいという意図からだ。
　そのきっかけは、"iPad/iPod" の "先読みスタンス" にあったかもしれない。
　つまり、本来は現行の "ePub" 仕様は "HTML5" 規格を受け容れないにもかかわらず、"iPad/iPod" は "ePub ファイル" での "video" や "audio" といった "HTML5" 規格水準のメディアを許容するという点である。それならば試してみない手はない......、と促されたのであった。
　しかし、いざ作業に取り掛かると、途端にとある "伏兵" に遭遇してしまった。

　現在、"Sigil" を使って "ePub 電子書籍" 化を進めている自作 "Web ページ" には、たまたま "PDF ファイル" が多数含まれている。"リンク" 付けをして、クリックすれば、"Acrobat" などの "PDF リーダー" が開いて表示することになっているのである。
　これらの "PDF ファイル" まで "ePub 変換" するのは煩わしいものだとやや懸念していた。
　そこで、密かな期待感を持って、同一の "ePub 電子書籍" ファイルにそのまま組み込んでみた。
　"Sigil" に備えられた "フォルダ" には、＜Text＞,＜Style＞,＜Images＞,＜Fonts＞のほかに、＜Misc＞という "フォルダ" がある。"Misc" とは、"miscellaneous" の略で、「種々雑多な、いろいろの、多方面にわたる、その他、雑」の意味だ。
　この辺りの "フォルダ" に "PDF ファイル" を置いておけば、ことによったら表示するのかもしれない......、という直観だったのである。

　なぜ、"Web ページ" を "(ePub)電子書籍" にするのかと尋ねられることがある。
　差し当たって現状では、"ePub 変換" のスキル・アップにとってこれ以上に適切な素材はないからだと答えるのだが、実を言えばそれだけではない。
　ＰＣで、"Web ページ" を閲覧するのは、それはその用途があるからに違いないが、その用途の中には、"コンテンツをジックリと読む" というニーズは含まれてはいない！　と言っていいのかもしれない。
　とにかくスピーディに "ファースト情報" を得るためには、"Web ページ" は最適だと思われる。しかし、ＰＣにかじりつくような、前のめりの姿勢では、コンテンツを "ジックリ" と読む、ということにはならないのではなかろうか。

　『電子書籍の衝撃』の筆者／佐々木俊尚氏は、この辺の事情を以下のように述べていた。

＜* 姿勢と距離から見る、コンテンツとデバイスの相性
　いま、ものすごい勢いで「タブレットサイズ」と呼ばれる電子ブックを読むためのコンピュータが登場してきています。
　つい最近まで、電子ブックを読む機器はパソコンか、そうでなければケータイでした。しかし、パソコンやケータイで本を読むという行為が本当に最適な読書スタイルなのかというと、かなり疑問です。
　コンテンツは、それに適した「姿勢」と「距離」が用意されないと、じっくりと楽しんだり取り組んだりできません。＞（佐々木俊尚『電子書籍の衝撃』／ディスカヴァ一携書／2010.04.15）

　自作小説の "ePub 電子書籍" 化に一段落した今、専らスキル・アップのために実践しているのが、"自作 Web ページ" をより忠実に "ePub 電子書籍" 化する作業だ。
　"より忠実に" というのは、自己に課したルールなのである。さもないと、"ややこしい部分" をやり易いように逃げてしまい、スキル・アップには繋がらないと思えたからなのである。
　自分が作った Web ページ でも時が経つと、まるで他人が作ったもののように "理解困難" となりがちで、良いトレーニング／"Case-Study" となっている。構造的に作り直した方が適当かと思えることもあるのだが、とにかく、表示をより忠実に再現すべく "ePub 編集・変換" を図るよう努めている。
　これが、実に手応えのあるトレーニングとなっているのである。以前、 ＜"ePub電子書籍"制作の訓練には、既存の"Web ページ"の"ePub 変換"が良さそう!? （当日誌 2010.01.03）＞ と書いたが、まさにその通りだと思われる。

　"自作 Web ページ" の中には、比較的古いものでは、まだ "XHTML & CSS" の方式を使わずに、いわゆる "table" 方式をガンガン使って "力ずく" で構成していたものもあったりする。
　 Web スクリプト/タグ で "table - tr - td" を多用してレイアウトを構成する方式( "table" 方式)は、作る際には比較的取っ付き易いからついつい多用してしまうのだが、とにかく "修正・更新" などの "メンテ" には手間が掛かる代物だと言える。
　"XHTML & CSS" の方式でも、一応この "table" 方式の考え方は踏襲されてはいるが、どこか "異端児" の感が拭い切れない。
　いや、今日のテーマは、この "table" 方式ではなくて、こうしたレイアウトのものを "XHTML & CSS" 方式に近づけようとするならば、実に骨が折れるということである。
　したがって、新たに "Web ページ" を作る際には、部分的に "table" 方式を使うことはあるとしても、極力控えてオーソドックスな、また、"ePub" と親和性の高い "XHTML & CSS" 方式で書き上げるべきかと痛感している。

　この間、まるでこの日誌を書くことやウォーキング同様に、毎日欠かさず "Sigil" を立ち上げ、"iPad/iPod" を両袖に置いて "ePub 電子書籍" 制作作業に勤しんでいる。
　よくもまあ "懲りずに" 続くものだとわれながら感心したりもするが、おかしなもので、たとえストレスが溜まることがあっても、そこを堪えて淡々と毎日欠かさず続けていると、次第に "よく見えてきたり" 、"脳の働きが馴染んできたり" するかのようである。

　正直言って、困惑させられるケースが少なくはなかった。"XHTML & CSS" の基本では了解できない不具合表示や、"Sigil" や "ePub リーダー" などではＯＫであっても、タブレットの "iPad/iPod" に "同期" を図れば、それは無残な表示結果となったことも度々であった。
　まさに "正体不明" の原因を相手として、トライ＆エラーを繰り返し、それでもその都度、自分なりの "秘策" に無理矢理にでも辿り着いていたようだった。だからこうして "懲りずに" 続いているのかもしれない。

　仮に、タブレット側に "バグ" があったとして（サイトを調べていたら、ご多分に洩れず、"iPad" の "バグ" を指摘する投稿も海外にはあるようだ......）、それを論(あげつら)ったところで当面の不具合が解消するわけではない。そんな事って、世の中には溢れ返っているいるわけだから。
　むしろ、「じゃあ、どうしてくれようか......」と自前の知恵を出すことに意を傾けた方が建設的！　であるに違いないと最近は考えている。それこそが "インディ・スピリッツ" と言うものかもしれない。

　"ePub 電子書籍" のメリットの一つに、Web ページなどの複層的な構成ファイルを、一つに統合された "ePub 圧縮ファイル" に仕上げるという点が挙げられる。
　とかくWeb ページなどでは、".html" や ".css" といったテキストファイルに加えて、".gif"、".jpg" などの画像ファイルほか多数のファイルが "Web コンテンツ" を構成することになる。
　さらに、複数の ".html" ファイル間にリンクを張って全体ページを構成した場合には、まさに複層的なファイル構成となり、きちんとしたファイル管理をしないとゴチャゴチャとなりかねない。
　時が経過して、サイトからリタイアさせたページなどは、作る時には労力を注いでも、管理さえ難しくなりかねない......。

　こんな場合、こうした "Web コンテンツ" の保存対策としての "ePub ファイル化" は実に好都合だと思われる。
　"圧縮ファイル" となるため "容量" も極小化できるし、何よりも、その内部に関連ファイルすべてが秩序立って整然と格納されるためありがたい。
　再編集したくなれば "Sigil" などの "ePub エディタ" を使えばよいし、また再利用のためにファイル類を取り出したい場合には、"解凍" すれば取り出せる。
　と言うことで、"ePub ファイル化" とは、ファイル類の便利でスマートな "収納庫" だとも言えそうである。

　昨日も書いたように、"iTunes" を介した "iPad/iPod" では、どうも "エラーを抱えた ePub" については、"同期" それ自体に "難色を示す(?)" かのようである。
　相応の "エラーを抱えた ePub" に関しては、それ以外の部分にマイナー修正を施しても、まるで、「直す箇所はそんなところじゃないでしょ！」と言わぬばかりに、マイナー修正箇所をまともに反映しない、ようなのである......。
　エラー箇所を、それと承知の上(後でまとめて直そうと)で別な部分のマイナー修正をしようとするのだが、どうにも受け容れないのである。こうした "頑固な" スタンスを一応了解(?)している今では、そうか、そうかと往なすようにはなった......。

　そんな折、"0.3.3" に Version Up された"Sigil"には、"Validate Epub"(Epub 検証)機能が搭載された。

◆ダウンロードサイト：＜Sigil Downloads　Sigil-0.3.3-Windows-Setup.exe ＞

　多少込み入った構成の "Web ページ" の "ePub 変換" は、やはり厄介なものだ。いや、厄介なのは "ePub 変換" 自体ではなく、タブレットの表示可能サイズにカスタマイズするための調整作業だと言うべきか......。
　多分、 "Web ページ" に掲載していた図表などの "画像ファイル" のサイズを、現行作業向けに、画像エディタなどで "リサイズ" すればスンナリ行くのかもしれない。だが、それは "画像の劣化" に等しいので "元のサイズ" のまま画像の "width 設定" の変更だけで済まそうとしているからギクシャクしているのかもしれない......。

　それはそうとして、こうした調整作業をしていると、どうしても編集プロセスのコンテンツを "頻繁に" タブレットへと "同期" することとなる。 "マイナーな修正" をかけた同じファイルを幾度となく "同期" するわけだ。
　こうした場合には、ブラウザでも "キャッシュ機能" に悩まされたりするものだ。 "マイナー修正" がそれとして認識されずに "キャッシュ機能" で済まされてしまいがちなのである。
　"iPad/iPod touch" でのこの辺の問題については、これまでにも何度も書いてきた。そして、かなり "好意的" にも解釈したりしてきた。

　"自炊 PDF" から "Calibre" などを介して作った "ePub 電子書籍" に、より快適に読めるように "ジャンプ可能な目次(TOC)" を付加することの意義は小さくない。
　ただ問題は、昨日も末尾で書いたように、
＜"自炊 PDF" から "Calibre" を介して "ePub 変換" した "ePub 電子書籍" は、言うまでもなく、"jpg ファイル" の羅列なのであり、"見出し" などの "文字列" なんぞはあるはずがない！＞(昨日の日誌)
ということであろう。
　"Sigil" での "Table Of Contents Editor" を利用するにも、元の ePub ファイルが＜"jpg ファイル" の羅列＞(= "連番jpg の ePub" ！　下図(1)を参照 ) なのだから、そのままでは対処のしようがない。

　そこで、ちょっとした "強行技 ( 裏技 )" に及ぶことになる。
　ところで、ここで "Sigil" での "目次/TOC(Table of Contents)" 機能の仕組みを思い起こすならば、"Sigil" が、"目次" の項目として "Entry" するものは、文字列のステイタスが、 "タグ" の "h1" ～ "h6" で囲まれた部分だという点である。
　つまり、"XHTML & CSS" における基本なのだが、"見出し(heading)" を構成する "タグ" の "h1" ～ "h6" を見つけると、"Sigil" はそれを "自動的" に "目次" の項目として "Entry" するのだ。
　この辺の事情は、既に説明済みだ。

＜(1) 先ず、道具立ての確認。"Sigil" のツールバーの二段目の左端に、"Normal" という文字が見える＜ドロップダウンリスト＞があるはずだ。これは、指定された文字列に、 <p> や <h1～h6> といった "ランク" 付け設定をするものなのである。＞（ 前述の＜"ePub電子書籍"では自前の"目次/TOC"は不要！"Sigil"での"TOC"の完璧作成技法！（当日誌 2010.01.04）＞）

　いくら、"電子書籍" の "フリック" や "めくり操作" が面白いからと言って、何百ページもある書籍を "めくりめくる" のは馬鹿げている。また、下部のページ目盛をヤマ勘でドラッグして望みのページに辿り着くのもどうかと思う。"一発選局" ではないが、やはり "一発で" ページ移動を果たすのが "電子書籍作法" というものではないか。
　となると、どうしても "iBooks" に装備された "目次／TOC(Table of Contents)" 機能(メニューバーの＜ライブラリ＞ボタンの右隣にある、"三段のリスト" で表現された＜目次＞ボタン)を活用する手だ。これが、たとえボリュームのある eBook であっても、速やかに eBook 内を案内してくれるからである。
　昨日も書いたが、"電子書籍" にあって、こうした機能を眠らせていては絶対にマズイ！　フル活用して、"電子書籍" での読書の "快適感" を堪能していただかなくてはならないからだ。

　そんなことで、つい先日は、"ePub 電子書籍" に、"Sigil" で簡単に "目次／TOC(Table of Contents)" を付加する方法を解説したばかりである。

◆ 参照 ＜"ePub電子書籍"では自前の"目次/TOC"は不要！"Sigil"での"TOC"の完璧作成技法！（当日誌 2010.01.04）＞

　それを書きながらも気にはなっていたのである。つまり、"自炊 PDF" から "Calibre" で作成した "ePub 電子書籍" に、比較的簡単に "目次／TOC" を付け足すことはできないものか......、と。
　"PDF 電子書籍" に "ジャンプ機能付き目次" をつけることは、"Adobe Acrobat" などを利用すればもちろん可能である。しかし、自分も何度となく活用したが、そこそこ手が掛かるのである。
　とすれば、もう一息、"Calibre" で "ePub 電子書籍" に変換してしまい、その "ePub ファイル" を "Sigil" で編集しつつ、 "Sigil" 流の "目次/TOC" 作成に向かってみるとうのも一法なのだと思った。

　昨日の日誌で何気なく次のように書いた。
＜"iPad" における "画像表示" では、タップをしてピンチアウトすれば "拡大表示" も自在なので、......＞（＜"段組み"されたWebページなどの"ePub電子書籍"化では,"横幅サイズ"なども厳密に（当日誌 2010.01.06）＞）と......。
　そうなんだ！　これは一例に過ぎないけれど、こうした他メディア(特に、ネット="Webページ" )との差別化ポイントをもっと積極的に注目し、活用すべきなのだ、と......。

　"電子書籍" への人々の関心・注目が、単なる "ブーム" に過ぎないとの酷評はかねてよりあった。事実、ちょいと調べてみると、「儲からない "電子書籍" ......」というフレーズもやたらに目に飛び込んでくる。
　確かに、"プラットフォーム戦争" は熾烈だし、書店には『 "電子書籍" ～』という新刊の How-to 本が溢れていて、さも "電子書籍全盛期" のような "空気(?)" はある。
　既存出版社にしても、 "一応!?" 、"電子書籍" ビジネスへと歩調を合わせているかの気配だし......。ただし何の確信もなく......、である。
　ひょっとしたら、外見は "大騒ぎ" 風でありながら、内心は「儲からない "電子書籍" ......」という "殺し文句" でヒンヤリと醒めているというのが大勢であのかもしれない......。

　様々なパターンの "Webページ" を "ePub 電子書籍" 化してみる作業をしているが、昨日書いた＜"iPod/iPad" については、"横幅サイズ" は "不問" で、タブレット側の自動調整機能に任せよう！＞というアプローチでは、逆に "手間が掛かる" ケースもありそうである。
　このアプローチは、シンプルなレイアウトの場合は大いに活用できるものの、 "二段組み"・"三段組み" といったやや複雑なレイアウトの "Webページ" となると、むしろ、タブレットの表示サイズ( "横幅サイズ" など)を計算しつつ、"Webページ" のスクリプト上で設定された、各要素の "横幅サイズ"・"縦サイズ"・"画像サイズ" などの数値を "再設定" してしまった方が "無難" だと思われる。

　"ePub 電子書籍" 制作に関する記事も、ここに来て "総論" 的なレポートから、ようやく "各論" 的な水準に移行してきたかに思う。
　それもそのはずで、右往左往の試行錯誤の域からやっと抜け出すことができたかのようであり、昨今ではこれまでの "経験的事実" の累積から、比較的細かな部分への類推が幾分か働くようになったからなのであろうか......。
　また、この日誌に、多々、間違ったことや思いこみを含む "体験レポート" を書いてきたことも、読み手は迷惑であったかもしれないが、書き手としては "実験レポート" を書く時のような "効能" が得られたのかもしれない......。
　つまり、文章化するということになると、仮に間違ったことや思いこみを含んだとしても、とにかく "モヤーッ" とした状況把握の状態から出て、状況推移を "対象化(目の前に置く！)" せざるを得ないからということだからである......。

　そんなわけで、状況把握は "流動化" しながら "進展" もすることとなり、現時点で書くことが以前に書いたことを修正することになる推移もまま起こり得る。ただ、参考になるかどうかは別にしても、できるだけ "体験的事実に照らして" これが妥当であろうと思われる事実を追加して行こうと考えている。
　そうした事実把握を二点以下にまとめておくことにする。

　"iPad"・"iPod touch" など向けの "ePub 電子書籍" には、あえて自前の "目次／TOC(Table of Contents)" を作る必要がない。
　"iBooks" で何らかの "電子書籍" を開くと、そのメニューバーの＜ライブラリ＞ボタンの右隣に、 "三段のリスト" で表現した＜目次＞ボタンが現れる。これをタップすると、"制作時に登録" した目次ページが表示されることになっている。
　えっ、別に "登録" した覚えはないけど......、という方もおられるかもしれないが、"ePub エディタ" などは "とある指標" に従って "自動登録" するのである。

　たとえば、"ePub editor=Sigil" でもそれは実行されている。

　"ePub editor=Sigil" を活用した "ePub 変換" のアプローチが、結局 "正攻法" だと実感している。
　そして、やはり "XHTML & CSS" の習熟度を高める以外に、スマートな "ePub 変換" はあり得ないという実感をも深めている。
　この間のトライ＆エラーにおいて遭遇した様々な "不具合" にしても、よくよく吟味してみると、"XHTML & CSS" の運用作法の誤りに帰着することが少なくなかったように振り返る。
　まあ確かに、"iPad"・"iPod touch" などのタブレット側の詳細情報が分からないことによる混乱は避けがたいものであった。また、"Sigil" が意外と "XHTML & CSS" のルールに甘い寛容な仕分けによって、問題点を "スルー" させてしまう点も困惑を増幅させたかに思う。この点は、ＰＣ上の "ePub リーダー" の反応についても同様だった。
　だから、何が本当の問題なのかが見極めにくく右往左往させられたわけであるが、現時点で振り返ってみると、＜"XHTML & CSS" の運用作法の誤り＞という原因が思いのほか多かったことを率直に認めざるを得ない。

　年末から梃子摺っていた "ePub 変換" プロセスのちょっとした問題を、この正月元日にようやく解決した。それも、"XHTML & CSS" の基本に則り、しらみつぶしでファイルリストを見直すというオーソドックスな方法によってであった。
　＜"Sigil"で暗礁に乗り上げていた"ePub"ファイルを"Calibre"で仕上げさせてみた?!（当日誌 2010.12.31）＞ というような、一見、あざといアプローチに惹かれがちではあるが、結局、"Calibre" のアウトプットを過大評価することはしなかった。あくまでも、参考データにするだけに留めた。つまり、当該の自作ファイルでも、アプローチを吟味しさえすれば "iPad"・"iPod touch" で妥当に表示されるようになる、というその点だけの証左を頂いたというわけである。

　今日は時間的な余裕がなく、昨日書いた "Calibre" によるアウトプットをじっくりと吟味するには至っていない。
　 "Calibre" によるアウトプット、とは、"Sigil" で制作中の "ePub" ファイルが今一つ思い通りには行かず手をこまねいていた際に、それを "Calibre" で再･ePub 化してみたところ、表示結果については見事にＯＫとなったという件のことなのである。
　ということで、このアウトプットを "解凍" して中身を吟味してみるなり、再度、"Sigil" に読み込んでみて何らかのヒントを得ようという算段をしたわけであった。
　が、 "Calibre" によるアウトプットは、"CSS" が、特有の "namespace" の設定となっていたりして、解析には幾分骨が折れそうな気配である。
　ただ、本筋とは離れてはいるが、"派生的" に気づかされた点が一つあり、この点は書いておくに値する事柄かと思えた。

　この間、"iPad" や "iPod touch" の "ファイル管理機能" に梃子摺っていたことは再三書いてきた。"キャッシュ機能" の "頑固さ" にも呆れていたが、ファイルの "同期" 時に、消去やエントリーでもたつく場合があることに問題を感じていたのだった。
　だが、この現象の中のあるものは、"ePub" ファイルとして問題含みである時に、"読み込み拒否" とでも言うようなフィルタを掛けていそうなことが推定され始めた......。"ePub" ファイルとしての規格から外れるファイル構成の場合には "門前払い" を喰らわせるというような仕組みがありそうだ......、と。