> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/ja/xiang-xi-ji-shi/06-an-introduction-to-kpathsea-and-how-tex-engines-search-for-files.md). # Kpathsea入門とTeXエンジンによるファイル検索の仕組み ## はじめに この記事では、TeX エンジンが LaTeX やその他のマクロパッケージを使って文書を組版するために必要なファイルをどのように見つけるかを紹介します。Overleaf は TeX のインストールを管理する難しさからユーザーを解放してくれますが（[TeX Live](https://www.tug.org/texlive/)）、TeX エンジンがファイルを検索する仕組みの基本は、Overleaf プロジェクトの管理に役立つ／興味深いものです。フォルダ構成を作ってプロジェクトを整理したい場合はなおさらです。 なぜそうなるのでしょうか？ Overleaf プロジェクトの一部のファイルをフォルダ内に保存すると、LaTeX がそれらのファイルを見つけられないことがあります。というのも、デフォルトでは TeX エンジン（コンパイラ）が *認識していない* そのフォルダも検索する必要があることを知らないからです。—そのため、そこに含まれるファイルを見つけられません。これを避けるには、プロジェクトに次の構成ファイルを作成して追加できます。 [latexmkrc ファイル](https://mg.readthedocs.io/latexmk.html#configuration-files) これは、あなたのフォルダが存在し、それらを検索すべきだと TeX エンジンに伝えるために使えます。 latexmkrc ファイルの例をすぐに見たい場合は、こちらのヘルプ記事を読んでください: [Overleaf で latexmkrc を使う方法: 例とテクニック](/latex/ja/xiang-xi-ji-shi/28-how-to-use-latexmkrc-with-overleaf.md)。その latexmkrc ファイルが実際にどう、あるいはなぜ機能するのかは、すぐには明らかでないかもしれません。理由を知りたい、そしておそらく、プロジェクトでさらに多くの設定の可能性を活用するための理解を深めたいなら、このまま読み進めてください…この記事の最後では、 [実践的な例](#kpathsea-and-texinputs-latexmkrc-file-to-the-rescue)—TeX がファイルをどのように検索するかという知識を使って—グラフィックスファイルを含む入れ子のフォルダを管理する latexmkrc ファイルを作成します。 ## TeX とプラットフォーム非依存性 Knuth が TeX を作ったとき、プラットフォーム非依存性はその設計と実装を導く中心原理でした。その考え方は TeX の内部動作全体に反映されています（たとえば、整数演算、独自実装の文字列処理、メモリ管理など）。今日においても、現代の TeX ベースのエンジンのプラットフォーム非依存性は、公開フォーラムでなお疑問や議論を呼んでいます。たとえば、tex.stackexchange のこの議論を見てください: [XeTeX と LuaTeX はプラットフォーム依存ですか？](https://tex.stackexchange.com/questions/94297/are-xetex-and-luatex-platform-dependent) そこには、著名な TeX 専門家たちによるコメントや見解が含まれています。 ただし、いまは細かな点はいったん脇に置き、TeX エンジンは依然として高い移植性を備えている必要がある、つまり複数のオペレーティングシステム上で動作し、“同一の”結果を出せる必要がある、という点だけ押さえておきましょう。移植性の重要な側面のひとつが、プラットフォームに依存しない方法でファイルを検索することです。 ## TeX エンジンはファイルを検索しない…本当に!? いいえ、TeX エンジンは *直接* ファイルを検索 *自力では*。ある `.tex` ファイルを処理していると、TeX エンジンは特定のファイルを開く必要があると判断することがありますが、 *それを委ね* 見つける作業を、次の別のソフトウェアに任せます [*Kpathsea*](https://tug.org/kpathsea/): つまり、次の一部ではない外部ソフトウェアライブラリです *コア* TeX エンジンのソースコードです。Kpathsea が提供するのは、実質的には API（[アプリケーション・プログラミング・インターフェース](https://en.wikipedia.org/wiki/Application_programming_interface)）であり、TeX エンジン（加えて BibTeX、MetaPost、その他のアプリケーション）が特定のファイルを開く必要があるたびに呼び出せます。実際にそのファイルを見つける作業を行うのは Kpathsea です。 Knuth が最初の TeX エンジン—そこから他のすべての TeX エンジンが、最終的には派生しています—を書いた当時、ファイルを見つけ／開く問題は、その時代の非常に異質な技術エコシステムのために特に大きな課題でした。実際、TeX のソースコードで Knuth はファイル入出力を“移植性の最大の障害”と呼んでいます（…の12ページ、25節参照の [TeX: The Program](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373)). TeX コミュニティは、TeX のファイル検索を調和（標準化）する必要があると認識していました—*そして TeX 関連ソフトウェアの*—そして、それを実現するためのツールを TeX に提供することを決めました。プラットフォームに依存しないファイル検索方法という非常に厄介な問題に対処するため、TeX コミュニティの中心的メンバーである Karl Berry が、その問題を解決するソフトウェアを書きました *パス*検索の問題です: 彼がその解決策に付けた名前は [**Kpathsea**](http://tug.org/texinfohtml/kpathsea.html)—これは、次から派生した名前です **K**Karl の **Path** **Sea**rching（こちらを参照 [Karl Berry へのインタビュー](http://www.tug.org/interviews/berry.html)). ここで、それは K と呼ばれていると**パス**sea であって K**ファイル**sea なのは、…が述べているように、 [ドキュメント](http://tug.org/texinfohtml/kpathsea.html) このライブラリは \*パス\* 検索ライブラリだからです。Kpathsea は TeX エンジンだけで使われるわけではない、という点も重要です。BibTeX や MetaPost を含むさまざまな TeX 関連プログラムも、入力ファイルの検索に Kpathsea を使います。 概略すると、TeX/LaTeX のマクロが特定のファイルを開く必要があるとき、それらのマクロを構成しているコマンドは、最終的には TeX エンジンが実際に実行する低レベルの TeX 命令（TeX のプリミティブ）に変換されます。もしその命令にファイルを開く必要が含まれていれば、TeX エンジンは Kpathsea に対して実質的に「このファイルを探してください」と呼び出します。その Kpathsea の検索が成功すれば、ファイルは開かれます。しかし、Kpathsea がそのファイルを見つけられなければ、TeX エンジンにその旨が通知され、あの悪名高いエラーを出して処理を停止します ``! そのファイル `...` が見つかりません`` 実のところ、Kpathsea がそれを見つけられないのです。 ### LuaTeX に関する注記 厳密には、この節には注記が必要です。LuaTeX には、ユーザーが独自のファイル検索コードを提供できる仕組みがあり、それは次を使います *コールバック*。LuaTeX では、Lua スクリプト言語で関数を書いて LuaTeX に登録でき、LuaTeX の実行中の特定の段階でそのユーザー定義関数を呼び出すようにできます—そのため、この用語が使われます *コールバック*。 [LuaTeXリファレンスマニュアル](http://www.pragma-ade.com/general/manuals/luatex.pdf) （執筆時点では、そのリンクは LuaTeX 1.09 用です）。 ### Kpathsea の設定ファイル: texmf.cnf すべての TeX インストールには、次のようなテキストファイルがあります `texmf.cnf` これは Kpathsea が使う設定ファイルで、多数の“設定変数”が含まれています。これらは、TeX エンジン（あるいは BibTeX、MetaPost など）が必要とするさまざまな種類のファイルを検索するために Kpathsea が使うパスを定義します。以下で見るように、これらの“設定変数”は、いわゆる次から構成される検索パスを定義します *パス要素*: さまざまな構成要素、変数、パラメータを使って、各パス要素を Kpathsea が処理して検索対象となる実際の物理的なディレクトリを生成する「テンプレート」として定義します。 具体例をひとつ挙げると、これは OpenType フォントの検索パスを定義する設定変数のひとつです—いまはこのパスの構成の意味は気にしなくてかまいません: ``` OPENTYPEFONTS = .;$TEXMF/fonts/{opentype,truetype}//;$OSFONTDIR// ``` ここで重要なのは、次のファイルが `texmf.cnf` （Kpathsea によって読み込まれる）が、次の名前の設定変数を定義しているということです `OPENTYPEFONTS` これは、Kpathsea が OpenType フォントを検索するために使うパスを定義するのに使われます。「=」の右辺は、一般的な端末で見かけるようなパスには見えません。なぜなら、さまざまな変数やパラメータを使って各パスを「テンプレート」または「設計図」として定義し、Kpathsea が実際に検索するための本物のディレクトリを生成するからです。 ### Kpathsea における「パス」の概念 おそらく、理解すべき中心的な概念は Kpathsea の「パス」という考え方です。これは、Kpathsea が特定のファイルの場所を突き止めるために使う基本構成要素です。先ほどの `OPENTYPEFONTS` 上の例で見たように、Kpathsea のパスの概念は、私たちがデスクトップや携帯端末で慣れ親しんでいるパスとはかなり違って見えます。 Kpathsea の次の記述を引用すると [ドキュメント](http://tug.org/texinfohtml/kpathsea.html#Searching-overview): > … 1つの *検索パス* は、コロンで区切られた次の一覧です *パス要素*, つまり少し“おまけ”が付いたディレクトリ名です。 —ただし、セミコロン（`;`）も区切りに使われます *パス要素*。後ほど、そうした“おまけ”のいくつかの性質を簡単に示します。 私たちの `OPENTYPEFONTS` 例では、3 つのパス要素があり、それぞれセミコロン（`;`): ![Kpathsea のパス定義に含まれるパス要素を示す画像](/files/0d4a24e15d68e27e399d5a04871b80f27a8d9181) 1. `.` （現在のディレクトリを意味します） 2. `$TEXMF/fonts/{opentype,truetype}//` 3. `$OSFONTDIR//` ダブルスラッシュ（`//`）がパス要素にある場合は、サブディレクトリを検索する（再帰的に）ことを意味します。 一般的な `texmf.cnf` ファイルには、Kpathsea が検索できるファイル種類ごとの検索パスを定義する多数の“設定変数”が含まれます。 ## Kpathsea: ごく簡単な概要 Kpathsea は高度なライブラリであり—細かな詳細や нюanced? nuances = 細かな点があります。さらに、その [ドキュメント](http://tug.org/texinfohtml/kpathsea.html) を少し見るだけでも、すべての詳細に踏み込むことはできないと分かります。それでも、何をするのかの概観を示して、考えを整理する助けとなり、さらなる学習の出発点を提供することはできます。 ### Kpathsea の中核的な目的 ドキュメントにあるように、Kpathsea の基本的な目的は「ユーザーが指定したディレクトリの一覧からファイル名を返すこと」であり、そのディレクトリ（検索パス）は「いくつかの余分な飾り」を使って指定されます。 ### その“余分な飾り”とは 上で述べた“いくつかの余分な飾り”には、Kpathsea が検索パス（または“パスのテンプレート”）を構築するために使うさまざまなパラメータや変数が含まれます。これにより、パスをより一般的な方法で定義できます。TeX エンジンが実際に動作しているときは、Kpathea はそれらのパラメータ／変数の現在値を使って、変数を実行時の実際の値に置き換えることで、実際のパスを求めることができます。これらの変数（パス要素内）は、先頭に `$` 記号が付いているので簡単に見分けられます。 したがって、Kpathsea が *展開する* パス要素を、つまりそれらのパラメータや変数を変換して、ファイルを探す実際の 1 つ以上の物理ディレクトリ名にする、という意味です。これは非常に柔軟であり、たとえばサブディレクトリを検索するよう指示された場合には、Kpathsea が 1 つのパス要素に対応するディレクトリ一覧を構築することもできます。 ### OpenType の例をもう一度 さまざまな要素をまとめて、 `OPENTYPEFONTS` もう少し詳しく見ていきます: ``` OPENTYPEFONTS = .;$TEXMF/fonts/{opentype,truetype}//;$OSFONTDIR// ``` 2 つのパス要素を考えてみましょう `$TEXMF/fonts/{opentype,truetype}//` や `$OSFONTDIR//`。ここで Kpathsea は中括弧の使用に気づき `{...}` 、それを `$TEXMF/fonts/{opentype,truetype}` 表しているものとして扱い *2 つの* パス要素: 1. `$TEXMF/fonts/opentype//` 2. `$TEXMF/fonts/truetype//` 、さらに *サブディレクトリ* も検索対象にすべきだと解釈します（末尾の `//`). **注**: Kpathsea のドキュメントの [サブディレクトリ展開](http://tug.org/texinfohtml/kpathsea.html#Subdirectory-expansion) を参照してください。どの階層のサブディレクトリをどの順序で検索するかについて重要な注意点があります（順序は未規定です）。 次の点についていくつか観察します `$TEXMF` 下記を参照してください。 #### $OSFONTDIR// `$OSFONTDIR` は、フォントが保存されている場所を含む環境変数として値を定義すべき変数です。正確な値はもちろん、TeX を実行しているオペレーティングシステムによって異なります。ここでは、末尾の `//` は、OpenType フォントを探すときにサブディレクトリを検索するよう Kpathsea に指示します。 のデフォルト定義は `OSFONTDIR` の内部で `texmf.cnf` の一般形は次のとおりです: ``` OSFONTDIR = /please/set/osfontdir/in/the/environment ``` したがって、これを使いたいなら必ず設定する必要があります。環境変数は、次に含まれるこの「プレースホルダー」の定義を上書きします `texmf.cnf`. 環境変数を設定すると `OSFONTDIR` 実行時に、Kpathsea が次を見つけるたびに `$OSFONTDIR` をパス要素の一部として（ `texmf.cnf`）それは変数を置き換えることができます `$OSFONTDIR` 環境変数に保存された実際の値に `OSFONTDIR`。忘れないでください。次の中でそれを使うときは `texmf.cnf` パス要素では、変数を指定します `$OSFONTDIR`—先頭に `$`—これが、Kpathsea に対して、次のような変数であることを知らせるためです *値* それを使用する必要があります。 #### $TEXMF についての簡単な注記 `TEXMF` も、次の中で定義される別の設定変数です `texmf.cnf`; たとえば、TeX Live のマスター配布版では次のようになります: ``` TEXMF = {$TEXMFAUXTREES$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,!!$TEXMFLOCAL,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFDIST} ``` この定義の詳細を気にする必要はありません `TEXMF`—すべての詳細には立ち入りませんが、単に次の点だけ押さえておきましょう `$TEXMF` この変数はパス要素内で使われます。なぜなら、ファイル検索を開始できる一連の最上位フォルダ（“texmf trees” と呼ばれる）を定義しているからです。 `TEXMF` これは、TeX のインストールを複数のディレクトリ（またはディレクトリの“ツリー”）に分割したい、あるいは分割する必要がある場合に非常に便利です。たとえば、TeX/LaTeX パッケージのメインまたはマスターの集まり（例: TeX Live）と、ローカルの LaTeX パッケージを保存するための別のファイルやフォルダの集まり、あるいはローカルの設定ファイルや標準パッケージのカスタマイズ版を保存するための集まりがあるとします。このように TeX を分割しておくと、TeX Live の配布版／インストールを更新したときに更新されるマスター・ファイルからローカルの集まりが分離されるため、TeX/LaTeX パッケージのメイン／マスター集まり（配布物）の更新管理がしやすくなります。 より複雑な TeX インストールの管理についてさらに詳しく知りたい方は、次の 2 本の論文を参照してください: * [複数の TDS ツリーを管理する](http://tug.org/TUGboat/Articles/tb22-3/tb72downes.pdf) Michael J Downes 著; * [texmf ツリーを扱う](http://www.ntg.nl/maps/27/17.pdf) Siep Kroonenberg 著。 #### TeX ディレクトリ構造 TeX のインストールを管理したことがある人なら、TeX Live のような現代の TeX システムには、非常に多種多様なファイルから成る何万ものファイルが含まれていることを知っています。TeX Directory Structure（TDS）は、稼働中の TeX インストールにある膨大なファイル群を整理するためのベストプラクティスとしての「設計図」として作られ、Kpathsea と併用することが強く推奨されています。 さらに詳しい情報については、TDS 仕様を参照してください: [TeX ファイルのためのディレクトリ構造](https://www.tug.org/tds/tds.pdf). ## Kpathsea のファイル種類 Kpathsea を使うアプリケーション群は、広範な種類のファイルにアクセスする必要があります。そのため Kpathsea は、サポートする各ファイル種別（またはファイル群）のパスを識別するために“設定変数”を使います。オンライン文書には完全な一覧があります（ [下の要約表も参照してください](#table-listing-kpathsea-config-variables)） | | | | -------------------- | -------------------------- | | **設定変数** | **ファイル種類の例** | | TEXINPUTS | TeX ソースファイルと図版／グラフィックスファイル | | BIBINPUTS, BSTINPUTS | BibTeX の文献ソースファイル | | TTFONTS | TrueType アウトラインフォント | | OPENTYPEFONTS | OpenType アウトラインフォント | `TEXINPUTS` は特に重要な設定変数です。なぜなら、TeX エンジンが入力ソースファイルをどこから取得するかを指定するからです。画像ファイルも入力ファイルと見なされ、次によって定義されたパスを使って検索できることに注意してください `TEXINPUTS`. ### Kpathsea のいくつかの細かな点 述べたように、Kpathsea にはここで詳しく扱えない多くの細かな点があります。ただし、興味のある読者が探究したくなる機能をいくつか挙げます: * **ファイル名データベース:** ディスク検索を最小限にするため、Kpathsea は“外部で構築された [ls-R という名前のファイル名データベースファイル](http://tug.org/texinfohtml/kpathsea.html#Filename-database) を利用して、ファイルとディレクトリの対応付けを行えます”。TeX Live にはこれが用意されており、新しいファイルが追加された場合に更新するためのツールもあります。 * **環境変数**: “設定変数”（たとえば `OPENTYPEFONTS`）に加えて [環境変数](https://en.wikipedia.org/wiki/Environment_variable)Kpathsea は次も巧みに利用します `texmf.cnf` ; たとえば、環境変数の実行時の値を使って、次の中のパス要素を定義できます `texmf.cnf`). * **プログラム名:** Kpathsea の動作における微妙ですが重要な点は、実行可能プログラム名（たとえば TeX エンジン）を使って、プログラム固有の検索パス構成を作れることです。これにより、特定の TeX エンジン向けのファイルに検索を向けられるため、かなり柔軟になります。たとえば LuaTeX/LuaLaTeX では次のようになります: ``` TEXINPUTS.lualatex = .;$TEXMF/tex/{lualatex,latex,luatex,generic,}// TEXINPUTS.luatex = .;$TEXMF/tex/{luatex,plain,generic,}// ``` * **見つけること `texmf.cnf`**: 疑問に思うかもしれないのは、Kpathsea がどこに `texmf.cnf` 保存されているかをどう知るのか、ということです。答えは、次のような環境変数です `TEXMFCNF`。これは、TeX を実行しているデバイス／プラットフォーム上で、次が保存されているパスに設定する必要があります `texmf.cnf` が保存されています。 #### Kpathsea の問題をデバッグする Overleaf のユーザーがこれらの機能を必要とすることはあまりないでしょうが、完全性のために挙げておきます: * **kpsewhich**: 設定をテストするために使える独立したプログラム（TeX Live に含まれています）で、変数の値を調べたりファイルを見つけたりできます。興味のある方は次を参照してください [オンライン文書](http://tug.org/texinfohtml/kpathsea.html#Invoking-kpsewhich) さらに情報を得ることができます。 * **環境変数**: Kpathsea は次の環境変数をサポートしています [`KPATHSEA_DEBUG`](http://www.tug.org/texinfohtml/kpathsea.html#Debugging) を使ってその動作のデバッグを支援できます。次を設定できます `KPATHSEA_DEBUG` デバッグ情報がどれだけ必要かに応じて、さまざまな値に。次を設定すると `KPATHSEA_DEBUG=-1` は *大量の* データを生成します。 ## そして最後に: フォルダ、図版ファイル、latexmkrc では、上の内容は latexmkrc とどう関係するのでしょうか？ この記事を読めば [Overleaf で latexmkrc を使う方法: 例とテクニック](/latex/ja/xiang-xi-ji-shi/28-how-to-use-latexmkrc-with-overleaf.md) latexmkrc の例にある（Perl）コードが、環境変数の値を設定していることが分かります `TEXINPUTS`: ``` $ENV{'TEXINPUTS'}='./tex//:' . $ENV{'TEXINPUTS'}; ``` ここで使われているコロン（:）（`./tex//**:**`）は *極めて* は重要です。そのコロンを省くと、TeX/LaTeX は LaTeX パッケージのような重要なシステムファイルを見つけられない可能性があります！ この latexmkrc ファイルが実質的に行っているのは、最上位フォルダのパス（`./tex` 上の例では）をシステム定義の `TEXINPUTS` 環境変数に追加することです。これにより Kpathsea がこの変数を使うときに `$TEXINPUTS` Kpathsea は次のフォルダがあることを認識します `/tex//` を入力ファイルの検索対象にすべきだと認識します。よく見ると、実際に使われているパスは `./tex//:` その `//` は、tex フォルダを再帰的に検索するよう Kpathsea に指示します。つまり、その `TeX` フォルダ内に含まれるサブフォルダも調べます。述べたように、重要なコロン文字も追加しました。 図版ファイルにもまったく同じ手法を使えます。 ### BibTeX に関する補足 述べたように、BibTeX プログラムも入力ファイルの検索に Kpathsea を使います。特に: * その `BSTINPUTS` 設定変数（検索パス）は、次を検索するために使われます `.bst` ファイル; * と `BIBINPUTS` 設定変数（検索パス）は、次を検索するために使われます `.bib` ファイルを準備する方法をざっと見ました。 新しい `.bst` または `.bib` ファイルを Overleaf プロジェクトに追加した場合は、以下の手法を使って BibTeX にそれらのファイルの場所を指示できます。置き換える必要があるのは `TEXINPUTS` と `BSTINPUTS` および／または `BIBINPUTS`. ### TEXINPUTS と、グラフィックスファイルのために入れ子フォルダを使うこと プロジェクトにグラフィックスファイルがたくさんあるなら、それらを保存・管理するためのフォルダ群を作ると便利です。たとえば、次のスクリーンショットは、次の名前の最上位フォルダを使っている Overleaf プロジェクトの一部を示しています **`graphics`**: ![Overleaf プロジェクト内の入れ子フォルダを示す画像](/files/cacdb6a68384f843ec1902afe30052c418e0cf5c) 文書のさまざまな節のグラフィックスを含む、数多くの（入れ子になった）サブフォルダがあります。 上のフォルダ構成があり、次を使いたいとします `graphicx` （`\usepackage{graphicx}`）を、次のように使おうとしたとします: ```latex \documentclass{article} \usepackage{graphicx} \begin{document} \includegraphics{endlinechar}% ベストプラクティスとしてはファイル拡張子を使わない \end{document} ``` これは動作せず、次のようなエラーになります: ``` ! LaTeX Error: File `endlinechar' not found. l.4 \includegraphics{endlinechar} これらの拡張子のいずれでもファイルを見つけられませんでした: .pdf,.PDF,.ai,.AI,.png,.PNG,.jpg,.JPG,.jpeg,.JPEG,.jp2,.JP2,.jpf,.JPF,.bmp,.BMP, ,.ps,.PS,.eps,.EPS,.mps,.MPS,.pz,.eps.Z,.ps.Z,.ps.gz,.eps.gz ``` このエラーは、グラフィックスファイルが TeX/LaTeX（および Kpathsea）が認識していない場所に保存されているため、そのファイルを見つけられないからです。グラフィックスファイルへのパスは次のとおりです: ``` ./graphics/Introduction/Chapter1/Section1/Subsection3/endlinechar.png ``` **注**: 一般に受け入れられているベストプラクティスは ***フォルダ名に空白文字を入れないことです***。フォルダ名に空白を含めることは確かに可能ですが、以下で説明する手法を使うとしても、Overleaf プラットフォーム外での文書の移植性を考えると避けることをお勧めします。 この [Overleaf のヘルプ記事で説明されているように](/latex/ja/sononotopikku/27-inserting-images.md) もちろん、フォルダを使ってグラフィックスを保存できますが、それらがどこにあるかを LaTeX に伝える必要があります。ここでは 2 つの解決策を見ていきます: * \graphicspath コマンドを使う; * Kpathsea についての知識と `TEXINPUTS`. ### \graphicspath を使う この `graphicx` パッケージは `\graphicspath` グラフィックスの場所を宣言するために使えるコマンドです。ですから、次のようにできます: ```latex \graphicspath{{./graphics/Introduction/Chapter1/Section1/Subsection3/}} ``` すると LaTeX は、そのパス下に保存されたあらゆるグラフィックスを見つけられるようになります。 **注**: もし *必要があります* フォルダ名に空白がある場合は、パスを二重引用符（`"..."`): ```latex \graphicspath{{"./graphics/Introduction/Chapter 1/Section 1/Subsection 3/"}} ``` **注**: 次のように複数のパスを宣言できます: ```latex \graphicspath{{path1}{path2}{path3}...{pathN}} ``` ここで `...` は、波括弧で囲まれた追加のパスを意味します。 **注**: パスは次で始めます `./graphics` であって、単に `/graphics`。ドット（.）は、そのパスが現在の作業ディレクトリからの相対パスであることをオペレーティングシステムに示します。 この `\graphicspath` コマンドはうまく機能しますが、フォルダが多いとすべてのパスを追加するのはかなり面倒になります。さらに、次を通じて定義されたパスは `\graphicspath` フォルダ名を変更したり再構成したりすると使えなくなります。もっと簡単な方法はあるのでしょうか？ はい、latexmkrc ファイルを使えます！ #### \graphicspath と再帰（サブディレクトリ） 一部のシステムが次をサポート／有効化するかどうかについては、オンラインで議論／論争があります `\graphicspath` を追加するとサブディレクトリを再帰的に検索することについて `//` パスの末尾に入れる場合です。たとえば、tex.stackexchange の次の議論を参照してください: * [LaTeX の \graphicspath 再帰検索](https://tex.stackexchange.com/questions/25443/latex-graphicspath-recursive-search); * [MikTeX 向けの Graphicspath](https://tex.stackexchange.com/questions/3131/graphicspath-for-miktex). 最大限の互換性を確保するには、次のように仮定するべきです `\graphicspath` は再帰的なディレクトリ検索をサポートしていない ### Kpathsea と TEXINPUTS（latexmkrc ファイルで解決） **注意:** 次の手法は Overleaf および適切に設定されたローカル TeX インストールでうまく動作することに注意してください; **しかし** latexmkrc ファイルを使うと、出版社やオンラインのジャーナル投稿システムで使われているような他の TeX インストールと、プロジェクトが互換性を失う可能性があります。サードパーティの TeX インストールが latexmkrc の使用をサポートまたは許可するかどうかは場合によります。Overleaf プロジェクトを他で使うためにエクスポートしたい、あるいはジャーナルに投稿したい場合は、パス名から空白文字をすべて削除し、互換性を高めるために次を追加すべきです `\graphicspath` すべてのパスを定義するコマンド: ```latex \graphicspath{{path1}{path2}{path3}...{pathN}} ``` ここで `...` は、波括弧で囲まれた追加のパスを意味します。 以下で説明する手法（ `TEXINPUTS`）は、Overleaf で pdfTeX、XeTeX、LuaTeX エンジン（つまり Overleaf メニューの pdfLaTeX、XeLaTeX、LuaLaTeX のコンパイラオプション）を使って正常にテストされています: ![Overleaf で LaTeX コンパイラを選ぶ方法を示す画像](/files/e49b6bdd7e601ea7913cab364afb24f2465b46c2) 例に戻ると、深く入れ子になったフォルダを含むこのコードを使いたいので、それを実現するために latexmkrc ファイルを使います: ```latex \documentclass{article} \usepackage{graphicx} \begin{document} \includegraphics{endlinechar}% ベストプラクティスとしてはファイル拡張子を使わない \end{document} ``` 上のコードが問題なく動作しているスクリーンショットです: LaTeX がグラフィックスファイル（`endlinechar.png`）を見つけています。たとえそれが、フォルダ名に空白のない深く入れ子になったフォルダ構造の中にあってもです。 ![Overleaf で入れ子フォルダを含むプロジェクトがコンパイルされている画像](/files/e8418935bdbcef0840a33069ba30ad34d6b3fc34) では、どうやってこれを実現したのでしょうか？ 必要なのは次のことだけです: * 拡張子なしで新しいファイルを作成し、それを latexmkrc と名付ける; * そのファイルに次の行を追加する: ``` $ENV{'TEXINPUTS'}='./graphics//:'.$ENV{'TEXINPUTS'}; ``` これで Kpathsea は、次の下に含まれるフォルダを認識します `**graphics**` そして次のために `//` サブフォルダも調べます。 繰り返しますが、次の中のコロンに注意してください `./graphics//:` 実際には *極めて* は重要です。そのコロンを省くと、TeX/LaTeX は LaTeX パッケージのような重要なシステムファイルを見つけられない可能性があります！ 上のシンプルなプロジェクトの例を使えば、これでコンパイルできて、ほら！LaTeX があなたのグラフィックスファイルを見つけます。そして /graphics 以下のフォルダの名前を変更したり再編成したりしても、LaTeX がそれらを見つける妨げにはなりません。 ## Kpathsea の「config variables」を一覧にした表 次の表は、〜から導かれた要約です [Kpathsea ドキュメントに記載されているデータ](http://tug.org/texinfohtml/kpathsea.html#Supported-file-formats). | | | | | --------------------------------------------------- | -------------------------------------- | ------------------------------ | | **Kpathsea の設定変数** | **ファイル種別の説明** | **ファイル拡張子** | | AFMFONTS | Adobe フォントメトリクス | .afm | | MFBASES, TEXMFINI | Metafont のメモリダンプ | .base | | BIBINPUTS, TEXBIB | BibTeX の文献ソース | .bib | | BLTXMLINPUTS | Biber 用の BibLaTeXML 文献ファイル | .bltxml | | BSTINPUTS | BibTeX のスタイル | .bst | | CLUAINPUTS | Lua 用の動的ライブラリ | .dll および .so | | CMAPFONTS | 文字マップファイル | .cmap | | TEXMFCNF | 実行時設定ファイル | .cnf | | CWEBINPUTS | CWEB 入力ファイル | .w, .web, .ch | | TEXCONFIG | config.ps などの Dvips の 'config.\*' ファイル | | | ENCFONTS | エンコーディングベクター | .enc | | TEXFORMATS, TEXMFINI | TeX のメモリダンプ | .fmt | | FONTCIDMAPS | CJK マッピング | .cid | | FONTFEATURES | 主に OpenType フォント機能用 | .fea | | FONTS, GFFONTS, GLYPHFONTS, TEXFONTS | 汎用フォントビットマップ | .gf | | TEXPICTS, TEXINPUTS | Encapsulated PostScript 図版 | .eps, .epsi | | TEXINDEXSTYLE, INDEXSTYLE | makeindex のスタイルファイル | .ist | | LIGFONTS | 連字定義ファイル | .lig | | TEXMFDBS | ファイル名データベース | | | フォントマップ | フォントマップ | .map | | MPMEMS, TEXMFINI | MetaPost のメモリダンプ | .mem | | MPSUPPORT | DMP で使用される MetaPost サポートファイル | | | MFINPUTS | Metafont ソース | .mf | | MFPOOL, TEXMFINI | Metafont のプログラム文字列 | .pool | | MFTINPUTS | MFT スタイルファイル | .mft | | MISCFONTS | 他のカテゴリに当てはまらないフォント関連ファイル | | | MLBIBINPUTS, BIBINPUTS, TEXBIB | MlBibTeX の文献ソース | .mlbib, .mlbib | | MLBSTINPUTS, BSTINPUTS | MlBibTeX のスタイル | .mlbst, .bst | | MPINPUTS | MetaPost ソース | .mp | | MPPOOL, TEXMFINI | MetaPost のプログラム文字列 | .pool | | OCPINPUTS | Omega コンパイル済みプロセスファイル | .ocp | | OFMFONTS, TEXFONTS | Omega のフォントメトリクス | .ofm, .tfm | | OPENTYPEFONTS | OpenType フォント | | | OPLFONTS, TEXFONTS | Omega のプロパティリスト | .opl | | OTPINPUTS | Omega 変換プロセスファイル | .otp | | OVFFONTS, TEXFONTS | Omega 仮想フォント | .ovf | | OVPFONTS, TEXFONTS | Omega 仮想プロパティリスト | .ovp | | PDFTEXCONFIG | PDFTeX 固有の設定ファイル | | | PROGRAMFONTS, PKFONTS, TEXPKS, GLYPHFONTS, TEXFONTS | パック済みビットマップフォント | .pk | | TEXPSHEADERS, PSHEADERS | ダウンロード可能な PostScript | .pro | | RISINPUTS | RIS の文献ファイル、主に Bibe 用 | .ris | | SFDFONTS | サブフォント定義ファイル | .sfd | | TEXINPUTS | TeX ソース | .tex | | TEXDOCS | TeX システムのドキュメントファイル | | | TEXSOURCES | TeX システムのソースファイル | | | TEXMFSCRIPTS | texmf ツリーで配布されるアーキテクチャ非依存の実行ファイル | | | TEXPOOL, TEXMFINI | TeX のプログラム文字列 | .pool | | TFMFONTS, TEXFONTS | TeX のフォントメトリクス | .tfm | | TRFONTS | Troff フォント | | | TTFONTS | TrueType アウトラインフォント | .ttf, ,TTF, .ttc, .TTC, .dfont | | T1FONTS, T1INPUTS, TEXPSHEADERS, DVIPSHEADERS | Type 1 PostScript アウトラインフォント | .pfa, .pfb | | T42FONTS | Type 42 PostScript アウトラインフォント | | | VFFONTS, TEXFONTS | 仮想フォント | .vf | | WEBINPUTS | WEB 入力ファイル | .web, .ch | | WEB2C | web2c 実装固有のファイル | | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/latex/ja/xiang-xi-ji-shi/06-an-introduction-to-kpathsea-and-how-tex-engines-search-for-files.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.