元のページサイズを維持する機能

[doraTeX]

「図版サイズでクロップせずに元のPDFのページサイズを維持する機能」というのはどうだろう。

メリット

例えば次のようなソースを pdfLaTeX でコンパイルすることで，「横幅を一定に保った数式画像の生成」が容易にできるようになる。

\documentclass[border=1pt]{standalone}
\pagestyle{empty}
\begin{document}
\begin{minipage}{10cm}
\abovedisplayskip=0pt
\[f(x)=\int_0^x e^t dt\]
\end{minipage}
\end{document}

仕様案

• PDFのページサイズとしては，通常のリーダーでの描画範囲として採用されている CropBox を採用するのがよいだろう。（→ 何Boxを採用するかを選ばせるUIを付ける手も。）
• CropBox の取得方法としては，TeX2img.app の中に pdfinfo を内包しておいてそれを利用する。
• CUI版のオプション（例：--keep-pagesize）を増補し，この機能の動作には pdfinfo 必須とする。（従来の mudraw と同様の扱い。TeX2img.app がインストールされていればその中もサーチ。）

→ OS X の Quartz API によって，5つのナントカBoxは全て取得できるので，これを用いれば pdfinfo 依存性を排除できる。

実装案

• gs >= 9.15 を前提とできるのならば，gs -sDEVICE=pdfwrite -dNoOutputFonts を使ってPDFのアウトライン化を行うのが楽だが，-dNoOutputFonts が使えない過去の gs をサポートしようと思うと，従来の変換経路の中に「EPSのBBox情報を元のPDFのCropBoxに書き戻す」という方法をとるのがよいだろう。

(A) gsを通さない経路の場合

従来の変換経路は

1. 速度優先モードでのビットマップ生成 (PDF →[pdfcrop類似処理でクロップ]→ PDF →[Quartz API でビットマップ化＋余白付与]→ JPEG/PNG/GIF/TIFF/BMP)
2. テキスト情報を残したPDF生成 (PDF →[pdfcrop類似処理でクロップ＋余白付与]→ PDF)
3. テキスト情報を残したSVG生成 (PDF →[pdfcrop類似処理でクロップ＋余白付与]→ PDF →[mudraw]→ SVG)

であった。この「pdfcrop類似処理でクロップ」においては，gs -sDEVICE=bbox の結果が pdfTeX に渡されていた。ここを，元のPDFのCropBoxのサイズを渡すことにすればよい。

(B) gsを通す経路の場合

従来の変換経路は

1. 画質優先モードでのビットマップ生成 (PDF →[gs(eps(2)write)でアウトライン化＋クロップ]→ EPS →[epstopdf(gs)]→ PDF →[Quartz API でビットマップ化＋余白付与]→ JEPG/PNG/GIF/TIFF/BMP)
2. アウトライン化PDF生成 (PDF →[gs(eps(2)write)でアウトライン化＋クロップ] → EPS →[epstopdf(gs)]→ PDF →[pdfcrop類似処理で余白付与]→ PDF)
3. アウトライン化EPS生成 (PDF →[gs(eps(2)write)でアウトライン化＋クロップ] → EPS →[BB情報を編集して余白付与] → EPS)

であった。これらの経路においては，「gs(eps(2)write)でアウトライン化＋クロップ」を行った直後に，生成したEPSのBBox情報を，元のPDFのCropBoxで上書きすればよい。（2. においては，後半の「pdfcrop類似処理で余白付与」の部分はクロップせぬよう (A) と同じ処理を利用する。）

[aminophen]

OS X の Quartz API によって，5つのナントカBoxは全て取得できる

OS X すごいですね… ただ、正直なところ「横幅を保った画像」を作りたいと思ったことがないのでどのくらい需要があるのかよく分かっていません。書くべきソースも特殊なので、テンプレートを新設しないと使いこなせない気がします。

[doraTeX]

