Wkhtmltopdfで指定サイズより小さく出力されるときの対処法
HTMLをPDFに変換してくれるオープンソースライブラリWkhtmltopdfがある。オープンソースな上にクロスプラットフォームという優れもののライブラリだ。ただ、これによって出力されたPDFで、フォントサイズやボックスサイズなどが指定より小さく出力されることがある。大凡、指定の90パーセント程度に縮小されるのである。A4判程度ならこの差はなかなか気が付かないが、A0といった大判出力では相当の絶対誤差となって出てくる。今回はそれの対処法について書こう。
原因はwebkitのレンダリング
Wkhtmltopdfはレンダリングエンジンwebkitを使っているが、このwebkitにはpixel/inch ratioを自動調整する機能がある。元々は種々のデバイス解像度に対応するためのものらしいが、これが悪さをするらしい。通常のCSSでは96［pixel/inch］であるが、この値を前提に厳密な位置指定をして居る状態でpixel/inchを弄られると当然おかしな出力になる。
オプションで回避。
上記の事態を避けるためには、PDF出力時に--disable-smart-shrinkingオプションを付ければよい。このオプションは公式では次の様に説明されて居る。
Disable the intelligent shrinking strategy used by WebKit that makes the pixel/dpi ratio none constant
さて、下記の様にオプションを付けると大体意図通りの大きさで出力された。
$ wkhtmktopdf --disable-smart-shrinking input output
最初はCSSの記述ミスかと思って居たが、調べてみたらライブラリのお節介な調節機能の所為だったという落ち。
属性の併記時におけるCSSのnth-of-typeの挙動
CSSのセレクタとしてnth-of-typeがある。指定した番目の要素に対してCSSを適用できる便利なものである。別段難しいセレクタではない様に見えるが、属性が併記されたときに案外勘違いしやすい挙動になって居るので、今回はそれについて書きたい。
nth-of-typeの挙動の確認
最初にCSSの入門サイトでよく見られる様な記述でnth-of-typeの挙動を確認する。
<style type="text/css"> li:nth-of-type(2) { color : red; } </style> <ul> <li>ネオサイタマ炎上</p> <li>キルゾーン・スモトリ</p> <li>キョート殺伐都市</p> </ul>
これをブラウザで表示すると下記の様になる。予想通り「キルゾーン・スモトリ」の文字が赤くなった。
属性が併記されたとき
それでは次の場合はどうだろう。先程と違ってクラス名にtitleを指定した。
<style type="text/css"> li.title:nth-of-type(2) { color : red; } </style> <ul> <li>ネオサイタマ炎上</p> <li class="title">キルゾーン・スモトリ</p> <li class="title">キョート殺伐都市</p> </ul>
これをブラウザで表示するとどの様に表示されるだろうか？――結果としては以下の様になる。先程と全く同じであり「キョート殺伐都市」の文字は決して赤くならない。
仕様通りの挙動！
これは決してバグではなく書いた通りの動きである。nth-of-typeの仕様を理解して居ないと勘違いしやすいのだが、属性が併記されたときnth-of-typeは次の手順を取る。一例として、element_name.class:nth-of-type(n)とあった場合、
- classやidが指定されて居ても、最初はelement_name:nth-of-type(n)として動作する。
- element_name:nth-of-type(n)にそのclassやidが指定されて居たら、そのCSSが適用される。
つまり、上述の例で説明すると先の記述は「2番目のli.titleに対するCSS」を意味するのではなく、「2番目のliで、かつtitleクラスが指定されたときに対するCSS」を意味するのである。
他サイトを見るとnth-of-typeの例はどれも要素名だけの場合で解説して居ることが多いが、属性も併記された場合など少し複雑な事例に対する説明は見かけない様な気がする。何れにせよ、CSSも思った通りに動くのではなく、書いた通りに動くことに変りはない。
InDesignの「保存」と「別名で保存」の差
InDesignの「保存」と「別名で保存」とでは、その挙動に相違があることを、自分がちゃんと把握して居なかっただけの話。InDesignのドキュメント編集で、大容量の画像を削除して保存してもファイルサイズが大きいままなので、バグか何かでデータが残ったままでは？と首を傾げて居たが、これはInDesignの仕様通りの挙動であった。
「保存」では不要情報は削除されない
InDesignの保存では、不要な情報は削除されない仕様である。つまり仮に大容量の画像データを削除したとしても内部的に保持されるわけだ。これは保存処理を高速に実行させるためであるが、その代償としてファイルサイズは減らない。
「別名で保存」は新規ファイルの作り直し
「別名で保存」を実行すれば、内部的に保持されたままの不要な情報が削除された上で保存されるから、ファイルサイズは小さくなる。当然、不要情報を削除して保存するので保存処理に多少の時間を要することになる。
公式の言及について
InDesign CS6の公式ヘルプページでは、上記の仕様についてははっきりと明言して居ない。
新しい名前でドキュメントを保存するには、ファイル／別名で保存を選択して、ファイルの保存場所と名前を指定し、「保存」をクリックします。新しく名前を付けたファイルが、アクティブなドキュメントになります。「別名で保存」コマンドを使用すると、ファイルサイズを縮小できることがあります。
しかしながら、InDesign 1.0Jのサポートページでは上記の仕様について、はっきりと言及して居る。
E.[別名保存]コマンドを使用してファイルを保存します。
[別名保存]コマンドを使うと、不要なデータを文書から消去できます。必要なデータだけの文書は、ファイルサイズが小さく、再描画やプリントを高速に行えます。
[別名保存]コマンドを使うと、文書が完全に作り直され、現在の文書に含まれているオブジェクトとページについての情報だけが保存されます。これに対して[保存]コマンドでは、文書に新しい情報が追加され、削除されたグラフィックについての情報などの古いデータは削除されません。
InDesign 1.0J (Mac)：パフォーマンスの最適化
この仕様による挙動はInDesign CS6などの新しいバージョンでも確認できる。大規模な改変を繰り返してドキュメントサイズが肥大化したら、「別名で保存」を適宜実施。
SHIROBAKOはヒーローズ・ジャーニー
先日の投稿（物語論から「艦これアニメ」を見る - 無銘書房）で「艦これアニメ」を物語論の観点から解釈しましたが、今回はアニメ業界を題材にしたアニメ作品「SHIROBAKO」を取り上げます。所謂「業界もの」に分類される本作ですが、このSHIROBAKOはヒーローズ・ジャーニーに忠実に従って居ることに気が付きました。前の題材がヒーローズ・ジャーニーを大分逸脱したものでしたから、その比較も兼ねてSHIROBAKOを物語論の観点から見ていきます。
ヒーローズ・ジャーニー
最初にSHIROBAKOのストーリーとヒーローズ・ジャーニーとの対応を示します。
| 話数 | ヒーローズ・ジャーニー | 概要 |
|---|---|---|
| 1 | 日常 | 高校時代 |
| 2～3 | 賢者との出会い、第一関門突破 | 第四話の納品危機 |
| 4～12 | テスト／仲間 | 最終話の製作進行の担当 |
| 13～21 | 危険な場所への接近 | 第三飛行少女隊の製作 |
| 22～23 | 最大の試練、報酬 | 最終話の全没の危機 |
| 24 | 帰路、再生、帰還 | 最終話の納品 |
冒険への誘い（ただし、回送シーンとして示される）と拒絶に対応するくだりがないことがわかります。さて、詳細を見ていきましょう。
