- extractbb は従来どおり「原座標系」に則った Box 値を返し、これに加えて %%Rotate: 行も出力する。dvipdfmx.def は bbox 値と rotate 値を取得し、TeX が確保すべき箱のサイズを計算する。
- dvipdfmx.def は bbox 値について従来どおり「bb= オプションがあればそれを採用 → オプションがなければ .xbb ファイルを探して読む → ファイルがなければ extractbb を実行してパイプ入力する」。rotate 値については bbox 値取得と同じ段階で行われ、「bb= オプションがあれば pdfrotate= オプションの値を読む → bb= オプションがなければ .xbb ファイルを探して読む → ファイルがなければ extractbb を実行してパイプ入力する」(bbox 値取得と同じ段階での読み込みに失敗すれば0とみなす)。
- epdf special の bbox 値には、viewport を考慮した画像表示範囲を「原座標系」で与える。あとは dvipdfmx がその範囲の画像を /Rotate にあわせて回転して取り込む。
- rotate 値が取得できなかった場合に0にフォールバックするという状況が起こりうるので、これは dvipdfmx.def が /Rotate 無視を意図したといえる。それにもかかわらず dvipdfmx が実際の取り込みで /Rotate を解釈することを許しているので、一貫性がない。
- 一貫性を持たせる案1【警告を新設 + \special を拡張】:rotate 値の取得法は上記のままとするが、取得に失敗した場合は0にフォールバックする前に警告を出す。これは /Rotate 無視にほかならず、その場合は箱確保が回転を考慮せずになされることから、dvipdfmx による取り込み時にも /Rotate を無視させる。これを実現するため、回転すべき新仕様版 DVI にだけ \special で userotate パラメタを埋め込んでマーキングし、これを検知した場合のみ PDF を回転する。案1では、一律に /Rotate を無視する従来のマチガッタ挙動と互換性も保証される(これはあくまで新 dvipdfmx と dvipdfmx.def を整合させるための要請からくる副次的な恩恵)。
- 一貫性を持たせる案2【エラーを新設】:rotate 値の取得法は上記のままとするが、取得に失敗した場合はエラーで落とす。ユーザには pdfrotate= オプションの明示または xbb ファイルの作り直しを強制する。この場合、従来のマチガッタ dvipdfmx に対しては正義だった “静的な bb 取得法” をバッドノウハウ認定することを意味する。悪いのは従来の dvipdfmx であるにもかかわらず、非のないユーザにしわ寄せすることとなり納得できないだろう。
- 一貫性を持たせる案3【警告を新設】:rotate 値の取得法は上記のままとするが、取得に失敗した場合は0にフォールバックする前に警告を出す。これは /Rotate 無視にほかならないが、rotate 値を明示しなかったユーザが悪いといえるので結果的に PDF がヘンになっても文句は言えないことにする。この場合も、従来のマチガッタ dvipdfmx に対しては正義だった “静的な bb 取得法” をバッドノウハウ認定することを意味する。また、古い DVI ファイルはもう新しい dvipdfmx で処理できないことを意味する。
- 一貫性を持たせる案4【rotate 取得試行を強化したうえでエラーを新設】:rotate 値の取得試行を bbox 取得試行と同じ段階に限定するのをやめ、たとえ bbox 値がとれても rotate 値がまだなら試行継続する。すなわち「pdfrotate= オプションがあればそれを採用 → オプションがなければ .xbb ファイルを探して読む → %%Rotate 行がなければ extractbb を実行してパイプ入力する」(ここまでの試行で失敗すればエラーで落とす)。案2のように即エラーとなるのは優しくないが、もうワンクッションあることで rotate 値の取得可能性が高まる利点がある(なお、-no-shell-escape 下では結局のところ案2と同じになる)。その一方で、bb= オプションや xbb 事前準備という “静的な取得” を望んだ人にとっては “動的な取得” が行われる余地を生み、再び完全な “静的な取得” を実現するために pdfrotate= オプションの明示または xbb ファイルの作り直しを強制することになる。案4は正しい結果に導く可能性が最も高い方法である。
- 一貫性を持たせる案5【案4 + \special を拡張】案4に加え、案1の一部である \special でマーキングする処理も行う。案5では、正しい結果に導く可能性が最も高いことに加えて、一律に /Rotate を無視する従来のマチガッタ挙動と互換性も保証される(案5は案1と異なり、新仕様の要請からではなく意図的に後方互換性を確保するもの)。
XeTeX は libpoppler の機能で Box 値のみならず rotate 値も取得できるので、これを xetex.def に渡して同様の処理を行えばよいだろう。
- 古い dvipdfmx で処理される前提で出力された DVI ファイルは、これまでどおり処理されると好ましい。これには、DVI 作成段階で /Rotate を考慮した箱が確保された DVI はそれとわかるようにマーキングし、マーキングがなければ /Rotate を無視した箱しか確保されていないとみなすという方法が考えられる(上記第1案参照)。マーキングがなければ、取り込まれる PDF に書かれている /Rotate は dvipdfmx によって無視されなければならない。
- extractbb が返す値は、従来と同じ (HiRes)BoundingBox 値を返さなければならない。そうでなければ、現在正しいはずの xbb ファイルや bb= オプション指定が突如として不正な値であることになってしまう。
- pdfLaTeX の viewport オプションは、/Rotate によって回転されたあとの「新座標系」における、“見せたい領域” の “採用される Box” に対する相対座標で指定する。この仕様を dvipdfmx でも踏襲しなければならない。
- dvipdfmx ドライバのための改変であるので、ドライバ非依存のファイル(graphics.sty など)を書き換えてはいけない。ただし、dvipdfmx.def によるマクロ定義の上書きは許される。
「pdf:epdf の書式を拡張して userotate パラメタを導入する」方向で、さらに「なんらかの理由で rotate 値を取得失敗した場合に警告を出す」ように dvipdfmx.def を改修するところに落ち着きそうである。その改修が完了したと仮定すると、これを dvipdfmx の側でどう解釈するかも問題である。結果だけ考えると
古い書式:
新しい書式:
であるが、その変換途中にいつ警告を出すかも気になるところである。一つの案として
とすることが考えられる(新書式の「userotate 0 を明記」と旧書式の「明記せず」を区別しているところがポイント)。この場合の新しい dvipdfmx.def の実装は
とするのが良いだろう。これにより、dvipdfmx.def と dvipdfmx が連携する:
なお、dvipdfmx.def の助けなしにユーザが userotate 0 を使った場合は、明らかに意図的に回さないことを選択しているので
とするのが自然である。