search

doraTeX / TeX2img

TeX2img for macOS
https://tex2img.tech
Other
26 stars 2 forks source link

初回起動時に設定プロファイルを選択する機能 → 自動判定対象エンジン選択機能に変更 #28

Closed doraTeX closed 9 years ago

doraTeX commented 9 years ago

現状は，初回起動時に platex へのパスが自動探索され，jsarticle を用いた典型的な和文文書作成の pLaTeX 用プリアンブルが設定されるようになっている。 しかし，将来的な国際展開まで視野に入れると，pLaTeX + dvipdfmx + jsarticle がデフォルトというわけにはいかないだろう。 一方，現状の TeX2img が日本語ユーザーにとって便利な初期設定になっており，そのため初期設定の障壁が下がっているというメリットは重大であり，軽視できない。

そこで，初回起動時に典型的な設定プロファイルから選ばせるという仕様はどうだろう。 例えば，初回起動時に

使用するプロファイルを選択してください。

  • pdfLaTeX（英文）
  • XeLaTeX（英文）
  • LuaTeX（英文）
  • pLaTeX（和文）
  • upLaTeX（和文）
  • XeLaTeX（和文）
  • LuaLaTeX（和文）

のようなダイアログを出す。日本語環境で起動された場合には「pLaTeX（和文）」がデフォルトで選択されているようにしておく。

そして，それぞれに対応するプリアンブルテンプレートがデフォルトでロードされるだけでなく，LaTeX コンパイラのパスも，それぞれに対応するものを探索して設定する。

初回起動時に誤ったプロファイルを選択した場合のために，後からでもやり直せるようにしておく。 環境設定の「自動判定」ボタンを利用し，次のような挙動をさせる。

  1. 自動判定ボタンを押す。
  2. 「どのコンパイラをサーチしますか？」というダイアログを出し，初回起動時と同じ選択肢を提示する。
  3. ユーザが選択したコンパイラパスをサーチした後に，次に「対応するプリアンブルのテンプレートもロードしますか？」というダイアログを出し，ユーザが「はい」と答えればプリアンブルもそれに書き換える。（デフォルトのプリアンブルテンプレートをユーザが削除していてもよいように，TeX2img.app に内包されているデフォルトのプリアンブルテンプレートの原本からロードする。）

一方，CUI版の --compiler のデフォルト値は現状 platex になっているが，これをどうするかという課題は残る。

aminophen commented 9 years ago

という観点から提案すると、初回起動時は

のほうが日本語話者にとってはいまはよいと思います。「自動判定」ボタンも日本語環境とそれ以外で分けて上記の挙動をするということになります。

以前、徹底的に“毒抜き”したときに、LaTeXiT のようにエンジンをいろいろ見せると「なんだそれー」と思われかねないという話になりました。

初回起動時に誤ったプロファイルを選択した場合のために，後からでもやり直せるようにしておく。

これを現行の「設定の保存」機能だけで補えないだろうか（デフォルトでいくつか作っておく？）と思ったのですが、自動判定との連携が難しいのでしょうか。

doraTeX commented 9 years ago

ということは可能です。ただ，問題は確かに

自動判定との連携

という部分ですね。「設定プロファイル」機能の現行の仕様では，各プロファイルには LaTeX コンパイラへのパスが保存されますが，デフォルトで用意しておくとなると，そのパスをどう指定するかを決め打ちすることができません。

考えられる手段としては，

という感じでしょうか。

また，「デフォルトで用意するプロファイルは上書き・削除不可能にするか？」という論点も生じますね。

aminophen commented 9 years ago

設定プロファイルと自動判定との連携は、確かに <AUTOSEARCH:****> というパス設定を使えば解決しそうですね。ただ、最も自然なのがどういう挙動かまだよくわかっていません。現在の「設定を保存」の流用ではエンジンだけを変えたい場合にすべての設定が連動してしまい、それはそれで不便かもしれないとも思ってきました。「ライトユーザに LuaLaTeX だの XeLaTeX だの見せたくない」と「LuaLaTeX や XeLaTeX などを自動判定で入れてほしい」との両立ができないか、もう少し考えたいと思います。