OS X すごいですね… ただ、正直なところ「横幅を保った画像」を作りたいと思ったことがないのでどのくらい需要があるのかよく分かっていません。

横幅を保った画像を作りたい状況としては，ブログ記事で中央揃えの別行立て数式を使いたい状況が挙げられます。
ブログシステムによっては段落スタイルとして中央揃えがサポートされていないこともあります。（Markdown入力，かつHTMLタグ禁止の場合は，中央揃えできないですよね。）
その場合は，ブログの横幅と合わせた画像を左詰めで出力し，その画像内で中央揃えにしておくという場合が考えられます。

書くべきソースも特殊なので、テンプレートを新設しないと使いこなせない気がします。

テンプレートを新設するほどの需要はないでしょうから，FAQに書いておけば十分でしょう。

他の用途としては，外部PDFファイル入力機能を利用して，「手持ちのPDFのフォント情報を潰すべくアウトライン化したい（PDFのページサイズは維持したい）」という状況でも役立つかと思います。
フォント埋め込みPDFであっても，Illustrator に貼り込むと，システムにインストールされていないフォントが化けたりします。したがって，「いかなる使い方をしても文字化けしないPDF」が欲しい場合は，フォントのアウトライン化を行う必要がありますが，その場合はページサイズは維持したい状況も多いはずです。
Adobe Acrobat を使えばPDF内の全フォントをアウトライン化することが可能ですが，それと同等のことが Acrobat なしでできるようになります。（Acrobat と異なり TeX2img では全ページバラバラにされてしまいますが。）

[aminophen]

今すでに書かれている FAQ で十分だと思っていたのと、いままで TeX2img を「TeX 画像化ツール」として使ってきたユーザに「ページサイズ」という概念があまりないかもしれないという危惧があります（複数ページが出てくるのも、開発サイドからすれば当然ですが、意識している人は少なそう）。その場合、ページサイズを維持という UI を見ても何ができるのか（あ、これは幅固定できるぞ！とか）わかる人が少ないのではないかと思うのです。

いかなる使い方をしても文字化けしないPDF

フォント埋め込みした PDF で文字化けが起こるのは Illustrator や Inkscape で開く場合だけで、要するに「編集する前提」だと思っています。となると、わざわざページサイズを維持する必要性をまだ感じていません。

ただ、Acrobat の代替ツールとしての利用はありえるかもしれません（とはいえ、Acrobat の当該機能を必要とする場面が私は思いついていません）。もちろんあるといいかもしれませんが、“なんに役立つか分からない”に起因する類のトラブルが増えないようにしないといけませんね。

[doraTeX]

するに「編集する前提」だと思っています。となると、わざわざページサイズを維持する必要性をまだ感じていません。

とはいえ、Acrobat の当該機能を必要とする場面が私は思いついていません

自分がソースを持っていないPDFファイルにちょっとした誤植が見つかったときに，Illustratorで該当ページを開いて，他の文字を切り貼りするなどして数文字分を修正することがあります。そのような際によくこの機能を使います。
Googleで「Acrobat アウトライン化」と検索してみると，色々な人の用途を見ることができます。

[aminophen]

「画像の横幅維持」の件と「Acrobat 代替ツール」の件をちょっと分離したいと思いました。

画像の横幅維持はそもそも UI を新設して「一定幅画像を作る」とかで px とか bp とかできる方が親切だと思っています。TeX ソースを先ほどのように特別に書いて頑張るハックより良いかと。

Acrobat 代替ツールが一定の需要を見込めることはなんとなくわかってきました。問題は「明瞭な UI ができるかどうか」にかかっている気がします。いままでの TeX2img にはページサイズという概念が表立ってはいませんでしたぢ、もはや IMG to IMG 機能での利用のほうが多いことも予想されます。

[doraTeX]

Ver. 2.0.2 beta 1 を作りました。

Ver. 2.0.1 → 2.0.2 beta 1 での変更点

