-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ベクター画像のパス変形(EMF の破線描画サポート) #68
Comments
eps(2)write でできた EPS の冒頭に例の再定義を書いても、どうやら破線の変形はできないようです… いま分かっていること (1)
%!PS-Adobe-2.0
%%Title: Blue Book Program 5, on page 145
%%Creator: Adobe Systems Incorporated
%%CreationDate: Thu Dec 28 13:19:30 PST 1989
%%EndComments
/oldsetdash /setdash load def % <= 追加(ここでなくファイル冒頭に
/setdash {oldsetdash .dashpath [] 0 oldsetdash} def % 書き込んでも可)
/centerdash
{ /pattern exch def
/pathlen pathlength def
/patternlength 0 def
pattern
{ patternlength add /patternlength exch def
} forall
pattern length 2 mod 0 ne
{ /patternlength patternlength 2 mul def } if
/first pattern 0 get def
/last patternlength first sub def
/n pathlen last sub cvi patternlength idiv def
/endpart pathlen patternlength n mul sub
last sub 2 div def
/offset first endpart sub def
pattern offset setdash % <= ここに setdash 登場
} def
/pathlength
{ flattenpath
/dist 0 def
{ /yfirst exch def /xfirst exch def
/ymoveto yfirst def /xmoveto xfirst def }
{ /ynext exch def /xnext exch def
/dist dist ynext yfirst sub dup mul
xnext xfirst sub dup mul add sqrt add def
/yfirst ynext def /xfirst xnext def }
{}
{ /ynext ymoveto def /xnext xmoveto def
/dist dist ynext yfirst sub dup mul
xnext xfirst sub dup mul add sqrt add def
/yfirst ynext def /xfirst xnext def }
pathforall
dist
} def
5 setlinewidth
newpath
72 500 moveto 378 500 lineto
[30] centerdash stroke
newpath
72 400 moveto 378 400 lineto
[30 50] centerdash stroke
newpath
72 300 moveto 378 300 lineto
[30 10 5 10] centerdash stroke
newpath
72 200 moveto 378 200 lineto
[30 15 10] centerdash stroke
newpath
225 390 300 240 300 arc
[40 10] centerdash stroke
showpage いま分かっていること (2)eps(2)write は /!{bind def}bind def
/#{load def}!
/d/setdash # これが定義されているので、ソース中ではもっぱら |
pdftopsによる出力EPSの場合はいかがでしょうか。 これの場合,途中に /d { setdash } def と定義されています。 (これに対して |
まだ gs9.10 の epswrite の場合しか試していませんが、どうやら
もしかすると直接 以下、
|
さらに簡略化して、 /oldstroke /stroke load def
/stroke {.dashpath [] 0 setdash oldstroke} def |
おおっ,お見事な発見です! |
ありがとうございます😏 EMF 以外の場合はパス変形せずに出力してくれたほうがスッキリしますので、採用する場合ば EMF 限定でお願いします。 |
ところで、肝心の EMF は破線を描けるようになりましたか? 元に立ち返ってちょっと考えたら
|
はい,大丈夫です😄 |
もう一つ面白いことを発見しました。先ほどの /oldstroke /stroke load def % 以降で一度も使っていないけどまあ保存しておこう ;)
/stroke {strokepath fill} def これは破線のみならずあらゆるストローク(太さを持った線分)のアウトラインをとり、その中を塗ります(というつもりです)。ただ、なんか見た目が変わっている気がします… 再定義の中身をもっと検討すれば調節できるかもしれませんが。 |
おおっ,それも朗報です! |
どうやら パスのアウトライン化にメリットがあるのなら、それを PDF などの他のベクター画像形式でも適用するとよいかも…~~と思ったのですが、ついこの前 #66 で gs9.15 以上を極力 pdfwrite 経由のアウトライン化に変更したばかりで、これは諦めざるを得ないかもしれません。~~とりあえず「アウトライン化 EMF」限定で |
/oldstroke /stroke load def
/stroke {strokepath fill} def を試してみたら,期待以上の結果が得られました!
|
よくわかっていませんが,pdfiumdrawにかます前にこんなんすればいいんでしょうか? |
はい、そういうことです。pdfwrite でも、しかもコマンドラインオプションでも成功するっぽいので、#66 の変更を保持したままパス変形も可能ですね! |
ここまで詰めれば「ストロークのアウトライン化 ON」という新機能も可能かもしれませんね。 Windows 版 EMF 出力(古い gs の場合):PDF →[epswrite(.dashpath)]→ EPS →[pdfwrite]→ PDF →[pdfiumdraw]→ EMF Windows 版 EMF 出力(新しい gs の場合):PDF →[pdfwrite(.dashpath)]→ PDF →[pdfiumdraw]→ EMF Mac 版 EMF 出力:PDF →[epswrite(strokepath)]→ EPS →[eps2emf]→ EMF 両バージョン EMF 以外のベクター出力で、かつストロークのアウトライン化 ON(古い gs の場合、または最終出力が EPS の場合)PDF →[epswrite(strokepath)]→ EPS →… 両バージョン EMF 以外のベクター出力で、かつストロークのアウトライン化 ON(新しい gs の場合、または Mac 版のテキスト形式 EPS の場合)PDF →[pdfwrite(strokepath)]→ PDF →… 両バージョン EMF 以外のベクター出力で、ストロークのアウトライン化 OFF完全に現状維持(パス変形なし)。 こんなのが思いつくわけですが…もしこれが可能なら、経路をほとんど変えることなくオプション一つ( |
とりあえずEMF生成直前に.dashpathをかますようにしてみました.
もきちんと出ますね.これはいい. |
gs9.10 で試したのですが、pdfiumdraw に入る前の PDF が A4 サイズに戻ってしまいました。gs9.18 で試すと大丈夫でしたので、#66 関連の経路変更の際にどこか失敗しているのだと思います。gs9.18 による破線の変形は成功していました。 |
#67, #68, #69, #70 を反映させた Ver. 2.1.4 beta 1 を作成しました。 |
Mac 版の変換経路図によると、いままで eps2emf に食わせる EPS は gs でアウトライン化していたはずですが、これをやめて pdftops でテキスト保持のままの EPS が( |
Win 版が PDF のページ数取得にときどき失敗します… 正式版の1.6.8も同じです。これと同じ現象でしょうか? |
多分そうですね.複数回試行することにします.(プロセスの間でやりとりするのはやっぱり難しい…….) |
複数回試行するものをおいておきましたが,そもそも原因はマルチスレッドで同期をとっていない部分があることな気がしてきたので,それも直しておきました.念のため複数回の試行も行うようにしてあるので,これで安定するのではないかと思います. 紙サイズがだめなのはまだ調べていないです. |
すみません,図のミスです。後で直します。 |
そのあたりは,他の画像形式の生成経路を極力借用しているためにそうなっています。 |
epstopdf を呼んでいるのは,一旦PDFにしてから pdftops にかけることで,後半の経路をgs 9.15 以上と 9.14 以下で共有するためでした。 |
なるほど… epstopdf をなんとかしてスキップできないですかね😥 |
この方針で考えていますが,
でそれぞれ専用の経路を用意せねばならないっぽくて結構大変です……。 |
あれ、よく見ると遅いのは epstopdf ではなく epswrite でした… なんかたまにログに表示される順番が違っているだけかもしれません。複数ページ処理しているとたまにログの順番が違っていることに気づきました。 そういうことなら、epstopdf はスムーズに進んでいますので、経路自体はこのままでいきましょう。 そういえば再現条件がわからず未報告だったのですが、ちょっと前に
のようにログがときどき増幅したことがあったような… |
いや,意外とシンプルに実装できるかも?もう少々お待ちください。 |
EMF生成に専用経路を用意し,#70 にも対応した,Ver. 2.1.4 beta 4 を作成しました。 |
ちょっととりあえずおいておきます.時間がとれていない…… |
すみません… 頭が混乱しそうなので Mac 版が理解できてから Win 版をテストさせてください。Mac 版の開発中に少しずつスキームの改善点が出てきていますので、それを踏まえて後日確認します。 (ベータ版は入手しましたので、しばらくはあまり中身を考えずに利用させていただきながら、気づいたときにお知らせする感じです。) |
ちょっとずつ手を入れています.とりあえずアニメーション設定のUIを入れました.もう限界だったのでタブを増やしました…… 同じURLに上書きしています. |
改造版 pstoedit を用いたEMF生成の品質が上がったので,Inkscape を用いた補助ツール eps2emf.app へのリンクを配布サイトから外しました。 |
Win 版をようやく試し始めました。いま気づいている点を挙げます:
|
あーやっぱり……gs 9.18でも古いバージョンの経路にすると出なくて,きちんと古いバージョンならば動くかと無駄な期待をしたのですが.何でなのかわかっていないです.確か-dEPSCropをつけた段階で消えたとおもいます.(その後おえていません.) |
だとすると、rewriteBB する値が違っているのかなと疑っています。PDF を最初に pdfcrop してそのあと epswrite にかける場合、最初に取得した bb(これが pdfcrop に使われる)では駄目で、再度 bbox を算出する必要が生じます。再算出した bbox で EPS を rewriteBB して -dEPSCrop 付きで PDF に戻す、ならクロップできそうです。 |
そういえば常にcropするようにしたことを忘れていました……後で直してみます. |
おお、ビンゴでした。クロップ範囲がおかしい件・ロンダリングの件ともに問題なくなりました。 \[
\left( \int _0 ^\infty \frac{\sin x}{\sqrt{x}} dx \right) ^2
= \sum _{k=0} ^\infty \frac{(2k)!}{2^{2k} (k!)^2} \frac{1}{2k+1}
= \prod _{k=1} ^\infty \frac{4 k^2}{4 k^2 - 1}
= \frac{\pi}{2}
\]
破線のテストです。
\begin{tikzpicture}
\draw[dashed](0,0)--(1,0);
\end{tikzpicture} が、画像の右のほうが消えてなくなってしまいました。 |
TeX2img Win 1.6.8 に同梱されている pdfiumdraw はちゃんと描画できましたが、いま Onedrive にある pdfiumdraw は右端が消えるということに気づきました。 |
pdfium自身は,Debug版はパッチがあたっていない状態でビルドされてしまっていたようです.リビルドしました. |
.dashpath,Ghostscirptの9.20あたりで消えたみたいです. |
消えたんですか…。おっしゃる通りそれが最善だと思います。 |
幸い(?) Mac版では以前の調査結果により元々 |
ありゃそれは失礼 |
#57 で話題に出た「破線の見た目が EMF でおかしい」という問題の解決策を考案しました(調査レポート)。Ghostscript 独自に拡張された PostScript operator のひとつである
.dashpath
を使います。以下の2行のコードを PS / EPS ファイルの冒頭に加え、出来上がった PS / EPS を gs の eps(2)write または pdfwrite デバイスに通します:
追記 (2015-12-06) より強力な方法を見つけました(出典)。上記の2行ではなく、下記の2行を PS / EPS ファイルの冒頭に加えます:
すると、元のファイルにあった“空でない破線配列 (dash array) を適用した一本の線分を描画する命令”は、新しいファイルでは“空の破線配列を適用したバラバラの線分を描画する命令”に置き換わります。こうすると、EMF 変換しても破線の見た目が保たれるのではないかと期待しています。
Windows 版はだいぶ状況が改善して EMF でも破線が綺麗に出てくる場合が増えたようですが、Mac 版は特に破線が苦手だったと思います。上の方法を使って、EMF 出力の場合だけ
のようにすればうまくいくかもしれません。ただし、任意の PS / EPS ファイルで上記の再定義法が適用できるかは未確認です。
The text was updated successfully, but these errors were encountered: