> 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/cs/clanky-do-hloubky/06-an-introduction-to-kpathsea-and-how-tex-engines-search-for-files.md). # Úvod do Kpathsea a jak TeX enginy vyhledávají soubory ## Úvod Tento článek poskytuje úvod do toho, jak enginy TeXu vyhledávají soubory potřebné k sazbě vašeho dokumentu — ať už používáte LaTeX nebo jakýkoli jiný makropaket. Ačkoli Overleaf zbavuje uživatele starostí se správou instalace TeXu ([TeX Live](https://www.tug.org/texlive/)), základní principy vyhledávání souborů enginy TeXu budou užitečné/zajímavé, pokud si chcete vytvořit strukturu složek, která vám pomůže spravovat váš projekt v Overleafu. Proč by to mohlo být pravda? Pokud některé soubory projektu Overleaf uložíte do složek, LaTeX je možná nenajde, protože ve výchozím nastavení engine TeXu (kompilátor) nemusí *vědět* že má tyto složky prohledávat — a soubory, které obsahují, tedy nenajde. Abyste tomu předešli, můžete ve svém projektu vytvořit a přidat konfigurační soubor nazývaný [soubor latexmkrc](https://mg.readthedocs.io/latexmk.html#configuration-files) který lze použít k tomu, aby enginu TeXu řekl, že vaše složky existují a že je má prohledávat. Pokud chcete rovnou přejít k příkladu se souborem latexmkrc, můžete si přečíst tento článek nápovědy: [Jak používat latexmkrc v Overleafu: příklady a techniky](/latex/cs/clanky-do-hloubky/28-how-to-use-latexmkrc-with-overleaf.md). Nemusí být hned zřejmé, jak nebo proč ten soubor latexmkrc vlastně funguje. Pokud byste chtěli vědět proč a možná si vytvořit lepší představu pro použití s dalšími možnostmi konfigurace vašeho projektu, čtěte dál... Na konci tohoto článku projdeme [praktický příklad](#kpathsea-and-texinputs-latexmkrc-file-to-the-rescue)—a využijeme naše znalosti o tom, jak TeX vyhledává soubory— k vytvoření souboru latexmkrc pro správu vnořených složek obsahujících vaše soubory s grafikou. ## TeX a nezávislost na platformě Když Knuth vytvářel TeX, byla nezávislost na platformě ústředním principem, který řídil jeho návrh a implementaci, a tato filozofie se odráží v celém vnitřním fungování TeXu (např. používání celočíselné aritmetiky, „domácího“ zpracování řetězců, správy paměti atd.). I dnes nezávislost moderních enginů založených na TeXu na platformě stále vyvolává otázky a diskuse na veřejných fórech; například viz tato diskuse na tex.stackexchange: [Jsou XeTeX a LuaTeX závislé na platformě?](https://tex.stackexchange.com/questions/94297/are-xetex-and-luatex-platform-dependent) která obsahuje komentáře a postřehy řady známých odborníků na TeX. Prozatím však odložme stranou podrobnější detaily a všimněme si, že enginy TeXu stále musí být vysoce přenositelné — schopné fungovat na více operačních systémech a vytvářet „identické“ výsledky. Klíčovým aspektem přenositelnosti je vyhledávání souborů způsobem nezávislým na platformě. ## Enginy TeXu soubory nevyhledávají… vážně!? Ne, enginy TeXu *přímo* soubory nevyhledávají *samy od sebe*. Při zpracování `.tex` souboru může engine TeXu rozpoznat potřebu otevřít určitý soubor, ale *předává* úkol jeho nalezení jinému kusu softwaru zvanému [*Kpathsea*](https://tug.org/kpathsea/): externí softwarové knihovně, která není součástí *jádrového* zdrojového kódu enginů TeXu. To, co Kpathsea poskytuje, je v podstatě API ([aplikační programové rozhraní](https://en.wikipedia.org/wiki/Application_programming_interface)) které mohou enginy TeXu (a také BibTeX, MetaPost a další aplikace) volat pokaždé, když potřebují otevřít určitý soubor: Kpathsea vykoná skutečnou práci při hledání daného souboru. Když Knuth psal původní engine TeXu — z něhož jsou nakonec odvozeny všechny ostatní enginy TeXu — byl problém nalezení/otevření souborů značnou výzvou částečně kvůli velmi rozdílnému technologickému ekosystému té doby. Ve skutečnosti Knuth ve zdrojovém kódu TeXu označuje vstup/výstup souborů za „pohromu přenositelnosti“ (viz strana 12, oddíl 25 [TeX: The Program](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373)). Komunita TeXu si uvědomila potřebu sjednotit (standardizovat) vyhledávání souborů pro TeX —*a software související s TeXem*—a rozhodla se dát TeXu nástroje, aby to dokázal. Aby se vyřešil velmi oříškový problém platformně nezávislé metody vyhledávání souborů, napsal Karl Berry, přední člen komunity TeXu, software řešící *problém s cestami*: řešení, které pojmenoval [**Kpathsea**](http://tug.org/texinfohtml/kpathsea.html)—odvozené od **K**arlova **Path** **Sea**rching (viz tento [rozhovor s Karlem Berrym](http://www.tug.org/interviews/berry.html)). Můžeme si všimnout, že se to nazývá K**problém s cestami**sea a ne K**souboru**sea, protože, jak [dokumentace](http://tug.org/texinfohtml/kpathsea.html) poznamenává, je to knihovna pro vyhledávání \*cest\*. Je důležité si uvědomit, že Kpathsea nepoužívají jen enginy TeXu; různé programy související s TeXem, včetně BibTeXu a MetaPostu, také používají Kpathsea k hledání vstupních souborů. Stručně řečeno, kdykoli makra TeXu/LaTeXu potřebují otevřít určitý soubor, příkazy, z nichž jsou tato makra sestavena, budou nakonec převedeny na nízkoúrovňové instrukce TeXu (primitive TeXu), které enginy TeXu skutečně vykonávají. Pokud tyto instrukce zahrnují potřebu otevřít soubor, engine TeXu zavolá na Kpathsea s tím, v podstatě: „prosím, najdi tento soubor“; pokud je toto vyhledávání Kpathsea úspěšné, soubor se otevře. Pokud však Kpathsea soubor nenajde, engine TeXu bude o tom informován a zastaví provádění, aby vydal nechvalně známou chybu ``! Soubor `...` nelze najít`` Pravda je, že Kpathsea ho nemůže najít. ### Poznámky k LuaTeXu Přesně vzato bychom tuto sekci měli doplnit upozorněním, že LuaTeX přece jen nabízí mechanismus, kterým může uživatel poskytnout vlastní kód pro vyhledávání souborů, a to pomocí *callbacků*. LuaTeX umožňuje uživatelům psát funkce v skriptovacím jazyce Lua a registrovat je v LuaTeXu, aby tuto uživatelem definovanou funkci volal v určitých fázích během provádění LuaTeXu — odtud název *callbacků*callback [Referenční příručce LuaTeXu](http://www.pragma-ade.com/general/manuals/luatex.pdf) . Je to velmi mocná technika a zájemce najde více informací v oddílu 9 ### Konfigurační soubor Kpathsea: texmf.cnf Každá instalace TeXu obsahuje textový soubor nazvaný `texmf.cnf` který je konfiguračním souborem používaným Kpathsea: obsahuje řadu „konfiguračních proměnných“, které definují cesty, jež bude Kpathsea používat k vyhledávání různých typů souborů, které enginy TeXu (nebo BibTeX, MetaPost apod.) mohou potřebovat. Jak uvidíme níže, tyto „konfigurační proměnné“ definují vyhledávací cesty sestavené z takzvaných *prvků cesty*: s využitím různých konstrukcí, proměnných a parametrů lze každý prvek cesty definovat jako „šablonu“, kterou Kpathsea zpracuje, aby vygeneroval skutečné, fyzické adresáře, které má prohledat. Abychom uvedli konkrétní příklad, zde je jedna taková konfigurační proměnná, která definuje vyhledávací cesty pro písma OpenType — prozatím se nemusíte zabývat významem této konstrukce cesty: ``` OPENTYPEFONTS = .;$TEXMF/fonts/{opentype,truetype}//;$OSFONTDIR// ``` Důležité je zde jen to, že soubor `texmf.cnf` (čtený Kpathsea) definuje konfigurační proměnnou nazvanou `OPENTYPEFONTS` která se používá k definování cesty (cest), jež bude Kpathsea používat k vyhledávání písem OpenType. Pravá strana znaku „=“ nevypadá jako žádná cesta, kterou byste viděli na typickém zařízení, protože je sestavena s použitím různých proměnných a parametrů, které definují každou cestu jako „šablonu“ nebo „náčrt“, který Kpathsea použije k vygenerování skutečných adresářů k prohledání. ### Kpathsea a jeho pojetí „cesty“ Možná je hlavním pojmem, kterému je třeba porozumět, pojetí „cesty“ v Kpathsea: základní konstrukce, kterou Kpathsea používá k určení, kde se určitý soubor nachází. Jak jsme viděli v `OPENTYPEFONTS` výše uvedeném příkladu, pojetí cesty v Kpathsea vypadá velmi odlišně od cest, které jsme zvyklí používat na našich stolních nebo přenosných zařízeních. Abychom citovali z dokumentace Kpathsea, [dokumentace](http://tug.org/texinfohtml/kpathsea.html#Searching-overview): > ... *vyhledávací cesta* je seznam prvků *cesty*oddělených dvojtečkami, které jsou názvy adresářů s několika „extra vylepšeními“. —ale všimněte si, že se k oddělování používá také středník (`;`) *cesty*. Později stručně naznačíme povahu některých z těchto „extra vylepšení“. V našem `OPENTYPEFONTS` příkladu jsou tři prvky cesty, každý oddělený středníkem (`;`): ![Obrázek zobrazující prvky cesty obsažené v definici cesty Kpathsea](/files/1238efeccfcfa2787fb8fc2e6875672964d63597) 1. `.` (což znamená aktuální adresář) 2. `$TEXMF/fonts/{opentype,truetype}//` 3. `$OSFONTDIR//` Všimněte si, že dvojitá lomítka (`//`) v prvku cesty znamenají prohledávat podadresáře (rekurzivně). Typický `texmf.cnf` soubor bude obsahovat řadu „konfiguračních proměnných“, které definují vyhledávací cesty pro typy souborů, které Kpathsea umí vyhledávat. ## Kpathsea: velmi stručný přehled Kpathsea je sofistikovaná knihovna — s mnoha jemnostmi a nuancemi — a i letmý pohled na její [dokumentace](http://tug.org/texinfohtml/kpathsea.html) dokumentaci jasně ukazuje, že se nemůžeme ponořit do všech detailů. Můžeme se však pokusit podat přehled toho, co dělá — abychom pomohli zorientovat vaše myšlení a nabídli výchozí bod pro další čtení. ### Hlavní účel Kpathsea Jak je uvedeno v dokumentaci, základním účelem Kpathsea je „vrátit název souboru ze seznamu adresářů určených uživatelem“ a že tyto adresáře (vyhledávací cesty) jsou určeny s použitím „několika extra vylepšení“. ### Těch „několik extra vylepšení“ Mezi výše zmíněná „několik extra vylepšení“ patří různé parametry a proměnné, které Kpathsea používá ke konstrukci svých vyhledávacích cest (nebo „šablon cest“), aby mohl cesty definovat obecněji. Když engine TeXu skutečně běží (provádí se), Kpathsea může použít aktuální hodnotu těchto parametrů/proměnných k určení skutečných cest tak, že tyto proměnné nahradí jejich skutečnými (za běhu) hodnotami. Tyto proměnné (uvnitř prvků cesty) snadno poznáte, protože začínají znakem `$` $ Říkáme tedy, že Kpathsea *rozšiřuje* prvek cesty, což znamená, že proměnné a parametry přemění: z cesty typu „šablona“ vytvoří skutečný název (názvy) jednoho nebo více fyzických adresářů, ve kterých má hledat soubor. To nabízí velkou míru flexibility a znamená, že Kpathsea může pro jeden prvek cesty sestavit seznam adresářů — například pokud je mu řečeno, aby prohledával podadresáře. ### Naše příklad OpenType znovu navštíven Spojíme jednotlivé nitky a podíváme se `OPENTYPEFONTS` trochu podrobněji: ``` OPENTYPEFONTS = .;$TEXMF/fonts/{opentype,truetype}//;$OSFONTDIR// ``` Pojďme se podívat na dva prvky cesty `$TEXMF/fonts/{opentype,truetype}//` a `$OSFONTDIR//`. Zde si Kpathsea všimne použití složených závorek `{...}` a chápe je `$TEXMF/fonts/{opentype,truetype}` jako reprezentující *dva* prvky cesty: 1. `$TEXMF/fonts/opentype//` 2. `$TEXMF/fonts/truetype//` a že *podadresáře* obou těchto prvků cesty mají být také prohledávány (naznačeno koncovým `//`). **Poznámka**: Viz dokumentaci Kpathsea k [rozšíření podadresářů](http://tug.org/texinfohtml/kpathsea.html#Subdirectory-expansion) pro důležitou poznámku o pořadí, v jakém jsou podadresáře na libovolné úrovni prohledávány (není určeno). Uděláme několik poznámek k `$TEXMF` níže. #### $OSFONTDIR// `$OSFONTDIR` je proměnná, jejíž hodnota by měla být definována jako proměnná prostředí obsahující umístění, kde jsou uložena písma: přesná hodnota bude samozřejmě záviset na operačním systému používaném k běhu TeXu. Všimněte si, že zde koncové `//` nařizuje Kpathsea prohledávat podadresáře při hledání písem OpenType. Výchozí definice `OSFONTDIR` uvnitř `texmf.cnf` je: ``` OSFONTDIR = /please/set/osfontdir/in/the/environment ``` Je tedy určitě třeba tuto proměnnou nastavit, pokud ji chcete používat — vaše proměnná prostředí přepíše tuto „zástupnou“ definici obsaženou v `texmf.cnf`. Pokud proměnnou prostředí `OSFONTDIR` nastavíte, pak za běhu může Kpathsea všude, kde uvidí `$OSFONTDIR` jako součást prvku cesty (v `texmf.cnf`) nahradit proměnnou `$OSFONTDIR` skutečnou hodnotou uloženou v proměnné prostředí `OSFONTDIR`. Pamatujte, že při použití uvnitř `texmf.cnf` prvků cesty uvádíme proměnnou `$OSFONTDIR`—s úvodním `$`—abychom Kpathsea řekli, že jde o proměnnou, jejíž *hodnota* potřebuje použít. #### Krátké poznámky k $TEXMF `TEXMF` je další konfigurační proměnná, která je definována v `texmf.cnf`; například v hlavní distribuci TeX Live byste viděli: ``` TEXMF = {$TEXMFAUXTREES$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,!!$TEXMFLOCAL,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFDIST} ``` Nemusíte se zabývat podrobnostmi této definice `TEXMF`—nebudeme probírat všechny detaily, ale jen si všimněte, že tato `$TEXMF` proměnná se používá uvnitř prvků cesty, protože definuje řadu složek nejvyšší úrovně (označovaných jako „texmf stromy“), od kterých můžete začít hledání souborů. `TEXMF` je nesmírně užitečná, pokud chcete nebo potřebujete rozdělit instalaci TeXu napříč více adresáři (nebo adresářovými „stromy“). Například mít hlavní nebo centrální kolekci balíčků TeXu/LaTeXu (např. TeX Live) a další kolekci souborů a složek používanou k ukládání místních balíčků LaTeXu — nebo třeba k ukládání místních konfiguračních souborů či upravených verzí standardních balíčků. Rozdělení instalace TeXu tímto způsobem může usnadnit správu aktualizací hlavní/centrální kolekce (distribuce) balíčků TeXu/LaTeXu, protože vaše místní kolekce je oddělena od hlavních souborů, které se aktualizují při aktualizaci vaší distribuce/instalace TeX Live. Pro další podrobnosti o správě složitějších instalací TeXu je zájemce odkázán na tyto dva články: * [Správa více stromů TDS](http://tug.org/TUGboat/Articles/tb22-3/tb72downes.pdf) od Michaela J. Downese; * [Žonglování s texmf stromy](http://www.ntg.nl/maps/27/17.pdf) od Siepa Kroonenberga. #### Struktura adresářů TeXu Každý, kdo spravoval instalaci TeXu, ví, že moderní systémy TeXu, jako je TeX Live, obsahují desítky tisíc souborů zahrnujících obrovské množství typů souborů. Struktura adresářů TeXu (TDS) byla navržena jako osvědčený „návrh“ pro organizaci rozsáhlé sbírky souborů ve fungující instalaci TeXu a pro použití s Kpathsea je důrazně doporučována. Pro další informace je čtenář odkázán na specifikaci TDS: [A Directory Structure for TeX Files](https://www.tug.org/tds/tds.pdf). ## Typy souborů Kpathsea Sada aplikací, které používají Kpathsea, potřebuje přístup k široké škále typů souborů, takže Kpathsea používá „konfigurační proměnnou“ k identifikaci cesty (cest) pro každý typ souboru (nebo skupinu souborů), který podporuje. Online dokumentace má úplný seznam (viz také naše [souhrnná tabulka níže](#table-listing-kpathsea-config-variables)) ale zde jsou „konfigurační proměnné“ pro běžnější typy souborů: | | | | ------------------------- | -------------------------------------------------- | | **Konfigurační proměnná** | **Příklady typů souborů** | | TEXINPUTS | zdrojové soubory TeXu a soubory s obrázky/grafikou | | BIBINPUTS, BSTINPUTS | zdrojové soubory bibliografie BibTeXu | | TTFONTS | obrysová písma TrueType | | OPENTYPEFONTS | obrysová písma OpenType | `TEXINPUTS` je zvlášť důležitá konfigurační proměnná, protože určuje, odkud engine TeXu získává své vstupní zdrojové soubory. Všimněte si, že soubory s obrázky jsou považovány za vstupní soubory a lze je také vyhledávat pomocí cesty definované proměnnou `TEXINPUTS`. ### Některé nuance Kpathsea Jak bylo poznamenáno, Kpathsea má mnoho nuancí, které zde nemůžeme podrobně prozkoumat. Zde jsou však funkce, které si někteří čtenáři mohou přát prozkoumat: * **databáze názvů souborů:** Aby se minimalizovalo prohledávání disku, může Kpathsea využít „externě vytvořený [soubor databáze názvů souborů s názvem ls-R](http://tug.org/texinfohtml/kpathsea.html#Filename-database) který mapuje soubory na adresáře“. TeX Live poskytuje vlastní a nástroje pro jeho aktualizaci, pokud se přidají nové soubory. * **proměnné prostředí**: Kromě „konfiguračních proměnných“ (jako `OPENTYPEFONTS`) Kpathsea také chytře využívá [proměnné prostředí](https://en.wikipedia.org/wiki/Environment_variable); například lze hodnotu proměnných prostředí za běhu použít k definování prvků cesty v `texmf.cnf` souboru (případně k přepsání proměnných stejného jména, které jsou definovány v `texmf.cnf`). * **název programu:** Jemným, ale zásadním aspektem chování Kpathsea je, že může využít název spustitelného programu (např. enginu TeXu) ke konstrukci vyhledávacích cest specifických pro daný program. To poskytuje značnou flexibilitu, protože vyhledávání cest lze směrovat na soubory pro konkrétní engine TeXu. Například pro LuaTeX/LuaLaTeX: ``` TEXINPUTS.lualatex = .;$TEXMF/tex/{lualatex,latex,luatex,generic,}// TEXINPUTS.luatex = .;$TEXMF/tex/{luatex,plain,generic,}// ``` * **hledání `texmf.cnf`**: Možná se ptáte, jak Kpathsea ví, kde `texmf.cnf` se ukládá? Odpovědí je proměnná prostředí nazvaná `TEXMFCNF`. Ta musí být nastavena (na zařízení/platformě, kde běží TeX) na cestu, kde `texmf.cnf` je uložen. #### Ladění problémů Kpathsea Uživatelé Overleafu pravděpodobně nebudou tyto možnosti potřebovat, ale uvádíme je pro úplnost: * **kpsewhich**: Samostatný program (součást TeX Live), který lze použít k otestování vašeho nastavení: určení hodnot proměnných a hledání souborů. Zájemce je odkázán na [online dokumentaci](http://tug.org/texinfohtml/kpathsea.html#Invoking-kpsewhich) pro další informace. * **proměnné prostředí**: Kpathsea podporuje proměnnou prostředí nazvanou [`KPATHSEA_DEBUG`](http://www.tug.org/texinfohtml/kpathsea.html#Debugging) pro pomoc s laděním svého chování. Můžete nastavit `KPATHSEA_DEBUG` na různé hodnoty podle toho, kolik ladicích informací potřebujete. Nastavení `KPATHSEA_DEBUG=-1` vygeneruje *značné* množství dat. ## A nakonec: složky, soubory s obrázky a latexmkrc Jak to tedy souvisí s latexmkrc? Pokud si přečtete tento článek [Jak používat latexmkrc v Overleafu: příklady a techniky](/latex/cs/clanky-do-hloubky/28-how-to-use-latexmkrc-with-overleaf.md) můžete vidět, že (Perl) kód v příkladu s latexmkrc nastavuje hodnotu proměnné prostředí `TEXINPUTS`: ``` $ENV{'TEXINPUTS'}='./tex//:' . $ENV{'TEXINPUTS'}; ``` Všimněte si, že dvojtečka (:) použitá zde (`./tex//**:**`) *mimořádně* je důležitá. Pokud tuto dvojtečku vynecháte, TeX/LaTeX nemusí být schopen najít důležité systémové soubory, jako jsou balíčky LaTeXu! To, co tento soubor latexmkrc ve skutečnosti dělá, je přidání cesty ke složce nejvyšší úrovně (`./tex` v příkladu výše) do systémově definované `TEXINPUTS` proměnné prostředí, takže když Kpathsea používá proměnnou `$TEXINPUTS` bude pak vědět, že složka `/tex//` má být prohledávána kvůli nalezení vstupních souborů. Když se podíváte pozorně, uvidíte, že skutečná použitá cesta je `./tex//:` webových stránkách `//` říká Kpathsea, aby prohledávalo složku tex rekurzivně — tedy aby se podívalo do všech podsložek obsažených ve složce `tex` složce. Jak bylo uvedeno, přidali jsme také důležitý znak dvojtečky. Úplně stejnou techniku můžeme použít pro soubory s obrázky. ### Poznámka k BibTeXu Jak bylo uvedeno, program BibTeX také používá Kpathsea k vyhledávání svých vstupních souborů; konkrétně: * webových stránkách `BSTINPUTS` konfigurační proměnná (vyhledávací cesta) se používá k vyhledávání `.bst` souborů; * a `BIBINPUTS` konfigurační proměnná (vyhledávací cesta) se bude používat k vyhledávání `.bib` soubory. Pokud přidáte nové `.bst` nebo `.bib` soubory do projektu Overleaf, můžete pomocí níže uvedené techniky instruovat BibTeX, kde tyto soubory najde — musíte nahradit `TEXINPUTS` s `BSTINPUTS` a/nebo `BIBINPUTS`. ### TEXINPUTS a používání vnořených složek pro soubory s grafikou Pokud váš projekt obsahuje mnoho souborů s grafikou, může být praktické vytvořit sadu složek, ve kterých je budete ukládat a spravovat. Následující snímek například ukazuje část projektu Overleaf, který používá složku nejvyšší úrovně nazvanou **`graphics`**: ![Obrázek zobrazující vnořené složky v projektu Overleaf](/files/c17ad0420cc185b16d51ae4a86ec6af4e38970e6) Existuje mnoho (vnořených) podsložek obsahujících grafiku pro různé části našeho dokumentu. Předpokládejme, že máme výše uvedenou strukturu složek a chceme použít `graphicx` balíček (`\usepackage{graphicx}`) a pokusíme se to udělat takto: ```latex \documentclass{article} \usepackage{graphicx} \begin{document} \includegraphics{endlinechar}% osvědčeným postupem je nepoužívat příponu souboru \end{document} ``` Nebude to fungovat a dostanete chybu jako tato: ``` ! Chyba LaTeXu: Soubor `endlinechar' nebyl nalezen. l.4 \includegraphics{endlinechar} Nepodařilo se mi najít soubor s žádnou z těchto přípon: .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 ``` Tato chyba vzniká proto, že náš soubor s grafikou je uložen v umístění, o kterém TeX/LaTeX (a Kpathsea) nevědí, a tudíž jej nemohou najít — cesta k souboru s grafikou je: ``` ./graphics/Introduction/Chapter1/Section1/Subsection3/endlinechar.png ``` **Poznámka**: Obecně je uznávaným osvědčeným postupem ***vyhýbat se mezerám v názvech složek***. Ačkoli je jistě možné mít v názvech složek mezery a použít níže popsané techniky, nedoporučovali bychom to kvůli přenositelnosti dokumentu mimo platformu Overleaf. Jak je vysvětleno v tomto [článku nápovědy Overleafu](/latex/cs/dalsi-temata/27-inserting-images.md) můžete samozřejmě použít složky k ukládání své grafiky, ale musíte LaTeXu říci, kde jsou uloženy. Zde se podíváme na dvě řešení: * Použití příkazu \graphicspath; * Využití našich znalostí o Kpathsea a `TEXINPUTS`. ### Použití \graphicspath Ta `graphicx` balíček poskytuje `\graphicspath` příkaz, kterým můžete deklarovat cesty, kde se vaše grafika nachází; mohli bychom tedy udělat něco takového: ```latex \graphicspath{{./graphics/Introduction/Chapter1/Section1/Subsection3/}} ``` a LaTeX nyní najde jakoukoli grafiku uloženou pod touto cestou. **Poznámka**: Pokud *musí* máte v názvech složek mezery, budete muset cesty uzavřít do uvozovek (`"..."`): ```latex \graphicspath{{"./graphics/Introduction/Chapter 1/Section 1/Subsection 3/"}} ``` **Poznámka**: Můžete deklarovat více cest takto: ```latex \graphicspath{{path1}{path2}{path3}...{pathN}} ``` kde `...` znamená další cesty uzavřené do složených závorek. **Poznámka**: Cestu začínáme `./graphics` a ne jen `/graphics`. Tečka (.) říká operačnímu systému, že cesta je relativní vůči aktuálnímu pracovnímu adresáři. Ta `\graphicspath` příkaz funguje dobře, ale pokud máte mnoho složek, může být docela únavné přidávat každou cestu; navíc cesty definované pomocí `\graphicspath` by už nefungovaly, pokud byste složky přejmenovali nebo je přeorganizovali. Existuje snadnější způsob? Ano, můžete použít soubor latexmkrc! #### \graphicspath a rekurze (podadresáře) Všimněte si, že na internetu probíhají diskuse/spory o tom, zda některé systémy podporují/povolují `\graphicspath` pro rekurzivní prohledávání podadresářů, pokud na konec cesty přidáte `//` : viz například tyto diskuse na tex.stackexchange: * [Rekurzivní vyhledávání \graphicspath v LaTeXu](https://tex.stackexchange.com/questions/25443/latex-graphicspath-recursive-search); * [Graphicspath pro MikTeX](https://tex.stackexchange.com/questions/3131/graphicspath-for-miktex). Pro co největší kompatibilitu byste měli předpokládat, že `\graphicspath` nepodporuje rekurzivní prohledávání adresářů. ### Kpathsea a TEXINPUTS (soubor latexmkrc na pomoc) **UPOZORNĚNÍ:** Všimněte si, že následující technika funguje dobře v Overleafu a ve správně nakonfigurovaných místních instalacích TeXu; **ale** pokud použijete soubor latexmkrc, může se váš projekt stát nekompatibilním s jinými instalacemi TeXu, jako jsou ty používané vydavateli a online systémy pro odevzdávání článků do časopisů. Instalace TeXu třetích stran mohou, ale nemusí, podporovat nebo povolovat použití latexmkrc. Pokud potřebujete exportovat svůj projekt Overleaf pro použití jinde, nebo jej chcete odeslat do časopisu, měli byste z názvů cest odstranit všechny mezery a pro lepší kompatibilitu přidat `\graphicspath` příkaz, který definuje všechny cesty: ```latex \graphicspath{{path1}{path2}{path3}...{pathN}} ``` kde `...` znamená další cesty uzavřené do složených závorek. Technika popsaná níže (s použitím `TEXINPUTS`) byla úspěšně otestována v Overleafu s enginy pdfTeX, XeTeX a LuaTeX (tj. s možnostmi kompilátoru pdfLaTeX, XeLaTeX a LuaLaTeX v nabídce Overleafu): ![Obrázek ukazující, jak zvolit kompilátor LaTeXu v Overleafu](/files/107283dcea2fbad1ec1c0d064a6c0b5c504a74f9) Vrátíme-li se k našemu příkladu, chceme použít tento kód (s hluboce vnořenými složkami) a k jeho dosažení použijeme soubor latexmkrc: ```latex \documentclass{article} \usepackage{graphicx} \begin{document} \includegraphics{endlinechar}% osvědčeným postupem je nepoužívat příponu souboru \end{document} ``` Zde je snímek obrazovky ukazující, že výše uvedený kód funguje bez problémů: LaTeX našel náš soubor s grafikou (`endlinechar.png`) přesto, že je v hluboce vnořené struktuře složek (bez jakýchkoli mezer v názvech složek). ![Obrázek zobrazující projekt s vnořenými složkami kompilovaný v Overleafu](/files/7870a384165782810f36f2c33b76242129e15b00) Tak jak jsme to udělali? Stačí: * vytvořit nový soubor bez přípony a pojmenovat ho latexmkrc; * přidat do tohoto souboru následující řádek: ``` $ENV{'TEXINPUTS'}='./graphics//:'.$ENV{'TEXINPUTS'}; ``` Kpathsea nyní bude znát složky obsažené pod `**graphics**` a protože obsahuje `//` tak bude nahlížet i do podsložek. Všimněte si znovu, že dvojtečka v `./graphics//:` je ve skutečnosti *mimořádně* je důležitá. Pokud tuto dvojtečku vynecháte, TeX/LaTeX nemusí být schopen najít důležité systémové soubory, jako jsou balíčky LaTeXu! Pomocí jednoduchého příkladu projektu výše jej nyní můžete zkompilovat a je to! LaTeX najde váš grafický soubor — a můžete přejmenovat nebo reorganizovat složky pod /graphics, aniž by to LaTeXu zabránilo je najít. ## Tabulka uvádějící „konfigurační proměnné“ Kpathsea Následující tabulka je souhrn odvozený z [dat uvedených v dokumentaci Kpathsea](http://tug.org/texinfohtml/kpathsea.html#Supported-file-formats). | | | | | --------------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------ | | **Konfigurační proměnná Kpathsea** | **Popis typu souboru** | **Přípona souboru** | | AFMFONTS | metriky písem Adobe | .afm | | MFBASES, TEXMFINI | výpis paměti Metafontu | .base | | BIBINPUTS, TEXBIB | zdroj bibliografie BibTeXu | .bib | | BLTXMLINPUTS | soubory bibliografie BibLaTeXML pro Biber | .bltxml | | BSTINPUTS | styl BibTeXu | .bst | | CLUAINPUTS | dynamické knihovny pro Lua | .dll a .so | | CMAPFONTS | soubory map znaků | .cmap | | TEXMFCNF | Konfigurační soubory za běhu | .cnf | | CWEBINPUTS | Vstupní soubory CWEB | .w, .web, .ch | | TEXCONFIG | Soubory 'config.\*' pro Dvips, například config.ps | | | ENCFONTS | kódovací vektory | .enc | | TEXFORMATS, TEXMFINI | výpis paměti TeXu | .fmt | | FONTCIDMAPS | mapování CJK | .cid | | FONTFEATURES | především pro vlastnosti písem OpenType | .fea | | FONTS, GFFONTS, GLYPHFONTS, TEXFONTS | obecná bitmapa písma | .gf | | TEXPICTS, TEXINPUTS | obrázky v Encapsulated PostScript | .eps, .epsi | | TEXINDEXSTYLE, INDEXSTYLE | stylové soubory makeindexu | .ist | | LIGFONTS | soubory definic ligatur | .lig | | TEXMFDBS | Databáze názvů souborů | | | TEXFONTMAPS | mapy písem | .map | | MPMEMS, TEXMFINI | výpis paměti MetaPostu | .mem | | MPSUPPORT | Podpůrné soubory MetaPostu, používané DMP | | | MFINPUTS | zdroj Metafontu | .mf | | MFPOOL, TEXMFINI | programové řetězce Metafontu | .pool | | MFTINPUTS | stylový soubor MFT | .mft | | MISCFONTS | soubory související s písmy, které nespadají do ostatních kategorií | | | MLBIBINPUTS, BIBINPUTS, TEXBIB | zdroj bibliografie MlBibTeXu | .mlbib, .mlbib | | MLBSTINPUTS, BSTINPUTS | styl MlBibTeXu | .mlbst, .bst | | MPINPUTS | zdroj MetaPostu | .mp | | MPPOOL, TEXMFINI | programové řetězce MetaPostu | .pool | | OCPINPUTS | zkompilované procesní soubory Omega | .ocp | | OFMFONTS, TEXFONTS | metriky písem Omega | .ofm, .tfm | | OPENTYPEFONTS | písma OpenType | | | OPLFONTS, TEXFONTS | seznamy vlastností Omega | .opl | | OTPINPUTS | soubory překladového procesu Omega | .otp | | OVFFONTS, TEXFONTS | virtuální písma Omega | .ovf | | OVPFONTS, TEXFONTS | virtuální seznamy vlastností Omega | .ovp | | PDFTEXCONFIG | konfigurační soubory specifické pro PDFTeX | | | PROGRAMFONTS, PKFONTS, TEXPKS, GLYPHFONTS, TEXFONTS | zabalená bitmapová písma | .pk | | TEXPSHEADERS, PSHEADERS | stahovatelný PostScript | .pro | | RISINPUTS | soubory bibliografie RIS, především pro Bibe | .ris | | SFDFONTS | soubory definic podpísem | .sfd | | TEXINPUTS | zdroj TeXu | .tex | | TEXDOCS | dokumentační soubory pro systém TeX | | | TEXSOURCES | zdrojové soubory pro systém TeX | | | TEXMFSCRIPTS | Spustitelné soubory nezávislé na architektuře distribuované ve stromech texmf | | | TEXPOOL, TEXMFINI | řetězce programu TeX | .pool | | TFMFONTS, TEXFONTS | metriky písem TeX | .tfm | | TRFONTS | písma Troff | | | TTFONTS | obrysová písma TrueType | .ttf, ,TTF, .ttc, .TTC, .dfont | | T1FONTS, T1INPUTS, TEXPSHEADERS, DVIPSHEADERS | obrysová písma PostScript typu 1 | .pfa, .pfb | | T42FONTS | obrysová písma PostScript typu 42 | | | VFFONTS, TEXFONTS | virtuální fonty | .vf | | WEBINPUTS | vstupní soubory WEB | .web, .ch | | WEB2C | soubory specifické pro implementaci 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/cs/clanky-do-hloubky/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.