• 日本語版GUIの表記も DVIware → DVI Driver と変更。
• CUIのオプション名を --dvidriver に変更。
• 互換性のために残してあるオプション --compiler, --dviware, --dvipdfmx をヘルプ画面上でも表示。
• PS→PDF 変換時に -dAutoRotatePages=/None を付与 → 回転問題 に対処
• eps2write デバイスを使用しているときも，生成したEPSのBB情報を gs -sDEVICE=bbox の結果で上書き→ gs9.15 以上の eps2write デバイスでもクロップに失敗する例がある #37 に対処
• 「単一ファイルにまとめる (PDF)」機能を追加 (PDF出力のときに単一PDFとして出力する機能 #38) （CUI版は --[no-]merge-output-files）
• 「元のページサイズを維持」機能を追加 (元のページサイズを維持する機能 #36) （CUI版は --[no-]keep-page-size）
• 「元のページサイズを維持」の際の採用するボックス種別の選択機能を追加 (元のページサイズを維持する機能 #36)（CUI版は --pagebox）

UI上の負担は最小限で済んだのではないかと思います。

「単一ファイルにまとめる」「元のページサイズを維持」の二大新機能は，

• 白紙ページしかなく結果的に生成ファイルが存在しない場合
• 一部に白紙ページを含む場合
• 一部に白紙ページを含むが余白付与の結果白紙ページが残る場合

といった例外的ケースについても一応テストし，概ね直感通りに動くようになっているはずです。

[aminophen]

Mac 版 2.0.2 beta 1 を簡単にですが使ってみました。構想どおりの実装になっていると思います。

以下はそもそも未定義か普通はありえない場合ですが、メモとして：OS X の API は「ナントカBox が不正な PDF」に対して以下の挙動をとるようにみえる。

• ArtBox / TrimBox / BleedBox が CropBox をはみ出す場合：CropBox でクリップせずそのままの値を返す（pdfinfo の出力や extractbb の -B オプションとは異なる）。
• MediaBox の左下が 0 0 でない場合：勝手に MediaBox の左下が 0 0 であるかのように原点シフトしたうえで、それを基準にほかの Box の範囲を描画する。←追記：こちらは OS X の API の挙動なのか TeX2img の独自挙動なのか未検証。

ツールによって扱いが異なるのはなかなか困りものです。（そもそも不正な PDF なので未定義ということでよいのですが。）

[doraTeX]

テストありがとうございます。
ブログ記事 にも書きましたが，OS X のAPIでは，取得できるボックスサイズは，他のボックスによるクリップなどは行わない「生の値」のようです。
TeX2img では，自前で MediaBox によるクリップ計算を行った後の値を各ボックス値として採用するようにしています。

[aminophen]

テスト用に MediaBox だけが書かれた原点が 0 0 でない PDF を作ってみて、これを TeX2img に通すと原点の位置がずれますね。

Page    1 MediaBox:   100.00   100.00   250.00   250.00   [dvipdfmx BB]
Page    1 CropBox:    100.00   100.00   250.00   250.00   [Implicit]
Page    1 BleedBox:   100.00   100.00   250.00   250.00   [Implicit]
Page    1 TrimBox:    100.00   100.00   250.00   250.00   [Implicit]
Page    1 ArtBox:     100.00   100.00   250.00   250.00   [Implicit]

よくわかっていないのですが、MediaBox の原点が 0 でない場合は PDF 的にどう定義されている（もしくは未定義）なのでしょう？

[doraTeX]

テスト用に MediaBox だけが書かれた原点が 0 0 でない PDF を作ってみて、これを TeX2img に通すと原点の位置がずれますね。

実例ありがとうございます。
確かに，これはまずいですね。ボックスの取得自体はうまくいっているのですが，その後の「ページサイズを維持した画像化処理」のどこかに問題があるようです。これから調査します。

[doraTeX]

Ver. 2.0.2 beta 2 で解決できたと思います。

BoundingBox がとにかくややこしい話(3)の

gs の bbox デバイスは「描画を CropBox と ﾅﾝﾄｶBox で二重にクリップしてからタイトに囲んだ領域」の「ﾅﾝﾄｶBox」に対する相対位置（デフォルト：ﾅﾝﾄｶBox = MediaBox）を返す

の「相対位置」というのがポイントでした。

「ページサイズ維持」かつ「OS X のAPIでPDFから直接画像化」の場合，gsは一切使いませんが，pdfcrop類似処理において gs の bbox の結果の代わりに，元のPDFの当該BB情報を pdfTeX ソースを渡すことで余白付与作業を行います。ここでも MediaBox に対する相対座標を用いなければならない点は盲点でした。

[aminophen]

Ver. 2.0.2 beta 2 はおそらく大丈夫だと思います。（簡単なテストしかしていませんが…）

「相対位置」というのがポイント

この相対位置というのは ZR さんも見落としていらっしゃった部分のようで、仕様書にも分かりやすい書き方がされていないので盲点になりがちですね。

[doraTeX]

ありがとうございます。
MediaBoxの左下が原点でなく，かつ他のボックスがMediaと異なる値を持つ場合にもうまくいくかどうかはちゃんと検証できていないので，検証しておいてくださると助かります。

また，現在気づいている制約としては，例えばArtBoxの内側にCropBoxが食い込んでいるときに，ArtBoxをページサイズとして維持して画像化を行った際に，ページサイズとしては正しくArtBoxにとられますが，CropBoxの外側の部分が描画されるかされないかが，出力画像形式によって異なります。

gs を通す経路である

• 画像優先モードでのビットマップ生成
• アウトライン化PDF生成
• EPS生成

ではCropBoxの外側が消え，gs を通さない経路である

• 速度優先モードでのビットマップ生成
• テキスト保持PDF生成
• SVG生成

ではCropBoxの外側が残ります。

これも，BoundingBox がとにかくややこしい話(3)で指摘されているgsのCropBoxによる二重クリップに起因していますね。これは仕様とするしかなさそうですね。

[aminophen]

いまちょうど「MediaBoxの左下が原点でなく，かつ他のボックスがMediaと異なる値を持つ場合」を試していました。おっしゃるとおり、「スキームによる違い」が生じますがそれは仕様ということにしましょう。（そもそもそんな PDF が世にあふれているとは言いがたいので問題なし）

うちのサブブログ、なんか役に立っているようで光栄です。私自身、あそこを検索して「ああそうだった」と思い出すことが最近非常に多いです。

[doraTeX]

お陰様で大変役立っております。
BBの闇にはまったときはあの一連の記事に立ち戻って読み直すようにしています。
今朝の記事 はその入り口となるリンク集としても役立っています。😅

そもそもそんな PDF が世にあふれているとは言いがたいので問題なし

MediaBoxの左下はともかく，CropBoxが他のボックスの内側に狭く刈り込まれているPDFは，Preview.app や Acrobat でトリミングすれば発生するので，「変換経路によってCropBoxの外側が描画されたりされたりされなかったりするPDF」というのはごく普通に存在します。
ただし，そのようなPDFの場合，ユーザが明示的にCropBox刈り込みの行為を行ったわけであり，また各種PDFビューワでもその範囲が描画されるわけですから，ページサイズとしてはCropBoxを期待していると想定してよいでしょう。「CropBoxが狭く刈り込まれているPDFを，刈り込む前の元のMediaBoxサイズで画像化したい」という状況はあまり考えにくく，想定外としてしまってもよいでしょう。
（そのため，TeX2img の設定におけるボックスのデフォルト値は CropBox になっています。）

[aminophen]

「変換経路によってCropBoxの外側が描画されたりされたりされなかったりするPDF」というのはごく普通に存在します。

そういえばそうですね… おっしゃるとおり「ユーザが明示的にCropBox刈り込みの行為を行ったわけであり」「ページサイズとしてはCropBoxを期待している」なので大丈夫でしょう。

今朝の記事 はその入り口となるリンク集としても役立っています。

私もよくブログをその用途に使います😁最近はサブブログが「その日参考にしたページのリンク集」になる傾向があり、まとまりがない割に使えてメインブログのネタ集めにも役立っています。（記事紹介ありがとうございます！）

[abenori]

縦横どちらも保つ、と言うことになったのでしょうか？以前（#21 (comment) ） ちょっと書いたのを思い出しました．そのとき横方向ならば意味がありそうだけど縦横だとどうなんだろう……と思った記憶が．

というか最大の問題は出力画像の余白よりオプション画面の余白なんですが……

[doraTeX]

縦横どちらも保つ、と言うことになったのでしょうか？

今回の「元のページサイズを維持する」機能は，まさにその

「サイズを文書サイズにあわせる」的なオプションを入れるとこのオプションの有無で切り替えられるだろうか．（http://oku.edu.mie-u.ac.jp/~okumura/texwiki/?TeX2img%20FAQ#s84b19a5 もこれで解決できるかなと思ったけど，これは横方向だけだった……．）

の「サイズを文書サイズにあわせる」機能ですね。

横方向だけの維持はまた別途検討課題ですが，とりあえず，「サイズを文書サイズにあわせる」機能があれば，冒頭の例のような方法で横方向のみ維持することは可能ではあります。

[abenori]

了解です．こちらでも検討してみます．（さすがにBoxを選択させるのは無理だろうけど……）

Mac版の機能追加に追いつけていない……

[abenori]

「元のページサイズを維持する」時は余白設定は無視ですか？

[doraTeX]

いえ，元のページサイズに加え，さらに指定された余白を追加する仕様になっています。

[abenori]

https://onedrive.live.com/redir?resid=4FABCB4EC4FA1E70!16825&authkey=!ANYoMX5Yq7PLXU4&ithint=folder%2cexe

eps以外はオプションをいじったりすればできそうなんですが，epsのBoundingBoxだけはどうにもならないですね．と言うわけで，pdftexを使ってBox取得です．-sDEVICE=bboxで取得していた部分をそっちに変更したらできているような気がするのですが……大丈夫かな．LaTeXソースから普通に作られるような「普通の」PDFでしかチェックしてませんが．

[aminophen]

遅くなりましたが Win 版を試してみました。CropBox に固定ということで、値取得自体はうまくいっているようですが、MediaBox の左下が 0 0 でない場合に（この前の Mac 版と同じく）ずれてしまいました。単一 PDF 出力もこれから、ですね。

[abenori]

一応LaTeXから生成されるのは基本的に全部同じかなと思ってCropBoxで固定しています．Mac版はイロイロ2imgですがこちらはまだTeX2imgなので（笑）左下がずれているときのもそんな理由でさぼっていたのですが，まぁ一応直しておきましょうかねー．
単一も手元では書いてみました．といっても最後にpdftexで全部くっつけるだけですが．

[abenori]

一応直して大丈夫そうなので公開しました．

[aminophen]

CropBox を正しくクロップできていないようなので調べていました。スキームがこれだとすると、Crop から Media を引くべきなので、逆になっていると思います（先に Crop を取得して Media の左下を引くと、相対座標になる）。

[abenori]

ありゃ，ぼけていました．直しました．

[aminophen]

直っていました。単一 PDF も自然な挙動だと思います。徐々に増えるこっそり機能が満載で楽しませていただいております☺ありがとうございます。

[aminophen]

うわ、tiff も単一ファイルで出てきました。すごい…

[abenori]

ググったらでてきたコードを（あまり理解せず）うつしただけなので，変なことが起こるかもしれません．何かあったら教えてください．