2010年12月 アーカイブ

　良い "検証データ" が得られたと思っている。
　と言うのも、「一難去ってまた一難」とばかりに、"ePub 変換" の作業で、いわば "暗礁" に乗り上げていた案件があったのだ。
　それは、"XHTML & CSS" で作成した "Web スクリプト" を元にして、"Sigil" で編集しかけていたファイルなのである。
　"Sigil" での表示では何ら問題ではなく、また、ＰＣ上の "EPUBReader"、"Adobe Digital Editions" などの "ePub リーダー" でもほぼまともに表示されるコンテンツが、いざ "iPad" や "iPod touch" へ "iTunes" で同期させると、無残な結果が表示されてしまうのであった。
　おまけに、昨日も書いたように、"iPod touch" ときたら、まるで駄々をこねる子供さながらに、"ファイル管理機能" で足を引っ張る有様であったから、いい加減イライラさせられていた。

　今日も、腰を据えてやるしかないか......、と基本的な部分からの見直しを延々と繰り返してみたが、埒が明かない始末であった。
　最大の原因は、当人は、一通りの山場を通過したつもりではいたものの、まだまだ到達技量そのものに "バグ" が潜伏している......、ということなのであろう。
　そして、二番手の原因は、信頼を置いてきた開発ツールの "Sigil" が、若干特殊な問題個所となると、それをそれとして指摘できずに "スルー" させてしまう点であったかもしれない。
　しかしまあ、メジャーな "ePub リーダー" でさえ感知できない問題点だとすれば、しょうが無いと言うべきかもしれないが......。

　つい先日、＜iPad/iPodのコンテンツ制作で辛い"再同期"時でのかなり根強い(?)キャッシュ機能（当日誌 2010.12.27）＞ と控え目に書いたが、iPodの"頑固な"キャッシュ機能！　と、硬直化するファイル管理機能！　にはほとほと参っている。ほとんど "バグ" だとしか言いようがなさそうだ......。

　幾度となく、 "修正更新" の "同期" を繰り返しても、修正部分の "更新" がなされずに、事前の表示状態が "頑固に" 残り続けている。同じことを "iPad" で試してみると、スンナリと "更新" がなされるにもかかわらずだとすると、どうもこれは、"iPod" 特有の現象かと "疑い" 始めた。
　しかも、"iPod" では、"iTunes" を介しての "ファイルの削除・追加" においても、スッキリと"ファイル削除" がなされずに、既存の状態が尾を引くことがしばしばなのである。
　いい加減にしてくれ！　と言いたいほどにウンザリした気分にさせられているのが実情だ。

　今年の自分は、かなりのエネルギーを割いて "電子書籍" ジャンルにのめり込んできたようだ。Apple が "画期的タブレット" である "iPad" シリーズおよびその環境を世に問い、またこれに熱狂で応えるユーザーが多かった年だけに、自然な流れであったかと思っている。いわゆる時代の "流行" から疎くなり始めている自分ではあるが、久々にワクワクする雰囲気に包まれたりしたものであった。
　もはやＰＣが身体の一部、いや頭脳の一部だとさえ感じている自分などにとっては、ＰＣへの概念を覆(くつがえ)さんばかりに斬新なこの種のタブレット(ＰＣ)は、やはり奇妙な興奮をもたらすもの以外ではなかったわけだ。
　もちろん、"ポータブル性" や "操作性" のスマートさや "手頃な価格" に象徴される "モノとしての魅力" が、先ずは大きな誘引だっただろう。
　しかし、"iPad" シリーズの魅力は決してそればかりではなく、ネット環境をふんだんに活用した "簡便なダウンロード環境" の併設完備という点の意義が大きいと言える。いわゆる "本のアンビエント化" （佐々木俊尚『電子書籍の衝撃』／ディスカヴァ一携書／2010.04.15）環境のことである。

＜≪iTunesによってそうした手間のほとんどは消滅し、いつでもどこでもどんな場面でも、自分が音楽を聴きたいと思った瞬間に手元のデバイスから魔法のように楽曲をひきだすことができるようになりました。これがアンビエント化です。≫（前述書）......
≪本はこれから電子ブックによってアンビエント化していくということです。そして、アンビエント化された本の世界では、古い既刊本も新刊も、あるいはアマチュアの書いた本もプロの書いた本も、すべてがフラットになっていきます。≫（前述書）＞（＜"電子書籍"は､"アンビエント"化状況によって書き手をも読み手をもアクティブに! （当日誌 2010.11.13）＞）

　そして、その "本のアンビエント化" 環境というものは、決して読み手側が "超・便利！" になるだけではなかったのである。

