search

doraTeX / TeX2img

TeX2img for macOS
https://tex2img.tech
Other
26 stars 2 forks source link

/Rotate 付きのPDFを入力時に「ページサイズを維持」すると回転が反映されない #56

Closed doraTeX closed 8 years ago

doraTeX commented 8 years ago

現象

としたとき，回転が反映されずおかしな出力になる。

原因

「元のページサイズ」を取得するために，OS X の API によって，指定された PageBox の値を取得しているが，その値は回転前のPDFにおける値。余白付与のために pdfTeX に食わせるが，

ため，おかしなことになっている。

/Rotate の情報は OS X のAPIで取得可能なので，それを取得して，pdfTeX に与えるBB値を，回転を考慮した後の値に修正すればよいと思われる。

検証すべきPDF

検証用ファイル群 の test-1.pdf, test-2.pdf について，それぞれ /Rotate 90, 180, 270 を付けて，元のページサイズ維持で画像をテストしてるとよい。

注意点

Preview.app は MediaBox の左下が原点でないPDFを回転すると，全ナントカBoxの場所が平行移動（MediaBoxの原点の座標を引くようにずれる模様）してずれてしまい，見た目も変わってしまう。 これは Preview.app の仕様なのかバグなのか分からないが，ともかく Preview.app は MediaBox の左下が原点でないPDFはサポート外の模様。 よって，正しく /Rotate を付けるには，Adobe Acrobat で回転する必要がある。

doraTeX commented 8 years ago

Ver. 2.0.7 beta 1 で対応できたと思います。 テスト用ファイル群はこちらです。

aminophen commented 8 years ago

Mac 版 Ver. 2.0.7 beta 1 は期待どおりに動いているように見えます。 Windows 版（pdfTeX で元のナントカ Box を取得）の場合に関連の問題が起きるのかどうか等は、まだ確認しておりません。

aminophen commented 8 years ago

pdfTeX による bbox 取得の時点では回転前の bbox が返ることを確認しました。ということは、やはり pdfTeX を使う Windows でも「/Rotate があるかどうか」を取得しなければならないということでしょうか？（すみません、まだ Win 版は動かしていません）実際に /Rotate 付き PDF をとりこんだ PDF を出力すると回転後の bbox が適用された状態になりますので、どこかで bbox が置き換わっていないとおかしいのですが、その状態を外から見ることが可能かどうかは不明です。

とはいえこれは「PDF 入力」でないと起こりえないので、非公式のままの Windows 版にとっては範囲外かもしれません。（例によって前処理すればよいですし）

doraTeX commented 8 years ago

pdfTeX を使う Windows でも「/Rotate があるかどうか」を取得しなければならないということでしょうか？ その状態を外から見ることが可能かどうかは不明です。

extractbb にかけてみて，その警告を見てみれば /Rotate の値が分かるのではないでしょうか。

Mac版では，回転角に応じて新しいBB（新しいMediaBoxに対する相対値）を次のように手動で計算しています。

    // 回転情報の考慮
    NSInteger rotation = pdfPage.rotation;
    if (rotation == 90) {
        rect = CGRectMake(rect.origin.y,
                          mediaBoxRect.size.width - rect.origin.x - rect.size.width,
                          rect.size.height,
                          rect.size.width);
    }
    if (rotation == 180) {
        rect = CGRectMake(mediaBoxRect.size.width - rect.origin.x - rect.size.width,
                          mediaBoxRect.size.height - rect.origin.y - rect.size.height,
                          rect.size.width,
                          rect.size.height);
    }
    if (rotation == 270) {
        rect = CGRectMake(mediaBoxRect.size.height - rect.origin.y - rect.size.height,
                          rect.origin.x,
                          rect.size.height,
                          rect.size.width);
    }
aminophen commented 8 years ago

なるほど… しかしいつまでも extractbb が同じ警告を出すとは限らないのでちょっと怖いです。より安全なのは pdfinfo でしょうか？（poppler と xpdf で微妙に /Rotate 値の表示場所が異なるけれど…）

ちょうどいま TeX Forum の dvipdfmx.cfg の話題が tex-live list に移行し、そこから派生して PDF の /Rotate 問題があがり、さらに XeTeX list に飛び火しているところです。強い要望を出せば (x)dvipdfmx と XeTeX の /Rotate 問題をなんとかしてくれないかな…？

abenori commented 8 years ago

手元で直しています．

extractbb にかけてみて，その警告を見てみれば /Rotate の値が分かるのではないでしょうか。

その発想はなかった……．手元ではMuPDFで取得しています．（ついでに各種Boxの取得もmudrawにつけてそっから取得するようにしました．）

とはいえこれは「PDF 入力」でないと起こりえないので、

pdftexならば/Rotateもはける疑惑があります（笑）

aminophen commented 8 years ago

手元で直しています．

ありがとうございます。

abenori commented 8 years ago

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

とりあえずおいてみます．（まだあまり試していません．）mudrawも新しくなっていますので，そっちも忘れないように．

abenori commented 8 years ago

（例によって前処理すればよいですし）

これ見て思いましたが，自分で計算せずとも一番最初にGhostscript -sDEVICE=pdfwriteあたりで「前処理」してしまえば終わりでしたね……

aminophen commented 8 years ago

前処理のしかたによってはあまり嬉しくなくて、縦書き PDF を一旦 gs に通す場合は表示が乱れる恐れがあります。アウトライン化後なら問題ありませんが、テキスト保持 PDF 出力の場合はこの乱れが困った結果になります。gs はなるべく通したくないのが本音です。

pdfTeX ならば /Rotate もはける疑惑

たしかに…笑 よほどの物好きですね。（我々 bbox ヤクザも同類ですが…）

abenori commented 8 years ago

確かにそうですね．そうするとpngとかを作る際もpdfiumdrawやmudrawを使っての変換にした方がよいのかしら．

aminophen commented 8 years ago

そうするとpngとかを作る際もpdfiumdrawやmudrawを使っての変換にした方がよいのかしら．

そういえば、実は png などがいまどうやって作られているのか把握できておりません（最近全然「動作の仕組み」の解説も更新できていませんね…）。かつては「テキスト保持 PDF / SVG を除き、Win 版はとにかくアウトライン化 EPS 経由」でしたので、このアウトライン化のおかげですべて正常に画像化されていました。gs のアウトライン化は縦書きかどうかに関わらず正常にできるのでこれで問題なかったわけです。いまはどうなっているのでしょう？

aminophen commented 8 years ago

ようやく Win 版を試してみました。簡単なテストしかしていませんが、mudraw での bbox 取得ができているようです。機能拡張すごいです…ありがとうございます。

普段あまり PNG 出力を使っていないので、久々に使ってみました（普段は解像度10、余白5bpの PDF or EMF 出力を使う機会が多いです）。Win 版はそういえば HiRes を使うようにしたのでしたっけ？ なんだか端が切れやすくなっている気がします。デフォルトの「解像度6、余白0px」だと

\documentclass{tarticle}
\pagestyle{empty}
\begin{document}
あいうえお \LaTeX かきくけこ
\end{document}

を PNG 出力したときに「こ」の二画目が消滅してしまいました。

abenori commented 8 years ago

問題があるのは，PDFの「描画」部分なんですかね．pngは以前と変わっていないはずで，PDF--(eps2write)→EPS--(png16mとか)→PNGです．他はソース読まないとわかりません……．時間がとれたらまとめておきます．

Ghostscriptの（とりあえず怪しそうな）pdfwriteを使っているは次の場所みたいです．

abenori commented 8 years ago

Win 版はそういえば HiRes を使うようにしたのでしたっけ？ なんだか端が切れやすくなっている気がします。

