表紙をPDFファイルにしたとき同名のPNG画像があるとずれる

[m-shibata]

PDF生成時、media=ebookでなおかつpdfmakerのほうのcoverimageをPDFファイル名にしておくとします。このときPDFファイルと同名の（拡張子を変えた）PNGファイルがあると、表紙の位置がずれるようです。

masterブランチでも再現しました。

再現手順

$ review-init uplatex
$ cd uplatex

AIファイルの表紙をPDFに変換
$ gm convert images/cover-a5.ai images/cover.pdf
$ pdfinfo images/cover.pdf
Title:          cover
Producer:       GraphicsMagick 1.4 snapshot-20190927 Q16 http://www.GraphicsMagick.org/
CreationDate:   Mon Feb 24 03:42:23 2020 JST
ModDate:        Mon Feb 24 03:42:23 2020 JST
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      437 x 612 pts
Page rot:       0
File size:      9312 bytes
Optimized:      no
PDF version:    1.2

media=ebookにして表紙を作るようにし、生成したPDFファイルを指定
$ sed -i 's/media=print/media=ebook/' config.yml
$ sed -i 's/cover-a5.ai/cover.pdf/' config.yml

JPG画像からPNG画像を生成
$ gm convert images/cover.jpg images/cover.png
$ file images/cover.png
images/cover.png: PNG image data, 1000 x 1600, 8-bit/color RGB, non-interlaced

book.pdfを生成
$ rake pdf

以下のような状況だと再現しません。

• cover.pngファイルを削除した場合
• cover-a5.aiからcover.pngファイルを生成した場合（437x612になる場合）
• cover.pngが存在してもcover-a5.aiを表紙として使う場合
• cover-a5.pngが存在しつつcover-a5.aiを表紙として使う場合

つまり同名のPDF/PNGがある場合、解像度の解釈が期待と異なってしまうように見えます。

[m-shibata]

上記の実行環境はUbuntu focalのTeX Live 2019です。Ubuntu 19.10のもう少し古いバージョンでも再現した記憶があります。

$ uplatex --version
e-upTeX 3.14159265-p3.8.2-u1.25-190908-2.6 (utf8.uptex) (TeX Live 2019/Debian)
kpathsea version 6.3.1
ptexenc version 1.3.7
Copyright 2019 D.E. Knuth.

$ dpkg -l | grep texlive
ii  texlive-base                   2019.20200218-1                   all          TeX Live: Essential programs and files
ii  texlive-binaries               2019.20190605.51237-3             amd64        Binaries for TeX Live
ii  texlive-fonts-recommended      2019.20200218-1                   all          TeX Live: Recommended fonts
ii  texlive-lang-cjk               2019.20200218-1                   all          TeX Live: Chinese/Japanese/Korean (base)
ii  texlive-lang-japanese          2019.20200218-1                   all          TeX Live: Japanese
ii  texlive-latex-base             2019.20200218-1                   all          TeX Live: LaTeX fundamental packages
ii  texlive-latex-extra            2019.202000218-1                  all          TeX Live: LaTeX additional packages
ii  texlive-latex-recommended      2019.20200218-1                   all          TeX Live: LaTeX recommended packages
ii  texlive-luatex                 2019.20200218-1                   all          TeX Live: LuaTeX packages
ii  texlive-pictures               2019.20200218-1                   all          TeX Live: Graphics, pictures, diagrams
ii  texlive-plain-generic          2019.202000218-1                  all          TeX Live: Plain (La)TeX packages

[kmuto]

PDFMakerは内部でextractbbを呼び出してバウンディングボックス情報を.xbb拡張子ファイルに書き出すのですが、cover.pdf.xbbやcover.png.xbbではなくcover.xbbになる、つまり同名ファイルがあると後に解釈されたほうで上書きされてしまいます。

既知の問題ではあるのですが、良い解決方法を現時点では思いついていません。同名があったときにWARNするくらいはできるかもしれないですが、目立たなくて読み飛ばしそう。

[m-shibata]

おぉ、なるほど。debug=trueにして確認できました。

そうすると、extractbbが、ファイル名指定で出力できて、かつ、includegraphicsがファイル名を指定できないと対応が難しそうですね。

ちなみにTeX Live 2015以降はLaTeXが（追記：graphicxパッケージのdvipdfmxドライバーが）勝手にextractbbを実行してくれるとのことなので、pdfmaker.rbのcopy_imageにあるextractbb実行周りをコメントアウトして見ましたが、上記の再現手順に限って言えば、同じbasenameでもうまく表示されました。

https://texwiki.texjp.org/?extractbb%20%E3%81%AE%E8%87%AA%E5%8B%95%E5%AE%9F%E8%A1%8C%E8%A8%B1%E5%8F%AF%E3%81%AE%E8%A8%AD%E5%AE%9A

[kmuto]

ありがとうございます。
TeXLive2014以下はサポート外なので(Debian oldstableのよりさらに前)今の手動実行の機能自体カットしちゃってもいい、ということですね。しかし既存のロジックを削除するということになると、本当に大丈夫かちょっと勇気がいりますね…

• graphicx dvipdfmxドライバの自動実行でのbox設定は\@ifundefined{Gin@pagebox}{\def\Gin@pagebox{cropbox}}{}で定義されているので、ボックス設定があるときにはこれを事前定義すればよさそう
• LuaTeXだと自前で計算するのでそもそもextractbbは使わない
• ロジックを削除する代わりにデフォルトでロジックをスキップで必要に応じてロジックを戻すというフラグを作る、というのは意味があまりなさそう

[m-shibata]

はい、TeX Live 2014以前をサポート外にして良いのであれば、削除する方向がいいのかなと思います。思いはするのですが、extractbbコマンドを実行することにした経緯とか、xbbファイルの読み込みとパイプラインで渡すのとでなにか違いがでるのかとか、細かいことはわかっていないので削除すべきだと言い切るほどの強さはありません。

おっしゃるとおり、これまでの挙動との互換性等を考えると、たしかに削除して大丈夫かどうかの判断基準も難しいですね。