10.10以下で「単一ファイルを生成」でアウトライン化PDFを生成したときに端が欠ける

doraTeX commented 8 years ago

現象

10.10以下で次のソースをコンパイルする。

\documentclass[fleqn,papersize]{jsarticle}
\pagestyle{empty}
\usepackage[ipaex]{pxchfon}
\begin{document}
ほげほげ
\end{document}

設定は

形式：アウトライン化PDF
余白：0
単一ファイルにまとめる：ON

このとき，次のように端が欠ける。

2015-11-10 21 03 03

10.11 El Capitan では，全く同じ設定で実行しても端が欠ける現象は生じない。

2015-11-10 21 03 34

原因

原因を追究してみたところ，Quartz API を用いたPDFのマージ処理が原因だった。

「単一ファイルにまとめる」がONのときは，Quartz API によるPDFのマージを行う。（出力が1ページの場合でも。）ところが，10.10 以下の Quartz API にはバグがあるようで，これを用いてPDFを作成すると，バウンディングボックスが縮んでしまうようだ。

10.11 El Capitan ではこのバグが修正されている模様。

対策

PDFマージ処理を，Quartz API を用いずに，pdfTeX を用いて行えばよいと思われる。

doraTeX commented 8 years ago

解決

出力が1ページになった場合はわざわざマージ処理に回さないようにした。
出力が複数ページになった場合は，Quartz API ではなく pdfTeX でマージするようにした。

これで，10.10 以下でも端が欠けなくなった。

doraTeX commented 8 years ago

本件と #59 を合わせて，Ver. 2.0.9 / 1.10.9 としてリリースしておきました。特に #59 は普通に起動できないという致命的な問題でしたのでリリースを急ぎました。

aminophen commented 8 years ago

もしやと思って Marvericks 環境で PNG 出力してみると、同じ問題が再現しました。（下は非透過 PNG、余白0bp、解像度50、画質優先モード）

equation

透過処理の有無によらず、ビットマップでも同じく描画の端がページ端までいかないようです。これは余白をつけたところで一向に改善しません。（下は非透過 PNG、余白10bp、解像度50、画質優先モード）

equation

私は普段 Mac ではビットマップ出力をせず PDF オンリーで使っていたため、全く気づきませんでした… Quartz を使う限り避けられないという致命的な問題です。

追記：…と思ったら、そういえば Mac 版でも GIF アニメ出力を試していたので、そんなに切れた印象はなかったのを思い出しました。あのときは Lion でしかテストしていなかったので、そう考えると Marvericks に特有（もしくは Marvericks と Yosemite に特有？）なのでしょうか？

aminophen commented 8 years ago

とりあえず Marvericks で「あいうえおか」「□○□」と書いた pLaTeX ソースの処理結果を貼ります。

画質優先モード、解像度50、余白0

quality-r50-m0-a

速度優先モード、解像度50、余白0

speed-r50-m0-a

画質優先だと「画像の上と右」が切れていますが、速度優先だと切れていないようです。

aminophen commented 8 years ago

Lion でも試してみましたが、Marvericks とまったく同じでした。

画質優先モード、解像度50、余白0

quality-r50-m0-a

quality-r50-m0

速度優先モード、解像度50、余白0

speed-r50-m0-a

speed-r50-m0

画質優先モードの切れ具合は、Lion のほうが Marvericks よりマシだったという程度です。

doraTeX commented 8 years ago

以前，10.10以下が現役であった時代にこんな現象が起こっていたら必ず気づいたはず，ということは10.11時代になって最近混入したバグでは？と思って調べてみたところ，原因が分かりました。

Ver. 2.0.6 で入れた a2fef17fca894b609647878c89733a74c1a240cf の改変が原因です。 epstopdf に --hires オプションを渡すようにした結果，「ギリギリまでクロップしたPDF」が得られるのですが，そのPDFを10.10以下で取り扱うと小数点以下の端が欠けるようです。

そこで，OSのバージョンを見て分岐させ，10.10以下ならば --nohires, 10.11以上ならば --hires を epstopdf のオプションに渡すことにしました。これで解決です。

また，#58 の元々の問題である「単一ファイルPDFの作成時の問題」も同じ原因でした。この解決のために Ver. 2.0.9 では pdfTeX を用いたマージを行うように変更しましたが，10.10以下で --hires を渡さないようにした結果これは不要になりました。元通り Quartz API を用いてPDFマージを行うよう戻しました。そちらの方が高速です。

aminophen commented 8 years ago

Ver. 2.0.6 で入れた a2fef17 の改変が原因です。

おお、根本的な原因が判明してよかったです。確かに「10.10以下が現役であった時代にこんな現象が起こっていたら必ず気づいたはず」ですね。Quartz は綺麗なビットマップを出すので、それを維持できて嬉しいです。

元通り Quartz API を用いてPDFマージを行うよう戻しました。そちらの方が高速です。

了解しました。

doraTeX commented 8 years ago

本件を修正したものを Ver. 2.1.0 / 1.11.0 としてリリースしておきました。また，本件を踏まえて変換経路図をアップデートしました。

doraTeX / TeX2img