計算間違いか何か勘違いかしているかもしれないです．後で試してみます．

aminophen commented 8 years ago

問題があるのは，PDFの「描画」部分なんですかね．

出力が gsview であろうと PDF であろうと縦書き PS を入力すると見た目がおかしくなりますので、必ずしも PDF の描画だとはいえないかなと思って実験してみました：

ということは

でしょうか（説明わかりにくくてすみません…）。おもしろいことに、ヒラギノの場合は上記 PDF → PDF で箱とグリフがずれるのですが、IPAex の場合はずれずに元のままになりました。

aminophen commented 8 years ago

↑ の推測からすると、結局 TeX2img に即して gs がダメなのは「gs を通って出てくるのがフォントを保持した PDF の場合」ですね。よって

Ghostscriptの（とりあえず怪しそうな）pdfwriteを使っているは次の場所みたいです．

のうち「.pdf / .emfを作る際にepsから変換」は eps が既にアウトライン化されているからセーフ、「PDFを一つのファイルにまとめる処理」はアウト（あれ、これは pdfTeX だと思っていたのだが…）、「PDFにMuPDFで注釈を入れると「変な」PDFができるので，それを直すための処理」はアウトになります。

abenori commented 8 years ago

これは pdfTeX だと思っていたのだが

1.6.6でGhostscriptにしました．（速いので．）こっちはpdftexでも処理できますが．最後の注釈を直す部分はpdftexではできないので，困りますね．まぁ仕方ないかー

aminophen commented 8 years ago

「注釈を直す」というよりはむしろ、そもそも mudraw が吐く PDF の xref table が正しくないのが問題ですよね… 注釈が悪いのではなく本家本元の mudraw が悪いのだと思います。

aminophen commented 8 years ago

たぶん mudraw が吐く PDF の場合、「xref table は20バイト固定長ブロックでなければならない」という規則に反する空行が入っているのが問題なのでしょう…（trailer の上の空行に注目）

xref
0 7
0000000000 00001 f 
0000000017 00000 n 
0000000063 00000 n 
0000000115 00000 n 
0000000186 00000 n 
0000000248 00000 n 
0000003162 00000 n 

trailer

フォーラム最初の IGOR の例だと末尾の [LF] が [SP][LF] になっていなくてアウト、同じフォーラム末尾の GeoGebra の例は mudraw と同様に trailer 直前の空行がアウト。PDF の解説はここが詳しいですね。 追記：PDF の仕様的には mudraw と GeoGebra は問題ないけれど、dvipdfmx はダメな PDF とみなしてしまう。（IGOR は本当に不正！）

abenori commented 8 years ago

このくらいならば直せるかもしれませんね．時間がとれたときに見てみます．

abenori commented 8 years ago

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

あれ？直った？＜mudraw

PDF結合はpdfiumdrawでしています．

aminophen commented 8 years ago

とりあえず mudraw が xref table を正常に出すようになったっぽいことを確認しました。ありがとうございます。trailer のすぐ上の空行ひとつというのは実に細かい…。

ところで、昨日「ウイルスバスタークラウド10」をインストールしたのですが、そのあとから「ソース埋め込み」のときに時々ブロックされて、TeX2img のプロセスが落とされるという現象に見舞われました。（これは正式リリース済みの TeX2img Ver 1.6.6 でも確認）

tex2img-virus

例外リストに追加すれば、次回以降は正常にソース埋め込みが可能になります。PNG や EMF はソース埋め込みできるのに PDF だけブロックされるのでちょっと不思議です。（てっきり拡張属性をいじっているのが原因かと思ったのですが、PNG とかがブロックされないっぽいのでよくわかっていません）

aminophen commented 8 years ago

ウイルスバスターにブロックされる件、PDF 以外にも PNG でも数回再現しました。ただ、ソース埋め込み PDF でも数回に一回は再現しないこともあり、まったく理由がわかりません。私の環境固有かもしれないので無視してください。