　"デジタル" のコンテンツ制作にあって、"慣れ" や "習熟" が必要だという "言い草" はいささか抵抗感があるのは事実だ。
　"デジタル" の領域では、境界線がはっきりしているのであるから、それを見定めて処理方法を "法則化" するならば、誰がどんな時に実行しても同じ結果が出なくてはならないはずだからである。
　"慣れ" や "習熟" というものは、ケース・バイ・ケースで臨機応変に微妙な "匙(さじ)加減" をして事をなさなければならない領域でこそ着目される要素であろう。したがって、"デジタル" の領域ではこんな "言い草" はまさに禁物だと言っていいはずである。

　しかし、事、自身の現状での "ePub 電子書籍" 制作作業においては、"慣れ" や "習熟" が欠かせないのかなぁ......、というのが少なくとも実感なのである。
　恐らく、各々の処理方法が持つ意味を正確に掴んで "客観化・定式化" し切れていないがために、"曖昧な部分" を "慣れ" で補おうとしているのだろうとは思う......。
　ふと、いわゆる "職人技" というジャンルが思い起こされる。処理方法を可能な限り "客観化・定式化・数値化" することを原理とする機械生産とは異なり、"職人技" というものは、処理過程で "客観化" し難く、残されてしまった "曖昧な部分" を、そのまま "経験や勘" を含む "身体全体" で引き受けて対処しようとする方式だと言える。
　これはこれで、一種の合理性のある対処法だと言うべきで、決して "いい加減" だと蔑視してはならない。事態を "客観化" しようと目論み、分解し難いものまでを中途半端に分解してその気になって、結局は "似て非なる" 処理に落ち着くよりは、はるかに理に叶っていると思えるからである。

　Webのブラウジングなどでは、できるだけ再表示を早めようとして、既に内在するコンポーネントについては、再読み込みを迂回して既存のコンポーネントで用を足すということがある。いわゆる "キャッシュ" 機能と呼ばれるものだ。これは便利てある一方で、また迷惑でもある。
　iPad/iPod 向けで "eBook" の制作をしている時、しかも微妙な数値の変更をしなければならない "レイアウト" 調整をしている際などには、ちょっとした数値の修正更新をかけても、まったく表示に変化が生じない場合などあったりする。
　当初は、修正側の操作の問題かと思ってもいたが、何度も経験するうちに、どうもこれは "キャッシュ" 機能だろうという意を強めている。
　おまけに、ソース・ファイルが同じで若干ファイル名を変えただけのものは、同期そのものさえ拒絶する場合があるのには、いささか驚いている。重複のエントリーを回避しようとするスタンスなのだろうか......。

　ここしばらくは、いわゆる "横幅サイズ" 指定なしのアプローチを検証してきた。
　つまり、iPad/iPhone/iPod touchに向けて、"Sigil" などのエディタを使って "ePub 変換" をする際に、元データの "XHTML & CSS" での画面作りでは、あえて "画面の横幅サイズ" を "スルー" してしまうというアプローチのことである。
　この点の詳細は以下を参照。

◆ ＜iPad/iPhone/iPod touchに向けた[html→ePub]変換では"横幅サイズ"指定は不要？（当日誌 2010.12.23）＞

　"ePub 電子書籍" 制作者にとっては、とにかく各種タブレットなどの「デバイスにあわせたレイアウト」に腐心せざるを得ない。もちろん、デバイスの "表示可能幅サイズ" に対応した画面作りを、元データの "XHTML & CSS" 段階から組み込むのが "正攻法" だと言うべきであろう。
　だが、もし、タブレット側の "自動調整" 機能が活用できるのであれば、それを利用しない手はなさそうだ。
　現に、＜"Calibre" で仕上がった "ePub ファイル" は、概ね "iPad" や "iPod touch(iPhone 4)" で問題なく表示される。拡大も、"PDF ファイル" と同様に "ダブル・タップ" でＯＫだ！　再編集の余地が無いほどスマートに出来上がる。＞（＜"Calibre"作成の"ePub"("自炊"PDFからの作成)を"Sigil"で再編集する意味と方法（当日誌 2010.12.19）＞）という事実がある。
　"Calibre" が作り出す "ePub ファイル" には、"白紙"ページを発生させるなどの問題点がないわけではない。しかし、"画面の横幅サイズ" をスルーしていながら、概ね首尾よく事を運んでいるのもまた事実なのである。
　そうした事実から、このアプローチの可能性と限界について確かめたいと思ったわけである。

　今日、検索サイトで以下のような "投稿" を目にした。

＜calibre ではiPadでePub白紙が1ページ毎に.＞

　この現象とは異なるケースなのだが、自分も今、とある "白紙" ページの現象解明を調べているだけに、思わず目を向けたわけだった。
　この "投稿" の場合は、自分もかつて "iPod touch" で遭遇したケースのそれではないかと推測している。"Calibre" だというから、既存の "PDF" または "自炊 PDF" を "Calibre" で "ePub 変換" されたのではなかろうか。
　その文脈で発生する ＜1ページ毎＞の "白紙" ページという件については、一応、自分なりに解消して、以前の日誌で以下のように書いたことがある。

