dvips + gs 経由の変換への対応（PSTricks などの用途を想定）

[doraTeX]

［#28 での議論を受けて，新規に Issue として独立させました。］

ここまでのまとめ

1. PSTricks をサポートしたい。
2. そのためには DVIware として dvipdfmx だけでなく dvipdf にも対応するようにしよう。
3. dvipdf は Ghostscript が入っている環境ならば存在を仮定してよいだろう。
4. GUI のパス設定画面の dvipdfmx という部分は DVI to PDF と改称しよう。
5. CUI 版の --dvipdfmx は --dvitopdf などと改称しよう。
6. PSTricks を \usepackage した PSTricks 用のテンプレートを増設しよう。

   課題

7. テンプレートの内容はどうするか。PSTricks を使用するための標準的なプリアンブルはどんな内容か。
8. DVIware として dvipdfmx と dvipdf の2つだけを想定するという前提でよいのか。そして，パス設定文字列に指定された DVIware の指定が dvipdfmx であるか否かによって，-vv オプションを付与するか否かを判定するという「毒入り」挙動でよいのか。代案としては，
   • 自動判定のサーチ対象 DVIware が dvipdfmx である場合には，見つかった dvipdfmx のパスに対して -vv を付けて，設定画面のパス欄に /path/to/dvipdfmx -vv を入力するという案 ➡ ユーザーが不審に思うかも。
   • dviware をまず --help 付きで実行してみて，そのヘルプメッセージに -vv という文字列が含まれていれば -vv 付きで実行するという案 ➡ やや大げさか。
   • 「-vv の ON / OFF を切り替えるためのチェックボックス」を設定画面に追加する ➡ 高々 -vv に対して大げさすぎる。
9. 「自動判定の対象の選択肢に表示されるエンジン名称」「ロードされるプリアンブルテンプレートのファイル名」「パスをサーチする実行ファイルの名称」の対応関係をどのように付けるか。自動的に対応が決まるような規則的な命名は可能か。それとも手動で対応をハードコーディングするしかないか。
10. pdfLaTeX, LuaLaTeX のような PSTricks をフルサポートできないエンジンに対する PSTricks 対応はしなくてよいか。UI上それをどう表現するか。

    案1

    • プロファイル一覧
    • LaTeX
    • pLaTeX
    • upLaTeX
    • XeLaTeX (Japanese)
    • LuaLaTeX (Japanese)
    • チェックボックス「use PSTricks」
    • 用意するテンプレート
      1. compiler: pdflatex
      2. compiler: latex (with PSTricks)
      3. compiler: platex
      4. compiler: platex (with PSTricks)
      5. compiler: uplatex
      6. compiler: uplatex (with PSTricks)
      7. compiler: xelatex
      8. compiler: lualatex

➡ この場合……

• 「UI上の選択状態 → ロードされるテンプレートのファイル名」はハードコーディングになる。
• 「use PSTricks」のチェックがONで LuaLaTeX などが選択されたときの挙動の規定が難しい。それをサポートしないのならば，それをUI上どう表現するかが課題。

  案2

エンジンと DVIware をフラットに列挙。dvipdf を使うテンプレートには PSTricks 用であることを明記。

• LaTeX + dvipdf (for PSTricks)
• pdfLaTeX
• pLaTeX + dvipdfmx
• pLaTeX + dvipdf (for PSTricks)
• upLaTeX + dvipdfmx
• upLaTeX + dvipdf (for PSTricks)
• XeLaTeX (Japanese)
• LuaLaTeX (Japanese)

この案のメリットとしては，

• PSTricks をサポートしない組み合わせははじめから選べない。
• 選択肢の表示名とテンプレートのファイル名とを完全に一致させられる。
• テンプレートの名称から，サーチすべきエンジン名と DVIware 名が機械的に算出できる。

デメリットとしては，

• 選択肢が多くて分かりにくく，特に初心者がぱっと見たときにどれが標準的な選択肢なのか困惑する

---

こう並べてみると，案1 が案外複雑で，それよりは案2の方がフラットで規則的でシンプルな設計である気がしてきました。

[aminophen]

Mac 版 1.9.9 のこの UI がシンプルで気に入っているので、あまりたくさん並ぶと困惑しそうなのが唯一の心配ですが、実装の手間と今後のメンテナンスを考えると案2でしょうかね… でもさすがに困惑する予感が強いので決断できません。

あべさんだったらどうするかも気になります。前に困ったときに「テンプレートを作る」という妙案を出したのもあべさんでしたし。

[aminophen]

ふと気づいたのですが、#28 でわかった「Ghostscript のフォント設定ファイルは今使っているシェルの PATH で最初に見つかったものが使われる」を考慮すると、Converter.m のなかで dvipdf / dvipdfmx 実行時にも gs に export PATH したほうがよいことになるんでしょうか。実際に Windows 版 TeX2img の応用で「EPS からほかの画像への変換」としての用途を Tips に書いていましたが、これを Mac 版でやろうとすると EPS から PDF への変換に必要な gs を見つけられず、conversion に失敗します。

[doraTeX]

なるほど，dvipdfmx 実行時にEPSの処理のために gs が呼ばれる場合に対する対処ですね。 こっそり後追いで Ver. 1.9.9 に潜り込ませましょう。

[doraTeX]

Ver. 1.9.9 に滑り込ませました。 （これでCUI版も内容が更新されることになりました。）

[aminophen]

（これでCUI版も内容が更新されることになりました。）

おそらく CUI はユーザのログインシェルが使われるのであまり問題はなかったとは思いますが、GUI にとっては重要ですね（なんでいままで気づかなかったのだろう…）。これで dvipdf / dvipdfmx ともに gs を正しく認識できる見込みが立ったといえますね。

[doraTeX]

Mac 版 1.9.9 のこの UI がシンプルで気に入っているので、あまりたくさん並ぶと困惑しそうなのが唯一の心配ですが、実装の手間と今後のメンテナンスを考えると案2でしょうかね… でもさすがに困惑する予感が強いので決断できません。

もともと，「自動判定」ボタンを押すたびにこの一覧を出さないようにし，一覧を「自動判定の詳細設定」のような別項目に押しだそうという話になったのは，「初心者に XeLaTeX などの一覧を見せて困惑させないため」でした。ということは，あえてこのボタンを押すのは上級者という想定でよいのではないでしょうか。 案2 の一覧の場合，上級者にとっては各選択肢が何を意図しているのか，それぞれを選ぶとどうなるのかがぱっと見て分かりやすいと思います。それに対し，案1 の場合，UIの設定状態とその後の動作との関係が複雑で，上級者にとっては逆に各選択肢に対して TeX2img が行う動作の予想が難しいような気がします。

[doraTeX]

ということは，あえてこのボタンを押すのは上級者という想定でよいのではないでしょうか。

ただし，この一覧はプリアンブルテンプレートのデフォルトとも連動するので，確かにその部分は初心者の目に付く部分でもありますね。

[aminophen]

もともと，「自動判定」ボタンを押すたびにこの一覧を出さないようにし，一覧を「自動判定の詳細設定」のような別項目に押しだそうという話になったのは，「初心者に XeLaTeX などの一覧を見せて困惑させないため」でした。

たしかにそうですね。

• 日本のユーザは (u)pLaTeX + dvipdfmx が主流
• 海外のユーザは pdfLaTeX または LaTeX + dvipdf が主流（後者は PSTricks や PSfrag にほぼ限る）

という憶測なのですが、CUI との兼ね合いやメンテナンスしやすさを考えると「デフォルトは pLaTeX + dvipdfmx」としたうえで8つ列挙するのが良い気がしてきました。ただ

• 日本で dvipdf の知名度が極端に低そう
• 各種統合環境で dvipdf をみると dvipdfmx を想起する癖がついた日本のユーザは多そう

という事情から、dvipdf の UI における表記だけ dvips + ps2pdf にしたほうが良いかもしれません。

[doraTeX]

dvipdf の UI における表記だけ dvips + ps2pdf にしたほうが良いかもしれません。

なるほど。嘘をつくことに若干の後ろめたさもありますが，そうすると

• pdfLaTeX
• pLaTeX + dvipdfmx
• upLaTeX + dvipdfmx
• XeLaTeX (Japanese)
• LuaLaTeX (Japanese)
• LaTeX + dvips + ps2pdf (for PSTricks)
• pLaTeX + dvips + ps2pdf (for PSTricks)
• upLaTeX + dvips + ps2pdf (for PSTricks)

となりますかね。（PSTricks 系を後ろにまとめてみました。若干見やすいかな？）

ところで，他にも和文用設定がいくつもあるのに，XeLaTeX, LuaLaTeX にだけ (Japanese) が付いているのは若干不自然な気がしてきました……。

[aminophen]

嘘をつくことに若干の後ろめたさもありますが，

ps2pdf は嘘ですものね… dvips + gs とかだとセーフでしょうか。ちなみに、いま Windows 版 Ghostscript もみてみたのですが、dvipdf は Unix 系とほぼ同じシェルスクリプトが入っているだけでした（要するに Win ネイティブで使えません）。

（PSTricks 系を後ろにまとめてみました。若干見やすいかな？）

確かにまとめるとみやすいです。ただ (for PSTricks) は dvips という単語があれば不要な気がします（用途はさすがにわかるはずですし、PSTricks だけでなく PSfrag の利用も十分考えられますし）。

[doraTeX]

ただ (for PSTricks) は dvips という単語があれば不要な気がします（用途はさすがにわかるはずなので）。

これは，プリアンブルテンプレートの名称を兼ねているので，(for PSTricks) がないと，プリアンブルにデフォルトで PSTricks が \usepackage されていることが不自然であろうという判断でした。

一方，逆に，((u)p)LaTeX + dvips + gs のプリアンブルテンプレートの用途を PSTricks に限定せず，プリアンブルに PSTricks の \usepackage を含めないという方向性の方が，汎用性も高くてよいのでは，という気がしてきました。 すると，上記課題の

1. テンプレートの内容はどうするか。PSTricks を使用するための標準的なプリアンブルはどんな内容か。

という問題も自然消滅します。

PSTricks などを使いたいユーザは，テンプレートとして ((u)p)LaTeX + dvips + gs を選んで自動判定・テンプレートロードを行った上で，自分でプリアンブルを編集して PSTricks の必要なパッケージ群をロードしてもらう，というわけです。

[aminophen]

PSTricks などを使いたいユーザは，テンプレートとして ((u)p)LaTeX + dvips + gs を選んで自動判定・テンプレートロードを行った上で，自分でプリアンブルを編集して PSTricks の必要なパッケージ群をロードしてもらう，というわけです。

はい、先ほどの舌足らずな発言はそういうことを意味したつもりでした… これで XeLaTeX や LuaLaTeX の場合を別途考慮する必要性もなくなりますし、良く知らないのにテンプレートを作るという危険性もなくなります。

[aminophen]

したがって、新規に用意するテンプレートは「graphicx と color に [dvips] オプションを与えたもの」で済みますね。（もしくはそもそもデフォルトで dvips.def になるので書かなくてもよい？）

[doraTeX]

なるほど，ではその方向で考えましょう。 ここまでの議論をまとめてみます。何か見落としがありましたらご指摘ください。

ここまでのまとめ

1. PSTricks をサポートしたい。
2. そのためには DVIware として dvipdfmx だけでなく dvipdf にも対応するようにしよう。
3. dvipdf は Ghostscript が入っている環境ならば存在を仮定してよいだろう。
4. GUI のパス設定画面の dvipdfmx という部分は DVI to PDF と改称しよう。
5. CUI 版の --dvipdfmx は --dvitopdf などと改称しよう。

用意するテンプレートの種類および「自動判定の対象」の一覧

1. pdfLaTeX
2. pLaTeX + dvipdfmx
3. upLaTeX + dvipdfmx
4. XeLaTeX (Japanese)
5. LuaLaTeX (Japanese)
6. LaTeX + dvips + gs
7. pLaTeX + dvips + gs
8. upLaTeX + dvips + gs
   • これらの名称は，自動判定対象の選択肢の表示名とテンプレートのファイル名の両方を兼ねる。
   • 後ろ3つを，「graphicx と color に [dvips] オプションを与えたもの」としてテンプレートを新設。
   • dvips + gs (dvipdf) を使うテンプレートについても，汎用性を重んじて，PSTricks をデフォルトでロードすることはしない。
   • パスの自動判定時には，これらのテンプレート名称の文字列を解析することで，「何をサーチすべきか」を判断する。具体的には，
   • はじめのスペースまでの部分を小文字に変更したものを LaTeX エンジンとしてサーチ
   • dvips が入っていれば dvipdf を，そうでなければ dvipdfmx を DVI to PDF としてサーチ
   • DVIware として dvipdfmx と dvipdf の2つだけを想定する前提で，パス設定文字列に指定された DVIware の指定が dvipdfmx であるか否かによって，-vv オプションを付与するか否かを判定する（いわゆる「毒入り」）挙動でとりあえず考える。

[aminophen]

dvips + gs とテンプレート名に書くのであれば、dvitopdf という紛らわしいプログラム名を自動補完するよりはいっそ自前で dvips と gs で実装した方が安全かもしれないのですが、どうなのでしょう？ もし仮に Windows 版で同じことを実装しようとすると dvipdf に対応するツールが存在せず、パス設定に入れるべきプログラム名に困りそうです。

一つの案として、dviware をとりあえず走らせて「PDF が出ていたら先へ進み、もし PS が出ていたら gs で PDF に持っていく」ということであれば、dvipdfmx / dvipdf / dvips のいずれが入力されても問題なく先へ進めることになります（dvipdfmx の時だけ毒入り操作で -vv を付与する）。

[doraTeX]

一つの案として、dviware をとりあえず走らせて「PDF が出ていたら先へ進み、もし PS が出ていたら gs で PDF に持っていく」ということであれば、dvipdfmx / dvipdf / dvips のいずれが入力されても問題なく先へ進めることになります（dvipdfmx の時だけ毒入り操作で -vv を付与する）。

おおっ，これは名案ですね。ちょうどPDF直接出力エンジンへの対応のときに使った技ですね。 後半のステップでの gs のオプションには気を遣う必要がありますが。

すると，現在のGUI版の dvipdfmx という表記は DVIware に変更，CUI版の --dvipdfmx は --dviware に変更しても問題ないということになりますね。

[aminophen]

もうひとつ dvipdf のスクリプトを嫌う理由が、dvips と gs の両方に -q を与えていることだったりします。これだとエラーハンドリングができないので、dvipdf のスクリプトのうち2つの -q を除去したものだけ作っていただくと大丈夫かもしれません。

ちょうどいまテスト用に Windows バッチファイルに大雑把に翻訳し終えたところでした。

[doraTeX]

最新版のまとめ

1. PSTricks をサポートしたい。
2. そのためには DVIware として dvipdfmx だけでなく dvips + gs にも対応するようにしよう。
3. GUI のパス設定画面の dvipdfmx という部分は DVIware と改称しよう。
4. CUI 版の --dvipdfmx は --dviware と改称しよう。

用意するテンプレートの種類および「自動判定の対象」の一覧

1. pdfLaTeX
2. pLaTeX + dvipdfmx
3. upLaTeX + dvipdfmx
4. XeLaTeX (Japanese)
5. LuaLaTeX (Japanese)
6. LaTeX + dvips + gs
7. pLaTeX + dvips + gs
8. upLaTeX + dvips + gs
   • これらの名称は，自動判定対象の選択肢の表示名とテンプレートのファイル名の両方を兼ねる。
   • 後ろ3つを，「graphicx と color に [dvips] オプションを与えたもの」としてテンプレートを新設。
   • dvips + gs を使うテンプレートについても，汎用性を重んじて，PSTricks をデフォルトでロードすることはしない。
   • パスの自動判定時には，これらのテンプレート名称の文字列を解析することで，「何をサーチすべきか」を判断する。具体的には，
   • はじめのスペースまでの部分を小文字に変更したものを LaTeX エンジンとしてサーチ
   • dvips が入っていれば dvips を，そうでなければ dvipdfmx を DVIware としてサーチ
   • DVIware として dvipdfmx と dvips の2つだけを想定する前提で，パス設定文字列に指定された DVIware の指定が dvipdfmx であるか否かによって，-vv オプションを付与するか否かを判定する（いわゆる「毒入り」）挙動でとりあえず考える。
   • TeXソースのコンパイル時には，次のように判定する。
     1. LaTeX エンジンでコンパイルして，新しいPDFが出力されていれば画像化に進む。
     2. 新しいDVIが出力されていれば DVIware での処理に進む。DVIも生成されていないのであればコンパイルエラー。
     3. DVIware での処理結果で新しいPDFが出力されていれば画像化に進む。
     4. DVIware での処理結果で新しいPSが出力されていれば gs の pdfwrite の処理に進む。PDF生成に成功すれば画像化に進む。失敗すればコンパイルエラー。

[aminophen]

gs のオプションは -q を除くことを確定したうえで、ほかは標準出力からのパイプ入力を前提にしているものがいくつかあるのでそこを削らないといけないですね。

dvips のほうは、-q を削らないといけないのとあわせて -f は標準出力に PS を吐くものなので削除し、-Ppdf は dvips が公式に「そのあと PDF 変換したいならばフォント関係で付けるべき」としているオプションなので残すべきですね。

ということは、毒入り挙動が二つあって

• dvipdfmx なら -vv を付与
• dvips なら -Ppdf を付与
• その他なら付与オプションなし

ですね。gs はこれから考えます。

[doraTeX]

これは大きな変更になるので，確かに Ver. 2.0.0 にしてもいいかもしれません。ちょうど 1.9.9 まで来ていたのでタイミングとしてはなぜか絶好です😏

[aminophen]

gs については ps2pdf を参考にした方が早いですね。ここの .setpdfwrite の項目にも載っていますが、その通り書けば ps2pdf の再実装が可能なようです。

[doraTeX]

調査ありがとうございます。これで仕様が一通り固まった感じでしょうかね。では後は実装あるのみ!?

[aminophen]

では後は実装あるのみ!?

おそらくもう固まったとみてよいと思います。ちょうど 1.9.9 まで来ていた絶好のタイミングで国際化を視野に入れた拡張ということになりますね☺

[doraTeX]

外部ファイル入力機能（GUI / CUI）において，外部PSファイルの入力も可能にできますね。

[doraTeX]

改めて。

最新版の仕様のまとめ

1. PSTricks をサポートしたい。
2. そのためには DVIware として dvipdfmx だけでなく dvips + gs にも対応するようにしよう。
3. GUI のパス設定画面の dvipdfmx という部分は DVIware と改称しよう。
4. CUI 版の --dvipdfmx は --dviware と改称しよう。
5. GUI, CUI版ともに，外部PSファイルの入力を受け付けられるようにしよう。

用意するテンプレートの種類および「自動判定の対象」の一覧

