TikZのパターンがSVG化の際に欠ける

[doraTeX]

現象

次のソースを TeX2img でSVG化すると，パターンが欠ける。

\documentclass[dvipdfmx]{article}
\usepackage{tikz}
\usetikzlibrary{patterns}
\pagestyle{empty}
\begin{document}
\begin{tikzpicture}
\filldraw[pattern = north east lines] (0,0) rectangle (5,5);
\end{tikzpicture}
\end{document}

# 原因

~~#34 で，mudraw の最新バージョン対応のために -l オプションを外したことが原因。 TeX2img.app に内包されている旧バージョンの mudraw は -l オプションを受け入れる。#34 の改修前のように，-l を付けておけば，パターンも無事に保持される。~~

# 対策

GUI版については，.app に内包されている旧バージョンの mudraw を使っているので，-l を付けるように戻せばよいだろう。 CUI版については，

• GUI版がインストールされている場合はその中の mudraw を優先的に使い，-l オプションを付ける。
• GUI版がインストールされておらず，新バージョンの mudraw のみインストールされている場合は，やむなく -l なしで実行する。

とするのが最善か？

# 検討事項

新バージョンの mudraw でも旧バージョンの -l に相当することはできないものか？

[aminophen]

EMF ってもしかして、描けるパスの数に上限があるのでしょうか…？

いやーさすがにそんなことはないでしょう……ぴったり画面サイズだし．

あながち間違っていないかもしれません… gs9.18 と gs9.10 で「普通の数式・破線・パターン塗り」だけを持つソースを EMF に変換してみました。

\documentclass[dvipdfmx]{article}
\usepackage{tikz}
\usetikzlibrary{patterns}
\pagestyle{empty}
\begin{document}
\[ 
\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} 
\begin{tikzpicture}
\filldraw[pattern = north east lines] (0,0) rectangle (5,5);
\end{tikzpicture}
\end{document}

gs9.18 はパターンが全て出ますが、gs9.10 はパターンが途中までしか描画されません。

gs9.10 が作る中間 EPS をみると、パターン部分が Patterns ではなく変な描き方になっていて、なんか細分化されているっぽいです。一方 gs9.18 の場合は pdfwrite を通るので Patterns が保持されているはずです。パターンがパターンでなくなった場合は大量のパスになってアウトなのかもしれません。もう少し調べます。

[abenori]

一応単純な数の問題ではないということとして，

\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=1}] (0,0) rectangle (3,3);
\end{tikzpicture}

を縦に並べると（うちでは）八個目でアウトですが．横に二つ並べると，14個（=2×7個）並べることができ，やはり八行目がアウトです．ともかく「画面サイズ外の塗り操作」になにか問題はありそうです．

おそらく上の例はまた別の問題なのかなぁと直感的には思います．ああ，また問題が増えた……．

例のURLに今の手元の最新版pdfiumdrawとTeX2imgをおいておきました．

[aminophen]

縦に並べると（うちでは）八個目でアウトですが．横に二つ並べると，14個（=2×7個）並べることができ，やはり八行目がアウトです．ともかく「画面サイズ外の塗り操作」になにか問題はありそうです．

うちでも全く同じです。「画面サイズ外の塗り操作」に問題がありそうというのもなんかわかります。パス描画が左上までで止まるのも、数ではなく画面サイズとパターン塗りの関係かもしれません。

[doraTeX]

当方では，なぜかGUI版では解決されているのにCUI版では微妙に崩れる問題が発生しております……。 もう少し調査してみます。

原因が分かりました。GUI/CUIの問題ではなく，SVGアニメーション生成ルーチンの問題でした。 この手順に従うと，ファイル名にスペースが含まれる場合に，SVGの要素の id 属性にスペースが含まれるようになってしまい，不正なSVGになってしまうことが原因でした。 ファイル名のスペースを _ に置換してSVGの id を生成するように修正したところ，問題が解決しました。 これでいよいよ調整が完了か!?

[doraTeX]

現状の最新版 Ver. 2.1.5 beta 8 です。

[aminophen]

abenori さんの SVG を Illustrator で見るとどうなるかの件、いかがでしょうか？＞doraTeX さん

これが綺麗だったら「transform=matrix の値を書き変えたもの」が Windows 版で採用できます。

[doraTeX]

Safari と Illustrator の見え方比較です。Illustrator では下半分が全部消えました。

