> 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/ko/in-depth-articles/06-an-introduction-to-kpathsea-and-how-tex-engines-search-for-files.md). # Kpathsea 소개와 TeX 엔진이 파일을 검색하는 방법 ## 소개 이 글은 LaTeX나 다른 매크로 패키지를 사용하여 문서를 조판하는 데 필요한 파일을 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/ko/in-depth-articles/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**arl의 **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 primitives)으로 변환됩니다. 그 명령에 파일을 열어야 하는 필요가 포함되어 있다면, TeX 엔진은 Kpathsea에 사실상 “이 파일을 찾아 주세요”라고 요청합니다. 그 Kpathsea 검색이 성공하면 파일이 열립니다. 그러나 Kpathsea가 파일을 찾지 못하면 TeX 엔진은 그 사실을 전달받고 실행을 멈춘 뒤 악명 높은 오류 ``! 파일 `...'을(를) 찾을 수 없습니다`` 사실 Kpathsea가 그것을 찾지 못한 것입니다. ### LuaTeX에 대한 참고 사항 엄밀히 말하면, 이 절에는 LuaTeX가 사용자가 다음을 사용하여 자체 파일 검색 코드를 제공할 수 있는 메커니즘을 제공한다는 점을 언급하는 단서를 달아야 합니다: *콜백*. LuaTeX는 사용자가 Lua 스크립팅 언어로 함수를 작성하고 LuaTeX에 등록하여, LuaTeX 실행의 특정 단계에서 그 사용자 정의 함수를 호출하도록 할 수 있습니다—따라서 용어 *콜백*. 이것은 매우 강력한 기법이며 관심 있는 독자는 다음의 9절에서 더 많은 정보를 찾을 수 있습니다 [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): > ... 하나의 *검색 경로* 는 콜론으로 구분된 목록입니다 *경로 요소*, 즉 몇 가지 ‘추가 장식’이 붙은 디렉터리 이름들입니다. —단, 세미콜론(`;`)도 구분에 사용된다는 점에 유의하세요 *경로 요소*. 나중에 그 ‘추가 장식’들 중 일부의 성격을 간단히 설명하겠습니다. 우리의 `OPENTYPEFONTS` 예제에는 세 개의 경로 요소가 있으며, 각각 세미콜론(`;`): ![Kpathsea 경로 정의에 포함된 경로 요소를 보여주는 이미지](/files/0b7dfddf01b81c1220a7994fa277168719b3af79) 1. `.` (현재 디렉터리를 의미함) 2. `$TEXMF/fonts/{opentype,truetype}//` 3. `$OSFONTDIR//` 이중 슬래시(`//`)는 경로 요소에서 하위 디렉터리를 검색(재귀적으로)하라는 뜻입니다. 일반적인 `texmf.cnf` 파일에는 Kpathsea가 검색할 수 있는 파일 형식에 대한 검색 경로를 정의하는 수많은 ‘구성 변수’가 들어 있습니다. ## Kpathsea: 아주 짧은 개요 Kpathsea는 매우 정교한 라이브러리로—세부 사항과 뉘앙스가 많으며—그것의 [문서](http://tug.org/texinfohtml/kpathsea.html) 문서를 잠깐 보기만 해도 모든 세부 사항을 다 다룰 수는 없다는 점이 분명해집니다. 그러나 그것이 무엇을 하는지에 대한 개요를 제공해, 이해의 방향을 잡고 추가 읽기를 위한 출발점을 제시할 수는 있습니다. ### Kpathsea의 핵심 목적 문서에 적혀 있듯이, Kpathsea의 기본 목적은 ‘사용자가 지정한 디렉터리 목록에서 파일 이름을 반환하는 것’이며, 그 디렉터리들(검색 경로)은 ‘몇 가지 추가 장식’을 사용해 지정됩니다. ### 그 ‘추가 장식’에는 위에서 언급한 ‘몇 가지 추가 장식’에는 Kpathsea가 검색 경로(또는 ‘경로 템플릿’)를 구성할 때 사용하는 다양한 매개변수와 변수가 포함되어 있어, 경로를 더 일반적인 방식으로 정의할 수 있습니다. TeX 엔진이 실제로 실행 중일 때, Kpathsea는 이러한 매개변수/변수의 현재 값을 사용해 변수들을 실제(런타임) 값으로 바꾸어 실제 경로를 계산할 수 있습니다. 이러한 변수는(경로 요소 안에서) 앞에 다음이 붙어 있기 때문에 쉽게 식별할 수 있습니다: `$` 달러 기호 따라서 우리는 Kpathsea가 *확장한다* 경로 요소를 확장한다고 말합니다. 즉, 해당 매개변수와 변수를 변환하여 경로 ‘템플릿’을 파일을 찾을 하나 이상의 실제 물리적 디렉터리 이름으로 바꾸는 것입니다. 이는 매우 큰 유연성을 제공하며, 예를 들어 하위 디렉터리까지 검색하라는 지시를 받으면 Kpathsea가 하나의 경로 요소에 해당하는 디렉터리 목록을 구성할 수 있다는 뜻입니다. ### OpenType 예제를 다시 보기 여러 내용을 한데 모아 살펴보겠습니다 `OPENTYPEFONTS` 조금 더 자세히: ``` OPENTYPEFONTS = .;$TEXMF/fonts/{opentype,truetype}//;$OSFONTDIR// ``` 두 경로 요소를 살펴봅시다 `$TEXMF/fonts/{opentype,truetype}//` 및 `$OSFONTDIR//`. 여기서 Kpathsea는 중괄호의 사용을 인식하고 `{...}` 이를 `$TEXMF/fonts/{opentype,truetype}` 다음의 두 경로 요소를 나타내는 것으로 취급합니다: *두* 경로 요소: 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 트리’라고 함)을 정의하기 때문입니다. `TEXMF` TEXMF는 TeX 설치를 여러 디렉터리(또는 디렉터리 ‘트리’)에 나누어 두고 싶거나 그렇게 해야 할 때 매우 유용합니다. 예를 들어, TeX/LaTeX 패키지의 मुख्य 또는 마스터 모음(예: TeX Live)과 로컬 LaTeX 패키지를 저장하는 다른 파일·폴더 모음, 또는 로컬 구성 파일이나 표준 패키지의 수정된 버전을 저장하는 데 쓰이는 모음을 둘 수 있습니다. 이렇게 TeX 설치를 분리하면 TeX/LaTeX 패키지의 मुख्य/마스터 모음(배포판) 업그레이드를 더 쉽게 관리할 수 있습니다. 로컬 모음은 TeX Live 배포판/설치를 업그레이드할 때 갱신되는 마스터 파일과 분리되어 있기 때문입니다. 더 복잡한 TeX 설치를 관리하는 방법에 대한 자세한 내용은 다음 두 논문을 참고하세요: * [여러 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`) 외에도 Kpathsea는 다음도 영리하게 활용합니다: [환경 변수](https://en.wikipedia.org/wiki/Environment_variable); 예를 들어, 환경 변수의 런타임 값을 사용해 다음에서 경로 요소를 정의할 수 있습니다: `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/ko/in-depth-articles/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` 폴더가 `/tex//` 입력 파일을 찾기 위해 검색되어야 한다는 것을 알게 됩니다. 자세히 보면 실제로 사용된 경로는 `./tex//:` 다음 `//` 는 Kpathsea에게 tex 폴더를 재귀적으로 검색하라고 지시합니다. 즉, `tex` 폴더 안에 포함된 모든 하위 폴더를 살펴보라는 뜻입니다. 앞서 언급했듯이 중요한 콜론 문자도 추가했습니다. 그림 파일에도 정확히 같은 기법을 사용할 수 있습니다. ### BibTeX에 대한 잠깐의 설명 앞서 언급했듯이 BibTeX 프로그램도 입력 파일을 찾기 위해 Kpathsea를 사용하며, 특히: * 다음 `BSTINPUTS` 구성 변수(검색 경로)는 다음을 검색하는 데 사용됩니다: `.bst` 파일; * 와 `BIBINPUTS` 구성 변수(검색 경로)는 다음을 검색하는 데 사용됩니다: `.bib` 파일을 불러오세요. 새로운 `.bst` 또는 `.bib` 파일을 Overleaf 프로젝트에 추가했다면 아래 기법을 사용하여 BibTeX에게 이 파일들을 어디서 찾을지 알려줄 수 있습니다—다음을 바꿔야 합니다: `TEXINPUTS` 다음으로 바꾸면 `BSTINPUTS` 및/또는 `BIBINPUTS`. ### TEXINPUTS와 중첩 폴더를 그래픽 파일에 사용하기 프로젝트에 그래픽 파일이 많다면 이를 저장하고 관리할 폴더 세트를 만드는 것이 편리할 수 있습니다. 예를 들어, 다음 화면 캡처는 다음과 같은 최상위 폴더를 사용하는 Overleaf 프로젝트의 일부를 보여 줍니다: **`graphics`**: ![Overleaf 프로젝트의 중첩 폴더를 보여주는 이미지](/files/15b000b0f469199d4cb0a4f928fed9525a0a2751) 문서의 여러 섹션에 대한 그래픽을 포함한 수많은(중첩된) 하위 폴더가 있습니다. 위와 같은 폴더 구조가 있고 다음을 사용하고 싶다고 가정해 봅시다: `graphicx` 패키지(`\usepackage{graphicx}`)를 사용해 보려고 한다고 합시다: ```latex \documentclass{article} \usepackage{graphicx} \begin{document} \includegraphics{endlinechar}% best practice is not to use the file extension \end{document} ``` 작동하지 않으며 다음과 같은 오류가 발생합니다: ``` ! LaTeX Error: 파일 `endlinechar'을 찾을 수 없습니다. 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/ko/more-topics/27-inserting-images.md) 물론 폴더를 사용해 그래픽을 저장할 수 있지만, LaTeX에게 그 위치를 알려 주어야 합니다. 여기서는 두 가지 해결책을 살펴보겠습니다: * \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 명령은 잘 작동하지만 폴더가 많으면 모든 경로를 추가하는 일이 꽤 번거로울 수 있습니다. 또한, 다음을 통해 정의한 경로는 `\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 설치와 호환되지 않을 수 있습니다. 제3자 TeX 설치는 latexmkrc 사용을 지원하거나 허용할 수도 있고 그렇지 않을 수도 있습니다. Overleaf 프로젝트를 다른 곳에서 사용하도록 내보내야 하거나 학술지에 제출하려면 경로 이름에서 공백 문자를 모두 제거하고, 호환성을 높이기 위해 다음을 추가해야 합니다: `\graphicspath` 모든 경로를 정의하는 명령: ```latex \graphicspath{{path1}{path2}{path3}...{pathN}} ``` 여기서 `...` 는 중괄호로 묶인 추가 경로를 뜻합니다. 아래에서 설명하는 기법(다음 사용) `TEXINPUTS`)는 Overleaf에서 pdfTeX, XeTeX 및 LuaTeX 엔진(즉, Overleaf 메뉴의 pdfLaTeX, XeLaTeX 및 LuaLaTeX 컴파일러 옵션)으로 성공적으로 테스트되었습니다: ![Overleaf에서 LaTeX 컴파일러를 선택하는 방법을 보여주는 이미지](/files/10b540216462a62481d46757daa91eed6502b078) 다시 예제로 돌아가서, 우리는 (깊이 중첩된 폴더가 있는) 이 코드를 사용하고 싶으며, 이를 달성하기 위해 latexmkrc 파일을 사용할 것입니다: ```latex \documentclass{article} \usepackage{graphicx} \begin{document} \includegraphics{endlinechar}% best practice is not to use the file extension \end{document} ``` 다음은 위 코드가 문제없이 작동하는 화면 캡처입니다: LaTeX가 그래픽 파일(`endlinechar.png`)를 찾았습니다. 비록 그것이 깊이 중첩된 폴더 구조 안에 있더라도(폴더 이름에 공백 없이) 말입니다. ![Overleaf에서 중첩 폴더가 있는 프로젝트가 컴파일되는 것을 보여주는 이미지](/files/efbe6d3db9e8c5d55b357edc9719b772fa9af945) 그렇다면 어떻게 했을까요? 필요한 것은 다음과 같습니다: * 확장자 없이 새 파일을 만들고 latexmkrc라고 이름 붙이기; * 해당 파일에 다음 줄을 추가하세요: ``` $ENV{'TEXINPUTS'}='./graphics//:'.$ENV{'TEXINPUTS'}; ``` 이제 Kpathsea는 다음 아래에 포함된 폴더를 알게 됩니다 `**graphics**` 그리고 다음 때문에 `//` 하위 폴더도 살펴볼 것입니다. 다시 한 번, 다음의 콜론은 `./graphics//:` 은 실제로는 *매우* 중요합니다. 그 콜론을 생략하면 TeX/LaTeX가 LaTeX 패키지와 같은 필수 시스템 파일을 찾지 못할 수 있습니다! 위의 간단한 프로젝트 예제를 사용하면 이제 컴파일할 수 있고, 짜잔! LaTeX가 그래픽 파일을 찾습니다—그리고 /graphics 아래의 폴더 이름을 바꾸거나 재구성해도 LaTeX가 파일을 찾는 것을 막지 않습니다. ## Kpathsea “config 변수” 목록 표 다음 표는 다음에서 요약한 것입니다 [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 and .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 | 캡슐화된 PostScript 그림 | .eps, .epsi | | TEXINDEXSTYLE, INDEXSTYLE | makeindex 스타일 파일 | .ist | | LIGFONTS | 합자 정의 파일 | .lig | | TEXMFDBS | 파일명 데이터베이스 | | | TEXFONTMAPS | Fontmap | .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 | 주로 Bibe용 RIS 참고문헌 파일 | .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/ko/in-depth-articles/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.