これまで、「デバイスにあわせたレイアウト」という問題にとらわれるあまり、コンテンツの "横幅サイズ" 指定にこだわり過ぎていたのかもしれない。
だから、 "ePub" 向けコンテンツを、"XHTML & CSS" で作成する際、タブレット側の "表示可能幅" を意識して、 "width" というタグを "重視" して "横幅サイズ" 指定を行ってきた。決して間違いではないのだが、とにかく煩わしいことも間違いない。
この辺については先日にも書いたばかりだ。
◆ ＜"Sigil"に適合した"XHTML&CSS"/"横幅サイズ"を指定した"サンプル"Webスクリプト（当日誌 2010.12.18）＞
◆ ＜"iPad"と"iPhone4/iPod touch"の両サイズ向けにePub電子書籍制作を進める技法！（当日誌 2010.12.14）＞
しかし、こだわらなくて済ませる "イージーな作法" もあるという点に気づかされた。 調整のすべてを、タブレット側の "自動調整" に任せてしまうという "作法" なのである。
これは何も、テキスト画面で文字が順次 "先送り" されると言った調整だけのことではない。画像や "table" に関しても "表示幅" が "自動調整" されるのである。
そのためには、"XHTML & CSS" で書くコードから一切の "width" というタグを一掃してしまわなくてはならにない。
上記の＜"Sigil"に適合した"XHTML&CSS"/"横幅サイズ"を指定した"サンプル"Webスクリプト（当日誌 2010.12.18）＞で書いたような、画面全体の "横幅サイズ" 指定である＜width: 547px;＞などは、あえて書き込まないし、他の "要素" にしても、＜width: ** %;＞と比率指定で "逃げる" のである。
すると、レイアウトにおける "横幅サイズ" 問題は少なくとも解消されてしまう。つまり、"iPad" の画面表示幅を想定して制作したコンテンツであっても、 "iPod touch" で "一応" 無難に表示される。横にはみ出して "欠ける" という無様さはなくなる。
ただし、 "縦方向" については別問題が残るが、これはしょうがない。"フォント拡大" をした時に発生するような、あの "尻切れトンボ" となるわけだ。まあ、これは "フォント拡大" をすればしばしば発生する問題なので、目をつぶれる範囲の問題なのかもしれないが......。
この "作法" だけで、「デバイスにあわせたレイアウト」という問題のすべてに対処するには多少の無理がありそうな気もする。しかし、"iPad" における "縦の単一ページ" 表示と "横の見開きページ" 表示との間の "齟齬(そご)" は解消されているなど、"使えそう" な感触もあると思えた。そして何よりも、タブレットの数だけのコンテンツを用意しなくても済む......、というラクさがメリットであるに違いない...... (2010.12.23）
コメントする