[aminophen]

Illustrator では下半分が全部消えました。

ありがとうございます。これは難しいです…

[doraTeX]

アウトライン表示にすると，何か隠れているのが見えます😅

[aminophen]

こっちの SVG だとどうですか？（半透明図版を除去したもの）

[doraTeX]

[aminophen]

mudraw1-tr.svg は transform の座標を変えたもの、mudraw2-fl.svg はパターンを崩したもの（ゆえにファイルサイズが大きくちょっと遅い）でした。どっちもパターンが出ていない… 手元では mudraw2-fl.svg を Inkscape で表示すると綺麗なのですが。

[abenori]

うーん，やっぱりという感じですが…… ちなみに一番最初のソースファイルをコンパイルしてPDFFを作ってIllustratorで開いてsvgで保存するとどんなファイルができるんでしょう？ちょっとIllustratorのキモチになってみようかと……

[doraTeX]

最初のソース をコンパイルしたPDFを Illustrator で開くと，まずは斜線の見た目が変です。

これをSVG化したものがこちらです。

[abenori]

ありがとうございます．開いた見た目とSVGを開いてみた見た目は一致しているんですね．しかしAdobeのくせにPDFもだめとかどういうことなんだ……．少しSVGを眺めてみます．

[aminophen]

Mac 版のこの SVG 生成経路だと、SVG になったときにパターン部分に Type3 フォントがそのまま残っていて大丈夫だろうかとちょっと心配です。文章はアウトライン化・パターンは文字のままになっていると思うのですが。

[doraTeX]

確か，それを gs でアウトライン化しようとするとパターンが乱れるのだったと思います。 生成したSVGの <text>〜</text> を削除するという手で対応しましょうかね。

[aminophen]

なんか pdftops の「パターン崩し」で色が変わる例を見つけました… gs9.14 以下を使用時のこの経路を、gs9.10 をインストールした Windows でまねています。

\documentclass[dvipdfmx]{article}
\usepackage{tikz}
\usetikzlibrary{patterns}
\pagestyle{empty}
\begin{document}
\[ 
\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} 
\begin{tikzpicture} % 斜線パターン
\filldraw[pattern = north east lines] (0,0) rectangle (5,5);
\end{tikzpicture}
\begin{tikzpicture} % 赤煉瓦に白漆喰
\def\mypath{(0,0) -- +(0,1) arc (180:0:1.5cm) -- +(0,-1)}
\fill[red] \mypath;
\pattern[pattern color=white,pattern=bricks] \mypath;
\end{tikzpicture}
\end{document}

最後のパターンは白で煉瓦のような模様を出すはずなのですが、pdftops 経由後の PDF を epswrite にかけて PDF に戻したときには黒になっています… エミュレートするときに色は保持されないのでしょうか？

[aminophen]

Mac 版のこの SVG 生成経路だと、SVG になったときにパターン部分に Type3 フォントがそのまま残っていて大丈夫だろうかとちょっと心配です。

確か，それを gs でアウトライン化しようとするとパターンが乱れるのだったと思います。

パターンが乱れるというより gs9.16 の pdfwrite (nooutputfonts) にビットマップ化されてしまうようですね。しかもパターンの左下のほうはアウトライン化しているのに、右上のほうはビットマップ化していて意味が解らない…たしかにこれはマズイ。

[doraTeX]

pdftops 経由後の PDF を epswrite にかけて PDF に戻したときには黒になっています… エミュレートするときに色は保持されないのでしょうか？

gs 9.15 以降の pdfwrite -dNoOutputFonts では保持されるのに，9.15 未満の epswrite では確かにダメですね……。 epswrite を噛ませることで色々な問題が生じていますので，以前おっしゃっていたように，gs 9.15 未満で PDF→PDF でフォントをアウトライン化する方法があればいいのですが……。

[aminophen]

あれ、手元の Windows では gs9.16 の pdfwrite アウトライン化でも、gs9.10 の epswrite 同様に色が変わりました。しかも斜め線パターンは途中からビットマップ。

[doraTeX]

gs 9.18 による結果です。このアニメーションの各フレームの見え方はどうでしょうか？

Safari の場合

Firefox の場合

Chrome の場合