　振り返ると、何度も同じこと書いていることに気づく。そりゃあ、そうだろうと思う。毎日書いている上に、何度も同じ失敗もしているからそういうことにもなり得る。
　今日のテーマもこれに類する。以前に同じことを書いていた。

　＜時々、"Sigil" の ≪WYSIWYG≫を過信して進めた作業が、タブレット側のテスト表示では異なっていることが無いではない。おまけに、"ePub" の表示テスターとも言える "EPUBReader"、"Adobe Digital Editions" までが "ＯＫ" を出していて、タブレット側の表示だけが異常となる場合は困惑させられる。＞＜"ePubエディタSigil"や"EPUBReader(Firefox)"でＯＫでもiPadが納得しない場合も（当日誌 2010.12.12）＞

　さらに下記も同様の観点であろう。

　これまで、「デバイスにあわせたレイアウト」という問題にとらわれるあまり、コンテンツの "横幅サイズ" 指定にこだわり過ぎていたのかもしれない。
　だから、 "ePub" 向けコンテンツを、"XHTML & CSS" で作成する際、タブレット側の "表示可能幅" を意識して、 "width" というタグを "重視" して "横幅サイズ" 指定を行ってきた。決して間違いではないのだが、とにかく煩わしいことも間違いない。
　この辺については先日にも書いたばかりだ。

◆ ＜"Sigil"に適合した"XHTML&CSS"/"横幅サイズ"を指定した"サンプル"Webスクリプト（当日誌 2010.12.18）＞
◆ ＜"iPad"と"iPhone4/iPod touch"の両サイズ向けにePub電子書籍制作を進める技法！（当日誌 2010.12.14）＞

　しかし、こだわらなくて済ませる "イージーな作法" もあるという点に気づかされた。　調整のすべてを、タブレット側の "自動調整" に任せてしまうという "作法" なのである。

　 "iTunes" で、アプリ "iBooks" の更新通知があったのですぐにインストールをしてみた。さして目新しい点があるようにも見えなかったが、目を凝らしてみると、これまでの "本棚" 、つまり最上段のメニューバーに＜ブック＞、＜PDF＞と二分類されていたボタンが消えている。その代わりに左側に＜コレクション＞という見慣れないボタンが添えられていた。
　これをクリックすると、＜ブック＞、＜PDF＞と従来どおりに分類された二段が表れる。どうもこれらが、 "従来の本棚" への入り口のようであった。とともに、これら以外にも "別の本棚" が作れそうなニュアンスが確実に伝わってきた。

＜ "iBooks" の新しい "本棚" ＞

◆ブック/PDF本棚に、自分の "コレクション" 向け本棚を追加できる！

　"ePub 変換" をいろいろと進めていると、ふと、かつて "一太郎 ver.4" などで作成した "化石" 的(?)な文書ファイル類のことが思い起こされた。
　当時、かなり根を詰めてキーを叩いて作り込んだ、自分にとっては相応に貴重なファイル類だったからかもしれない。
　そして、これらを再活用できるファイル、できれば "ePub 変換" へと持ち込みたいものだと思ったのであった。
　これは、ちょうど、気になる "蔵書" 類を "自炊 PDF" にしたり、さらに "ePub 変換" しようとする動機と似ている。放置しておけば見捨てることになりかねないと思えたわけだ。

　しかし、"一太郎 ver.4" ファイルは、拡張子が ".jsw" であり、"MS-Word" で読み込み、再編集するのも一苦労......。おまけに、やたら "一太郎の罫線" を駆使して "表組み" 形式で作ったファイルが多かったので苦労もひとしお......。
　が、とにかく "MS Word 2007" の土俵に乗せるまでは何とかなった。しかし、やはり "一太郎の罫線" を復元することは叶わず、罫線を模したぶつ切りの "記号文字" で置き換えられる始末だった。また、"表組み" 形式に近いものを望むと、"Windows メタファイル" を選ばざるを得ず、これは "図(画像)" となってしまいテキストが消失するので選択できなかった。
　そこで、テキスト部分のみを活かし、"表組み" 構造については新たに "MS-Word" 上で作り直すことに決めた。

　"ePub editor = Sigil" のひとつの "売り" は、表紙や挿絵などとして "画像" が挿入できることであろう。また、画像挿入機能と表裏一体となって "改ページ" を "Chapter Break" 機能で実行することも特徴となっている。
　これらは、活用しない手はないほどに非常に貴重な機能なのだが、慣れがないと上手く運ばないこともあり得る。中には何度試みても失敗してしまう場合もありそうだ。自分も、慣れないうちは、しばしば失敗したものである。
　各所で解説されている手順を、"コード" ベースで吟味してみて、ようやく手順のひとつひとつの意味がのみ込めたものである。
　そこで、自己確認を含めて、下記のように "図解" 表示をしてみた。"Sigil" の重要な機能であるだけに、ジックリとのみ込んで大いに活用すべきかと思う。

　"ePub editor = Sigil"との付き合い方、＜(2) スクリプトの修正・改造をどう適切に進めるか。＞を継続させている。
　今回は、出来上がった "ePub 電子書籍" を入力データとして読み込み、これを再編集するといったアプローチを想定してみる。
　出来上がった "ePub 電子書籍" といった場合、すぐに思い起こせるのは、"自炊" PDFを "Calibre" で "ePub 変換" したものであろう。 "Calibre" は "PDF ファイル" を簡単に "ePub" ファイルに変換する。
　 "Calibre" に関しては、以前に書いた分を参照していただきたい。

◆ (1) ＜"PDF ⇒ ePub" 変換ソフト"Calibre"の優秀さと､"ePub"仕様に対する理解度不足!?（当日誌 2010.08.13）＞
◆ (2) ＜"Calibre"も､"Word 文書"を"ePub変換"する!/但し"OpenOffice"で".odt"に変換後! （当日誌 2010.11.25）＞

　 "Calibre" で仕上がった "ePub ファイル" は、概ね "iPad" や "iPod touch(iPhone 4)" で問題なく表示される。拡大も、 "PDF ファイル" と同様に "ダブル・タップ" でＯＫだ！　再編集の余地が無いほどスマートに出来上がる。
　但し、何の問題もない、というわけには行かない。"iPod touch" では以下のような不具合が生じる。

　"Sigil" での "ePub 変換" を上手に実行するには、何の下準備もない "丸腰" で臨むのではなく、できれば "XHTML & CSS" で書かれた "Webスクリプト" を用意したいものだ。今日も、昨日に引き続き＜(2) スクリプトの修正・改造をどう適切に進めるか。＞について書こうとしている。

　もちろん、何も "おみやげ" が無くても "Sigil" はもてなしてはくれる。
　＜Book View＞モードにテキストの "直接入力" をするならば、＜Cord View＞モードの画面の方に "Webスクリプト" が "自動作成" されるからだ。この "Webスクリプト" に少しづつ手を加えながらいわば "積み上げ" 方式でお望みの "Webスクリプト" を完成させるという方法もアリには違いなかろう。
　だが、まともなのは "改行" だけで、ほかにスタイル("CSS")は何も設定されていない文章表示というのは、"ページ・レイアウト" とは呼べないだろう。もちろん「デバイスにあわせたレイアウト」には程遠い状態に留まっている。
　そこで少なくとも注目せざるを得ないのが、"Webスクリプト" に、文章などのコンテンツ表示の "横幅サイズ" なのである。これが設定できると、"ページ・レイアウト" を手堅く決めていくことがかのうだ。だが、この指定こそは、"CSS" ( "Sigil" では、＜Styles＞フォルダに格納される)の守備範囲にあり、前記のような "直接入力" では "CSS" ファイルは自動生成されようがないわけだ。
　そこで、"CSS" ファイルを外から "移植" しようというのである。

　世の中では、"代行" 屋が大流行りである。"代行" 屋は、"ユーザの意向" に沿って恙無(つつがな)く結果を出すことが使命だ。過不足なく対応するのがプロなのであろう。水準が下回る結果だと手抜きだと言われかねない。また逆に、やり過ぎると、「余計なことをした！　そこまで頼んだ覚えはない」と非難されかねない。その辺のさじ加減が難しいのだろう。
　ソフトでも同じことかもしれない。"ユーザの意向" さえ決まれば、その達成方法がほぼ均一であるケースでは、ソフト側が自動処理で結果を導き出す方式のことである。
　"見た目" の簡単なスタイルとこれを数式やコードで置き換えるというジャンルでは、この方式は採用され易い。"WYSIWYG" 方式のソフトはここに立脚していると言える。

　"Sigil" はまさに "WYSIWYG" 方式のソフトである。＜Cord View＞モードにおいてスクリプト・コードが書かれれば、即座に＜Book View＞モードにおいて結果としての表示画面を再表示する。
　また、その逆も同じ理屈で実行される。つまり、＜Book View＞モードにおいて「これは、こういうスタイルで......」と手を加えると、その結果、＜Cord View＞モードにおけるスクリプト・コードが自動的に書き込まれるわけだ。

　"ePub editor=Sigil" との "自分なりの付き合い方" について書いている。そんなものがあるのかどうかは知らないが、もし "オーソドックス" な付き合い方に関心をお持ちの方は、次のサイトを参照してください。

◆ ＜グーグル翻訳による「Sigil 基本的なチュートリアル」＞

　自分の場合、ゼロスタートで一から "Sigil" に頼りながら "ePub 電子書籍" を作るというアプローチはとっていない。
　大抵は、自分なりの "Web ページ"("XHTML & CSS")を用意して、これを "Sigil" で読み込み、修正・改造しながら "ePub 変換" をするといったアプローチをとる。
　その理由は以下のとおりなのである。

　"ePub editor" である "Sigil" と付き合い続けていると、これを単に "ePub 変換ツール" だと見なすのはかなり "見くびった見方" だと思えてくる。
　確かに、"ePub editor = Sigil" は、 "Web ページ(HTML ファイル)" や "一般文章(Text ファイル)" を簡単に "ePub" ファイルへと変換してくれる。
　しかし、それだけしかできないのであれば、他の "ePub 変換" ソフト、たとえば "Calibre" であっても一向に差し支えなかろう。
　"Sigil" は "ePub 変換" ソフトであるばかりか、"ePub editor" でもある点が有難いわけであり、評価すべきポイントなのであろう。

　つまり、"Sigil" は "ePub" ファイルを読み込んだら、この圧縮ファイルを "解凍" した上で、 "構成要素" 別に仕分けながら、"再構築＝再編集" 可能な状態を作り出してくれるのである。ここが有難いのである。
　もし、こうした "Sigil" を使わずに既存の "ePub" ファイルを修正したり、改造したりといった "再構築＝再編集" をしようとするならば、次のようになろう。
　先ず、"ePub" ファイルという圧縮ファイルを "解凍" して、"XHTML ファイル(プラス CSS)" を抽出し、これらをテキスト・エディタで再編集し、それが終わったらその結果を他の付随するファイル類と一緒に "再圧縮" をかけ、 "zip" という拡張子を "epub" という拡張子に書き換える......、といった、まさに "まどろっこしい作業" をしなければならないのである。しかも、再編集過程では、逐一、ブラウザを起動してチェックするという手間もかかるわけだ。

　タブレットのサイズにかかわりなくコンテンツサイズが自動調整される "PDF 電子書籍" とは違って、"ePub 電子書籍" の場合には、作り手はサイズの異なるタブレットそれぞれに向けてコンテンツを "再編集" しなければならない。ここでも、あの「デバイスにあわせたレイアウト」という課題が浮上するのである。
　自分の場合、とりあえず現在、"iPad" と "iPhone4/iPod touch" とを当面のターゲット・タブレットとしている。したがって、コンテンツはひとつ作れば間に合う、というイージーなわけには行かない。それぞれのサイズに向けた再編集が必要と覚悟している。
　さらに、"iPad" の場合には、"縦長" の "単一ページ" 表示と、"横長" の "二ページ見開き" 表示とが随時併用される構造のため、さらにそれを見越した調整までしておかなければならない。
　ページ・レイアウトに無頓着な読み手に向けてならば、とにかく読めることは読めるわけだから良さそうな気がしないではない。しかし、そんな読み手ばかりではないわけで、まさに「デバイスにあわせたレイアウト」に関して、最大限、神経を使った方が無難だということになろう。
　では、幾とおりものコンテンツを逐一用意しなければならないのだろうか。"Web スクリプト" も、書き方次第では大混乱を来すことにもなりかねない。自分も、以前には、かなりの混乱を招いていた覚えがある。
　ただ、バカではないから(もちろん利口でもないが)、今ではできるだけ手の掛からない方法に辿り着いている。"XHTML & CSS" アプローチをフル活用する方法の事である。
　以前、次のように書いたことがある。

　昨日から持ち越していた "ePub 電子書籍" 編集での "悩ましい" 表示不具合問題複数個を、なんとかすべて解消することができた。
　但し、ＰＣと "iPad" との間で同期(転送)をとった回数はかなりの数にのぼった。ネバリのスタンスがなければ叶わない作業であった。
　今回の不具合が手ごわかったのは、昨日も書いたように、さまざまな "WYSIWYG" 方式の開発・編集ツールが何ら問題視せずに表示したにもかかわらず、いざ "iPad" へ転送してみると、意に沿わない表示結果を返してくる点なのであった。
　もうこうなってくると、いかにして "iPad" の御機嫌伺い(?)をするか、というような卑屈な姿勢にさえなってしまうものだ。

　"ePub 電子書籍" 制作で、最終工程で "悩ましい" 課題と言えば、やはり「デバイスにあわせたレイアウト」という点のようだ。つくづくとそう思う。
　もっばら、"ePub エディタ Sigil" を活用しながらの制作なのだが、基本的なレイアウトや、基本事項に関しては "Sigil" が頼もしい "助っ人" となってくれている。
　ただし、時々、"Sigil" の ＜WYSIWYG＞を過信して進めた作業が、タブレット側のテスト表示では異なっていることが無いではない。おまけに、"ePub" の表示テスターとも言える "EPUBReader"、"Adobe Digital Editions" までが "ＯＫ" を出していて、タブレット側の表示だけが異常となる場合は困惑させられる。
　以前にも以下のように書いたことがある。

　日本語 "縦書き" 表示が "鮮やか" なのに魅了されて、ついつい "青空文庫形式" による、"i文庫HD"(for iPad)や "SkyBook"(for iPhone)向け "Text 電子書籍" の話題に前のめりとなってしまった。
　"是非とも" 日本語 "縦書き" 表示を！　との依頼を受けた場合には、こうした "Text 電子書籍" の方式で応じるのが最も妥当ではないかとの確信を深めた。ただ、それが貴重な選択肢であることを一応確認できれば、とりあえず "Text 電子書籍" の話題はそろそろ "通過" しても良さそうな気がしている......。
　"ChainLP" による "縦書きテキスト画像化" という "ePub 変換" も、場合によっては採用しなければならないケースも無いとは言えない。だが、テキスト本来の属性(検索やフォントサイズ変更など)が保持されたままで "縦書きテキスト" ファイルを "電子化" するとなると、やはりこの "青空文庫形式" 関連の "Text 電子書籍" か、あるいはより大きな汎用性を踏まえて "PDF 電子書籍" (→ ※ 注.1)ということになるのであろう。

　※ 注.1 "PDF 縦書き表示電子書籍" の制作については下記を参照。
　◆ ＜"Word"を使った"Text文書のPDF変換"/メリットは①縦書き可②ページ単位編集可！（当日誌 2010.09.28）＞
　◆ ＜"縦書き指定"の"Word"×"印刷"操作からの"PDF変換"法⇒"縦書き"の"PDF電子書籍"（当日誌 2010.09.29）＞

　"青空文庫形式" での "eBook制作" 実習(?)に勤(いそ)しんでいるとちょっとしたことに興味が向いたりする。取りあえず、"SkyBook"(for iPhone)を例にして、バカバカしいかもしれないが、こんな実習(楽しみ方)もあるという話である。

　その一つが、御本家の "青空文庫" のダウンロード書籍に、① 自分なりの気に入った "表紙画像" を付け足してみたり、② フィットするような "挿絵画像" を挿入してみたり、さらには、③ 読書感想のテキストを末尾に加えるというようなこと......。
　要するに、"青空文庫" の御歴々の作家の作品を "自分ライク" にカスタマイズしちゃおうという "物好き" なのである。こうした "物好き" とも見えるアクションがそこそこシャドウ・トレーニングになるのだと思われる(?)。
　老婆心ながら言えば、もちろん、これらは "商用" に馴染むわけがなく、あくまでプライベート空間での読書という範疇でのことでしかないが。

　"青空文庫形式" による、"i文庫HD"(for iPad)や "SkyBook"(for iPhone)向けの"画像"挿入方法の基本は、以前にも書いたように下記のとおりとなる。

＜　★"SkyBook" 向け――［＃挿絵（For_iPod_cover_kainen.jpg）］
　　★"i文庫HD" 向け―― <IMG SRC="For_iPad_cover_kainen.jpg">
　　※ 注記やタグを、画像を挿入したいその箇所に書き込む。なお、画像ファイルは "jpeg" か "png" に限られている点に注意。＞(参照：＜"i文庫HD"(for iPad)/"SkyBook"(for iPhone)向けに"青空文庫形式"でeBook制作！（当日誌 2010.12.07）＞)

これらの基本に加えて注意が必要な点を補足しておきたい。

　"i文庫HD" (for iPad) や "SkyBook" (for iPhone) 向けに "青空文庫形式"という "注記(表記)" を調べながら、 "電子書籍(eBook)" 制作(の学習)をしている。
　何がどうなっているのかがわからない時は、"ややこしいルール(?)" があるんだなぁ、くらいにしか受けとめていなかった。
　だが、昨日も書いたように、実際、"i文庫HD" (for iPad) や "SkyBook" (for iPhone) 向けの自作 "Text" 文書作りで体験し、まさに "プログラミング" 的に正確に反映されて実行されることを実感すると、にわかに興味が湧いてくる。
　今日も、せっせと自作 "Text" 文書の "ルビ" 振り作業を楽しみながらやっていたところである。