1. pdfLaTeX
2. pLaTeX + dvipdfmx
3. upLaTeX + dvipdfmx
4. XeLaTeX (Japanese)
5. LuaLaTeX (Japanese)
6. LaTeX + dvips + gs
7. pLaTeX + dvips + gs
8. upLaTeX + dvips + gs

仕様

• これらの名称は，自動判定対象の選択肢の表示名とテンプレートのファイル名の両方を兼ねる。
• 後ろ3つを，「graphicx と color に [dvips] オプションを与えたもの」としてテンプレートを新設。
• dvips + gs を使うテンプレートについても，汎用性を重んじて，PSTricks をデフォルトでロードすることはしない。
• パスの自動判定時には，これらのテンプレート名称の文字列を解析することで，「何をサーチすべきか」を判断する。具体的には，
  • はじめのスペースまでの部分を小文字に変更したものを LaTeX エンジンとしてサーチ
  • dvips が入っていれば dvips を，そうでなければ dvipdfmx を DVIware としてサーチ
• TeXソースのコンパイル時には，次のように判定する。
  1. LaTeX エンジンでコンパイルして，新しいPDFが出力されていれば画像化に進む。
  2. 新しいDVIが出力されていれば DVIware での処理に進む。DVIも生成されていないのであればコンパイルエラー。
     1. DVIware での処理結果で新しいPDFが出力されていれば画像化に進む。
     2. DVIware での処理結果で新しいPSが出力されていれば gs の pdfwrite の処理に進む。PDF生成に成功すれば画像化に進む。失敗すればコンパイルエラー。
• DVIware の実行にあたっては，パス設定文字列に指定された DVIware の指定によって挙動を分ける。
  1. dvipdfmx のときは -vv オプションを付与。
  2. dvips のときは -Ppdf を付与。
  3. それ以外の場合はオプションを追加しない。
• PS→PDF の変換時は，gs -dSAFER -dNOPAUSE -dBATCH -sOutputFile=hoge.pdf -sDEVICE=pdfwrite -c .setpdfwrite -f hoge.ps のように実行する。

[abenori]

追いついていませんが……とりあえず思ってみたことを五月雨式に書いてみます．

• dvipdfはWindowsでは（本質的には）ないように見えます．（TeX Liveにはなし．Ghostscriptに入っているのはシェルスクリプト：Windowsでは実行不可）
• -vvは常にとってしまえばよいのではないでしょうか？どうせログなんて必要にならないとみないし，本当に欲しいならばパスにオプション毎指定してしまえばよいと思うので．（dvipsの-Ppdfもしたい人はパスに指定するのでよいかなと：こっちはちと微妙ですが．）
• dvips経由の変換は，初期設定で用意しておくほどよく使われているのでしょうか？（例えばTeXworksのデフォルト設定にはないわけですが……．）

[abenori]

それと--platex/--dvipdfmx/--gsなんですが，美文書に入れたインストーラが使っているので極力変更したくはないです．

[doraTeX]

では，やはり「毒抜き」のために，次のような挙動にすることにしてみます。

Before

DVIware の実行にあたっては，パス設定文字列に指定された DVIware の指定によって挙動を分ける。

1. dvipdfmx のときは -vv オプションを付与。
2. dvips のときは -Ppdf を付与。
3. それ以外の場合はオプションを追加しない。

After

パスの自動判定にあたっては，テンプレート名から判断した，検索する DVIware の名称（dvipdfmx または dvips）によって挙動を分ける。

1. dvipdfmx のときは -vv オプションを付与したものをパスに設定する。
2. dvips のときは -Ppdf を付与したものをパスに設定する。

[doraTeX]

↑この After の仕様の場合，CUI版で実行したときに -vv や -Ppdf を付けるためには，

• --dviware="dvipdfmx -vv"
• --dviware="dvips -Ppdf"

と設定する必要が生じてしまいますので，やはり Before の方に戻してみます。

[doraTeX]

上記の仕様 に基づいて，Ver. 2.0.0 beta 1 を作りました。

（↑これは自動的に辞書式順序にソートされてしまいますが）

テスト用 PSTricks ソース

% compiler: platex
\documentclass[fleqn,papersize]{jsarticle}
\usepackage{amsmath,amssymb}
\usepackage[dvips]{graphicx,color}
\pagestyle{empty}
\usepackage{pst-3dplot}

\begin{document}
Test: 日本語の\textgt{テスト}。

\psset{unit=0.75}
\begin{pspicture}(-10,-10)(6,6)
\psset{Beta=20,Alpha=50,linewidth=0.1pt,linecolor=blue}
  \parametricplotThreeD[xPlotpoints=200,yPlotpoints=100](80,360)(0,360){%
    /k 2 def /k2 4 def
    t cos k mul 3 u sin k mul add mul
    t sin k mul 3 u sin k mul add mul
    u cos k2 mul
  }
  \parametricplotThreeD[xPlotpoints=100,yPlotpoints=200](0,360)(80,360){%
    /k 2 def /k2 4 def
    u cos k mul 3 t sin k mul add mul
    u sin k mul 3 t sin k mul add mul
    t cos k2 mul
  }
  \parametricplotThreeD[xPlotpoints=100,yPlotpoints=2,linecolor=red,linewidth=2pt](0,360)(80,360){%
    /k 2 def /k2 4 def
    u cos k mul 3 t sin k mul add mul
    u sin k mul 3 t sin k mul add mul
    t cos k2 mul
  }