Chromeはなんかおかしいです。また，アニメーションの間隔が異様に長くなり，また，ChromeのCPU使用率を占拠し，Macのファンが爆音を立てて回り始めます。 どうも，このSVGはChromeが苦手としているようです。

[doraTeX]

↑の変換元ソース：

\documentclass[dvipdfmx]{article}
\usepackage{tikz}
\usetikzlibrary{shadows.blur,patterns}
\pagestyle{empty}
\begin{document}
\[ 
\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} 
\begin{tikzpicture} % 斜線パターン
\filldraw[pattern = north east lines] (0,0) rectangle (5,5);
\end{tikzpicture}
\begin{tikzpicture} % 赤煉瓦に白漆喰
\def\mypath{(0,0) -- +(0,1) arc (180:0:1.5cm) -- +(0,-1)}
\fill[red] \mypath;
\pattern[pattern color=white,pattern=bricks] \mypath;
\end{tikzpicture}

\newpage

\[ 
\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} 
\begin{tikzpicture} % 斜線パターン
\filldraw[pattern = north east lines] (0,0) rectangle (5,5);
\end{tikzpicture}
\begin{tikzpicture} % 赤煉瓦に白漆喰
\def\mypath{(0,0) -- +(0,1) arc (180:0:1.5cm) -- +(0,-1)}
\fill[red] \mypath;
\pattern[pattern color=white,pattern=bricks] \mypath;
\end{tikzpicture}
\end{document}

[aminophen]

変換経路はどれでしょう？ 手元では gs9.16 でも gs9.18 でもこの方法だと白漆喰が黒になります。

[doraTeX]

こんな感じです。

        // まずはpdfcrop類似処理で1ページごとに砕く
        if (![self pdfcrop:pdfFilePath
            outputFileName:croppedPdfFileName
                      page:page
                 addMargin:NO
                  useCache:NO
            fillBackground:NO]) {
            return NO;
        }

        // 直ちにQuartzでPDFロンダリング
        [self launderPDF:croppedPdfFileName];

        // gs pdfwrite でPDF内のフォントをアウトライン化
        if (![self outlinePDF:croppedPdfFileName
 intermediateOutlinedFileName:outlinedPdfFileName
               outputFileName:outlinedPdfFileName
                         page:1
                    addMargin:NO
                     useCache:NO
               fillBackground:NO]) {
            return NO;
        }

        // パターンのアウトライン化をするために pdftops で EPS に変換
        if (![self pdf2plainTextEps:outlinedPdfFileName outputFileName:epsName page:1]) {
            return NO;
        }

        // BBを書き換え
        [self replaceEpsBBox:epsName withBBoxOfPdf:outlinedPdfFileName page:1];

        // パスのアウトライン化を行うための stroke 再定義
        [self modifyEpsForOutliningPaths:epsName];

        // epstopdf で再びPDFに戻す
        if (![self eps2pdf:epsName outputFileName:pdfName addMargin:NO]) {
            return NO;
        }

        // pdfcrop類似処理で余白付与＋Quartzで背景塗り
        if (![self pdfcrop:pdfName
            outputFileName:trimmedPdfFileName
                      page:1
                 addMargin:YES
                  useCache:NO
            fillBackground:YES]) {
            return NO;
        }

        // 生成した単一ページアウトライン化PDFを mudraw にかけてSVG生成
        [self pdf2svg:trimmedPdfFileName
       outputFileName:svgFilePath
                 page:1
        skipEmptyPage:NO];
        [controller exitCurrentThreadIfTaskKilled];

[aminophen]

あーそれだと pdftops の後にアウトライン化を経ないので「色変化」は起きないですね。手元では

PDF →[pdftops]→ EPS →[epstopdf]→ PDF →[アウトライン化]→ PDF

だと gs のバージョンに依らず「色変化」します。pdftops のあとにアウトライン化するのはアウト、という意味です。これは pdfwrite でも起きている・しかもアウトライン化しないで単に pdfwrite なら色保持であることから、アウトライン化するときにパターンが Type3 フォントになっている状態はアウト、と私は読んでいます。

なんだか pdftops を通すこと自体がかなり危ない気がしています。いまはパターンに対処しようとしているわけですが、予期せぬ場所で変なエミュレートをしている可能性はあり、わざわざ pdftops を通すのは怖いです。Windows 版が目指しているような mudraw のパッチでなんとかするほうが筋が良いかもしれません。（成功すれば、アウトライン化 SVG にもテキスト SVG にも対応できる見込みもあります）

