-
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
TikZのパターンがSVG化の際に欠ける #64
Comments
|
#68 の方法を応用することで,この問題も解決できそうです。 現状,gs 9.15 以上での pdfwrite を用いたアウトライン化SVG生成は pdfwrite でアウトライン化PDF生成 → mudrawでSVG変換 としていますが,これを eps2write(または pdfwrite + pdftops)でアウトライン化EPS生成 → EPSの冒頭に という経路を経れば,patternsライブラリによるパターンのアウトライン化が可能でした。 できればEPSを経由しない方が望ましいのですが……。
では Syntax error になってしまいました。
|
あれれ、この話のときは pdfwrite で出来ていたのですが… |
実はその話のときも,自分は一度も「pdfwrite と同時のパスのアウトライン化」というものに成功したことがありませんでした……。 |
現状の変換経路では,「パスのアウトライン化」を行うのは,改造版 pstoedit にかける直前の EPS に対してのみとなっていますので,「pdfwrite と同時のパスのアウトライン化」の必要は幸い生じておりませんでした。 |
いま Mac で
あれれ…とよくみたら @doraTeX さんのコマンドは
ではなく
が正しいです。
|
OS によらず pdfwrite / eps(2)write で ところで、ここで触れたように、PDF などの形式でもストロークをアウトライン化する選択肢があってもよいかもと思っています。仮にこれを付けた場合、SVG もその設定状態に応じて変えるというのがよいでしょうか。 |
すみません,1回目の方ではコピペをミスしました。 Ghostscript のバージョンはいくつで実験しておられますでしょうか。
は,gs 9.16 (MacPorts) では成功,9.18(Richardのページで配布しているものを美文書インストーラ方式でインストールしたもの)では上記のエラー,という結果になっています。 |
なお,gs 9.16 では,stroke 改変付き pdfwrite 自体はとおるものの,それを mudraw にかけてもやはりパターンが欠けます。 gs 9.16 の環境で,in.pdf (テキスト保持PDFとして切り出したもの)に対して以下の一連のコマンドを実験してみました。
この実験では,pdftops を経由する |
すみません、gs9.18 はソースからのビルドが Mac で通らず試せなかったため gs9.16 オンリーで実験していました。gs9.18 での実験はビルド環境が整っている Windows であとで試してみます。
確かに SVG になったときにパターンがみえるのは out3.svg だけですね。out3.pdf をよくみると、パターンにカーソルをあてると文字のように選択できて どちらももう少し調べてみます。 |
よく考えたら私の Lion ならマスクメロン版 Ghostscript.app が使えるなと思って、gs9.18 を入手することに成功しました。ところが
はエラーなく終了しました(できたファイルは gs9.16 のものと同じ見た目)。
が再現しません。あれ? |
美文書方式でインストールした gs 9.16 の環境でも同じエラーが発生しました。 |
えっ… それは困りました… 美文書では gs のライブラリのどれかが正しく読まれなくなっている可能性があるということですよね? |
美文書インストーラでは, #!/bin/bash
GHOSTSCRIPT_PREFIX=${MACTEXADDONS_PREFIX:-/Applications/TeXLive/mactexaddons}
case $(uname -m) in
x86_64) __gs=${GHOSTSCRIPT_PREFIX}/bin/gs-noX11-64Bit;;
*) __gs=${GHOSTSCRIPT_PREFIX}/bin/gs-noX11;;
esac
$__gs \
-I ${GHOSTSCRIPT_PREFIX}/share/ghostscript/9.16/Resource/Init \
-I ${GHOSTSCRIPT_PREFIX}/share/ghostscript/9.16/Resource/Font \
-I ${GHOSTSCRIPT_PREFIX}/share/ghostscript/9.16/lib \
-I ${GHOSTSCRIPT_PREFIX}/share/ghostscript/9.16/fonts \
-I ${GHOSTSCRIPT_PREFIX}/share/ghostscript/fonts \
$@ これにより, |
なるほど… だとすると美文書の gs はひょっとして ところで |
その可能性はありますが,通常のPSファイルに対する ps2pdf であれば,問題なくPDFが出力できています。(美文書インストーラを作成したときにもテストは行いました。) |
美文書だけのために pdfwrite に |
なんとか美文書のような特殊な方法でインストールされた gs でも |
うーん,自分が美文書gsユーザであることもあり,美文書gsの利用を封じられるのは厳しいです……。
インストール先をインストーラで柔軟に変更できる設計にするために,「MacTeXのgsビルド+ラッパースクリプト」という構成をとっていました。 |
そういえば Unix 的インストールと Mac 的インストールがありましたね。それだとしょうがないか…
ではその方向で進めましょう。 「 |
早速できてしまいました。ただし一手間かかります。この方法は、gs のドキュメントに書かれている たとえば、以下を pdfLaTeX でコンパイルして出てくる dash.pdf を % dash.tex
\documentclass{article}
\usepackage{tikz}
\pagestyle{empty}
\begin{document}
\begin{tikzpicture}
\draw[dashed](0,0)--(1,0);
\draw[dashed](2,0)--(1,1);
\end{tikzpicture}
\end{document} この場合、次の内容の set-strokepath.ps ファイルを適当な場所に置きます: .setpdfwrite /oldstroke /stroke load def /stroke {strokepath fill} def そして、コマンドは以下のようにします(gs-bibun というのは先ほどの教えていただいたシェルスクリプトです):
そうすると、出てくる dash-out.pdf はストロークのアウトラインがとられた状態になります。 コマンドの見た目は以前に登場した「gs で PDF / PS / EPS を結合する」と同じですが、PS にページ描画命令が入っていないため、以上の作業が可能になります。 もちろん
を実行すると
を再現することもできていますので、gs-bibun を作成したテスト法は合っているつもりです。 |
「Mac風」「Unix風」の2つのテンプレートを選べるほか,そのテンプレートを土台として,テキストボックスの内容を書き換えることで,インストール先はユーザが任意にカスタマイズできるようになっています。 外部 ps を経由する方法でうまくいくことは確認できました。 ただし,
という問題は依然として変わりませんでした。 美文書方式 gs 9.18 + 外部 ps 方式で pdfwrite で in.pdf をアウトライン化し,それを mudraw で svg にしても,SVG上はやはりパターンが欠けてしまいました。 そもそも,mudraw にかける以前の問題として,
によって生成する そして,この模様の部分はアウトライン化されていません。 つまり, .setpdfwrite /oldstroke /stroke load def /stroke {strokepath fill} def では,「パスのアウトライン化」は可能でも,「塗りパターンのアウトライン化」はできていないことが分かります。 「塗りパターンのアウトライン化」を行う PostScript コードはあるのでしょうか? |
そもそも,最初の |
以前言及したように,previewパッケージを経由しておく方法も試してみました。 \documentclass[dvipdfmx]{article}
\usepackage{tikz}
\usetikzlibrary{patterns}
\pagestyle{empty}
\usepackage[dvipdfmx,tightpage,active]{preview}
\PreviewEnvironment{tikzpicture}
\begin{document}
\begin{tikzpicture}
\filldraw[pattern = north east lines] (0,0) rectangle (5,5);
\end{tikzpicture}
\end{document} 生成PDF :
|
これは奥村先生に一応お伝えしておいたほうがよいと思いました。あとでこちらから伝えておきます。(そもそも今まで上がってこなかったということは、gs の猛者は美文書ユーザにいなかった?) パターンが変わるという問題は、なんだか mudraw のせいではなさそうなので、あとでそれも調べてみます。(昨日アドベントカレンダーの記事を書き始めたばかりで間に合わせるのに必死です…) |
このgsのパッケージングを行ったのは山本さんなので,山本さんにもご一報を入れる必要があるでしょうね。 |
あと,もちろん著者であられる黒木さんにも。 |
そうなのですね。では山本さんにもお知らせしておきます。もちろん黒木さんも。 |
Mac 版の EMF については、この方法が最善なのだろうという結論です(出力はこれ)。再掲すると EMF 出力;gs 9.15 以上の場合TeX → PDF →[pdfTeXでクロップ+余白付与]→ PDF(ここで Quartz API で背景塗り&ロンダリング)→[gs pdfwrite]→ アウトライン化PDF →[pdftops]→ EPS →[stroke修正処理を仕込んでからpstoedit]→ EMF
EMF 出力;gs 9.15 未満の場合TeX → PDF →[pdftops]→ EPS →[stroke修正処理を仕込んでからepstopdf]→ PDF →[pdfTeXでクロップ+余白付与]→ PDF(ここで Quartz API で背景塗り&ロンダリング)→[gs epswrite]→ EPS →[pstoedit]→ EMF
「ストローク修正の結果としてその後のアウトライン化でも変色しない効果が得られる」というのは新しい知見のようです(この変色は、通常のフォントが fill で描かれているのに対してエミュレートの Type3 フォントは stroke で描かれていることが原因;すなわち「Type3 フォントでエミュレートした場合は必ず stroke 修正を行うべき」)。「pdftops とそれに続く stroke 修正処理によってどうやらビットマップ化を防げる」というのも新しいかも。 |
いま、PDF のアウトライン化のベストプラクティスを考えています。すぐ上の Mac 版 EMF 出力で得た知見をもとに考えると、「gs9.15 未満でパターンがどうしてもビットマップ化してしまう」という問題を防ぐには以下のようにする必要がありそうです: アウトライン化 PDF 出力;gs 9.15 以上の場合TeX → PDF →[pdfTeXでクロップ+余白付与]→ PDF(背景塗り&ロンダリング)→[gs pdfwrite]→ アウトライン化PDF
PDF 出力の場合、pdftops を通してしまうと勝手に Type3 フォントでエミュレートされてしまうのでパターンが失われて不都合です。したがって、パターンを残せる上記の経路が妥当でしょう。 アウトライン化 PDF 出力;gs 9.15 未満の場合TeX → PDF →[pdftops]→ EPS →[stroke修正処理を仕込んでからepstopdf]→ PDF →[pdfTeXでクロップ+余白付与]→ PDF(背景塗り&ロンダリング)→[gs epswrite]→ EPS →[epstopdf]→ PDF
アウトライン化 PDF 出力;gs 9.15 未満の場合(次善の策)TeX → PDF →[pdfTeXでクロップ+余白付与]→ PDF(背景塗り&ロンダリング)→[gs epswrite]→ EPS →[epstopdf]→ PDF
古い gs でもパターンをアウトライン化できた方がよければ pdftops を使うのがよさそうですが、「古い gs のバージョンではパターンは今はサポート外」としてしまうのも一理あると思っています。gs 単独で「ビットマップ化されない安全なテキストのアウトライン化」を実現できればむしろ pdftops を使わない方がベストになるはずですし、もう少し真面目に探してみます。 |
こちらはpdfiumdraw直接の線でそのまま考えていますが,いろいろ試しても外の塗りは出ないので,いったんあきらめます…….状況が起こりにくくなるように,--scale=10をはずそうかと.ちと不便ですが,きちんと描画されないよりはましなので.または解像度レベルにあわせるかなぁとも思っていますが. |
EMF はだいぶしんどいですね… いろいろ試していただいてありがとうございます。--scale=10 を外すと右上が消えやすくなるという話は余白機能で対処することにします。 |
今のところの最新をおいておきます.だめなことがわかっているの以外は大丈夫そうですが,もう少しテストしていったん出します.(たぶん今年最後……)何か気がついたことがあれば. |
あけましておめでとうございます。本年もよろしくお願いいたします。 時間が空いてしまいましたが、SVG への対応については
Mac 版の mudraw のビルドと変換経路を元に戻すという話だった気がしましたので、mudraw のビルドを試してみました。Lion 環境で素朴に mupdf-1.7a-source.tar.gz を展開して
とすると一応ビルドは通るみたいです。できた mudraw を otool で見ると依存ライブラリは
でした(ということは port には依存していないようだが、libcrypto がまずい…? どうすればよいのでしょう)。ソースに abenori さんのパッチ svg-device.patch をあてればパターンの translate が直るということのようです。なお、mupdf-1.8-source.tar.gz で同じことをやろうとするとなぜか X11 を無効にできず、Makerules の
としたらビルドは通りました。(mutool というのしかできませんが、単に mudraw の機能が mutool に統合されただけですので、リネームまたはシンボリックリンクで mudraw にできます)。 ちなみに、PDF → PDF の文字アウトライン化を PostScript 藝で試そうとしましたが、どうもうまくいきません。素直に考えれば
|
あけましておめでとうございます。 さて,mupdf のビルド法の調査ありがとうございます。 新機能
これで,SVGパターン塗り問題が一気に解決したのではないでしょうか。😄 |
Ver. 2.1.5 beta 9 を試しました。libcrypto がなくなって軽くなったのでよかったです😃 SVGZ 形式での出力、 結局、本トピックで経路としては変わったのは EMF だけということですね。アウトライン化 PDF / SVG のパターン塗りが gs9.15 未満でたまにビットマップ化されるのは対処が面倒だし、Win/Mac ともにしょうがないということで。 mupdf のパッチ版が translate 修正に成功しているかどうか今手元ではわかりません… 後で出来たSVG を Windows に持っていってチェックします…(ビルド済み dmg で配布されている Inkscape 0.91 が Lion でクラッシュ&MacPorts のは依存ライブラリ libvisio-0.1 のビルドで落ちる😥) |
というところがいい加減(特に根拠無し)なので,きちんと考えた方が良いかもしれないです.たぶん塗りつぶし一つ一つの高さぴったりにするのが良いのですが,sdev->tiles->step.yはそれよりちょっと小さい気がしています. |
ちなみに,前回 mupdf のビルドができなかったのは,El Capitan で OpenSSL のヘッダファイルが提供されなくなったことが原因だったようです。 |
この方法でやると,パターンがアウトライン化されて,斜線のつなぎ目が綺麗になりますね。 パターンのアウトライン化をしない場合- 斜線のつなぎ目が見える - ファイルサイズ 62KB - レンガは綺麗パターンのアウトライン化をした場合- 斜線のつなぎ目が見えず綺麗 - ファイルサイズ 633KB - レンガの模様に微妙につなぎ目が見えるこれらの結果は,Safari, Chrome, Firefox のいずれでも同様でした。 どちらがよいでしょうか……。 |
PDF / PS のパターンは本来 SVG のパターンへと変換されるべきで、MuPDF がパターンの分割をバグ認定したうえで修正したのは妥当でしょう。これを昔のものに戻すのは良くないと思います。 |
なるほど,そうでした。 |
端が微妙に切れるのは大した問題ではないと思います。(もしかするとこれと関係?)というわけでリリースよろしくお願いします。 |
現象
次のソースを TeX2img でSVG化すると,パターンが欠ける。
# 原因#34 で,mudraw の最新バージョン対応のために-l
オプションを外したことが原因。TeX2img.app に内包されている旧バージョンの mudraw は
-l
オプションを受け入れる。#34 の改修前のように,-l
を付けておけば,パターンも無事に保持される。# 対策GUI版については,.app に内包されている旧バージョンの mudraw を使っているので,-l
を付けるように戻せばよいだろう。CUI版については,GUI版がインストールされている場合はその中の mudraw を優先的に使い,-l
オプションを付ける。GUI版がインストールされておらず,新バージョンの mudraw のみインストールされている場合は,やむなく-l
なしで実行する。とするのが最善か?# 検討事項新バージョンの mudraw でも旧バージョンの-l
に相当することはできないものか?The text was updated successfully, but these errors were encountered: