- 追加された行はこの色です。
- 削除された行はこの色です。
// 以下，独断と偏見で“画像関連のこと（というより，“TeX”と“TeX 以外のもの”
// との関係）について初心者（というより，“いまどきの”ユーザ）が
// ふまえておくべき点”を書き連ねてみます．
// 至らない点については，積極的に書き換えてください．
私の存在自体がお気に召さない人間が存在するようですので，
私が（大半を）作成した項目については撤去します（しっぽ愛好家）．
* この項を用意した動機 [#e469c9a6]
最近，各種の統合環境や dviware から“ボタン一発”で
PDF 化できるように設定してあることが増えるにつれ，
“プレビュー時には表示されているにもかかわらず，PDF 化したら表示されない”
の類のトラブル（結局，ユーザ自身が“自分が何をしているのか”を把握していない，
ということが真の原因なのですが）を見かけることが多くなりました．
そこで，ここでは“TeX と TeX 以外のものとの関係”について初心者の
（というより，“いまどきの”）TeX ユーザがふまえておくべき点を
（独断と偏見で）挙げてみます．
以下の記述は“目の前にある問題の解決”には決して役には立ちませんが，
“TeX 以外のものに関する問題に直面したときに落ち着いて対処する余裕”
を身につける手助けにはなるでしょう．
* TeX を用いた文書作成の概要と心構え [#w4e0707a]
TeX を用いた文書作成では，基本的には次の手順を用います．
- 適当なテキストエディタで TeX 文書（ソースファイル）を作成
- ソースファイルを TeX そのもので処理して，dvi ファイルを作成
// なお，pdfTeX を用いた場合，直接 PDF ファイルを作成することもできますが，
// pdfTeX は（まだ）日本語化されていないので，以下の記述では pdfTeX は無視します．
- 必要があれば，索引・参考文献等を mendex や BibTeX/jBibTeX といった
（TeX とは別の，索引・参考文献リストの作成のための）
ソフトウェアで生成させたのち，ソースファイルを TeX そのもので処理します．
// mendex/makeindex は索引の作成以外にも利用できる
// “項目の階層構造”をサポートした汎用ソーティング・ツールですが，
// そのような用途にはここでは言及しません．
- dvi ファイルを適当なソフトウェアで閲覧・加工します．
ここで，TeX 自身は“ソースファイルを処理して dvi ファイルを作成する”
という作業しか行いません．
それ以外の，“dvi ファイルの画面表示”，
“dvi ファイルのほかの形式（PostScript/PDF など）への変換”といった処理は，
''TeX とはまったく別の''ソフトウェアで行います．
入門書においては，（不慣れな読者に負担をかけたくないという理由からだとは思いますが）
“TeX 自身”と各種の“TeX 関連ソフトウェア”をあまり区別せずに“TeX（システム）”
としてひとくくりにしていることもしばしばあります．
しかし，TeX 自身と個々の TeX 関連ソフトウェアの区別，
あるいは，TeX 関連ソフトウェアどうしの区別，は''厳格に''行うように心がけてください．
上記の一連の作業で用いる個々のソフトウェアの区別をきちんとつければ，
“いつもと違う”ことをする場合にどのソフトウェアを取り換えて処理すればよいかの見当がつくでしょう．
また，“トラブルの際には‘どのソフトウェアの’問題であるかを把握する必要がある”
という（TeX 関係のコミュニティでしばしば指摘される）ことの理由も自ずと明らかになるでしょう．
もし，ユーザ自身が WinShell 等の“統合環境”しか用いたことがないのでしたら，
“コマンドプロンプト”の類からコマンドを直接入力して処理する方法も
（常用するかどうかは別としても）心得ておいてください．
実際，トラブルシューティングの際には，“問題の所在”を明確にするために，
個々のソフトウェアをなるべく単独で使用することになります．
また，個々のコマンドを直接実行してみれば，
TeX 自身とそれ以外のソフトウェアを用いていることを明確に認識できるでしょう．
また，統合環境や各種ソフトウェアの“便利ボタン”を用いるときには，
“個々の処理の際にどのソフトウェアを呼び出しているか”
（これは，通常，各種オプション設定のところで確認・変更できます）
を必要があれば（少なくとも，最初に用いるときには必ず）確認することになります．
* TeX 自身で処理することと TeX 自身では扱わないこと [#sf617d5c]
最近のワープロソフトに慣れた方には奇異に思えるかもしれませんが，
“画像の取り込み”，“色の設定”といったことは ''TeX 自身の機能ではありません''．
（実際に出力される文書の体裁に関して）TeX 自身でできることは，極端に言えば
“文字と罫線（水平または垂直なもののみ）を並べる”ことだけです
（もちろん，それに必要な行分割処理などの内部処理は当然行います）．
// “組版処理に特化したプログラミング言語の処理系”である，という
// TeX のもうひとつの重要な側面にはここでは触れません．
では，“画像の取り込み”という処理はどのようにして実現されているか，
というと，“取り込むべき画像ファイルのファイル名や取り込み方（拡大率など）
に関する指示”を dvi ファイルの中に書き込み
（TeX 自身では dvi ファイルには画像そのものは入れません），
それを dvi ファイルを処理する個々のソフトウェア（以下，dviware と総称します）
に解釈させる，という方法を用います．
“色”の処理や PDF の“しおり”（bookmark）の処理に関しても同様です．
// こういうことは“初心者”自身から見ればどうでもいいことでしょうが，
// こういうことをふまえていないがゆえに“graphicx パッケージに複数の
// ドライバ指定を *同時に* 与える”ような（ときとして致命的な）ミスが生じるのです．
// したがって，一度はきちんと教える必要があります．
組版処理自身（TeX そのものの処理）と dviware が担当する処理が“分業”されている
（実際，TeX 自身は，画像に関しては
“画像用のスペースを空けておきあとで貼り込んでもらう”
という古式ゆかしい方法でしか処理していないわけです）
というのには，確かに面倒な面があります．
しかし，これは，プラットフォームに応じた dviware
あるいは個々のユニークな機能をもった dviware を適宜選択して用いることができる，
ということへの代償とみなすのが妥当でしょう．
また，その面倒さを軽減するために“統合環境”が用意されたわけです．
* 画像の取り扱いと graphicx パッケージ [#c2559a37]
前項で述べたように，画像の取り込みという処理は TeX 自身の機能ではなく，
“dvi ファイルの中に書き込まれた画像の取り扱いに関する指示”
を個々の dviware が解釈する，という仕組みになっています．
ここで，次のことに注意が必要です．
- dviware によって，“理解できる指示”の形式は異なる
- dviware によって，“サポートする画像形式”の種類は異なる
まず，前者（dviware によって，“理解できる指示”の形式は異なる）についてですが，
dviware によって“理解できる指示”の形式が異なるのは
（指示を解釈するのが個々の dviware である以上）当然のことで，
TeX 自身は“各々の dviware ''専用''の指示”を
dvi ファイルに書き込まなければならないわけです．
もっとも，画像の取り込みや色に関してはよその dviware に対する指示を理解する
dviware もかなりありますが，その場合でも“完全互換”であることを期待はできません．
一方，ユーザ側から見れば，
\includegrahics[<options>]{<filename>}
という形式で画像を取り込めるわけで，dviware 専用の記述は見当たりませんが，
// （LaTeX 2.09 時代には \special を直接書き込むようなマネもなされていましたが…
// いまどきそのような方法に言及することもないでしょう）
実際には，graphicx パッケージ（の内部で読み込まれる graphics パッケージ）
へのオプション指定によって，dviware を指定することに注意してください．
例えば，
\usepackage[dvips]{graphicx}
という指定で graphicx パッケージを読みこんだ場合には，
オプション指定 dvips に応じて dvips.def というファイルも読み込まれ，
この def ファイルの中に“dvips に対する指示の仕方”が載っているのです．
ほかの dviware を指定した場合も同様で，
\usepackage[dvipdfm]{graphicx}
ならば“dvipdfm への指示の仕方”をファイル dvipdfm.def から取得するわけです．
このような仕組みになっているため，graphicx パッケージ（に限らず，
dviware の機能に頼った処理へのインタフェイスを提供するパッケージ）への
“ドライバ指定”（＝“dviware 指定”）
オプションは一度には''ただひとつ''しか指定できないことがわかるでしょう
（実際，“複数の dviware に共通に理解されるような指示法”が存在するとは限りません）．
// なお，graphicx パッケージなどの場合は，複数のドライバ指定オプションを
// 設定しても最後に設定したものが有効になり，def ファイルはただひとつしか
// 読み込まれませんが… これは各パッケージの実装に関する細かい点にすぎません．
もし，何らかの理由で複数の dviware を使い分ける場合は，
“dviware A で処理するための dvi ファイルを，
dviware A 用のドライバ指定を行った状態でタイプセットして作成する”
一方，“dviware B で処理するための dvi ファイルを，
dviware B 用のドライバ指定を行った状態でタイプセットして作成する”
という具合にいちいちドライバ指定を切り換えなければなりません．
// これは面倒ですが，“ドライバ指定を切り換えなくても済むようにしろ”
// という注文は“W○RD だろうと○太郎だろうと，あるいは，
// 今後現れるかもしれないいかなるワープロソフトであろうと
// 編集できるような共通フォーマットを用意しろ”という注文に似ています．
後者（dviware によって，“サポートする画像形式”の種類は異なる）のほうも，
このこと自体は言うまでもないことでしょうけれども，
ユーザ自身が“自分で何をしているのか”を把握していない場合には問題となります．
例えば，ある dviware（≠ dvipdfm，dvipdfmx）が
“裏で dvipdfmx を呼び出して PDF 化する”という処理を用意していたとしましょう．
このとき，その dviware 自身がサポートする形式の画像を取り込んだ場合には，
その dviware での処理は問題なく実行できます．
しかし，取り込まれている画像の形式が dvipdfmx
ではサポートしないものであった場合には，
dvipdfmx での PDF 化の際にユーザの意図しない結果が生じるわけです．
もちろん，このようなことは各 dviware の責任ではなく，
単に，
- ユーザ自身が“自分が何をしているのか”（実際には何を使っているのか）を把握し
- 実際に使われている dviware がサポートしている形式の画像のみを用いるように画像ファイルのほうを変換する
ようにすれば済みます．
もちろん，各種“便利ボタン”に関連付けられているソフトウェアのほうを，
使いたい形式の画像をサポートするものに変更してもよいわけです．
* 特殊なパッケージ [#yba4e5eb]
しばしば見かける“初心者向けの”書籍では各種のパッケージをあれこれと紹介していることもあり，
ユーザの技術レベルに関係なく様々な処理を利用している場面をよく目にします．
そのこと自体には問題はないのですが，
''各種のパッケージのすべてが TeX の機能だけで済ませているとは限らない''ことに注意が必要です．
例えば，psfrag パッケージや pstricks パッケージは
PostScript コードを直接用いてそれらのパッケージが提供する機能を実現しています．
実際，psfrag.pro あるいは pstricks.pro などの dvips 用の各種ヘッダファイルに
必要な PostScript コードが記述されています．
したがって，psfrag パッケージや pstricks パッケージを用いる際には，
それらのヘッダファイル（および psfrag や pstricks によって与えられる
special 命令）をパッケージの意図通りに使用できる dviware を用いる必要があるわけです．
>実際，ここで例示した 2 個のパッケージは，基本的には dvips(k) で
PostScript 化した後，その PostScript ファイルを更に加工することを念頭に置いています．
したがって，例えば psfrag パッケージを用いた文書の PDF 化には
dvipdfm(x) は（少なくとも，何も細工・設定をしない状態では）使えないわけです．
ほかのパッケージに関しても同様で，
少なくともそれぞれのパッケージのマニュアルを通読し，パッケージが前提とする条件
（例えば，dvi ファイルを dvips(k) で PostScript 化するといった条件）
について確認する必要があります．
その際，先にも述べた
>TeX 自身でできることは，極端に言えば
“文字と罫線（水平または垂直なもののみ）を並べる”ことだけ
<という点を心得ておけば“TeX 自身の機能以外のものを用いているか否か”の見当がつけやすくなることでしょう．
>例えば，psfrag パッケージが提供する
“図中のラベル文字列を，文書側で指定した文字列で置き換える”
という処理は，(La)TeX 側では画像ファイルの中身には関知しない以上，
dviware（あるいはその先の処理を担当するソフトウェア）
の機能に頼っているのではないかと見当がつくわけです．