[doraTeX]

アウトライン化するときにパターンが Type3 フォントになっている状態はアウト、と私は読んでいます。

確かに，それはさっきの

Mac 版のこの SVG 生成経路だと、SVG になったときにパターン部分に Type3 フォントがそのまま残っていて大丈夫だろうかとちょっと心配です。

確か，それを gs でアウトライン化しようとするとパターンが乱れるのだったと思います。

パターンが乱れるというより gs9.16 の pdfwrite (nooutputfonts) にビットマップ化されてしまうようですね。しかもパターンの左下のほうはアウトライン化しているのに、右上のほうはビットマップ化していて意味が解らない…たしかにこれはマズイ。

とも共通していますね。

しかも，pdftopsによるパターンのアウトライン化は，パターン単独だと成功しているけれども，破線と同じページに存在すると駄目になっています。なんとも微妙……。

[doraTeX]

Windows 版が目指しているような mudraw のパッチでなんとかするほうが筋が良いかもしれません。

まだ mudraw を MacPorts なしで自力でビルドすることに成功しておらず，この方向は試せておりません。

[aminophen]

破線と同じページに存在すると駄目になっています。

それも不思議ですね… 全然状況がつかめません。一気に方針転換して、SVG を「PDF 生成経路に続いて“パッチ適用 mudraw”に通す」ほうがわかりやすいと思いました。abenori さんのほうで既に二案出していただいていますが、いずれも Illustrator だとダメだったようですのであと一歩でしょうか？

さて、mudraw のビルドから勉強します…

[doraTeX]

どうも，Illustrator のSVG解釈能力は，ブラウザのそれに比べて極めて限定的なように感じています。だから，Illustrator 上での表示をまともなものにすることにはあまりこだわらなくてよいのではと思うようになってきました。

[aminophen]

どうも，Illustrator のSVG解釈能力は，ブラウザのそれに比べて極めて限定的なように感じています。

だとすると、「パターンを崩す」という2番目のほう（処理が遅くてファイルサイズが大きい方）が Inkscape で綺麗なのでそれもありでしょうか？

[doraTeX]

SVG を「PDF 生成経路に続いて“パッチ適用 mudraw”に通す」ほうがわかりやすいと思いました。

確かに，pdftops の極めてデリケートな性質に依存するよりも，それによってこの問題を根本的に解決することができれば，それに越したことはありませんね。

「パターンを崩す」という2番目のほう（処理が遅くてファイルサイズが大きい方）が Inkscape で綺麗なのでそれもありでしょうか？

パターンをアウトライン化する方が，閲覧環境を問わず同じ見た目になる可能性が高そうなので，よさそうに思います。

Mac での mudraw のビルドに成功したら教えてください……😓

[abenori]

ファイルサイズがかなり大きくなるので悩みます．たぶんいったんバグ認定されたこれ↓なんじゃないかと． http://bugs.ghostscript.com/show_bug.cgi?id=695988 Inkscapeでの両者の違いは少し切れて見えるかでしょうか？

[aminophen]

あー、それっぽいです…

Inkscapeでの両者の違いは少し切れて見えるかでしょうか？

transform を変えるほうは、「オブジェクトをドラッグして動かすと突如見え始める」というおかしな挙動です。一方、パターンを崩して膨大なパスにする方は初めから見えています。

[abenori]

あれ，うちではきちんと最初から見える……＜Inkscape

[aminophen]

あ、もしかして最新版 0.91 ですか？（私は 0.48 なので、そこに違いがあるかも）

[abenori]

そうですー．ブラウザ表示と同じに見えています．

[abenori]

こんな感じですね．

[aminophen]

今、0.48.5 をアンインストールして 0.91 を入れました。最初から綺麗に表示されていて感動です。transform を書き変える方法は、パターンはパターンのままなのでサイズが増えず、かなり良さそうです。もう少し他の例でも試してみます。

[aminophen]

先ほどのソースを処理していますが、ごくわずかにパターンが欠ける程度でほとんど気にならない SVG ができました。gs9.15 以上・未満ともに、PDF 出力（テキスト保持・アウトライン化）のあとにそのまま（破線変形やパスアウトライン化を経ずに）“transform 修正パッチ適用 mudraw” にかけるだけでシンプルです。