\end{pspicture}

\end{document}

[aminophen]

dvips について調べていたのですが、手元の 2012 年頃の W32TeX はデフォルトで pk フォントを使っていた（このころ既に TeX Live は type1 フォントを採用）ので -Ppdf にしないと綺麗にならなかったようですが、2015 年現在は W32TeX / TeX Live ともに type1 フォントを使っているようです。だから現時点では「昔の dvips をサポートするなら必須で、最新の環境では付けても利益はないが害もない」といえるようです。

Mac 版 Ver. 2.0.0 beta 1 はこれから試します。

[aminophen]

Mac 版 Ver. 2.0.0 beta 1 を試してみました。dvips (+ gs) による変換も日本語対応も大丈夫そうです。念のため dvipdf もプログラムに書いてみたところ、正常に動作していました。

ところでなんで dvips のログって標準エラー出力に全部行ってしまうのでしょうね…

[aminophen]

外部ファイル入力機能（GUI / CUI）において，外部PSファイルの入力も可能にできますね。

これも正しく機能しているように見えます。PS ができるということは EPS も類似処理ができるのかもしれないので、調べてみます。

→これは .eps を .ps と“偽装”すれば通りますね。ということは .eps を拡張子として許容すれば大丈夫そうです。

[abenori]

とりあえずdviwareにdvipsを書いても大丈夫にしてみました． https://onedrive.live.com/redir?resid=4FABCB4EC4FA1E70!16825&authkey=!ANYoMX5Yq7PLXU4&ithint=folder%2cexe オプションは取っ払いました．dvipdfmx -vv -o (output) (input)となっていたのがdvipdfmx (input)と実行されます．

[aminophen]

とりあえずdviwareにdvipsを書いても大丈夫にしてみました．

試してみました。たぶん正常に処理できていると思います。

オプションは取っ払いました．

dvipdfmx の -vv なしだと「読まれた map ファイルの情報」「埋め込まれた実フォント名」が出なくてただ何ページの PDF ができたかしか見えないので、情報量が少ないのですよね。dvips の -Ppdf も W32TeX 2012年頃をサポートするなら要るのですが、どうしましょう… -o (output) は不要ということでよいです。

[abenori]

-vvは，そういう情報を欲するような猛者は自分でオプション指定してくれればいいかなぁと思いました．ログを見るのって失敗した時に限りません？ -Ppdfは，指定してもいないオプションがいきなりついてくるのもどうなんだろうと……特に出力に関わるオプションですし．（ないとは思うけど）「つけたくない」という時にどうにもならないのも気になります．

パス推定もいじってしまったのですが，なんか議論からプレアンブルの%compiler: の行を読んでそれを使うのだと思ってしまっていました……後で議論を見返します．

[doraTeX]

Mac 版 Ver. 2.0.0 beta 1 を試してみました。dvips (+ gs) による変換も日本語対応も大丈夫そうです。念のため dvipdf もプログラムに書いてみたところ、正常に動作していました。

テストありがとうございます。事前に仕様をしっかり検討して固めておいたおかげで，すんなりと実装できました。

外部ファイル入力機能（GUI / CUI）において，外部PSファイルの入力も可能にできますね。

これも正しく機能しているように見えます。PS ができるということは EPS も類似処理ができるのかもしれないので、調べてみます。

→これは .eps を .ps と“偽装”すれば通りますね。ということは .eps を拡張子として許容すれば大丈夫そうです。

Ver. 2.0.0 beta 2 でGUI版/CUI版ともにEPS入力に対応させました。

[aminophen]

いま合意に至ってないのは以下の2点でしょうか。

dvipdfmx と dvips のオプション

整理すると、Mac 版はいま“毒入り”で「dvipdfmx なら -vv を付与、dvips なら -Ppdf を付与、その他なら無し」で、Win 版は毒なしで「一律に無し」になっています。個人的にはオプションが付いていてほしいのですが

-Ppdfは，指定してもいないオプションがいきなりついてくるのもどうなんだろうと……特に出力に関わるオプションですし．（ないとは思うけど）「つけたくない」という時にどうにもならないのも気になります．

も一理ありますね。-vv のように本質的に出力に関係ないもの以上に慎重にする必要がある気がしてきました。だとすると、オプションまわりの仕様をもう少し真剣に考えないといけない段階に来ていますね。以前、オプションを UI から（LaTeX の interaction は別途必須としたうえで）自由に変えられるようにする案がお蔵入りになった気がしますが、それも視野に入れないといけないかもしれません。