aminophen commented 9 years ago

最初に考えていた「設定プロファイルに含めてしまう」だと、あらゆる設定と同期してしまって不便そうなので、かつて「MacTeX 用設定」があったように別の挙動をするボタンか、新しいメニューを配置した方がよい気がしてきました。案として

のようなものを思いつきました。デフォルトは日本語環境かそれ以外かで切り替わってほしいので

という感じでしょうか。「自動判定」ボタンだけでいちいちダイアログが出るのは嫌なので別にしてしまおうという案ですが、煩雑すぎますかね？

aminophen commented 9 years ago

自動判定がはたらいたあとは、続いて

ユーザが選択したコンパイラパスをサーチした後に，次に「対応するプリアンブルのテンプレートもロードしますか？」というダイアログを出し，ユーザが「はい」と答えればプリアンブルもそれに書き換える。（デフォルトのプリアンブルテンプレートをユーザが削除していてもよいように，TeX2img.app に内包されているデフォルトのプリアンブルテンプレートの原本からロードする。）

となってほしいです。

doraTeX commented 9 years ago
  • 「自動判定の詳細設定」ボタンを新設し、クリックすると pLaTeX / upLaTeX / pdfLaTeX などを選べるダイアログを出す。「OK」すると自動判定がはたらく。
  • 「自動判定」ボタンは、上記設定の状態に依存してプログラムを探す。

自動判定がはたらいたあとは、続いて

ユーザが選択したコンパイラパスをサーチした後に，次に「対応するプリアンブルのテンプレートもロードしますか？」というダイアログを出し，ユーザが「はい」と答えればプリアンブルもそれに書き換える。（デフォルトのプリアンブルテンプレートをユーザが削除していてもよいように，TeX2img.app に内包されているデフォルトのプリアンブルテンプレートの原本からロードする。） となってほしいです。

「エンジンパスの自動判定」という概念と，「プリアンブルの詳細設定」という概念をどう分離または結合するのかの仕様を詰めなければなりませんね。

「自動判定の詳細設定」ボタンを押したときの選択肢に

などの候補が現れるのは，「欧文」「和文」という概念がコンパイラの種類ではないため不自然な気がします。 しかし，自動判定に続いてプリアンブルテンプレートのロードまで伴うとなると，「欧文」「和文」といった区別が必要になってきます。 いかがいたしましょう。

aminophen commented 9 years ago

「エンジンパスの自動判定」という概念と，「プリアンブルの詳細設定」という概念をどう分離または結合するのかの仕様を詰めなければなりませんね。

「自動判定の詳細設定」ボタンというのは仮称で、「エンジンサーチの切替」と「プリアンブルの切替」を一括で選択できるほうがよいと思っています。名称は議論の余地がありますね。

doraTeX commented 9 years ago

「自動判定の詳細設定」ボタンというのは仮称で、「エンジンサーチの切替」と「プリアンブルの切替」を一括で選択できるほうがよいと思っています。名称は議論の余地がありますね。

なるほど。 逆に，「自動判定」ボタンを押したときに，毎回その選択肢のダイアログが出るのではまずいでしょうかね？ 「自動判定」はそんなに頻繁に使うボタンではないでしょうから，「自動判定」と「自動判定の詳細設定」のボタンが2つに分かれている意義もあまりない（代わりにUIがごちゃごちゃしてしまう）かなぁと思いました。

doraTeX commented 9 years ago

補足です。

逆に，「自動判定」ボタンを押したときに，毎回その選択肢のダイアログが出るのではまずいでしょうかね？

一方日本語環境での初回起動時はダイアログを出さず pLaTeX 決め打ちで自動判定するという形を想定しています。 （非日本語環境での初回起動時にダイアログを出すべきか否かは要検討ですが……。）

aminophen commented 9 years ago