一応、「細かい斜線パターン」については gs9.15 未満の epswrite が苦手としていますが、これはもう昔の gs の問題なのでどうすることもできないでしょう。これでファイナルアンサーで良いと思います。

• gs9.15 以上の場合：pdfwrite を通るので綺麗です。
• gs9.15 未満の場合：epswrite を通った時点で「細かい斜線パターン」のみビットマップ化します。

あとは Mac 版の mudraw のビルドと変換経路を元に戻すところですかね…

[aminophen]

まだ EMF がありますが… とりあえず今の課題は以下でしょうか：

• Windows 版はページの外の塗りがまずい？
• Mac 版は pdftops を通った後にアウトライン化すると色が変わるのでこれだと NG？ → これは「pdftops のあとに stroke を strokepath fill に修正」をかませると色が保持される模様。

[abenori]

パターンが欠けるのもわずかに何か数値がずれているとかそんな気がしますけどね－．気が向いたら少し追ってみます．Illustratorのキモチもわかりたいところですが，手元にいないと厳しい気がしてきました．

EMF（ぐぅ）

[doraTeX]

MacはEMF生成にWindows APIが使えない以上，経路の選択肢は非常に限られます。pstoedit を根本的に改良できない限り，現状がベストプラクティスになるのではないかと思われます。（とはいえ現状の経路のパターン出力も端がはみ出ていて十分ではありませんが……）

[aminophen]

とはいえ現状の経路のパターン出力も端がはみ出ていて十分ではありませんが……

パターンのはみ出しは気にしていない＆eps2emf 本体の調整は想定していません。が、「色が白から黒に変わる問題」は gs9.15 未満の現行の経路で起きそうです。いままで調整してきたパターンはもしかすると気づかないうちに PDF の時点でビットマップ化されていた可能性もでているので、もう少し調べてみます。

[abenori]

ふとpdfiumdrawを単独実行してみたところ，上の小さい箱を八個繰り返したものの一番最後の青い箱が出力されました．どうも.dashpathをかますと塗りがでないみたいです．（赤はどっちにしても出ないけど．）

[aminophen]

Mac 版の EMF については、この方法が最善なのだろうという結論です（出力はこれ）。再掲すると

EMF 出力；gs 9.15 以上の場合

TeX → PDF →[pdfTeXでクロップ＋余白付与]→ PDF（ここで Quartz API で背景塗り＆ロンダリング）→[gs pdfwrite]→ アウトライン化PDF →[pdftops]→ EPS →[stroke修正処理を仕込んでからpstoedit]→ EMF

• 必要条件である「テキスト部分のアウトライン化」と「eps2emf 入力用 EPS の準備（ストローク修正済み）」を満たしています（パターンだけ Type3 フォントのまま）。
• pdftops によって Type3 フォントでエミュレートした文字はそのまま eps2emf に渡るため、アウトライン化による変色を防止できています。Type3 フォントが残ってはいますが、ストローク修正は済んでいるため見た目は同じになります。
• 逆に、パターンから変換された Type3 フォントをアウトライン化しようとするとビットマップ化してしまう危険がありますが、これも防止できています。

EMF 出力；gs 9.15 未満の場合

TeX → PDF →[pdftops]→ EPS →[stroke修正処理を仕込んでからepstopdf]→ PDF →[pdfTeXでクロップ＋余白付与]→ PDF（ここで Quartz API で背景塗り＆ロンダリング）→[gs epswrite]→ EPS →[pstoedit]→ EMF

• 必要条件である「テキスト部分のアウトライン化」と「eps2emf 入力用 EPS の準備（ストローク修正済み）」を満たしています（しかもパターンもアウトライン化済み）。
• pdftops で最初に Type3 フォントでエミュレートしてはいますが、ストローク修正の結果としてその後のアウトライン化でも変色しない効果が得られるようです。
• 細かいパターン塗りが存在する状態で epswrite を先にかけてしまうと、epswrite がパターンをビットマップ化してしまいます。ビットマップ化してしまうと pstoedit がビットマップは駄目だと警告を吐いてパターンを消してしまうのですが、pdftops とそれに続く stroke 修正処理によってどうやらビットマップ化を防げるようです。

「ストローク修正の結果としてその後のアウトライン化でも変色しない効果が得られる」というのは新しい知見のようです（この変色は、通常のフォントが fill で描かれているのに対してエミュレートの Type3 フォントは stroke で描かれていることが原因；すなわち「Type3 フォントでエミュレートした場合は必ず stroke 修正を行うべき」）。「pdftops とそれに続く stroke 修正処理によってどうやらビットマップ化を防げる」というのも新しいかも。

[aminophen]

いま、PDF のアウトライン化のベストプラクティスを考えています。すぐ上の Mac 版 EMF 出力で得た知見をもとに考えると、「gs9.15 未満でパターンがどうしてもビットマップ化してしまう」という問題を防ぐには以下のようにする必要がありそうです：

アウトライン化 PDF 出力；gs 9.15 以上の場合

TeX → PDF →[pdfTeXでクロップ＋余白付与]→ PDF（背景塗り＆ロンダリング）→[gs pdfwrite]→ アウトライン化PDF

• 要するに、現状の変換経路です。
• この変換経路ではパターンは完全に元のパターンのまま残ります。
• 上記のアウトライン化 PDF から別の形式に変換する際に
  • 破線に困る場合は、上記に続いて pdfwrite で .dashpath をかませます。
  • 破線にもストロークにも困る場合は、上記に続いて pdfwrite で strokepath をかませます。

PDF 出力の場合、pdftops を通してしまうと勝手に Type3 フォントでエミュレートされてしまうのでパターンが失われて不都合です。したがって、パターンを残せる上記の経路が妥当でしょう。

アウトライン化 PDF 出力；gs 9.15 未満の場合

TeX → PDF →[pdftops]→ EPS →[stroke修正処理を仕込んでからepstopdf]→ PDF →[pdfTeXでクロップ＋余白付与]→ PDF（背景塗り＆ロンダリング）→[gs epswrite]→ EPS →[epstopdf]→ PDF

• 現状の変換経路とは異なります。
• 細かいパターン塗りが存在する状態で epswrite を先にかけてしまうと、epswrite がパターンをビットマップ化してしまいます。すなわち、パターンをパターンのまま保持することは不可能です。そこで、pdftops とそれに続く stroke 修正処理によってビットマップ化を防止する方がメリットが大きいと思われます。（ただし、他の副作用がないかどうかは未確認）
• 上記のアウトライン化 PDF から別の形式に変換する際には、既に strokepath をかませているためこのまま他の形式に変換できます。

アウトライン化 PDF 出力；gs 9.15 未満の場合（次善の策）

TeX → PDF →[pdfTeXでクロップ＋余白付与]→ PDF（背景塗り＆ロンダリング）→[gs epswrite]→ EPS →[epstopdf]→ PDF

• 要するに、現状の変換経路です。
• この変換経路ではパターンはビットマップ化されてしまいますが、pdftops なしでは gs のアウトライン化失敗を受け入れるほかはないでしょう。
• 上記のアウトライン化 PDF から別の形式に変換する際に
  • 破線に困る場合は、上記に続いて pdfwrite で .dashpath をかませます。
  • 破線にもストロークにも困る場合は、上記に続いて pdfwrite で strokepath をかませます。

古い gs でもパターンをアウトライン化できた方がよければ pdftops を使うのがよさそうですが、「古い gs のバージョンではパターンは今はサポート外」としてしまうのも一理あると思っています。gs 単独で「ビットマップ化されない安全なテキストのアウトライン化」を実現できればむしろ pdftops を使わない方がベストになるはずですし、もう少し真面目に探してみます。

[abenori]

こちらはpdfiumdraw直接の線でそのまま考えていますが，いろいろ試しても外の塗りは出ないので，いったんあきらめます……．状況が起こりにくくなるように，--scale=10をはずそうかと．ちと不便ですが，きちんと描画されないよりはましなので．または解像度レベルにあわせるかなぁとも思っていますが．

[aminophen]

状況が起こりにくくなるように，--scale=10をはずそうかと．ちと不便ですが，きちんと描画されないよりはましなので．または解像度レベルにあわせるかなぁとも思っていますが．

EMF はだいぶしんどいですね… いろいろ試していただいてありがとうございます。--scale=10 を外すと右上が消えやすくなるという話は余白機能で対処することにします。

[abenori]

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

今のところの最新をおいておきます．だめなことがわかっているの以外は大丈夫そうですが，もう少しテストしていったん出します．（たぶん今年最後……）何か気がついたことがあれば．