ここしばらくは、いわゆる "横幅サイズ" 指定なしのアプローチを検証してきた。
つまり、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 ファイル" には、"白紙"ページを発生させるなどの問題点がないわけではない。しかし、"画面の横幅サイズ" をスルーしていながら、概ね首尾よく事を運んでいるのもまた事実なのである。
そうした事実から、このアプローチの可能性と限界について確かめたいと思ったわけである。
ところで、ここ二、三日取り掛かっていた＜複数の各章一ページ目だけが表示されて、その後は "白紙" という珍現象＞の問題は、どうやら原因が掴めた感触である。スッキリとしない点を残してはいるものの、主な原因は、 "二つ" あったかのようだ。
一つ目は、"画面の横幅サイズ" ばかりに気を取られていて、"高さ(height)" の指定を軽んじていた点であった。すべての "要素" 範囲に関しての "幅(width)" 指定は "スルー" させたものの、ある "要素" 範囲の高さ指定を一か所だけ残したままの状態だったのである。
この点だけであれば支障はなかったのかもしれないが、ここに "画像" が収められていたのである。ここから、スペースの "高さ(height)" において "オーバーフロー" が生じてしまったかのようで、ここから "白紙" ページの連鎖が生まれたのではないかと推測している。 "hedding" については、副次的な問題だったようだ......。
現に、残っていた、 "要素" 範囲に関する "高さ(height)" 指定を取り払ったところ、 "珍現象" が取り除かれたのだった。
ここで、目を向けたのは、不用意に "高さ(height)" 指定を残したこと、それと同時に、とかく "挿入画像" の元サイズによっては、上手く "自動調整" されない場合がありそうだという点なのである。これが、二つ目の点なのである。これについては、画面や要素のサイズ指定を "スルー" するアプローチではあっても、注意深く調整する必要がありそうだ。
今のところ、 "幅(width)" 指定 "スルー" のアプローチの留意点としては、(1) "高さ(height)" についても "スルー" してしまうことと、(2) "挿入画像" については、"元データ" のサイズに注意深く配慮すること、などが挙げられそうな感触か......。
とにかく、"実際にやってみなければ判明しない" ことが次から次へと立ち現われてくるような実情であり、骨が折れる......。と同時に、まるでパズルを解くような手応えもあるにはあるが...... (2010.12.26）
コメントする