本題のほうは、mudraw の xref table が正常化し、PDF 結合は pdfiumdraw になったので gs が縦組みを崩す問題とは無縁になりました。/Rotate も mudraw が正しく取得しているように見えます。

abenori commented 8 years ago

なんか超話が脱線していますが……

png出力を試してみましたが，こちらでは特に二画目が消えることはないようです．微妙に消えてしまっている気もするのですが，消えているのかぎりぎりで生きているのかよくわかりません…… equation

aminophen commented 8 years ago

すみません！ PNG はビューアがなんか端っこを表示していないだけでした。pdfiumdraw が出力する EMF は余白0だと本当に切れているようです（今度は横書き）。E の下の画が存在しなくなっていました。

emf-pdfiumedraw

aminophen commented 8 years ago

もうひとつ、mudraw の件で気づいているのが、テキスト保持 PDF に

$ mudraw -o out.pdf in.pdf

を実行すると

error: pdf device supports only base 14 fonts currently
warning: Ignoring error during interpretation

で base 14 fonts 以外（日本語などすべて）が落ちます。これはちょっと困りました… しかしソース埋め込み処理では起きないので大丈夫そうです。

abenori commented 8 years ago

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

PNGはプログラムを書いてチェックしてみましたが，1ポイント切れることがあるのがわかりました．念のため縦横+1してみました．もう少し調べてみます．

EMFも手元ではそこまでは切れてないです…あれ？こちらも縦横+1してみました．

eq
aminophen commented 8 years ago

EMFも手元ではそこまでは切れてないです…あれ？

あっ、違いの理由がちょっとだけわかりました。私が「EMF が切れる」と報告したのは PowerPoint に貼りつけた場合の結果です（実用上は Inkscape で開くのではなくそれがメインなので）。今日 texconf15 で #57 について doraTeX さんとお話したのですが、どうやら Mac 版 Office が EMF を表示するとき「EMF 自体に余白がなくても、勝手にその外側まで表示する（結果的に余白が付いたかに見える）」ようです。これと同じで Windows 版 Office も、EMF に実際に書かれている内容と異なる範囲を表示するということかもしれません。実際、手元で Inkscape で開くと abenori さんと同じ見え方になります。

…となると pdfiumdraw のせいではないようですが、実用上ちょっと不便ではあります（まあ私は TeX2img の余白機能をデフォルト 5 にしているので切れたことはないですが…）。

abenori commented 8 years ago

静かに集い参加の自慢をされましたね（笑）

Officeでは端が切れてしまうので，チェックは常にInkscape（かペイント）でしていました．pdfiumdrawに--scale=10を渡して10倍にしてみたら，切れていない気もします．デフォルトは小さすぎると思っていたりもするので，これを渡してみるのはどうでしょう．自分では使わないので普段使っている方の感想があると助かります．

aminophen commented 8 years ago

静かに集い参加の自慢をされましたね（笑）

すみません(^^;) Mac 版ベータ直前のモノを直にみて確認できて有意義でした。来年は是非！

pdfiumdrawに--scale=10を渡して10倍にしてみたら，切れていない気もします．

確かに --scale=10 だと切れませんね。大してサイズも増えませんし、拡張子関連付けの関係でペイントが開く場合もそのほうが見やすくて良いです。若干気になったのが破線が吹っ飛ぶ件ですが、これは「--scale が大きいからダメ」みたいな相関関係はなさそうだった気がするので、--scale=10 に賛成です。

abenori commented 8 years ago

--scale=10 --extent=5を渡すことにして公開しました

abenori commented 8 years ago

ちなみに現在の変換等々はこんな感じです（tex2img.pdf）．

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

aminophen commented 8 years ago

--scale=10 --extent=5を渡すことにして公開しました

了解です！

ちなみに現在の変換等々はこんな感じです（tex2img.pdf）．

わかりやすい資料をありがとうございます。参考にさせていただきます。