　とりあえず自分が素材としている自作 "Text" 文書は、"ePub" や "PDF" の "電子書籍" 制作で使ってきた自作小説『海念と保兵衛』( "タイムトラベル"× "時代物" )なのである。と言うこともあり、"時代物" なので、やたらに "漢字" が多用されているわけだ。これじゃあ、読み手に敬遠されてもしょうがないかなぁ......、と感じ続けてきた。
　そんな事情もあって、"青空文庫形式"の "注記(表記)" では、"ルビ" 表記にことさら関心が向いたりするのである。
　そうでなくとも、"縦書き" 仕様の "電子書籍" にこだわってきた自分であり、その "縦書き" 仕様の典型的作法でもありそうな "ルビ" 振り表記が、何となく "眩しく" 目に映えたりもするのである。
　と言うか、"ルビ" 振り表記が伴うことで、"縦書き" の良さが一段と輝くかに見えたりするのである。美しい日本語と共にあることに、何故だか安堵感めいたものを覚えたり......。
　日本語に馴染んできた者としては、"電子書籍" 制作のひとつのターゲットは、日本語が活き活きと表現された、そんな "電子書籍" を作ることなのかなぁ、なぞと思ったりもしている。

　"青空文庫形式" については、昨日レポートしたとおりほぼ理解できたかに思え、忘れないうちにと、早速、"i文庫HD" (for iPad)向けと "SkyBook" (for iPhone)向けに自作 "電子書籍(eBook)" のかたちを作ってみることにした。
　これまで、自作 "Text" 文書を "SkyBook" や"i文庫HD" へと取りあえず転送し、無難に表示させるところまでは確認済みではあった。
　転送の方法は、"SkyBook" については、フリーソフトの "i-FunBox" ( 参照：＜"iPhone/iPod touch"での"ポケット文庫 SkyBook"で､"自前のテキスト文書"を読む（当日誌 2010.07.31）＞ )を使い、また "i文庫HD" については、"iTunes" の "App" における "ファイル共有" の機能 ( 参照：＜USB転送／i文庫HD／ベンダーサイト＞ ) を使い、どちらも何の問題もなく転送できてしまう。
　むしろ問題であったのは、これらのブックリーダー・アプリが "準拠" する "青空文庫形式" というものが今ひとつ活用できなかったために、コンテンツ側のレイアウトなどに "不本意な箇所" を残し続けていたのであった。

　主な "不本意な箇所" を列記すると以下のようであった。
　① "画像表示" ができない点。――――――――→ 表紙画像、挿絵を入れたい！
　② "改ページ" が適切にできない点。―――――→ 章・節の "頭出し" ができない！
　③ "ルビ" 表示ができない点。――――――――→ 青空文庫のような "ルビ" を付したい！
　④ "二桁の半角数字" が正立表示されない点。―→ 半角数字の "横倒し" が不快！

　"電子書籍"制作 に関心を持つ者ならば、何かと気になるのが "青空文庫" であり、その書式の "形式" がどうなっているのだろうか？　という点でもあろう。
　先日も、"i文庫HD(iPad専用App)" について書いた際、下記のように "青空文庫形式" が "意味ありげ" に言及されていたわけだ。

＜　このアプリで "青空文庫" を読むという一般的、ありきたりな利用法についてはおくとして、関心を向けたのは、次の点であった。

≪あなたが作ったファイルも i文庫HDで
あなたが書いた文章なども簡単に i 文 庫 H D で読むことができます。
テキストファイルや画像ファイルを、まるで出版された本のように楽しんで下さい。≫(カスタマイズ自在／i文庫HD／ベンダーサイト)
≪txtファイル
txtファイルはShift-JISまたはUTF8形式で、改行はCR+LFとなります。
txtファイル内の装飾形式は、青空文庫準拠の形式となります。
青空文庫形式についての詳細は青空文庫のページを参照して下さい。
拡張形式として、以下の形式をサポートします。
<PBR> 改ページ
<IMG SRC="xxx.jpg"> 挿絵、同zip内の画像ファイルを挿絵として表示します。≫(同上サイト)＞(＜"i文庫HD(iPad専用App)"で､"自炊PDF電子書籍"や"自作Textファイル"を読んでみる（当日誌 2010.12.01）＞)

　そこでこの間、"青空文庫形式" について調べにかかっていたのだったが、適当なサイトが見つからずあぐねていた。
　が、漸く、これだこれだ！　というサイト、＜青空文庫 組版案内 テキスト版のまとめ方、XHTML版への変換法＞)に遭遇できた。そして何となく "青空文庫形式" の相貌が掴めそうな感触を得た。

　自作の "Text" 文書を "縦書き" 表示させたいという意向にどうもこだわり続けてきたようだ。そうした文脈もあってか、"ChainLP" による "縦書きテキスト画像化" という "ePub 変換" にも、再び目を向けて吟味したりしたわけであった。
　だが、やはり "Text" 文書は、たとえ "縦書き" 表示の条件が叶えられたとしても、"Text" の属性が失われることになる "画像化" に向かうのはいかがなものか？　という思いが沸々と湧いてくるのも事実なのである。それが、"ePub" 化されるというメリットがあったとしても同じことのように思われる......。

　そうだとすれば、"ePub" ではもちろんないが、その "使い勝手の良さ" を評価して "i文庫HD(iPad専用App)" を使ってみるのも、大いにありかと考え直したりしている。

　"ChainLP" で、"Text" 文書を "縦書きText画像"(jpeg 連番方式)へと "ePub 変換" する機能に関して、思いつくままの試行錯誤をしている。
　フリーソフトだから致し方ないが、マニュアルがないために、専ら、直観的な試行錯誤をするしかないわけなのだ。
　"ChainLP" が出力する "ePub" ファイルは、何度も書くように "jpeg 連番方式" の "画像 ePub" であるため、"Text" の検索やフォント変更などに強い関心がある自分としては、第二義的な位置づけをしている。
　ただ、 "縦書き ePub" というものに見通しがない（と思っている）以上、"画像 ePub" ではあっても "縦書き" 風に表示するそんな方法も視野に入れておきたいと......。
　また、自作の "Text" 文書から、"ePub 電子書籍" に仕上がっていく作業工程で、もし自由度のあるレイアウト設定などが可能となっているのであれば、相応に使えるものかもしれないと見ているわけでもある。

　"電子書籍" 制作のプロセスで、 "章や節" などの "頭出し" 表示を叶えるために、"改ページ" という技法が結構重要である点を昨日は書いた。
　今日も、その文脈での話となる。
　ところで、"改ページ" という技法に注目する時点というのは、作業工程で言えば、変換ソフトツールによって "ePub 変換" を行う前の "Text" 素材ベースの段階だということになる。これは "Word 文書" を素材とする場合でも同じことであり、"PDF" なり "ePub" なりへと変換する前の素材ベースの段階で、"改ページ" 技法を処理しておくことになるわけだ。幸い、"Word" には "ページ区切り" という機能も備わっている。
　もっとも、昨日も書いたように、"Sigil" の "Chapter Break" 機能のように、"ePub 変換" のためのエディティング中に設定処理をする場合もある。
　が、一般的には、"Text" 素材ベースの段階で、"Text" エディタが備えた "改ページ" 機能を使って "Text" 素材に "その機能" を書き込むことになるはずであろう。

　"Web ページ" と "電子書籍" の差異はいくつもあろうが、"Web ページ" が縦方向にいわば "エンドレス" で表示されるのに対して、"電子書籍" は各ページが限られたスペースで構成されていることから、"改ページ" がなされるという点にも注目したい。
　この点は、"ePub"、"PDF"、"Text" というフォーマットの違いがあっても "電子書籍" に共通して指摘できる点であろう。

　余談めいて言えば、この点は結構おもしろいことだと感じている。"電子書籍" なぞと "大見得" (?)を切っていながら、"紙の書籍" の当たり前の制約をそのまま継承しているからである。
　だが、考えてみると、"紙の書籍" の "ページ" という区切りは決して悪くはないと思っている。その "ページ" の区切りというものが、読み手に "安堵感" (?)めいた気分や、気分そのものの区切りなどを適時与えているかのようだからである。
　妙な譬えとなるが、もし人生の一生が、昼夜で区切られた日々で構成されておらず、エンドレス的な長い一日で構成されていたならば、どんなにか耐えがたいことか......、とバカなことを考えたりする。と、"ページ" で構成される "書籍" というものは、"日々" の連なりで構成される人生と似ているのかなぁ、と思ったりするのである。

　今や、"電子書籍" 読書では "めくり感覚" (めくりアニメーション)機能付きのブックリーダーが当たり前のようになった。別に、この機能がないと読書としての雰囲気・臨場感がないというほどのものではないにしても、この機能に慣れてしまうと、無いとやや物足りなくなるのも事実であろうか。
　となると、"電子書籍" は "ePub " ファイル形式でないとマズイということになるのであろうか。今のところ、"めくり感覚" 機能付きで人気を集めているのが、"iBooks" の "本棚／ブック" であり、そこに収めるためには "ePub " ファイル形式でなければならないからだ。
　"PDF 電子書籍" ("Text ファイル" の場合も)の場合には、"iBooks" にせよ、"GoodReader" にせよ、ページ移動は "スライド" 型移動となっている。
　ただし、"Text ファイル" のままでこの機能を発揮している App もあるにはある。あの "青空文庫" をターゲットとした "SkyBook" がそれである。
　また、"SkyBook" では、"自作Textファイル" をも転送して、既成の書籍と同じスタイルで読むことも可能となっている。
　"自作Textファイル" をブックリーダーで読むことが可能という点については、一目置いてよい点なのかもしれない。何も "めくり感覚" 機能の有無にかかわらず、頻繁に使う "自作 Textファイル" がブックリーダーで扱えることの意義は小さくないからだ。
　以前の当日誌での以下を参照。