名前: . 日時: 2007-08-21 17:16:12 IPアドレス: 59.134.169.*
>>49166 いまどきの TeX 関係の統合環境による連携についてたとえ話をするなら， どこぞのファーストフード店のセットメニューは確かに手軽で割安かもしれない． しかし，ときとして要らない品までついていたり，自分の好みの組み合わせでは なかったりする． あたりでしょうか． # さらに“統合環境は裏で何をやっているのだかわかったものではない”に対応する # 記述を入れるとすれば，“あと，原材料や調理過程を疑い出せばきりがない” # くらいになるのかもしれませんが，こんな言い方は実在するファーストフード店の # ほうに気の毒です． 実際，“決まりきったソフトウェアを決まりきった設定でしか使わない”のなら， 統合環境に（デフォルトで，あるいはユーザ自身の手で明示的に）仕込んである 設定で間に合うのでしょうし，それで便利なのかもしれません． しかし， ・source specials は，ソースファイルの形で他者に渡す文書の最終版の作成時には 用いてはならない（つまり，日常的に source specials を使うユーザは， source specials を用いない設定でもタイプセットできるように しておかねばならない） ・PDF 化の作業ひとつとっても，dvipdfmx で間に合うときもあれば， PostScript に依存するパッケージを用いているために dvips + distiller (or ps2pdf) でなければならないという場合もある，という具合に 作業経路は複数ある といった状況を少し考えればわかるように，(La)TeX を多少使い込んでいけば， いずれ 使用するソフトウェアやそれに対するオプション指定をとっかえひっかえする という状態に到り得ます． # そうならないユーザもいるでしょうが， # それはそれで“お幸せ”というだけのことです． この状態に到ると，むしろコマンドラインからの操作が便利となるでしょう （もっとも，エディタマクロによっては，呼び出すコマンドの引数を呼び出し時に 変更できるようなものもあるようですが）． # まあ，私の場合は仕事ごとにタイプセット等の処理用のバッチファイルを # 用意していて，これはこれで昔ながらの連携策ではあります（が，連携する # 個々のソフトウェアをユーザ自身が明確に認識している分だけ，統合環境に # 頼り切るよりはマシです）． それと，“各種の統合環境は便利であることもあり，また，開発者と呼ばれる 方々が努力なさっている”という点に異論を述べるつもりはまったくありませんが， 各種の統合環境の普及に伴い “自分が何をしているのか”すら認識できていないユーザが増加している 点は看過できません． # 例えば，dvipdfmx が bmp 形式の画像に対応する前に， # bmp 画像を取り込んだ文書は dviout ではプレビューできるが， # “ニコニコマーク”のボタンを押して PDF 化したら bmp 画像が # 意図通りに取り扱われていない # などという質問をしばしば見かけましたが，これなどは， # “‘統合’することによって，実際に行われていることが‘隠蔽’されている” # ことがもたらすネガティブな影響を表す典型的な例です． 特に，TeX 関係の各種ソフトウェアの連携は， 互いに完全に独立した複数のソフトウェアを組み合わせている というだけで，個々のソフトウェアは（例外はあるものの，原則として） “連携させることを前提としたつくり”にはなっていないわけで―― とまで言うのは言いすぎだと思うのでしたら，“連携させる TeX 関連 ソフトウェアの各々は，‘ひとつのパッケージソフトの個々のコンポーネント’ のような存在などではない”くらいに言い直しても構いませんが―― どのソフトウェアをどのように連携させているのかをユーザ自身に 明確に認識させておかないと，つまらないトラブルが生じる ことになるわけです． # pstricks パッケージを使用した LaTeX 文書の PDF 化の際に， # “dvipdfmx を呼び出すボタン”を押して途方に暮れるユーザ…… # なんていくらでも存在しそうではありませんか．
この書き込みへの返事：