Closed doraTeX closed 8 years ago
Illustrator での見た目は
TikZ のパターンはかなり細かい斜線の集合体ですので、相当見辛いです。例示 PS ファイルのパターン辞書の中のパラメタ(XStep、YStep、BBox、PaintProc の中の座標)を互いに重ならないように弄ってみると良いでしょう(これならアウトライン表示にしなくても正常)。
Mac版は pdftops を既に内包していますので,もし gs での emulate 法が見つからなければ,アウトライン化SVG生成はこの経路で行くことにしましょう。
悩ましいのがテキスト保持 SVG です。xxx... がいったん EPS のソースに書かれてしまうと、その「パターンを描くための文字」と「もともとのテキスト」が混ざってしまい、もはや分離できなくなります。その手前でパターンの文字だけをアウトライン化できれば理想なのですが、それには「pdftops を使わずエミュレートする」しか方法はありません。
エミュレートは gs と PostScript 芸では非現実的です。PS のオペレータの再定義でやらないといけないのですが、相当難易度が高いです(たぶん makepattern と setpattern がスタックされているときの fill 系を再定義するのでしょうが、ざっと見たところ .dashpath や strokepath のときのような専用のオペレータがない)。むしろ pdftops の当該部分のコードを TeX2img のバイナリに取り込んでしまえば、パターンのアウトライン化も同時に可能かもしれません。あとは Adobe TechNote を参考に独自にコードを書くとか…
これまでも,テキスト保持PDFはIllustratorに配置するとフォントが化けたりすることから,「見た目を確実に維持したいならフォントのアウトライン化」ということを定石としていました。ですから,SVGについてもそれを適用して,「テキスト保持SVGで見た目が変わる場合はアウトライン化せよ」ということでいいのではと思います。
ではそうしましょう。アウトライン化 SVG については上記の pdftops 経由に決定するのが現実的でしょう。とはいえ現状のスキームからあまり変えたくないのですが、その場合今のアウトライン化 PDF 出力に続けて pdftops → pdfwrite/epswrite+epstopdf → mudraw がよいですね。
ふと gs9.14 以下の EMF もパターンが欠けたりしないか心配になりました。gs9.15 以上では pdrops を通っていますが、未満では epswrite なのでどうなのでしょう?
今のアウトライン化 PDF 出力に続けて pdftops → pdfwrite/epswrite+epstopdf → mudraw がよいですね。
その経路で行くと,gs 9.15 未満のときにおかしくなりました。
gs 9.15 以上:TeX → PDF →[pdftops]→ EPS →[epstopdf]→ PDF → [gs pdfwrite]→ PDF →[mudraw]→ SVG gs 9.14 以下:TeX → PDF →[pdftops]→ EPS →[epstopdf]→ PDF → [gs epswrite]→ EPS →[epstopdf]→ PDF →[mudraw]→ SVG
という経路ならOKです。フォント情報が残ったまま pdftops にかけるのが怖かったのですが,やってみたら和文フォントや数式フォントを含めて,後半できちんとアウトライン化ができているようです。
ふと gs9.14 以下の EMF もパターンが欠けたりしないか心配になりました。gs9.15 以上では pdrops を通っていますが、未満では epswrite なのでどうなのでしょう?
左が 9.07, 右が 9.18 による変換結果を Excel に張ったものです。どちらもイマイチですね。
という経路ならOKです。フォント情報が残ったまま pdftops にかけるのが怖かったのですが,やってみたら和文フォントや数式フォントを含めて,後半できちんとアウトライン化ができているようです。
ありがとうございます。不思議ですが先に pdftops にかける方法を採用しましょう。テキスト保持 PDF は現状維持が無難ですかね。
EMF はどうしましょう… やはり pdftops をかませるのがよいでしょうか?
EMFのことはまた後で考えるとして,まだSVG生成が安定しません……。 gs 9.15 以上と未満で,経路を大きく分けた方がよさそうな感じがしてきました。(片方でエラーを抑えるともう片方でエラーが発生したりするのに悩まされています。) もはや,EMF同様,アウトライン化SVG生成に専用の経路を用意した方がよい感じになってきました。
まだSVG生成が安定しません……。
pdftops は PostScript Language Level 1 の範囲に自らを縛ってしまうようで、パターンが保持されても他の場所にしわ寄せが行くことは十分考えられるのですよね。どうするのがよいかまだわかりません… やっぱりどうにかして PostScript コードを書いて emulate しないといけないでしょうか?
Ver. 2.1.5 beta 3 で,アウトライン化SVG生成を安定化させることができたのではないかと思います。
経路は先程の
gs 9.15 以上:TeX → PDF →[pdftops]→ EPS →[epstopdf]→ PDF → [gs pdfwrite]→ PDF →[mudraw]→ SVG gs 9.14 以下:TeX → PDF →[pdftops]→ EPS →[epstopdf]→ PDF → [gs epswrite]→ EPS →[epstopdf]→ PDF →[mudraw]→ SVG
です。 複数ページ対応,白紙ページ対応,背景塗りなども一通りチェックしました。
これでたぶんアウトライン化SVG生成におけるパターン塗りはなんとかなったと思いますが,おそらく,EMFの他にもパターン塗りが失敗する出力形式がまだいろいろあるのではないかと思われます。 そこでテスト項目にパターン塗りを加えました。また包括的なチェックが必要になりますね。
Ver. 2.1.5 beta 3 は、パターン塗り EMF が PowerPoint 2011 for Mac で「イメージを表示できません」ですね。やっぱり EMF もなにか対策をとらないといけませんね。
アウトライン化 SVG 出力で「半透明図版」のページがクロップされていないですね。テキスト保持 SVG は大丈夫でした。うーん…
アウトライン化 SVG 出力で「半透明図版」のページがクロップされていないですね。
これは対策しました。
Ver. 2.1.5 beta 3 は、パターン塗り EMF が PowerPoint 2011 for Mac で「イメージを表示できません」ですね。
こちらでは再現しません。gs 9.07, 9.18 の両方で試しましたが,これと同じ結果でした。
Ver. 2.1.5 beta 3 は、パターン塗り EMF が PowerPoint 2011 for Mac で「イメージを表示できません」ですね。
こちらでは再現しません。
単にメモリ不足で落ちているだけかもしれません。もう少し調べてみます。
全然違う方向性ですが,svgが見えないのが不思議だったので調べてみました.どうもviewBoxを外れてしまって見えていないようです.
これが最初のソースで作った見えないsvgです.
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"[]>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" viewBox="0 0 142.13 142.13">
<clipPath id="cp0">
<path transform="matrix(.057396,0,0,-.057396,0,142.13)" d="M 3.46875 3.46875 L 2472.8687 3.46875 L 2472.8687 2472.8687 L 3.46875 2472.8687 Z " />
</clipPath>
<g clip-path="url(#cp0)">
<symbol id="pac1">
<g clip-path="url(#cp2)">
<path transform="matrix(.057396,0,0,-.057396,-148.693,667.226)" stroke-width="6.94299" stroke-linecap="butt" stroke-miterlimit="10" stroke-linejoin="miter" fill="none" stroke="rgb(0,0,0)" d="M 0 0 L 53.8086 53.8086 " />
</g>
</symbol>
<pattern id="pa1" patternUnits="userSpaceOnUse" patternContentUnits="userSpaceOnUse" x="0" y="0" width="2.98883" height="2.98883">
<clipPath id="cp3">
<path d="M -.99628 -.99628 L 3.9851 -.99628 L 3.9851 3.9851 L -.99628 3.9851 Z" />
</clipPath>
<g clip-path="url(#cp3)">
<g transform="matrix(1,0,0,-1,148.693,667.226)">
<use x="0" y="0" xlink:href="#pac1" />
<use x="0" y="-2.98883" xlink:href="#pac1" />
<use x="-2.98883" y="0" xlink:href="#pac1" />
<use x="-2.98883" y="-2.98883" xlink:href="#pac1" />
</g>
</g>
</pattern>
<clipPath id="cp2">
<path transform="matrix(.057396,0,0,-.057396,-148.693,667.226)" d="M -18 -18 L -18 70 L 70 70 L 70 -18 Z " />
</clipPath>
<rect transform="matrix(1,0,0,-1,-148.693,667.226)" fill="url(#pa1)" x="148.89209" y="525.2951" width="141.73368" height="141.7337" />
</g>
<path transform="matrix(.057396,0,0,-.057396,0,142.13)" stroke-width="6.94299" stroke-linecap="butt" stroke-miterlimit="10" stroke-linejoin="miter" fill="none" stroke="rgb(0,0,0)" d="M 3.46875 3.46875 L 2472.8687 3.46875 L 2472.8687 2472.8687 L 3.46875 2472.8687 Z " />
</svg>
これの10行目,18行目,27行目のtransform=matrixの値をそれぞれ次のように書き換えます.
こうするとパターンがよみがえりました.いろいろ数字を変更してみると,ちょうどviewBoxを超えたあたりで消えるので,おそらくtransformしすぎて外に出て描画されていない(その後戻すのだけどそれは無視)ということなんじゃないかと.
EMF生成経路を調整しまくった結果,ここまで持ち込めました。
左が gs 9.07, 右が gs 9.18 の場合です。 これくらいで合格点としてよいのではないかと思います。
調整後の新EMF生成経路は以下の通りです。
TeX → PDF →[pdfTeXでクロップ+余白付与]→ PDF(ここで Quartz API で背景塗り)→[gs pdfwrite]→ アウトライン化PDF →[pdftops]→ EPS →[stroke修正処理を仕込んでからpstoedit]→ EMF
TeX → PDF → [pdftops] → EPS → [stroke修正処理を仕込んでからepstopdf]→ PDF →[pdfTeXでクロップ+余白付与]→ PDF(ここで Quartz API で背景塗り)→ [gs epswrite] → EPS →[pstoedit]→ EMF
現時点での最新版を Ver. 2.1.5 beta 4 としてビルドしました。
見えないのが不思議だったので調べてみました.どうもviewBoxを外れてしまって見えていないようです.
ありがとうございます。なんかズレているのは確かなのですね(PDF のときも BBox をはみ出してタイルが描画されている気がしたので)。ソースがテキストで書かれている SVG をうまく修正できれば、それもよいと思います。
EMF生成経路を調整しまくった結果,ここまで持ち込めました。
EMF の変換経路、難しいですね… 調整ありがとうございます。あとで動かしてみます。
mudrawをいじっています.とりあえずmupdf\source\pdf\pdf-on-run.cのTILEの#defineを外してやるとタイルの繰り返しを展開してたくさんのパスとして処理してくれるようになるようです.手元では(テキストの有無に限らず)最初のソースは処理されています.
ソースがテキストで書かれている SVG をうまく修正できれば、それもよいと思います。
あれ,テキスト保持SVGはうまくいっていないと思っていたのですが.何か勘違いしているかな?
とりあえずおいておきます.mudrawが座標をいじったもの,mudraw2がたくさんパスを描くようにしたものです.
なんかズレている
ズレているというのは不正確な言い方かもしれません.たぶん,パスを描く時にtransformで飛ばし(このときviewBoxを超える)パターンとして描く時に飛ばした分戻す,としているように見えます.SVG的にいいのかだめなのか知りませんが,とりあえず手元のFirefoxではそのせいで描画されていないように見えました.
EMFはpdfiumdrawでやろうとすると固まるようですが,これは大きいやつの外が描画されないのの対策をしたことが悪さをしているようです.どうすれば両立できるか考えてみます.
とりあえずリンク先のpdfiumdrawを対策を外したものに置き換えてみました.ただ,いずれにせよデフォルト(--extent=50)だと200M近いファイルができてしまいます.TeX2imgから呼び出すときも--extent=5 --scale=10なので同じです.頑張りすぎだろ……
pdfiumdrawを更新しました.最初の例もまともに出ると思います.
まず Mac 版です。
現時点での最新版を Ver. 2.1.5 beta 4 としてビルドしました。
SVG は綺麗に出るようになりました。クロップも正常にできるようになっていました。
EMF を Office 2011 に貼ると「イメージを表示できません。」となるのが不思議で、該当する EMF を Illustrator CS5 で開いてみるとまったくの白紙でした。そもそも描画できていないようです…
「表示できません」な EMF のファイルサイズは、本来は図版があるはずのファイルも白紙透明のファイルも一律に 304 byte でした。
gs のバージョンはどれをお使いですか?
すみません,gs 9.15 以上経由のときにPDFロンダリングするのを忘れていました。 Ver. 2.1.5 beta 5 でPDFロンダリングを行うようにしましたので大丈夫なはず……!
gs 9.15 以上経由のときにPDFロンダリングするのを忘れていました。
なるほど、そういうことでしたか。これで半透明図版以外の EMF は gs9.16 でも gs9.05 でも正常化しました(白紙透明のページは「イメージを表示できません」ですが、まず要らないので問題なし)。「半透明図版」については、gs9.16 では「イメージを表示できません」で、gs9.05 ではクロップされない図が表示されました。
半透明は,他の出力形式でもまともに出力できることが少ないので,EMFの場合はなおさら苦しいです。半透明は諦めるということでいいのではないかと思います。
半透明は諦めるということでいいのではないかと思います。
やっぱりそうですね。ざっと見たところ他は問題なさそうでした。
SVG については、あとで Windows 版を動かして「mudraw の改変によるパターンの平易化」と「pdftops 経由」を比較してみるつもりです。pdftops がどういうツールなのかまだよく知らないものでして、もう少しいろいろ試してみます。
pdftops がどういうツールなのかまだよく知らないものでして、もう少しいろいろ試してみます。
「@doraTeX さんと私で、同じコマンドで SVG のサイズが違う」の原因が分かりました… そしてちょっと厄介な問題が出てきました。
port では conflict を防ぐために Poppler のほうを標準とし、Xpdf のほうはすべて xpdf-*\ という名前に変更してあります。そして、私が CUI 版 tex2img で「パターン塗り」を成功させるには xpdf-pdftops という名前のプログラムを起動しなければならない状態です:
Poppler は Xpdf の「Type3 フォントを並べることによるエミュレート」を嫌ったようで、わざわざソースを変えて Level 2 以上の場合に本来のパターン塗りを行うようにしたようです。こちらが port の標準ですので、CUI プロセス起動時にこちらが呼ばれると全く以て今回の「パターン塗りへの対応」が成立しないことになります…
パターン塗り問題への対処法を探すための検証作業はほとんど Windows で行っていたため、そちらは W32TeX に同梱されている Xpdf 3.04 の pdftops でした(ゆえに pdftops を通すとエミュレートできて嬉しいという話はすべて Xpdf を使った実験結果であって正統)。「サイズが違う」の発言だけは Mac で試したので Poppler 0.38.0 だったと思います。ややこしくてすみませんが、まさかこのエミュレートに関する挙動が異なるとは…😱
なるほど,それはちょっと困りましたね。
今CUI版TeX2imgは,/Application/TeX2img.app
や /Application/TeXLive/TeX2img.app
を最優先にサーチするようにしてありますので,GUI版がインストールしてあればCUI版からは Xpdf 3.04 の方が呼ばれるはずです。
一つの手としては,pstoedit
→ eps2emf
のように,GUI版同梱のものを別名に変えてしまうという手も考えられますが,
であれば,1. よりは 2. の方がましであると思われますから,現状維持でいいのかなと思います。
CUI 版 tex2img が最優先で /Applications/TeX2img.app を探すのなら、このままでいきましょう。
ついでにxpdf-pdftopsも探すと良かったりする?
port は /opt/local にイロイロ入れるのですが、かすかな記憶では「xpdf という port をインストールすると xpdf-* が入る」「さらに xpdf-tools という port を入れると xpdf-* の接頭辞がとれた名前になる(この場合 poppler という port をアンインストール必須)」とかだったと思います。
ついでにxpdf-pdftopsも探すと良かったりする?
あ、それはいいかもしれません。助かります。
xpdf-pdftops
を探して,見つからなければ pdftops
をサーチするという順番にしました。~/Desktop/TeX2img.app
→ ~/Applications/TeX2img.app
→ ~/TeX2img.app
→ /Applications/TeX2img.app
→ /Applications/TeXLive/TeX2img.app
→ 元の $PATH
の順番でサーチするようにしました。TeX2img.app/Contents/Resources/pdftops/pdftops
に対してTeX2img.app/Contents/Resources/pdftops/xpdf-pdftops
というシンボリックリンクを張ることにしました。
これにより,TeX2img.app
内の xpdf-pdftops
が真っ先にサーチされます。
現時点での最新版 Ver. 2.1.5 beta 6 です。
アウトライン化SVGを gs 9.18 経由の経路でパターン化した場合の見え方の比較です。
まともです。
ちなみに,このSVGの Illustrator 上での見え方を見ると,以前のEMFと同様,パスの部分や破線の表示がおかしいことに気づきます。例えば:
これはもしやと思って,EMFのときと同様に途中のEPS経由時に stroke 再定義を仕込んでみました。すると……
パス部分は確かに改善されています。
stroke再定義を仕込むと,Illustrator でのパス・破線部の見え方は改善されましたが,せっかく調整したブラウザ上でのパターンの見え方が崩れました。あちらを立てればこちらが立たず,ですね……。
今度は Windows 版の mudraw と pdfiumdraw を試してみました。
pdfiumdrawを更新しました.最初の例もまともに出ると思います.
EMF が非常にきれいに出ていました! これで破線もパターンも、大きなページも大丈夫でしょう。
mudrawが座標をいじったもの,mudraw2がたくさんパスを描くようにしたものです.
あれ、いま置いてあるのはどっちもたくさん「パスを描くようにしたもの」に見えます。が、テキスト保持でも綺麗に出ているような気がします。これは良いかも。 ただちょっとファイルサイズが大きいので、座標をいじったものと比べてみたい気はします。
置き換えました.これで大丈夫かな?
gs 9.15 以上でのアウトライン化SVG生成の経路をさらに調整した結果,出力を改善できました! Ver. 2.1.5 beta 7 としました。
(ただし,パターンを含むページの出力SVGがなぜか Illustrator で開けなくなるという問題点が生じてしまいました。)
TeX → PDF →[pdfTeXでクロップ]→ PDF →[PDFロンダリング] → PDF →[gs pdfwrite]→ アウトライン化PDF →[pdftops]→ EPS →[stroke再定義をしたうえでepstopdf]→ PDF →[pdfTeXで余白付与+背景塗り]→ PDF →[mudraw]→ SVG
これで SVG / EMF,gs 9.15以上 / 未満 のそれぞれがかなりいい具合に調整できてきたのではないかと思います。
パターンを含むページがアニメーションのフレームに入ったときに描画が崩れる問題が解決されました。
当方では,なぜかGUI版では解決されているのにCUI版では微妙に崩れる問題が発生しております……。もう少し調査してみます。
そういえばIllustratorとブラウザで違うことがあるようなので,こちらのsvgをIllustratorで試してもらっても良いでしょうか?上にequation.svgでおいてあります.(やばげな点線,パターン塗り,半透明のセットです.)同じ場所においてあるequation.pdfと同じように見えれば良いのですが.
EMFもと思ったのですが,そもそもこっちでも変ですね.同じソースを処理したら最後のボックスが出てこなかったり.
\begin{tikzpicture}
\useasboundingbox(0,0) rectangle (4,4);
\filldraw[fill=blue,general shadow={%
fill=red,shadow xshift=1,shadow yshift=-1,%
opacity=0.5}] (0,0) rectangle (3,3);
\end{tikzpicture}
\begin{tikzpicture}
\useasboundingbox(0,0) rectangle (4,4);
\filldraw[fill=blue,general shadow={%
fill=red,shadow xshift=1,shadow yshift=-1,%
opacity=0.5}] (0,0) rectangle (3,3);
\end{tikzpicture}
というだけのを処理してみても,左右のボックスが違ったりしています.うーむ.
置き換えました.これで大丈夫かな?
あれ、まだ mudraw が新しくなってないっぽいです…
Illustrator は今いる環境にはないので @doraTeX さんにお任せします。ただ、半透明図版が入ったページはただでさえ苦手なので、一緒に登場するともはやどうしようもないと思ってはいます(どちらか一方の場合なら何とかなるかもしれないけど)。
今自分でダウンロードしてみた限りでは新しくなっているっぽいですが.不思議ですね.もう一度あげてみました.起動直後にDEBUG VERSION!!!みたいに出たら正しいやつです.
ちなみにequation.svgがそのmudrawで生成したやつです.
背景塗りもなんだか変な感じで,
\begin{tikzpicture}
\useasboundingbox(0,0) rectangle (4,4);
\filldraw[fill=blue,general shadow={%
fill=red,shadow xshift=1,shadow yshift=-1,%
opacity=0.5}] (0,0) rectangle (3,3);
\end{tikzpicture}
に対して背景色を塗ると青い四角が消えてしまっていたりしました.背景塗りをpdfiumdraw側にうつして対処したものをおいておきます.
\begin{tikzpicture}[x=1bp,y=1bp]
\useasboundingbox(0,0) rectangle (4,4);
\filldraw[fill=blue,general shadow={%
fill=red,shadow xshift=1,shadow yshift=-1,%
opacity=0.5}] (0,0) rectangle (3,3);
\end{tikzpicture}
として小さくして,縦にたくさん並べると途中から消えてしまいます.「画面サイズ外が描けない」と同じ状況なのですが,単なる文字をたくさん並べると消えずに出力がされています.うーん,不思議…….
こんどは2つの mudraw で全く違うファイルサイズの SVG ができました。gs9.15 以上を使った場合、やっぱりパス分割のほう(DEBUG VERSION!!! が出ないほう)が若干遅くて大きいです(mudraw の変換に3倍くらい時間がかかり、ファイルサイズは15倍くらい)。
ちなみに両方とも「半透明もパターン塗りも入っているページ」を gs9.14 以下で処理すると、両方とも同じファイルができます。もともと半透明のページが苦手な gs がパスを細分化しているため、そもそもパターンが存在しない状態になっているためのようです。
Ghostscriptが頑張ってくれないのはあきらめるしかないですかね…….
手元の9.18はそっちと同じ感じです.Illustratorでの描画がうまく行くようならば,このmudrawでSVGを生成するでファイナルアンサーにします.(上の方の議論は全然理解していないですが…….)
EMF ってもしかして、描けるパスの数に上限があるのでしょうか…? なんかそうとでも言わないと書けない理由が説明が付かない感じですね。(ところで、Win 版がウイルスバスターで落ちるのが気持ち悪いので、脱線防止で Win 版リポジトリに Issue を Open しておきます)
いやーさすがにそんなことはないでしょう……ぴったり画面サイズだし.ちなみにopacity=1にすると枠だけ描画されていました.おそらく塗るところで何か問題があるのでしょうねぇ.
現象
次のソースを TeX2img でSVG化すると,パターンが欠ける。
# 原因~~#34 で,mudraw の最新バージョン対応のために
-l
オプションを外したことが原因。 TeX2img.app に内包されている旧バージョンの mudraw は-l
オプションを受け入れる。#34 の改修前のように,-l
を付けておけば,パターンも無事に保持される。~~# 対策GUI版については,.app に内包されている旧バージョンの mudraw を使っているので,-l
を付けるように戻せばよいだろう。CUI版については,GUI版がインストールされている場合はその中の mudraw を優先的に使い,-l
オプションを付ける。GUI版がインストールされておらず,新バージョンの mudraw のみインストールされている場合は,やむなく-l
なしで実行する。とするのが最善か?# 検討事項新バージョンの mudraw でも旧バージョンの-l
に相当することはできないものか?