> 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/sv/fordjupade-artiklar/06-an-introduction-to-kpathsea-and-how-tex-engines-search-for-files.md). # En introduktion till Kpathsea och hur TeX-motorer söker efter filer ## Introduktion Den här artikeln ger en introduktion till hur TeX-motorer hittar de filer som behövs för att sätta ditt dokument—med LaTeX eller något annat makropaket. Även om Overleaf befriar användare från utmaningarna med att hantera en TeX-installation ([TeX Live](https://www.tug.org/texlive/)), grunderna för hur TeX-motorer söker efter filer kommer att vara till nytta/av intresse om du vill skapa en mappstruktur för att hjälpa dig att hantera ditt Overleaf-projekt. Varför kan det vara så? Om du lagrar några av dina Overleaf-projektfiler i mappar kan LaTeX kanske inte hitta de filerna eftersom TeX-motorn (kompilatorn) som standard kanske inte *vet* att den behöver söka i dessa mappar—och därmed inte hittar filerna de innehåller. För att undvika detta kan du skapa och lägga till i ditt projekt en konfigurationsfil som kallas en [latexmkrc-fil](https://mg.readthedocs.io/latexmk.html#configuration-files) som kan användas för att tala om för en TeX-motor att dina mappar finns och att den ska söka i dem. Om du vill hoppa direkt till ett exempel som visar en latexmkrc-fil kan du läsa den här hjälpartikeln: [Hur man använder latexmkrc med Overleaf: exempel och tekniker](/latex/sv/fordjupade-artiklar/28-how-to-use-latexmkrc-with-overleaf.md). Det kanske inte är helt uppenbart hur, eller varför, den latexmkrc-filen faktiskt fungerar. Om du vill veta varför och kanske utveckla en bättre förståelse för användning med ytterligare konfigurationsmöjligheter för ditt projekt, så läs vidare... I slutet av den här artikeln går vi igenom ett [praktiskt exempel](#kpathsea-and-texinputs-latexmkrc-file-to-the-rescue)—med vår kunskap om hur TeX söker efter filer—för att skapa en latexmkrc-fil för att hantera nästlade mappar som innehåller dina grafikfiler. ## TeX och plattformsoberoende När Knuth skapade TeX var plattformsoberoende en central princip som styrde dess design och implementering och den filosofin återspeglas i hela TeX:s interna funktioner (t.ex. användning av heltalsaritmetik, ”hemmagjord” stränghantering, minneshantering osv.). Än i dag väcker plattformsoberoendet hos moderna TeX-baserade motorer frågor och debatt på offentliga forum; se till exempel denna diskussion på tex.stackexchange: [Är XeTeX och LuaTeX plattformsberoende?](https://tex.stackexchange.com/questions/94297/are-xetex-and-luatex-platform-dependent) som innehåller kommentarer och iakttagelser från flera välkända TeX-experter. Men låt oss tills vidare lägga detaljerna åt sidan och notera att TeX-motorer fortfarande behöver vara mycket portabla—kunna fungera på flera operativsystem och ge ”identiska” resultat. En nyckelaspekt av portabilitet är att söka efter filer på ett plattformsoberoende sätt. ## TeX-motorer söker inte efter filer… verkligen!? Nej, TeX-motorer *direkt* söker inte efter filer *själva*. När de bearbetar en `.tex` fil kan en TeX-motor identifiera behovet av att öppna en viss fil men den *delegerar* uppgiften att hitta den till en annan mjukvarukomponent som kallas [*Kpathsea*](https://tug.org/kpathsea/): ett externt mjukvarubibliotek som inte ingår i *kärnans* källkod för TeX-motorer. Det Kpathsea tillhandahåller är i praktiken ett API ([Application Programming Interface](https://en.wikipedia.org/wiki/Application_programming_interface)) som TeX-motorer (plus BibTeX, MetaPost och andra program) kan anropa när de behöver öppna en viss fil: Kpathsea gör det faktiska arbetet med att lokalisera den filen. När Knuth skrev den ursprungliga TeX-motorn—som alla andra TeX-motorer i slutändan härstammar från—var problemet med att hitta/öppna filer en betydande utmaning på grund av, delvis, det mycket disparata teknikekosystemet vid den tiden. Faktum är att Knuth i TeX:s källkod hänvisar till filinmatning/utmatning som ”portabilitetens gissel” (se sida 12, avsnitt 25 i [TeX: The Program](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373)). TeX-communityt insåg behovet av att harmonisera (standardisera) filsökning för TeX—*och TeX-relaterad programvara*—och beslutade att förse TeX med verktygen för att göra det. För att tackla det mycket svåra problemet med en plattformsoberoende metod för att hitta filer skrev Karl Berry, en ledande medlem av TeX-communityt, programvaran för att lösa *sökvägs*-sökningsproblemet: en lösning han kallade [**Kpathsea**](http://tug.org/texinfohtml/kpathsea.html)—vilket är härlett från **K**Karls **Path** **Sea**rching (se denna [intervju med Karl Berry](http://www.tug.org/interviews/berry.html)). Vi kan notera att det kallas K**sökvägs**sea och inte K**fil**sea eftersom, som [dokumentationen](http://tug.org/texinfohtml/kpathsea.html) antecknar, är det ett bibliotek för \*sökvägssökning\*. Det är viktigt att inse att Kpathsea inte bara används av TeX-motorer; olika TeX-relaterade program, inklusive BibTeX och MetaPost, använder också Kpathsea för att söka efter indatafiler. I stora drag gäller att när TeX/LaTeX-makron behöver öppna en viss fil kommer kommandona som dessa makron bygger på så småningom att omvandlas till lågnivåinstruktioner i TeX (TeX-primitiver) som TeX-motorerna faktiskt kör. Om dessa instruktioner inkluderar behovet av att öppna en fil, anropar TeX-motorn Kpathsea och säger i praktiken ”hitta den här filen åt mig”; om den Kpathsea-sökningen lyckas öppnas filen. Men om Kpathsea inte kan lokalisera filen kommer TeX-motorn att informeras om det och stoppa körningen för att ge det ökända felet ``! Jag kan inte hitta filen `...'`` Sanningen är att Kpathsea inte kan hitta den. ### Anteckningar om LuaTeX Strängt taget bör vi förse detta avsnitt med en brasklapp genom att notera att LuaTeX faktiskt erbjuder en mekanism för användaren att tillhandahålla egen kod för filsökning genom att använda *återanrop*. LuaTeX gör det möjligt för användare att skriva funktioner i skriptspråket Lua och registrera dem hos LuaTeX så att det anropar den användardefinierade funktionen vid vissa steg under LuaTeX:s körning—därav termen *återanrop*. Det är en mycket kraftfull teknik och den intresserade läsaren kan hitta mer information i avsnitt 9 av [LuaTeX Reference Manual](http://www.pragma-ade.com/general/manuals/luatex.pdf) (vid tidpunkten för skrivandet är den länken för LuaTeX 1.09). ### Kpathsea-konfigurationsfilen: texmf.cnf Varje TeX-installation innehåller en textfil som heter `texmf.cnf` som är en konfigurationsfil som används av Kpathsea: den innehåller många ”konfigurationsvariabler” som definierar de sökvägar som Kpathsea kommer att använda för att söka efter olika typer av filer som TeX-motorer (eller BibTeX, MetaPost osv.) kan behöva. Som vi ser nedan definierar dessa ”konfigurationsvariabler” sökvägar som är uppbyggda av så kallade *sökvägselement*: med hjälp av olika konstruktioner, variabler och parametrar för att definiera varje sökvägselement som en ”mall” som Kpathsea bearbetar för att generera de faktiska, fysiska kataloger som ska sökas. Låt oss ge ett konkret exempel: här är en sådan konfigurationsvariabel som definierar sökvägarna för OpenType-teckensnitt—oroa dig inte för tillfället för betydelsen av hur den här sökvägen är konstruerad: ``` OPENTYPEFONTS = .;$TEXMF/fonts/{opentype,truetype}//;$OSFONTDIR// ``` Allt som är viktigt här är att filen `texmf.cnf` (läst av Kpathsea) definierar en konfigurationsvariabel som heter `OPENTYPEFONTS` som används för att definiera den/de sökväg(ar) som Kpathsea kommer att använda för att söka efter OpenType-teckensnitt. Högersidan av ”=” ser inte ut som någon sökväg du ser på en typisk enhet eftersom den är konstruerad med hjälp av olika variabler och parametrar för att definiera varje sökväg som en ”mall” eller ”ritning” som Kpathsea använder för att generera verkliga kataloger att söka i. ### Kpathseas uppfattning om en ”sökväg” Kanske är det centrala begreppet att förstå Kpathseas uppfattning om en ”sökväg”: den grundläggande konstruktion som Kpathsea använder för att räkna ut var en viss fil finns. Som vi såg i `OPENTYPEFONTS` exemplet ovan ser Kpathseas uppfattning om en sökväg väldigt annorlunda ut än de sökvägar vi är vana att använda på våra stationära eller bärbara enheter. För att citera från Kpathseas [dokumentationen](http://tug.org/texinfohtml/kpathsea.html#Searching-overview): > ... en *sökväg* är en kolonseparerad lista med *sökvägselement*, som är katalognamn med några få ”extra finesser”. —men notera att ett semikolon (`;`) också används för att avgränsa *sökvägselement*. Senare kommer vi kort att ange karaktären hos några av dessa ”extra finesser”. I vårt `OPENTYPEFONTS` exempel finns det tre sökvägselement, var och ett avgränsat med semikolon (`;`): ![Bild som visar de sökvägselement som finns i en Kpathsea-sökvägsdefinition](/files/6ca0d2dbaca9407f326379486ca520ae36b6d79c) 1. `.` (vilket betyder den aktuella katalogen) 2. `$TEXMF/fonts/{opentype,truetype}//` 3. `$OSFONTDIR//` Observera att ett dubbelt snedstreck (`//`) i ett sökvägselement betyder att underkataloger ska sökas igenom (rekursivt). En typisk `texmf.cnf` fil kommer att innehålla många ”konfigurationsvariabler” för att definiera sökvägarna för de filtyper som Kpathsea kan söka efter. ## Kpathsea: En mycket kort översikt Kpathsea är ett sofistikerat bibliotek—med många finesser och nyanser—och bara en snabb blick på dess [dokumentationen](http://tug.org/texinfohtml/kpathsea.html) gör det tydligt att vi inte kan gå in på alla detaljer. Men vi kan försöka ge en översikt över vad det gör—för att hjälpa dig att orientera ditt tänkande och erbjuda en utgångspunkt för vidare läsning. ### Kpathseas kärnsyfte Som dokumentationen påpekar är Kpathseas grundläggande syfte ”att returnera ett filnamn från en lista över kataloger som angetts av användaren” och att dessa kataloger (sökvägar) anges med hjälp av ”några extra finesser”. ### Dessa ”extra finesser” De ”några extra finesser” som nämns ovan omfattar olika parametrar och variabler som Kpathsea använder för att konstruera sina sökvägar (eller ”sökvägsmallar”) så att den kan definiera sökvägar på ett mer generellt sätt. När en TeX-motor faktiskt kör (exekveras) kan Kpathsea använda det aktuella värdet på dessa parametrar/variabler för att räkna ut de faktiska sökvägarna genom att ersätta dessa variabler med deras faktiska värden vid körning. Du kan lätt identifiera dessa variabler (i sökvägselement) eftersom de börjar med ett `$` tecken. Så säger vi att Kpathsea *expanderar* ett sökvägselement, vilket betyder att den omvandlar dessa parametrar och variabler: den förvandlar en sökvägs ”mall” till det faktiska namnet på en eller flera fysiska kataloger där man ska leta efter en fil. Detta ger stor flexibilitet och innebär att Kpathsea kan konstruera en lista över kataloger som motsvarar ett enskilt sökvägselement—till exempel om den instrueras att söka i underkataloger. ### Vårt OpenType-exempel på nytt Vi sammanför de olika trådarna och utforskar `OPENTYPEFONTS` det lite mer i detalj: ``` OPENTYPEFONTS = .;$TEXMF/fonts/{opentype,truetype}//;$OSFONTDIR// ``` Låt oss betrakta de två sökvägselementen `$TEXMF/fonts/{opentype,truetype}//` och `$OSFONTDIR//`. Här lägger Kpathsea märke till användningen av klammerparenteser `{...}` och behandlar `$TEXMF/fonts/{opentype,truetype}` som representerande *två* sökvägselement: 1. `$TEXMF/fonts/opentype//` 2. `$TEXMF/fonts/truetype//` och att *underkatalogerna* i båda dessa sökvägselement också ska genomsökas (angivet av det avslutande `//`). **Obs**: Se Kpathsea-dokumentationen om [utvidgning av underkataloger](http://tug.org/texinfohtml/kpathsea.html#Subdirectory-expansion) för en viktig brasklapp om i vilken ordning underkataloger på alla nivåer söks igenom (den är inte specificerad). Vi gör några iakttagelser om `$TEXMF` nedan. #### $OSFONTDIR// `$OSFONTDIR` är en variabel vars värde bör definieras som en miljövariabel som innehåller platsen där teckensnitt lagras: det exakta värdet beror förstås på vilket operativsystem som används för att köra TeX. Observera att det avslutande `//` instruerar Kpathsea att söka i underkataloger när den letar efter OpenType-teckensnitt. Standarddefinitionen av `OSFONTDIR` inom `texmf.cnf` är: ``` OSFONTDIR = /please/set/osfontdir/in/the/environment ``` Så det är verkligen något du behöver ställa in om du vill använda det—din miljövariabel kommer att åsidosätta denna ”platshållar”-definition som finns i `texmf.cnf`. Om du ställer in miljövariabeln `OSFONTDIR` så kommer Kpathsea vid körning, där det ser `$OSFONTDIR` som en del av ett sökvägselement (i `texmf.cnf`) att kunna ersätta variabeln `$OSFONTDIR` med det faktiska värde som lagras i miljövariabeln `OSFONTDIR`. Kom ihåg att när du använder den inom `texmf.cnf` sökvägselement anger vi variabeln `$OSFONTDIR`—med ett inledande `$`—för att tala om för Kpathsea att detta är en variabel vars *värde* den behöver använda. #### Kort om $TEXMF `TEXMF` är en annan konfigurationsvariabel som definieras i `texmf.cnf`; till exempel skulle du i den överordnade TeX Live-distributionen se: ``` TEXMF = {$TEXMFAUXTREES$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,!!$TEXMFLOCAL,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFDIST} ``` Du behöver inte bekymra dig om detaljerna i denna definition av `TEXMF`—vi kommer inte att gå igenom alla detaljer, utan bara notera att `$TEXMF` variabeln används inom sökvägselement eftersom den definierar en serie mappar på toppnivå (kallade ”texmf-träd”) där du kan börja sökningen efter filer. `TEXMF` är extremt användbart om du vill, eller behöver, dela upp en TeX-installation över flera kataloger (eller katalog”träd”). Till exempel kan du ha en huvudsamling eller överordnad samling av TeX/LaTeX-paket (t.ex. TeX Live) och en annan samling av filer och mappar som används för att lagra lokala LaTeX-paket—eller kanske för att lagra lokala konfigurationsfiler eller anpassade versioner av standardpaket. Att dela upp TeX-installationen på detta sätt kan göra det lättare att hantera uppgraderingen av huvud-/överordnade samlingen (distributionen) av TeX/LaTeX-paket, eftersom din lokala samling är åtskild från huvudfilerna som uppdateras när du uppgraderar din TeX Live-distribution/installering. För ytterligare detaljer om att hantera mer komplexa TeX-installationer hänvisas den intresserade läsaren till dessa två artiklar: * [Hantera flera TDS-träd](http://tug.org/TUGboat/Articles/tb22-3/tb72downes.pdf) av Michael J Downes; * [Jonglera med texmf-träd](http://www.ntg.nl/maps/27/17.pdf) av Siep Kroonenberg. #### TeX Directory Structure Alla som har hanterat en TeX-installation vet att moderna TeX-system, såsom TeX Live, innehåller många tiotusentals filer som omfattar ett enormt antal filtyper. TeX Directory Structure (TDS) utformades som en ”ritning” för bästa praxis för att organisera den enorma samlingen av filer i en fungerande TeX-installation och rekommenderas starkt för användning med Kpathsea. För ytterligare information hänvisas läsaren till TDS-specifikationen: [En katalogstruktur för TeX-filer](https://www.tug.org/tds/tds.pdf). ## Kpathsea-filtyper Den uppsättning program som använder Kpathsea behöver komma åt ett brett spektrum av filtyper, så Kpathsea använder en ”konfigurationsvariabel” för att identifiera sökvägen/sökvägarna för varje typ av fil (eller grupp av filer) som den stöder. Online-dokumentationen har en fullständig lista (se även vår [sammanfattningstabell nedan](#table-listing-kpathsea-config-variables)) men här är ”konfigurationsvariablerna” för de vanligaste filtyperna: | | | | -------------------------- | ------------------------------------ | | **Konfigurationsvariabel** | **Exempel på filtyper** | | TEXINPUTS | TeX-källfiler och figur-/grafikfiler | | BIBINPUTS, BSTINPUTS | BibTeX-källfiler för bibliografier | | TTFONTS | TrueType-streckteckensnitt | | OPENTYPEFONTS | OpenType-streckteckensnitt | `TEXINPUTS` är en särskilt viktig konfigurationsvariabel eftersom den anger var en TeX-motor hämtar sina indata-källfiler. Observera att bildfiler betraktas som indatafiler och också kan sökas efter med hjälp av sökvägen som definieras av `TEXINPUTS`. ### Några nyanser hos Kpathsea Som nämnt har Kpathsea många nyanser som vi inte kan gå in på här i detalj. Här är dock funktioner som vissa läsare kanske vill utforska: * **filnamnsdatabas:** För att minimera disksökningar kan Kpathsea använda en ”externt byggd [filnamnsdatabasfil som heter ls-R](http://tug.org/texinfohtml/kpathsea.html#Filename-database) som mappar filer till kataloger”. TeX Live tillhandahåller en sådan och verktygen för att uppdatera den om nya filer läggs till. * **miljövariabler**: Förutom ”konfigurationsvariabler” (såsom `OPENTYPEFONTS`) använder Kpathsea också på ett smart sätt [miljövariabler](https://en.wikipedia.org/wiki/Environment_variable); till exempel kan miljövariablers körningsvärde användas för att definiera sökvägselement i `texmf.cnf` filen (eventuellt för att åsidosätta variabler med samma namn som definieras i `texmf.cnf`). * **programnamn:** En subtil men viktig aspekt av Kpathseas beteende är att det kan använda namnet på det körbara programmet (e.g., TeX-motorn) för att konstruera programspecifika sökvägsstrukturer. Detta ger stor flexibilitet eftersom sökvägssökning kan riktas till filer för en viss TeX-motor. Till exempel för LuaTeX/LuaLaTeX: ``` TEXINPUTS.lualatex = .;$TEXMF/tex/{lualatex,latex,luatex,generic,}// TEXINPUTS.luatex = .;$TEXMF/tex/{luatex,plain,generic,}// ``` * **hitta `texmf.cnf`**: En fråga du kanske ställer dig är hur Kpathsea vet var `texmf.cnf` lagras? Svaret är en miljövariabel som heter `TEXMFCNF`. Den måste vara inställd (på den enhet/plattform där TeX körs) till den sökväg där `texmf.cnf` lagras. #### Felsökning av Kpathsea-problem Användare av Overleaf behöver sannolikt inte dessa funktioner men vi listar dem för fullständighetens skull: * **kpsewhich**: Ett fristående program (ingår i TeX Live) som kan användas för att testa dina inställningar: fastställa värdet på variabler och hitta filer. Intresserade läsare hänvisas till [online-dokumentationen](http://tug.org/texinfohtml/kpathsea.html#Invoking-kpsewhich) för mer information. * **miljövariabler**: Kpathsea stöder en miljövariabel som heter [`KPATHSEA_DEBUG`](http://www.tug.org/texinfohtml/kpathsea.html#Debugging) för att hjälpa till med felsökning av dess beteende. Du kan ställa in `KPATHSEA_DEBUG` till olika värden beroende på hur mycket felsökningsinformation du behöver. Att sätta `KPATHSEA_DEBUG=-1` kommer att generera en *betydande* mängd data. ## Och slutligen: mappar, grafikfiler och latexmkrc Så, hur hänger ovanstående ihop med latexmkrc? Om du läser den här artikeln [Hur man använder latexmkrc med Overleaf: exempel och tekniker](/latex/sv/fordjupade-artiklar/28-how-to-use-latexmkrc-with-overleaf.md) kan du se att (Perl-)koden i latexmkrc-exemplet sätter värdet på en miljövariabel `TEXINPUTS`: ``` $ENV{'TEXINPUTS'}='./tex//:' . $ENV{'TEXINPUTS'}; ``` Observera att kolon-tecknet (:) som används här (`./tex//**:**`) är *extremt* viktigt. Om du utelämnar det kolonet kan TeX/LaTeX bli oförmöget att hitta viktiga systemfiler, såsom LaTeX-paket! Vad denna latexmkrc-fil i praktiken gör är att lägga till en sökväg till en toppnivåmapp (`./tex` i exemplet ovan) till den systemdefinierade `TEXINPUTS` miljövariabeln så att när Kpathsea använder variabeln `$TEXINPUTS` kommer den då att vara medveten om att mappen `/tex//` ska genomsökas för att hitta indatafiler. Om du tittar noga ser du att den faktiska sökväg som används är `./tex//:` den `//` anger Kpathsea att söka igenom tex-mappen rekursivt—dvs. titta i alla underkataloger som finns i `tex` mappen. Som nämnt lade vi också till det viktiga kolon-tecknet. Vi kan använda exakt samma teknik för grafikfiler. ### En utvikning om BibTeX Som nämnt använder BibTeX-programmet också Kpathsea för att söka efter sina indatafiler; i synnerhet: * den `BSTINPUTS` konfigurationsvariabeln (sökvägen) används för att söka efter `.bst` filer; * och `BIBINPUTS` konfigurationsvariabeln (sökvägen) kommer att användas för att söka efter `.bib` .bib-filer. Om du lägger till nya `.bst` eller `.bib` filer i ditt Overleaf-projekt kan du använda tekniken nedan för att tala om för BibTeX var den ska hitta dessa filer—du måste ersätta `TEXINPUTS` med `BSTINPUTS` och/eller `BIBINPUTS`. ### TEXINPUTS och använda nästlade mappar för grafikfiler Om ditt projekt har många grafikfiler kan det vara praktiskt att skapa en uppsättning mappar för att lagra och hantera dem. Till exempel visar följande skärmbild ett avsnitt av ett Overleaf-projekt som använder en toppnivåmapp kallad **`graphics`**: ![Bild som visar nästlade mappar i ett Overleaf-projekt](/files/f3f808a40fd1e11ab89f2862d321d1607ba31ea2) Det finns många (nästlade) undermappar som innehåller grafik för olika avsnitt av vårt dokument. Anta att vi har ovanstående mappstruktur och vill använda `graphicx` (`\usepackage{graphicx}`) och att vi försöker göra det så här: ```latex \documentclass{article} \usepackage{graphicx} \begin{document} \includegraphics{endlinechar}% bästa praxis är att inte använda filändelsen \end{document} ``` Det kommer inte att fungera och du får ett fel som detta: ``` ! LaTeX-fel: Filen `endlinechar' hittades inte. l.4 \includegraphics{endlinechar} Jag kunde inte lokalisera filen med någon av dessa ändelser: .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 ``` Det felet uppstår eftersom vår grafikfil lagras på en plats som TeX/LaTeX (och Kpathsea) inte känner till, och därför inte kan hitta den—sökvägen till grafikfilen är: ``` ./graphics/Introduction/Chapter1/Section1/Subsection3/endlinechar.png ``` **Obs**: Det anses generellt vara bästa praxis att ***undvika blanksteg i mappnamnen***. Även om det visserligen är möjligt att ha blanksteg i mappnamn, med hjälp av de tekniker som diskuteras nedan, avråder vi från detta av skäl som rör dokumentets portabilitet utanför Overleaf-plattformen. Som förklaras i denna [Overleaf-hjälpartikel](/latex/sv/fler-amnen/27-inserting-images.md) kan du naturligtvis använda mappar för att lagra din grafik, men du måste tala om för LaTeX var de lagras. Här tittar vi på två lösningar: * Använda kommandot \graphicspath; * Använda vår kunskap om Kpathsea och `TEXINPUTS`. ### Använda \graphicspath Den `graphicx` paketet tillhandahåller `\graphicspath` kommandot som du kan använda för att deklarera sökvägarna där din grafik finns; så vi skulle kunna göra något i stil med detta: ```latex \graphicspath{{./graphics/Introduction/Chapter1/Section1/Subsection3/}} ``` och LaTeX kommer nu att hitta all grafik som lagras under den sökvägen. **Obs**: Om du *måste* har blanksteg i mappnamnen måste du omsluta sökvägarna med dubbla citationstecken (`"..."`): ```latex \graphicspath{{"./graphics/Introduction/Chapter 1/Section 1/Subsection 3/"}} ``` **Obs**: Du kan deklarera flera sökvägar så här: ```latex \graphicspath{{path1}{path2}{path3}...{pathN}} ``` där `...` betyder ytterligare sökvägar omslutna av klammerparenteser. **Obs**: Vi börjar sökvägen med `./graphics` och inte bara `/graphics`. Punkten (.) talar om för operativsystemet att sökvägen är relativ till den aktuella arbetskatalogen. Den `\graphicspath` kommandot fungerar bra men om du har många mappar kan det bli ganska omständligt att lägga till varje sökväg; dessutom skulle sökvägar som definieras via `\graphicspath` inte längre fungera om du bytte namn på mapparna eller omstrukturerade dem. Finns det ett enklare sätt? Ja, du kan använda en latexmkrc-fil! #### \graphicspath och rekursion (underkataloger) Observera att det på nätet finns diskussioner/debatter om huruvida vissa system stödjer/aktiverar `\graphicspath` att rekursivt söka igenom underkataloger om du lägger till `//` i slutet av sökvägen: se till exempel dessa diskussioner på tex.stackexchange: * [Rekursiv sökning med LaTeX \graphicspath](https://tex.stackexchange.com/questions/25443/latex-graphicspath-recursive-search); * [\graphicspath för MikTeX](https://tex.stackexchange.com/questions/3131/graphicspath-for-miktex). För största möjliga kompatibilitet bör du anta att `\graphicspath` inte stöder rekursiv katalogsökning. ### Kpathsea och TEXINPUTS (latexmkrc-fil till räddning) **VARNING:** Observera att följande teknik fungerar bra på Overleaf och på lämpligt konfigurerade lokala TeX-installationer; **men** om du använder en latexmkrc-fil kan ditt projekt bli inkompatibelt med andra TeX-installationer, såsom dem som används av förlag och system för inlämning av vetenskapliga artiklar online. Tredjeparts TeX-installationer kanske, eller kanske inte, stöder eller tillåter användning av latexmkrc. Om du behöver exportera ditt Overleaf-projekt för användning någon annanstans, eller vill skicka in det till en tidskrift, bör du ta bort eventuella blanksteg från sökvägsnamnen och, för bättre kompatibilitet, lägga till ett `\graphicspath` kommando som definierar alla sökvägar: ```latex \graphicspath{{path1}{path2}{path3}...{pathN}} ``` där `...` betyder ytterligare sökvägar omslutna av klammerparenteser. Tekniken som diskuteras nedan (med `TEXINPUTS`) har testats framgångsrikt på Overleaf med motorerna pdfTeX, XeTeX och LuaTeX (dvs. kompilatoralternativen pdfLaTeX, XeLaTeX och LuaLaTeX i Overleaf-menyn): ![Bild som visar hur man väljer LaTeX-kompilatorn i Overleaf](/files/85b609a6f946c81b048a1579c081e1af056ab5c0) Om vi går tillbaka till vårt exempel vill vi använda denna kod (med djupt nästlade mappar) och vi använder en latexmkrc-fil för att åstadkomma det: ```latex \documentclass{article} \usepackage{graphicx} \begin{document} \includegraphics{endlinechar}% bästa praxis är att inte använda filändelsen \end{document} ``` Här är en skärmbild som visar att ovanstående kod fungerar utan problem: LaTeX har hittat vår grafikfil (`endlinechar.png`) även om den ligger i en djupt nästlad mappstruktur (utan några blanksteg i mappnamnen). ![Bild som visar ett projekt med nästlade mappar som kompileras på Overleaf](/files/d09afc4a1e0c891be2e437c12cf3b72ca3aed0fe) Så, hur gjorde vi detta? Allt du behöver göra är: * skapa en ny fil utan filändelse och kalla den latexmkrc; * lägga till följande rad i den filen: ``` $ENV{'TEXINPUTS'}='./graphics//:'.$ENV{'TEXINPUTS'}; ``` Kpathsea känner nu till mapparna som finns under `**graphics**` och på grund av `//` kommer den också att leta i undermapparna. Observera återigen att kolon i `./graphics//:` är faktiskt *extremt* viktigt. Om du utelämnar det kolonet kan TeX/LaTeX bli oförmöget att hitta viktiga systemfiler, såsom LaTeX-paket! Med hjälp av det enkla projektexemplet ovan kan du nu kompilera det och voilà! LaTeX hittar din grafikfil — och du kan byta namn på eller omorganisera mapparna under /graphics utan att det hindrar LaTeX från att hitta dem. ## Tabell som listar Kpathseas “konfigurationsvariabler” Följande tabell är en sammanfattning baserad på [data som listas i Kpathsea-dokumentationen](http://tug.org/texinfohtml/kpathsea.html#Supported-file-formats). | | | | | --------------------------------------------------- | ----------------------------------------------------------------------- | ------------------------------ | | **Kpathsea-konfigurationsvariabel** | **Beskrivning av filtyp** | **Filtillägg** | | AFMFONTS | Adobe-teckensnittsmetriker | .afm | | MFBASES, TEXMFINI | Metafont-minnesdump | .base | | BIBINPUTS, TEXBIB | BibTeX-bibliografikälla | .bib | | BLTXMLINPUTS | BibLaTeXML-bibliografifiler för Biber | .bltxml | | BSTINPUTS | BibTeX-stil | .bst | | CLUAINPUTS | dynamiska bibliotek för Lua | .dll och .so | | CMAPFONTS | teckenmappningsfiler | .cmap | | TEXMFCNF | Körningskonfigurationsfiler | .cnf | | CWEBINPUTS | CWEB-inmatningsfiler | .w, .web, .ch | | TEXCONFIG | Dvips-filerna 'config.\*', till exempel config.ps | | | ENCFONTS | kodningsvektorer | .enc | | TEXFORMATS, TEXMFINI | TeX-minnesdump | .fmt | | FONTCIDMAPS | CJK-mappning | .cid | | FONTFEATURES | främst för OpenType-teckensnittsfunktioner | .fea | | FONTS, GFFONTS, GLYPHFONTS, TEXFONTS | generisk teckensnittsbitmap | .gf | | TEXPICTS, TEXINPUTS | Inkapslade PostScript-figurer | .eps, .epsi | | TEXINDEXSTYLE, INDEXSTYLE | makeindex-stilfiler | .ist | | LIGFONTS | ligaturdefinitionsfiler | .lig | | TEXMFDBS | Filnamnsdatabaser | | | TEXFONTMAPS | Fontmappar | .map | | MPMEMS, TEXMFINI | MetaPost-minnesdump | .mem | | MPSUPPORT | MetaPost-stödjefiler, används av DMP | | | MFINPUTS | Metafont-källkod | .mf | | MFPOOL, TEXMFINI | Metafont-programsträngar | .pool | | MFTINPUTS | MFT-stilfil | .mft | | MISCFONTS | teckensnittsrelaterade filer som inte passar in i de andra kategorierna | | | MLBIBINPUTS, BIBINPUTS, TEXBIB | MlBibTeX-bibliografikälla | .mlbib, .mlbib | | MLBSTINPUTS, BSTINPUTS | MlBibTeX-stil | .mlbst, .bst | | MPINPUTS | MetaPost-källkod | .mp | | MPPOOL, TEXMFINI | MetaPost-programsträngar | .pool | | OCPINPUTS | kompilerade processfiler för Omega | .ocp | | OFMFONTS, TEXFONTS | Omega-teckensnittsmetriker | .ofm, .tfm | | OPENTYPEFONTS | OpenType-teckensnitt | | | OPLFONTS, TEXFONTS | Omega-egenskapslistor | .opl | | OTPINPUTS | Omega-översättningsprocessfiler | .otp | | OVFFONTS, TEXFONTS | Omega-virtuella teckensnitt | .ovf | | OVPFONTS, TEXFONTS | Omega-virtuella egenskapslistor | .ovp | | PDFTEXCONFIG | PDFTeX-specifika konfigurationsfiler | | | PROGRAMFONTS, PKFONTS, TEXPKS, GLYPHFONTS, TEXFONTS | packade bitmapteckensnitt | .pk | | TEXPSHEADERS, PSHEADERS | nedladdningsbar PostScript | .pro | | RISINPUTS | RIS-bibliografifiler, främst för Bibe | .ris | | SFDFONTS | definitionsfiler för underteckensnitt | .sfd | | TEXINPUTS | TeX-källkod | .tex | | TEXDOCS | Dokumentationsfiler för TeX-systemet | | | TEXSOURCES | Källfiler för TeX-systemet | | | TEXMFSCRIPTS | Arkitekturoberoende körbara filer som distribueras i texmf-träden | | | TEXPOOL, TEXMFINI | TeX-programsträngar | .pool | | TFMFONTS, TEXFONTS | TeX-teckensnittsmetriker | .tfm | | TRFONTS | Troff-teckensnitt | | | TTFONTS | TrueType-streckteckensnitt | .ttf, ,TTF, .ttc, .TTC, .dfont | | T1FONTS, T1INPUTS, TEXPSHEADERS, DVIPSHEADERS | PostScript-outline-teckensnitt av typ 1 | .pfa, .pfb | | T42FONTS | PostScript-outline-teckensnitt av typ 42 | | | VFFONTS, TEXFONTS | virtuella teckensnitt | .vf | | WEBINPUTS | WEB-inmatningsfiler | .web, .ch | | WEB2C | filer som är specifika för web2c-implementationen | | --- # 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/sv/fordjupade-artiklar/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.