逆に，「自動判定」ボタンを押したときに，毎回その選択肢のダイアログが出るのではまずいでしょうかね？

TeX Live 2014 から TeX Live 2015 に更新したので、自動判定をやりなおそう → XeLaTeX, LuaLaTeX ってなんだ？ となるのを避けたいというのがありまして、別にしたいなあと思っていました。

（非日本語環境での初回起動時にダイアログを出すべきか否かは要検討ですが……。）

非日本語環境だと pLaTeX がよいのか pdfLaTeX がよいのか悩んでしまうので、ダイアログを出したほうが無難だと思うのですが、いかがでしょう。

doraTeX commented 9 years ago

では，ごちゃっとしないUI例を考えてみました。こんな感じでいかがでしょう。

2015-08-27 12 33 25
aminophen commented 9 years ago

そのくらいの控えめな感じが良いと思います。

非日本語環境だと pLaTeX がよいのか pdfLaTeX がよいのか悩んでしまうので

そもそも CUI 版は pLaTeX なのを忘れていました。環境によらず pLaTeX をデフォルトにしておいてよいかもしれませんね。

doraTeX commented 9 years ago

CUI版のデフォルトも悩みどころですね。 GUI版に合わせるならば，

という挙動をさせてもいいかもしれません。

一方で，そのような挙動の場合，「言語環境の設定次第で同じスクリプトが動いたり動かなかったりする」という問題が生じます。

aminophen commented 9 years ago

「言語環境の設定次第で同じスクリプトが動いたり動かなかったりする」のは困るので、GUI/CUI ともにデフォルトを pLaTeX に固定し、pdfLaTeX を使いたい場合は詳細…や --compiler で指定するのが安全だと思います。最も需要が高い「数式の画像化」ならエンジン非依存のソースで済むはずなので、さほど心配しなくてよいかもしれません。

doraTeX commented 9 years ago

「できるだけ邪魔にならないUI」と考えてみた結果，次のようなUI案が浮かびました。

2015-08-28 0 29 44

実装の簡略化のため，次のような仕様を検討しています。

現在デフォルトで用意されているプリアンブルテンプレートが上記5つなので，今は上記5つが選択肢になっています。

検討事項

上記仕様はあくまで検討段階であり，まだ中身は実装しておりません。 ご意見をお待ちしております。

aminophen commented 9 years ago

だいたい納得のいく仕様になってきましたね！

さすがに pdfTeX の DVI モードを敢えて使わせる必要はないと思いますので

自動判定時には，テンプレート名のスペースまでの部分を小文字に変更したものをエンジン名と解釈してエンジンパスを検索する。

これはテンプレートファイルの冒頭行の %compiler: に一致させたいです。

XeLaTeX (English) や LuaLaTeX (English) なども用意すべきか？

これはヒラギノを設定しているコードが海外でどの程度受け入れられるかにもよるでしょうが（pLaTeX のようにシンボリックリンクを作るという特殊な作業を強いるとすれば、海外ユーザは好まないでしょう）、pdfLaTeX 用テンプレートはそのまま XeLaTeX / LuaLaTeX に流用できるので、テンプレートファイルをわざわざ用意するのはやりすぎかもしれません。

doraTeX commented 9 years ago

これはテンプレートファイルの冒頭行の %compiler: に一致させたいです。

その手がありました！それで行きましょう。

pdfLaTeX 用テンプレートはそのまま XeLaTeX / LuaLaTeX に流用できるので、テンプレートファイルをわざわざ用意するのはやりすぎかもしれません。

fontspec のおかげでシンボリックリンクなしでいけますからね。 海外ユーザが (Japanese) という表記を見て「日本語を一切使わなくても普通に使える」と読んでくれればよいのですが。

とりあえず，ここまでに挙がった仕様案に基づいて実装を始めてみます。

doraTeX commented 9 years ago

ここにきてちょっとした問題が2点。

(1) プリアンブルテンプレートの LaTeX.tex は，

% compiler: latex
\documentclass[fleqn]{article}
\usepackage{amsmath,amssymb}
\usepackage{graphicx,color}
\pagestyle{empty}

となっていました。compiler: latex です……！

いっそのこと，これも compiler: pdflatex に修正しましょう。

すると，テンプレート名自体も pdfLaTeX に統一しておいた方が分かりやすい気がしますね。

すると，元の

自動判定時には，テンプレート名のスペースまでの部分を小文字に変更したものをエンジン名と解釈してエンジンパスを検索する。（例：XeLaTeX (Japanese) → xelatex）

という仕様でも問題ないということになります。

(2) デフォルトテンプレートの XeLaTeX (Japanese).tex は，なぜか ( の前に半角スペースが2つ入っていました……！これもスペース1つに修正しておきます。

doraTeX commented 9 years ago

↑テンプレート名を色々変更するとなれば，この際，非日本語ユーザでも使えるという意味で (Japanese) とかを外してしまうというのも一手ですが。

doraTeX commented 9 years ago

ひとまずここまでの仕様案を，Ver. 1.9.9 beta 4 で一通り実装しました。

2015-08-28 3 06 39

「自動判定対象エンジン設定機能」現行の仕様

Ver. 1.9.9 beta 4 をお試し頂き，この仕様についてご意見を賜れればと思います。

aminophen commented 9 years ago

compiler: latex です……！ いっそのこと，これも compiler: pdflatex に修正しましょう。

ほんとですね… compiler が latex だとすると DVI を吐くので、そのあと dvipdfmx を指定してしまうと NG になって都合が悪かったことになりますね。

…と、ここで気づいたのですが

と思いました。

実装していただいた点については、私が確認できた範囲では期待通りになっていると思います。

aminophen commented 9 years ago

dvipdfmx に dvipdf を指定すれば dvips になるので問題ない → じゃあこれも新規にプロファイルの一つに加えてよいのではないか？（PSTricks の画像化に役立ちそう）

よくみると TeX Live に dvipdf は入っていないようですし、TeX2img が付ける -vv オプションを扱えないので、付けるとしたらその点も検討しないといけなくなってしまいますね。

doraTeX commented 9 years ago

現行の「自動判定」機能は，

となっています。

もしも DVIware もあわせて可変にするなら，

という課題が生じます。

TeX Live に dvipdf は入っていないようですし

これは，「自動判定」のサーチパスに TeX2img.app の内部を含めて，dvipdf を TeX2img.app に内包するという手があります。

TeX2img が付ける -vv オプションを扱えないので、

これは内部処理を場合分けすれば何とかなります。

自分としては最も悩ましいのは

  • どのテンプレートに対して何という名称の DVIware を検索するのかをどのように判定するのか

この問題ですね……。

doraTeX commented 9 years ago

↑一案としては，

という感じでしょうか。

aminophen commented 9 years ago

よくみると TeX Live に dvipdf は入っていないようですし

おっと、手元で which すると最初に MacPorts の /opt/local/bin/dvipdf が見つかりますが、それ以外に /usr/local/bin/dvipdf もありました。どちらもいつ入れたか記憶にないのですが、/usr/local/bin のほうは MacTeX なのでしょうか… ただ /usr/local/texlive/2015/bin/x86_64-darwin には入ってないのでよくわかりません。（あまりディストリビューションに詳しくないもので…）

ただ、海外では dvipdfmx より dvipdf のほうが知名度が高いのはどうやら確かなようです。いろいろな統合環境を見ると、dvipdfmx でなくインタフェースに dvipdf と書いている例が散見されますので、サポートしておくのがよいかもしれないです。

  • プリアンブルテンプレート名を LaTeX (for PSTricks) などとする。

という案はいいかもしれませんね。LaTeX (for PSTricks) と pLaTeX (for PSTricks) と upLaTeX (for PSTricks) が増えることになるのでしょうか。

doraTeX commented 9 years ago

という案はいいかもしれませんね。LaTeX (for PSTricks) と pLaTeX (for PSTricks) と upLaTeX (for PSTricks) が増えることになるのでしょうか。

そうすると，(for PSTricks) でない方の pLaTeX は何なのかが不明瞭な気もしてきます。 いっそのこと，

などとした方が統一的な気もします。（一方で初心者には分かりにくさが増すかもしれませんが。）

aminophen commented 9 years ago

（一方で初心者には分かりにくさが増すかもしれませんが。）

並べてみると、ちょっとうるさいですね… 海外の人が dvipdf しか知らないことが想定される一方で、日本人は dvipdfmx しか知らない場合が多そうですし、混乱しますね。悩ましいです。

ただ、海外では dvipdfmx より dvipdf のほうが知名度が高いのはどうやら確かなようです。

latexmk も初期値が dvipdf になっているようです。ということは、もしかすると幅広く TeX ディストリビューションに入っているのかもしれません。ただ、先ほど dvipdf の存在に気づいたばかりで実用経験が全くないので

を先に調べたほうがいいようです。

doraTeX commented 9 years ago

おっと、手元で which すると最初に MacPorts の /opt/local/bin/dvipdf が見つかりますが、それ以外に /usr/local/bin/dvipdf もありました。どちらもいつ入れたか記憶にないのですが、/usr/local/bin のほうは MacTeX なのでしょうか… ただ /usr/local/texlive/2015/bin/x86_64-darwin には入ってないのでよくわかりません。（あまりディストリビューションに詳しくないもので…）

これは MacTeX の仕業ですね。MacTeX は TeX Live + Ghostscript という構成になっていて，それぞれのインストールディレクトリは別個です。 TeX Live の方は主に /usr/local/texlive 以下に配置しますが，Ghostscript は /usr/local/bin に様々な実行ファイルをばらまき，他の実行ファイルとの分離が困難になっています。 /usr/local/bin に次のファイルが存在するとすれば，それは MacTeX 付属の Ghostscript のインストーラの仕業です。

やはり Mac 用の行儀の良いインストーラの作成は急務ですね……。TeX2img の方が落ち着いたらそちらに手を付けたいものです。

aminophen commented 9 years ago

/usr/local/bin に次のファイルが存在するとすれば，それは MacTeX 付属の Ghostscript のインストーラの仕業です。

ビンゴですね… MacTeX の Ghostscript インストーラの仕業でしたか。ということは、Ghostscript 本体に dvipdf というスクリプトが入っているとみてよいことになりますかね。（TeX2img.app に同梱するまでもない？）

やはり Mac 用の行儀の良いインストーラの作成は急務ですね……。

よろしくお願いします m( )m

doraTeX commented 9 years ago
  • dvipdf がどのくらいのディストリに入っているか

つまり，dvipdfmx は TeX Live の標準同梱物であるのに対して，Ghostscript および gs 依存の dvipdf や ps2pdf などは Ghostscript の同梱物ということですね。

では Ghostscirpt が付いてくるのに対して，

となっています。

aminophen commented 9 years ago

ありがとうございます。TeX2img の動作条件が「TeX ディストリと Ghostscript のインストール」なのであることを考慮すると、dvipdf が後者に含まれているということは同梱は不要でしょうね。ちなみに「W32TeX では Ghostscirpt が付いてくる」ではなく、W32TeX 本体とは別に角藤さんのサイトからダウンロードする必要がある（例外的にあべのりインストーラは勝手にとってきてくれる）わけです。

となると、dvipdf の挙動をもう少し詳しく調べなければならないですね。

doraTeX commented 9 years ago

ちなみに「W32TeX では Ghostscirpt が付いてくる」ではなく、W32TeX 本体とは別に角藤さんのサイトからダウンロードする必要がある（例外的にあべのりインストーラは勝手にとってきてくれる）わけです。

そうでしたか。Windows はあまり知らないものでして，ご指摘ありがとうございます。

dvipdf の仕様（オプションや変換経路の詳細）

中身を見ると，単に dvips して gs で ps2pdf と同様にPDF化するスクリプトですね。

（一方で初心者には分かりにくさが増すかもしれませんが。）

並べてみると、ちょっとうるさいですね… 海外の人が dvipdf しか知らないことが想定される一方で、日本人は dvipdfmx しか知らない場合が多そうですし、混乱しますね。悩ましいです。

一方で，元の LaTeX (for PSTricks) の案であれば，プリアンブルにはじめから PSTricks を \usepackage しておくということが自然であるのに対して，LaTeX + dvipdf の案では，PSTricks がはじめから \usepackage されているのが不自然な気もします。

すると，

となってきます。ますますうるささが増してしまいました……。

aminophen commented 9 years ago

ますますうるささが増してしまいました……。

別案として

と「use PSTricks」というチェックボックスを併設し、ON にすると PSTricks パッケージを含んだテンプレートと dvipdf がサーチされるようにすることにするのはいかがでしょう？

doraTeX commented 9 years ago

pdfLaTeX は

だったような。（あまり知りませんが……）

「PSTricks のフル機能は使えない」のは，gs を通さない経路を通る XeLaTeX や LuaLaTeX でも同様で，PSTricks を満足に使いたいなら gs 経由が必須となったはずです。

aminophen commented 9 years ago

PSTricks は私はほとんど使ったことないです… では、改めて

と「use PSTricks」というチェックボックスが一覧に表示され、用意するテンプレートは

という案はどうでしょう？

doraTeX commented 9 years ago

☑️ use PSTricks は全体にまとめて1つ設置するのでしょうか，それとも

のように1つ1つに表示される感じでしょうか？

doraTeX commented 9 years ago

（あと，dvipdf による PSTricks サポートも加えるとなると，CUI版の --dvipdfmx というオプションも --dviware などと改称すべきということになりますね。）

doraTeX commented 9 years ago

また，実装の手間という観点からは，

  1. 「自動判定の対象」の選択肢に表示されるエンジン名称
  2. ロードされるプリアンブルテンプレートのファイル名
  3. パスをサーチする実行ファイルの名称

の間に，実装に便利な明確な規則性があるとありがたいです。

aminophen commented 9 years ago

☑️ use PSTricks は全体にまとめて1つ設置するのでしょうか

全体にまとめて1つのつもりでした。「XeLaTeX / LuaLaTeX で PSTricks にチェックが入った場合」は、これらの場合に PSTricks をフル活用できないというのであれば単にチェックを無視すればよいと思っていました。（ただ、XeLaTeX に限ってはどうやら Overleaf の PSTricks サポートとして公式に採用されていそうな気配なので、XeLaTeX 用 PSTricks テンプレートは用意してよいかも）

（あと，dvipdf による PSTricks サポートも加えるとなると，CUI版の --dvipdfmx というオプションも --dviware などと改称すべきということになりますね。）

これは既に Windows 版が歴史的経緯で --platex=pdflatex のようなオプション指定を維持しているので、敢えて変えなくてもよいと思います。

もっと問題なのは GUI/CUI ともに「dvipdfmx には -vv オプションを与え、dvipdf には…」という場合分けだと思います。せっかく今まで徹底的に毒抜きしてきたので、今後もこの方向を維持するとすれば

などの対応が必要になりそうです。ただ、-vv オプションだけのためにそこまでするかという印象のほうが強いので、むしろ「標準で -vv なし」「dvipdfmx のログを詳細に（デバッグ用）」のほうがいいかもしれません。

doraTeX commented 9 years ago

もっと問題なのは GUI/CUI ともに「dvipdfmx には -vv オプションを与え、dvipdf には…」という場合分けだと思います。

私はそれは特に問題とは感じておりません。単に dvi→pdf の変換時に，変換ツールの名称に応じてオプションを変えるだけですので，コード上は数行で済みます。 今までは DVIware は dvipdfmx 固定だったところが，dvipdfmx / dvipdf の2つに対応するのであれば，むしろ DVIware 依存性が1つ減少する「毒抜き」の方向であるとも言えます。

むしろ私が気にしているのは上記の「規則性」です。 「この選択肢が選ばれた場合は，このテンプレートをロードして，コンパイラはこれ，DVIwareはあれをサーチして……」というのでは，コーディングがまさに「毒だらけ」で大変ですし，そのようなルールが今後も延々と増えてゆくとなると，管理が難しくなります。

doraTeX commented 9 years ago

CUI版については，これまでは DVIware が dvipdfmx 固定であったので，事実上 --dvipdfmx=dvipdfmx というオプションを使うことは無意味でした。ですから，歴史的しがらみもほとんどありませんので，これを機に --dviware=dvipdfmx / --dviware=dvipdf のように改称する方が，将来性を考えるとよいと思います。

doraTeX commented 9 years ago

「XeLaTeX / LuaLaTeX で PSTricks にチェックが入った場合」は、これらの場合に PSTricks をフル活用できないというのであれば単にチェックを無視すればよい

UIの観点からは，無視される選択肢なのであればグレーアウトするなどしてユーザーにインタラクションを返すべきでしょうね。するとますます「規則性」が難しくなってきます……。

aminophen commented 9 years ago

歴史的しがらみもほとんどありませんので，

確かにそれもそうですね。影響がほとんど無さそうなので、この機会に変えてしまうのもありかも。

単に dvi→pdf の変換時に，変換ツールの名称に応じてオプションを変えるだけですので，コード上は数行で済みます。

ああ、『毒抜き』というのは DVIware 依存性の解消ということではなく、「エンジンや変換ツールの設定状態に応じて実行コマンドが変わる」という挙動の解消の意味でした。platex なら --kanji が使えるけど pdflatex なら --kanji が使えないのでどうしようかという話になったとき、文字コードを「指定しない」の新設で --kanji なしをデフォルトにしたという一連の流れを思い出していました。「UI の設定状態によって（プログラム名に関わらず）実行コマンドが一意に定まる」のが私の言う毒抜きです。

「この選択肢が選ばれた場合は，このテンプレートをロードして，コンパイラはこれ，DVIwareはあれをロードして……」というのでは，コーディングがまさに「毒だらけ」で大変ですし

確かにそれも大きな問題です。先ほどの私の案

でいくとあとあと大変ですかね…

doraTeX commented 9 years ago

「UI の設定状態によって（プログラム名に関わらず）実行コマンドが一意に定まる」のが私の言う毒抜きです。

LaTeX エンジンは同系統のファミリーですが，dvipdfmx と dvipdf では書式の全く異なる別々の DVIware ですので，DVIware がこれまでの dvipdfmx 固定ではなく，異なる2つの DVIware をサポートしようと思えば，それによる場合分けが生じるのは必然だと思いますし，それが特に問題であるとは思いません。

  • プロファイル一覧
    • 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上の選択状態 → ロードされるテンプレートのファイル名」の対応関係は全部ベタ指定ということになりますでしょうか？

aminophen commented 9 years ago

LaTeX エンジンは同系統のファミリーですが，dvipdfmx と dvipdf では書式の全く異なる別々の DVIware ですので，DVIware がこれまでの dvipdfmx 固定ではなく，異なる2つの DVIware をサポートしようと思えば，それによる場合分けが生じるのは必然だと思いますし

それはそうかもしれないのですが、たとえば「ユーザが dvipdfmx というシェルスクリプトを作って dvips + ps2pdf を実装していた場合」に困るなあと思っています（かつて --dvipdfmx オプションがなかった頃を考えると、十分こんなシェルスクリプトを作っていたことは考えられますので）。

この場合，「UI上の選択状態 → ロードされるテンプレートのファイル名」の対応関係は全部ベタ指定ということになりますでしょうか？

そうなってしまいますね。もう少し管理しやすく、かつうるさくない案があればよいのですが。

aminophen commented 9 years ago

かつての「毒を食らわば皿まで」はここですね。いくら「LaTeX エンジンは同系統のファミリー」とはいっても、いろいろな LaTeX エンジンをサポートするにあたって読み込むテンプレートが問題となり、「エンジンのパスを文字列解析して変化させる」というのを一旦は実装していただきましたが、のちに完全に逆の挙動に変えた経緯がありますね。このときの結果が現在の TeX2img 1.9.9 beta 4 までは維持されていて、それを今回の dviware 問題で再び毒を注入してしまうのは嫌だなあという気分です。

追記：あとで「徹底的な毒抜き」に方針転換したのはここですね。

doraTeX commented 9 years ago

たとえば「ユーザが dvipdfmx というシェルスクリプトを作って dvips + ps2pdf を実装していた場合

この場合であっても，TeX2img は強制的に dvipdfmx に対して -vv オプションを発行していたわけですから，従来は「-vv を受け付けるかスルーするという仕様を持つ DVIware であること」を要求していたわけですよね。 「DVIware 名が dvipdfmx である場合に限って -vv を発行する」という挙動にすれば，より多くの DVIware を受け付けることができます。

いろいろな LaTeX エンジンをサポートするにあたって読み込むテンプレートが問題となり、「エンジンのパスを文字列解析して変化させる」というのを一旦は実装していただきましたが、のちに完全に逆の挙動に変えた経緯がありますね。

これは，あるUIの設定状態が別のUIの挙動に影響を与えるという点で，確かにUIとして不自然でした。 しかし，今回はユーザには見せない内部処理の話であるので，同列の問題ではないと思います。 実際，現在でも，LaTeX エンジンに pdfLaTeX を指定している場合と pLaTeX を指定している場合では，「コンパイル後に DVIware を呼ぶか否か」というユーザーに見せない内部処理が異なっています。

それを今回の dviware 問題で再び毒を注入してしまうのは嫌だなあという気分です。

代案としては，自動判定のサーチ対象 DVIware が dvipdfmx である場合には，見つかった dvipdfmx のパスに対して -vv を付けて，設定画面のパス欄に

dvipdfmx: /path/to/dvipdfmx -vv

を入力するという手もあります。こうすれば，UIの状態から DVIware の発行コマンドが明示的に確定すると言えるでしょう。 ただ，この挙動が自然かどうかは自信がありません。

aminophen commented 9 years ago

DVIware 名が dvipdfmx である場合に限って

その場合は文字列解析をしていることになりますよね。私は「パスの文字列解析で挙動を変える」が不自然だと思っていて、文字列がたとえ何であってもその他の UI から一意に内部コマンドが定まってほしいという希望があります。書かれているプログラム名（＋TeX2img が付加するオプション）を素直にそのまま実行してほしいというところです。

実際，現在でも，LaTeX エンジンに pdfLaTeX を指定している場合と pLaTeX を指定している場合では，「コンパイル後に DVIware を呼ぶか否か」というユーザーに見せない内部処理が異なっています。

これはあくまで「エンジンが PDF を出したか DVI を出したかをタイムスタンプから判断し、DVI なら dvipdfmx に指定されたプログラムを起動」というだけなので、パスの文字列解析は含んでいません。

doraTeX commented 9 years ago

これはあくまで「エンジンが PDF を出したか DVI を出したかをタイムスタンプから判断し、DVI なら dvipdfmx に指定されたプログラムを起動」というだけなので、パスの文字列解析は含んでいません。

それは内部的な実装の方法であって，ユーザーサイドから見れば同じなのではないでしょうか？ 「パスの文字列解析を含まなければよい」というのであれば，例えば， 「dviware をまず --help 付きで実行してみて，そのヘルプメッセージに -vv という文字列が含まれていれば -vv 付きで実行する」という挙動にするという手も考えられますが。

aminophen commented 9 years ago

そこまではやりすぎかもしれませんね…

「DVIware 名が dvipdfmx である場合に限って -vv を発行する」という挙動にすれば

これがいちばんよいかもしれません。