CUI のパス指定オプション名

いちおう整理すると、Mac 版は昔から --compiler があって最近 --dvipdfmx / --gs が付いたのですが、今回 --dviware に変更しようとしています。Win 版は --platex / --dvipdfmx / --gs になっています。Win 版の

美文書に入れたインストーラが使っているので極力変更したくはないです．

が強い制約になってきます。（美文書6版3刷を持っていないのですが、Mac 版 CUI は入っているのでしょうか？）とはいえ --dvipdfmx オプションが従来 -vv を勝手に与えてきたことを考慮すると、本物の dvipdfmx 以外を使うために愛用してきた人はほぼいないだろうということで、名称を変えるなら今しかないという感覚もあります。そこでなのですが

• 従来のオプション名は削除せずそのまま残す： --platex / --dvipdfmx (Win), --dvipdfmx (Mac)
• そのうえでオプションを増設する： --compiler / --dviware (Win), --dviware (Mac)
• ヘルプメッセージに出すのは --compiler / --dviware の方にするが、もしユーザが従来のオプションを実用しても受け入れる；仮に両方指定されて矛盾した場合は、後から指定された方を採用（これは no- とかマイナスとかの場合と類似）して処理する

とかだと後方互換性としては十分だと思うのですが、だめですかね？

[doraTeX]

Mac版は現在

• LaTeX ↔︎ --compiler
• DVIware ↔︎ --dviware
• Ghostscript ↔︎ --gs

となっています。 今回，従来の --dvipdfmx を --dviware に変更しましたが，ついでに，GUIの表記とあわせて --compiler を --latex に変更するのがよいと思っています。

互換性のために --compiler と --dvipdfmx も隠しオプションとして残しておくことは可能ですが，そこまで必要でしょうかね？

美文書6版3刷を持っていないのですが、Mac 版 CUI は入っているのでしょうか？

入っていません。Windows版は，インストーラ側から TeX2img の設定を制御するのにCUIオプションを使っていたと思います。Mac版は，インストーラが設定に応じた ~/Library/Preferences/com.loveinequality.TeX2img.plist を生成します。ですから，Mac版ではCUIのオプションの互換性はそれほど重視する必要がありません。

Windows版とMac版の挙動は既に色々異なる点がありますので，あまり細かいところまで挙動を統一する必要はないのではと思います。

[doraTeX]

「-Ppdf を外す手段がない」という問題に対処するには，やはり After案 を再検討するのがよいかもしれません。（その場合CUI版ユーザは各自必要に応じて対処してもらうことになります。）

[aminophen]

-Ppdf の有無によって変化がある W32TeX を使って、どれくらい画像に違いが出るか調べました。

W32TeX [2012/11/04] の dvips はデフォルトでは pk フォント <c:/w32tex/share/texmf/fonts/pk/ljfour/public/cm/cmr10.600pk> を使いますが、-Ppdf を付けると type1 フォントに切り替わります。 W32TeX [2014/12/29] の dvips は type1 フォント <c:/w32tex/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb> を使うようになっていて、-Ppdf を付けても付けなくても type1 フォントです。 この2年間のどこかで変更されたようですが、やはり TeX2img (Win) の解像度20で PNG 化すると違いは目立ちますね（上が2012で下が2014）。

ただ、teTeX / ptetex のほうは2006年の時点で type1 フォントを使っているので、（少なくとも日本で使われているであろう）TeX Live は最初から type1 です。そう考えると、あえて TeX2img が -Ppdf を付けなくても綺麗に文字を出せる環境は案外多く、敢えて毒入りにしなくて良い気がしてきました。W32TeX の古いものを使っている人だけ dvips で -Ppdf を使うように Tips に書いておけば十分でしょう。併せて -vv も取っ払えば全部毒抜きにすることができます。現行の Win 版の挙動が素直なのかもしれません。

[aminophen]

互換性のために --compiler と --dvipdfmx も隠しオプションとして残しておくことは可能ですが，そこまで必要でしょうかね？

--compiler が --latex に変わるのであれば、なおさら隠しオプションが必要だと思います。--dvipdfmx は使っていた人が少なそうですが、--compiler はかなり前からあってメジャーなオプションだったのではないでしょうか？（ver 1.9.10 から ver 2.0.0 へのメジャーアップデートなので、この際一気に変えてしまおうというのであれば否定はしませんが。）

[doraTeX]

Ver. 2.0.0 beta 3 を作りました。

• --compiler や --dvipdfmx を隠しオプションとして復活させました。
• dvipdfmx -vv や dvips -Ppdf のオプション実行時自動付与を停止し，「毒抜き」しました。代わりに，After案 に従い，「自動判定」ボタンを押したときにこれらを自動付与します。CUI版ユーザでこれらが必要な場合は各自対処が必要です。

[abenori]

--dviwareってオプション名があまりしっくりきていないのは僕だけでしょうか……．ともかくこんな感じですかね？＜オプション https://onedrive.live.com/redir?resid=4FABCB4EC4FA1E70!16825&authkey=!ANYoMX5Yq7PLXU4&ithint=folder%2cexe

推定はこんな感じでしょうか？（テンプレート名からじゃなくて，%compiler:を読むことにしたままです……これでいい気もしてきた．）

[doraTeX]

仮想マシン内でWindows版TeX2imgを立ち上げてみました。 本件とは無関係ですが，プリアンブルウィンドウを開いたときに，メインウィンドウが左の方にあると，プリアンブルウィンドウが画面左に切れてしまい，マウスでつかんで移動できない状態になってしまいました。

この方法で移動可能でしたが，新規ウィンドウ表示時に画面端からはみ出さないようにしておくと親切かと思いました。 （これはたぶん旧Windows版のときに自分が書いたコードのせいかと思います…… m(__)m）

[aminophen]

Mac 版 Ver. 2.0.0 beta 3 を試しました。隠しオプションの件、ありがとうございます。ひとつ気になっているのは GUI 版の自動判定で /Applications/Ghostscript.app/bin/gs が最初に見つかってくれないことです。/usr/local/bin/gs という MacTeX のほうが先に見つかりますが、仕様でしょうか。

[doraTeX]

/usr/local/bin/gs という MacTeX のほうが先に見つかりますが、仕様でしょうか。

現仕様では，

1. まずユーザがログインシェルにて設定している $PATH 内をサーチ
2. そこに見つからなければ，TeX2img が知っている「よくある TeX システムインストールパス」内を自力で検索

という挙動をしています。

お使いのターミナルを起動して，echo $PATH してみてください。おそらく /usr/local/bin の優先度が高くなっているのだと思います。

コマンドラインを普段から常用しているユーザのことを考え，まずユーザがログインシェルにて設定しているパス設定を優先的にサーチしている（Windows版でシステムワイドのPATH設定をサーチするのと同様）のですが，この仕様ではまずいでしょうか？

[aminophen]

Win 版も試してみました。隠しオプションではなく (obsolete) としてヘルプに表示してありますね。どちらでもよいです。ふと気づいたのですが、TeX2img.exe のほうがコマンドで tex2img としても起動せず「ファイル tex2img に対応する出力ファイルが指定されていません」というダイアログが出ました。（このまえ tex2imgc で起きたのと同じ理由だと思います）

Win 版の自動判定の高度な設定ボタンの実装ありがとうございます。そのうち dvips 用のテンプレートも準備されるのかなと期待です。微妙に Mac 版と挙動が異なるのですが

• Mac 版は「詳細…」ボタンでプロファイルを選択してもパス設定などは変わらず、「自動判定」ボタンを押すと初めて推定がはたらく。推定が終わったら初回起動時と同様の「…に設定しました。」のダイアログが出て、その後に続いて「以下のプリアンブルをロードします」という上書き確認ダイアログが出てくる。
• Win 版は「高度」ボタンでプロファイルを選択するとパス設定がすぐに変わる（「…に設定しました。」のダイアログはなし）。テンプレート部分は自動では切り替わらない。

となっています。両方の動きを見ていて、なんだか Mac 版の2回連続ダイアログが冗長な気がしてしまいました… というのも

• 初回起動時に「…に設定しました」は、そのときパス設定画面が表示されていないのでダイアログを見せた方が親切だろう。
• 自動判定やりなおしのときはパス設定画面を目の前にしているので、わざわざダイアログで「…に設定しました」は言われなくてもわかるだろう。

という理由からです。ここで考えているのですが

• Mac 版のひとつめの「…に設定しました」ダイアログを削ってもいいかもしれません。
• Win 版の「高度」ボタンの切り替えで即パスが変わるのと、Mac 版の「自動判定」ボタンで初めて切り替わるのと、どちらが自然でしょう？
• 上記の自然な挙動にしたうえで、Win 版もテンプレートを自動で切り替えてくれると使いやすいと思います。

あと細かい点ですが、Mac 版の「詳細…」が途中でちぎれていることに気づきました。

欲を言えば Win 版もボタンが近すぎて切れている気がしないでもないです。

[aminophen]

お使いのターミナルを起動して，echo $PATH してみてください。

普段ターミナルでは bash を使っているのですが

lab-no-iMac:~ nojilab$ echo $PATH
/Applications/Ghostscript.app:/Applications/Ghostscript.app/bin:/opt/local/bin:/opt/local/sbin:/Applications/gnuplot.app:/Applications/gnuplot.app/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/X11/bin:/Library/TeX/texbin

です。

[doraTeX]

/usr/libexec/path_helper -s してみてください。そちらの結果はいかがでしょうか。