出力に白紙ページが含まれる場合に挙動がおかしい #21
Comments
|
出力に白紙ページが含まれる場合，どの画像形式への出力の場合でも，元の用紙サイズを保持した白紙画像を出力する（余白付与はしない）ように修正。 |
|
うちの bcpdfcrop でもやっと応急処置したところでした。ありがとうございます。 |
|
bcpdfcrop の \procinclude を参考にさせてもらいました😊 |
|
bcpdfcrop では 0 0 0 0 な場合しかハンドルしていませんが、オリジナルの pdfcrop.pl は x 座標と y 座標をそれぞれ比較して、逆転がある場合を含めて対処していました。gs が返す座標が逆転したり 0 0 0 0 でない場合があり得るのか解らなかったので、手抜きです😅 |
|
なるほど，本当はそのような場合への対処も必要ですね……。 |
私も同じことを考えていました。いまの例外処理で十分でしょう。 |
|
EPS を経由する画像化の場合の挙動は問題ないでしょうか。eps(2)write を通る処理では白紙ページの扱いが気になりました。特に、epswrite のときに #18 対策で bbox を上書きしていた部分を確認したいと思います。 |
図星でした。その場合に問題が生じていましたので解決しておきました。 ちなみに，変換経路が複雑化してきて，新機能を加えるたびにどのようなパターンをテストすべきかを見落としやすくなってきましたので，備忘録としてテストすべき項目を列挙しておきます。 gsを通さない経路
gsを通す経路
gsを通す経路については，そのそれぞれについて，
の4通りのテストが必要です。 |
|
これからテストしますが、上記の「gs を通さない経路」の 1. 速度優先モードでのビットマップ生成は PDF →[pdfcrop類似処理でクロップ＋余白付与]→ PDF →[OS XのQuartz API]→ JPG/PNG/BMP/GIF/TIFF だと思っていましたが、そうではなかったのでしたっけ… |
|
どちらでもなくて， PDF →[pdfcrop類似処理でクロップ]→ PDF →[Quartz API でビットマップ化＋余白付与]→ JPEG/PNG/GIF/TIFF/BMP でした。上の書き込みも訂正しておきます。 |
もはや把握できなくなってしまいました…😅 Windows 版と合わせて頭の中が混乱しそうですが、私の記事も今度直します… |
|
gs9.16 と gs9.05 で上の全ての場合をテストしました（つもりです）。真っ白な EPS をプレビューしようとすると、gs9.16 の eps2write で吐いた場合のみ「Preview.app の前処理 epstopdf (?) が Warning を吐いてプレビューが開かない」という現象が起きました。ほかは問題なさそうです。
|
これはコマンドラインから呼び出しても同じですので，OS X の仕様ということで仕方なさそうです。 $ pstopdf hoge.eps
%%[ Warning: Empty job. No PDF file produced. ] %% |
ありがとうございます。ではこれで全て解決ですね。 |
|
あんまりよくわかっていないのですが，空白ページにはpdfcropを通さないと言うことでしょうか？ |
はい，それで大丈夫なはずです。 \pdfoutput=1\pdfhorigin=0bp\relax\pdfvorigin=0bp\relax\setbox0=\hbox{\pdfximage page ページ番号 mediabox{ファイル名}\pdfrefximage\pdflastximage}\pdfpagewidth=\wd0\relax\pdfpageheight=\dimexpr\ht0+\dp0\relax\shipout\hbox{\raise\dp0\box0\relax}\endのような pdfTeX ソースをコンパイルして切り出すようにしています。 |
|
Windows 版の場合、空白ページが問題になるのは
だと思います（eps2write で空白ページを処理すると元の bbox が維持されるっぽいので大丈夫）。この2パターンに対して bbox = 0 0 0 0 への例外処理を加えれば良さそうです。 |
|
ええと，「白紙ページが存在したらそのページはそのまま出力される」と言うことですよね．なんだかあまりこれを意図して使われるところが想像できないのですが…… |
白紙ページを見つけたら単にそのページをスキップして、空白でないページだけ出力するということでしょうか。うーん、どちらがよいでしょう？ 私の bcpdfcrop は複数ページ処理を単一ファイル出力と分割ファイル出力の両方に対応すべく、枚数を維持する方を優先しました。真っ白なページは要らないという考えも一理ありますね。 あと、bbox が 0 0 0 0 になる他の例としては「CropBox の内側は確かに真っ白だが、その外側でかつ MediaBox に入っている部分にはなんか物体があるとき」です。gs の bbox デバイスは CropBox の中しか検知しない一方、pdfTeX に mediabox を使わせるのでインクルードすればその外側が描画されて出てくるという現象が起きます。TeX2img で意図する人はいないでしょうが… |
そうではなく，「白紙ページがあったらユーザにその旨を伝える」というのが一番の意図です．（既にそうなっていたらすみません．）（基本的にはエラー扱いして何も出さなくてよいかなとも思っていますが．）意図して空白ページを生成するよりも，間違って白紙ページを作ってしまう方が遙かに多いだろうというわけです． pdfcropの場合は白紙ページが入力に意図して含まれることも多いと思います．そもそもTeX2imgとは目的が異なるものですし…… |
それだと golden_lucky さんの牛耕式みたいなのが通らなくなってしまうなあと思います。意図していない空白ページが末尾にあって、でも対処法がよくわからないみたいなのは往々にしてあるかなと。 |
|
繰り返しますが，「白紙ページがあったらユーザにその旨を伝える」のがどうかと言うことです． |
そこまで必要性を感じていません。この場合は出力を見れば明らかなので敢えて言わなくても、と思います。考えるべきなのは、先ほど私が出した
と、Mac 版のような
のどちらを採るか、かつそれらの場合にメッセージを出すべきかという最も自然な組み合わせですね。 |
|
うーん，「勝手に空白ページはそのままページをはき出す」という仕様が「最も自然である」とはやはりまだ思えていません． |
|
自分で言い出しておいて何ですが，結構面倒ですね．あまり例外処理をしたくないのですが． ところで，eps->画像の変換では，新しくepsを作りそれに古いepsを取り込ませているようですが，そうしている理由は何かあるのでしょうか？単にもともとのepsにGhostscriptをかますだけでは何か不都合がある？ |
|
上のを単にかますだけに変更したので，何か不具合があるかもしれません． |
|
Ver. 1.9.6 beta 6 を作りました。
→ 対応しました。
複数ページがスキップされた場合は，最後にまとめて のように表示させるようにしました。
→ 修正できたはずです。
→ epstopdf はゼロ幅のEPSを処理するとエラーを吐くようですので，ゼロ幅のページは epstopdf を経由しない別経路を通るように例外対応することで修正しました。
どうでしたっけね……。Windows版を作ったのはかなり昔だったので記憶にありません……。（現在のMac版ではその変換法は用いておりません。）
Mac版では，HiResBoundingBox を用いて EPS からビットマップ画像に変換すると，小数点以下の値を持つ BoundingBox から整数値の縦横ピクセル幅を持つビットマップ画像に変換する際に，丸め誤差で BoundingBox の端の方が切り捨てられる現象が見られました。 |
ありがちですね（笑）とりあえず問題なさそうなので変更してみます．
なるほど，とりあえずBoundingBoxを使うように戻しました．（PDFに変換するときは大丈夫ですかね？） |
|
丸一日外出していたので、テストが遅くなりました…すみません。 Mac 版 Beta 1.9.6 beta6 で、「余白をつけたビットマップ画像」が画質優先・速度優先ともに「スキップするのにメッセージを出さない」状態になっていることが分かりました。意図しているのは「スキップせず余白の分のキャンバスを持つビットマップ画像を出す」だと思います。他は動いているようです。 例外処理、スキームが多いと難しいですね… |
テストありがとうございます。Ver. 1.9.6 beta 7 で修正できたはずです。 |
|
Windows 版、ようやくテストしました。遅くなって申し訳ありません。
あとは大丈夫そうです。でも上に書いたのもそんなに問題ない気がします… |
あくまで「白紙ページはミスだろう」と思っての警告です．
あーそうですね．epsのマージンを増やすときにいったん解像度レベルで割っているので，5/6 = 0となっているんだと思います．ページが空とか関係なく問題になる気がしますね．極力分岐を起こさないようにしたのが失敗しました．少し考えてみます． |
白紙だったら心配されかねないので、警告があるとありがたいでしょうね。
やはりそこでしたか。余白のつき方が白紙かどうかにかかわらず本来と違うことになるのはそのとおりですね。 |
|
うーん，上で書いたEPS→IMGの処理方式の変更が早速裏目に出たようです．（とはいえ問題自身は前々からあったように思われますが．）translateは多分整数じゃなくても大丈夫ですよね？仕方ないので戻します．（がやらなきゃならないのにやっていないことがあるのを思い出したのでそれが終わってからで……．） |
Mac 版 Ver. 1.9.6 beta 7 では画像変換およびメッセージはすべて意図したとおりになっているように思います。空白ページの扱いがキャンバスが0の場合も余白付きの場合も、ビットマップでもベクターでも、画質優先でも速度優先でも、テキスト保持でもアウトライン化でも正常のようです。ありがとうございます。 |
|
Windows版のように，「白紙ページに余白付与した結果白い画像が生成された」場合にその警告を出すようにもしてみようと思います。今しばらくお待ちください。 |
|
#16 とあわせて，Ver. 1.9.6 beta 8 で，「白紙ページに余白付与した結果白い画像が生成された場合に警告を表示」する機能を付けました。 |
|
Mac 版 Ver. 1.9.6 beta 8 を試しました。
警告が出るようになったのを確認しました。問題ないと思います。 |
今改めて確認しました。TeX2img (Windows/Mac) の動作の詳細（改訂版）の
は，正しくは
となります。（PDF→PDF の変換においては，px 単位の余白付与ができないからです。） |
ありがとうございます。記事を修正しました。 |
|
eps --> jpg等を元に戻して，更にtranslateに整数に切らない値を与えることにしました．PostScript全然知らないのでいいのかわかりませんが……とりあえず動いているっぽいです．
も厳密にはかつある意味では嘘ですね．しかし細かいことはうるさい気もするのでまぁいいか……．
実はこっちは（結果的には）あまり手を加えていません．例外処理もあまり無し．API呼び出しによる複雑さ故でしょうか． |
|
Windows 版を試しました。
大丈夫そうです。ひとつだけ、Windows 版は生成画像のうち最初の一枚をプレビューする仕様ですが、1ページ目がスキップされた場合に欠番となった equation-1 がプレビューされうることに気づきました（前回の TeX2img 処理で当該ファイルが生成していた場合など）。画像が全てスキップされた場合はプレビューしないので大丈夫そうですが、「同じディレクトリにある“数字がいちばん小さいファイル”をプレビュー」になっているような気がして若干気になりました。
確かに Mac 版は「画質優先モード」と「速度優先モード」で gs を使ったり OS X の API を使ったりしているので、複雑になった感じはありますね。 |
別のプログラムが生成している可能性を忘れていました．生成された一番最初のファイルをプレビューするようにしました．（前々から）複数ページの場合はどれをプレビューするべきかは悩んでいます． |
Windows 版、確認しました。ありがとうございます。
Mac 版は「生成した画像全て」をプレビューするようになっていますが、これは合わせても合わせなくても良いと思っていました。 別件ですが、#23 で「CUI 版の「ソース埋め込み」をデフォルトで OFF にしよう」という話が出ていますが、いかがでしょう。Windows 版は GUI の設定を引き継ぐわけですが、プレビューオプションと同様に GUI の設定を無視する形となると思いますが。 |
あ，そうなのですね．どっちが便利ですかねぇ．まぁとりあえず今のままでよいか……．
これはあっちに書いた方がよいですね． |
出力に白紙ページが含まれる場合，モードによって色々とおかしな挙動を示す。
特に，「速度優先モード かつ ビットマップ出力」の場合に，出力に白紙ページが含まれると，コンパイル後は二度と Command+T によるコンパイルが効かなくなってしまう。
The text was updated successfully, but these errors were encountered: