> 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/no/dybdeartikler/06-an-introduction-to-kpathsea-and-how-tex-engines-search-for-files.md). # En introduksjon til Kpathsea og hvordan TeX-motorer søker etter filer ## Innledning Denne artikkelen gir en introduksjon til hvordan TeX-motorer finner filene som trengs for å sette dokumentet ditt i sats — ved bruk av LaTeX eller en annen makropakke. Selv om Overleaf avlaster brukerne fra utfordringene med å administrere en TeX-installasjon ([TeX Live](https://www.tug.org/texlive/)), er det grunnleggende om hvordan TeX-motorer søker etter filer nyttig/interessant hvis du vil lage en mappestruktur for å hjelpe deg med å administrere Overleaf-prosjektet ditt. Hvorfor kan det være sant? Hvis du lagrer noen av prosjektfilene dine i mapper, kan det hende at LaTeX ikke finner disse filene fordi TeX-motoren (kompilatoren) som standard kanskje ikke *vet* at den må søke i disse mappene — og dermed ikke finner filene de inneholder. For å unngå dette kan du opprette og legge til i prosjektet ditt en konfigurasjonsfil kalt en [latexmkrc-fil](https://mg.readthedocs.io/latexmk.html#configuration-files) som kan brukes til å fortelle en TeX-motor at mappene dine finnes, og at den bør søke i dem. Hvis du vil hoppe rett til et eksempel som viser en latexmkrc-fil, kan du lese denne hjelpeartikkelen: [Slik bruker du latexmkrc med Overleaf: eksempler og teknikker](/latex/no/dybdeartikler/28-how-to-use-latexmkrc-with-overleaf.md). Det er kanskje ikke umiddelbart åpenbart hvordan, eller hvorfor, den latexmkrc-filen faktisk fungerer. Hvis du vil vite hvorfor og kanskje utvikle en bedre forståelse for bruk med flere konfigurasjonsmuligheter for prosjektet ditt, så les videre ... På slutten av denne artikkelen skal vi gå gjennom et [praktisk eksempel](#kpathsea-and-texinputs-latexmkrc-file-to-the-rescue)—ved å bruke vår kunnskap om hvordan TeX søker etter filer—til å lage en latexmkrc-fil for å håndtere nestede mapper som inneholder grafikkfilene dine. ## TeX og plattformuavhengighet Da Knuth opprettet TeX, var plattformuavhengighet et sentralt prinsipp som styrte utformingen og implementeringen, og den filosofien gjenspeiles i hele TeX sine interne operasjoner (f.eks. bruk av heltallsaritmetikk, «egenutviklet» strenghåndtering, minnehåndtering osv.). Selv i dag vekker plattformuavhengigheten til moderne TeX-baserte motorer fortsatt spørsmål og debatt i offentlige forum; se for eksempel denne diskusjonen på tex.stackexchange: [Er XeTeX og LuaTeX plattformavhengige?](https://tex.stackexchange.com/questions/94297/are-xetex-and-luatex-platform-dependent) som inneholder kommentarer og observasjoner fra en rekke kjente TeX-eksperter. For nå lar vi imidlertid de finere detaljene ligge og bemerker at TeX-motorer fortsatt må være svært portable — kunne fungere på flere operativsystemer og produsere «identiske» resultater. Et sentralt aspekt ved portabilitet er å søke etter filer på en plattformuavhengig måte. ## TeX-motorer søker ikke etter filer … egentlig!? Nei, TeX-motorer *direkte* søker ikke etter filer *på egen hånd*. Når en `.tex` fil behandles, kan en TeX-motor identifisere behovet for å åpne en bestemt fil, men den *delegerer* oppgaven med å finne den til et annet program kalt [*Kpathsea*](https://tug.org/kpathsea/): et eksternt programbibliotek som ikke er en del av *kjerne-* kildekoden til TeX-motorer. Det Kpathsea tilbyr er i praksis et API ([Application Programming Interface](https://en.wikipedia.org/wiki/Application_programming_interface)) som TeX-motorer (i tillegg til BibTeX, MetaPost og andre applikasjoner) kan kalle når de trenger å åpne en bestemt fil: Kpathsea gjør selve arbeidet med å finne den filen. Da Knuth skrev den opprinnelige TeX-motoren — som alle andre TeX-motorer til syvende og sist nedstammer fra — var problemet med å finne/åpne filer en betydelig utfordring, delvis på grunn av datidens svært ulike teknologiske økosystem. Faktisk omtaler Knuth i kildekoden til TeX filinn-/utdata som «plattformuavhengighetens akilleshæl» (se side 12, avsnitt 25 i [TeX: The Program](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373)). TeX-fellesskapet erkjente behovet for å harmonisere (standardisere) filsøking for TeX —*og TeX-relatert programvare*—og bestemte seg for å gi TeX verktøyene til å gjøre det. For å ta tak i det svært vriene problemet med en plattformuavhengig metode for å finne filer, skrev Karl Berry, et ledende medlem av TeX-fellesskapet, programvaren for å løse *bane*-søkeproblemet: en løsning han kalte [**Kpathsea**](http://tug.org/texinfohtml/kpathsea.html)—som er avledet fra **K**Karls **Path** **Sea**rching (se dette [intervjuet med Karl Berry](http://www.tug.org/interviews/berry.html)). Vi kan merke oss at det kalles K**bane**sea og ikke K**fil**sea fordi, som [dokumentasjonen](http://tug.org/texinfohtml/kpathsea.html) noterer, er det et bibliotek for \*path\*-søking. Det er viktig å være klar over at Kpathsea ikke bare brukes av TeX-motorer; ulike TeX-relaterte programmer, inkludert BibTeX og MetaPost, bruker også Kpathsea til å søke etter inndatafiler. I grove trekk, når TeX/LaTeX-makroer trenger å åpne en bestemt fil, vil kommandoene som disse makroene er bygget av etter hvert bli konvertert til lavnivå TeX-instruksjoner (TeX-primitiver) som TeX-motorene faktisk utfører. Hvis disse instruksjonene inkluderer behovet for å åpne en fil, vil TeX-motoren kalle på Kpathsea og i praksis si: «finn denne filen, takk»; hvis Kpathsea finner den, blir filen åpnet. Men hvis Kpathsea ikke kan finne filen, vil TeX-motoren få beskjed om det og stoppe kjøringen for å gi den beryktede feilen ``! Jeg kan ikke finne filen `...'`` Sannheten er at Kpathsea ikke kan finne den. ### Merknader om LuaTeX Strengt tatt bør vi sette inn et forbehold i denne delen ved å bemerke at LuaTeX faktisk tilbyr en mekanisme for brukeren til å levere sin egen filsøkingskode gjennom bruk av *tilbakekall*. LuaTeX gjør det mulig for brukere å skrive funksjoner i skriptspråket Lua og registrere dem hos LuaTeX, slik at det kaller den brukerdefinerte funksjonen på bestemte stadier under LuaTeX-kjøringen — derav begrepet *tilbakekall*tilbakekall [LuaTeX Reference Manual](http://www.pragma-ade.com/general/manuals/luatex.pdf) (på skrivende tidspunkt er den lenken for LuaTeX 1.09). ### Kpathsea-konfigurasjonsfilen: texmf.cnf Hver TeX-installasjon inneholder en tekstfil kalt `texmf.cnf` som er en konfigurasjonsfil brukt av Kpathsea: den inneholder en rekke «konfigurasjonsvariabler» som definerer banene Kpathsea vil bruke til å søke etter ulike typer filer som TeX-motorer (eller BibTeX, MetaPost osv.) kan trenge. Som vi skal se nedenfor, definerer disse «konfigurasjonsvariablene» søkestier konstruert fra såkalte *baneelementer*: ved bruk av ulike konstruksjoner, variabler og parametere for å definere hvert baneelement som en «mal» som Kpathsea behandler for å generere de faktiske, fysiske katalogene som skal søkes. For å gi et konkret eksempel, her er en slik konfigurasjonsvariabel som definerer søkebanene for OpenType-fonter — foreløpig trenger du ikke bekymre deg for betydningen av hvordan denne banen er bygd opp: ``` OPENTYPEFONTS = .;$TEXMF/fonts/{opentype,truetype}//;$OSFONTDIR// ``` Det eneste viktige her er at filen `texmf.cnf` (lest av Kpathsea) definerer en konfigurasjonsvariabel kalt `OPENTYPEFONTS` som brukes til å definere banen(e) Kpathsea vil bruke til å søke etter OpenType-fonter. Høyresiden av «=» ser ikke ut som noen bane du ville se på en typisk enhet fordi den er konstruert ved hjelp av ulike variabler og parametere for å definere hver bane som en «mal» eller «blåkopi» som Kpathsea vil bruke til å generere virkelige kataloger å søke i. ### Kpathseas begrep om en «bane» Det kanskje sentrale konseptet å forstå er Kpathseas forestilling om en «bane»: den grunnleggende konstruksjonen Kpathsea bruker for å finne ut hvor en bestemt fil ligger. Som vi så i `OPENTYPEFONTS` eksempelet ovenfor ser Kpathseas forestilling om en bane veldig annerledes ut enn banene vi er vant til å bruke på stasjonære eller bærbare enheter. For å sitere Kpathseas [dokumentasjonen](http://tug.org/texinfohtml/kpathsea.html#Searching-overview): > ... en *søkebane* er en kolonseparert liste av *baneelementer*, som er katalognavn med noen få «ekstra finesser». —men merk at semikolon (`;`) også brukes til å skille *baneelementer*. Senere skal vi kort angi arten til noen av disse «ekstra finessene». I vårt `OPENTYPEFONTS` eksempel er det tre baneelementer, hver avgrenset ved hjelp av semikolon (`;`): ![Bilde som viser baneelementene i en Kpathsea-banedeklarasjon](/files/6ee7e75ad06d70a1735e4827407972eaa56894d1) 1. `.` (som betyr gjeldende katalog) 2. `$TEXMF/fonts/{opentype,truetype}//` 3. `$OSFONTDIR//` Merk at en dobbel skråstrek (`//`) i et baneelement betyr søk i underkataloger (rekursivt). En typisk `texmf.cnf` fil vil inneholde en rekke «konfigurasjonsvariabler» for å definere søkestier for filtypene Kpathsea kan søke etter. ## Kpathsea: en svært kort oversikt Kpathsea er et sofistikert bibliotek — med mange fine detaljer og nyanser — og selv et kort blikk på [dokumentasjonen](http://tug.org/texinfohtml/kpathsea.html) dokumentasjonen ### hovedformålet til Kpathsea Som nevnt i dokumentasjonen er Kpathseas grunnleggende formål «å returnere et filnavn fra en liste over kataloger spesifisert av brukeren», og at disse katalogene (søkestiene) er spesifisert ved bruk av «noen få ekstra finesser». ### Disse «ekstra finessene» De «noen få ekstra finessene» nevnt ovenfor omfatter ulike parametere og variabler som Kpathsea bruker til å konstruere søkebanene sine (eller «banemaler») slik at det kan definere baner på en mer generell måte. Når en TeX-motor faktisk kjører, kan Kpathsea bruke den gjeldende verdien av disse parameterne/variablene til å finne ut de faktiske banene ved å erstatte disse variablene med deres faktiske (kjøringstid) verdier. Du kan lett identifisere disse variablene (inne i baneelementer) fordi de begynner med et `$` tegn. Dermed sier vi at Kpathsea *utvider* et baneelement, som betyr at det omformer disse parameterne og variablene: det gjør en bane «mal» om til det faktiske navnet/navnene på én eller flere fysiske kataloger der det skal lete etter en fil. Dette gir stor fleksibilitet og betyr at Kpathsea kan konstruere en liste over kataloger som svarer til et enkelt baneelement — for eksempel hvis det får beskjed om å søke i underkataloger. ### Vårt OpenType-eksempel, sett på nytt Vi skal samle trådene og utforske `OPENTYPEFONTS` det litt nærmere: ``` OPENTYPEFONTS = .;$TEXMF/fonts/{opentype,truetype}//;$OSFONTDIR// ``` La oss se på de to baneelementene `$TEXMF/fonts/{opentype,truetype}//` og `$OSFONTDIR//`. Her legger Kpathsea merke til bruken av klammer `{...}` og behandler `$TEXMF/fonts/{opentype,truetype}` som representerer *to* baneelementer: 1. `$TEXMF/fonts/opentype//` 2. `$TEXMF/fonts/truetype//` og at *underkatalogene* til begge disse baneelementene også skal søkes i (angitt av den avsluttende `//`). **Merk**: Se Kpathsea-dokumentasjonen om [utvidelse av underkataloger](http://tug.org/texinfohtml/kpathsea.html#Subdirectory-expansion) for et viktig forbehold om rekkefølgen underkataloger på ethvert nivå søkes i (den er ikke spesifisert). Vi skal gjøre noen observasjoner om `$TEXMF` nedenfor. #### $OSFONTDIR// `$OSFONTDIR` er en variabel hvis verdi bør defineres som en miljøvariabel som inneholder stedet der fonter er lagret: den eksakte verdien vil selvsagt avhenge av operativsystemet som brukes til å kjøre TeX. Merk at den avsluttende `//` instruerer Kpathsea til å søke i underkataloger når det leter etter OpenType-fonter. Standarddefinisjonen av `OSFONTDIR` inne i `texmf.cnf` er: ``` OSFONTDIR = /please/set/osfontdir/in/the/environment ``` Så det er absolutt noe du må sette hvis du ønsker å bruke det — miljøvariabelen din vil overstyre denne «plassholder»-definisjonen i `texmf.cnf`. Hvis du setter miljøvariabelen `OSFONTDIR` så kan Kpathsea ved kjøring, der det ser `$OSFONTDIR` som del av et baneelement (i `texmf.cnf`) erstatte variabelen `$OSFONTDIR` med den faktiske verdien lagret i miljøvariabelen `OSFONTDIR`. Husk at når du bruker den innenfor `texmf.cnf` baneelementer, angir vi variabelen `$OSFONTDIR`—med en ledende `$`—for å fortelle Kpathsea at dette er en variabel hvis *verdi* den trenger å bruke. #### Korte merknader om $TEXMF `TEXMF` er en annen konfigurasjonsvariabel som er definert i `texmf.cnf`; for eksempel, i den sentrale TeX Live-distribusjonen ville du se: ``` TEXMF = {$TEXMFAUXTREES$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,!!$TEXMFLOCAL,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFDIST} ``` Du trenger ikke å bry deg om detaljene i denne definisjonen av `TEXMF`—vi kommer ikke til å utforske alle detaljene, men bare merke oss at `$TEXMF` variabelen brukes inne i baneelementer fordi den definerer en rekke toppnivåmapper (omtalt som «texmf-trær») som du kan starte filsøket fra. `TEXMF` er ekstremt nyttig hvis du vil, eller trenger, dele en TeX-installasjon opp på flere kataloger (eller katalog«trær»). For eksempel ha en hoved- eller sentral samling av TeX/LaTeX-pakker (f.eks. TeX Live) og en annen samling filer og mapper som brukes til å lagre lokale LaTeX-pakker — eller kanskje brukes til å lagre lokale konfigurasjonsfiler eller tilpassede versjoner av standardpakker. Å dele TeX-installasjonen på denne måten kan gjøre det enklere å administrere oppgraderingen av hoved-/sentral samling (distribusjon) av TeX/LaTeX-pakker fordi den lokale samlingen din er adskilt fra hovedfilene som oppdateres når du oppgraderer TeX Live-distribusjonen/installasjonen din. For ytterligere detaljer om å administrere mer komplekse TeX-installasjoner henvises den interesserte leseren til disse to artiklene: * [Administrere flere TDS-trær](http://tug.org/TUGboat/Articles/tb22-3/tb72downes.pdf) av Michael J Downes; * [Å jonglere texmf-trær](http://www.ntg.nl/maps/27/17.pdf) av Siep Kroonenberg. #### TeX-katalogstruktur Alle som har administrert en TeX-installasjon vet at moderne TeX-systemer, som TeX Live, inneholder mange titusenvis av filer som omfatter et enormt spekter av filtyper. TeX Directory Structure (TDS) ble utformet som en beste praksis-«blåkopi» for organisering av den enorme samlingen filer i en fungerende TeX-installasjon og anbefales sterkt for bruk med Kpathsea. For mer informasjon henvises leseren til TDS-spesifikasjonen: [En katalogstruktur for TeX-filer](https://www.tug.org/tds/tds.pdf). ## Kpathsea-filtyper Applikasjonspakken som bruker Kpathsea trenger tilgang til et bredt spekter av filtyper, så Kpathsea bruker en «konfigurasjonsvariabel» for å identifisere banen(e) for hver type fil (eller gruppe filer) den støtter. Nettdokumentasjonen har en fullstendig liste (se også vår [oppsummeringstabell nedenfor](#table-listing-kpathsea-config-variables)) men her er «konfigurasjonsvariablene» for de vanligste filtypene: | | | | -------------------------- | ------------------------------------- | | **Konfigurasjonsvariabel** | **Eksempler på filtyper** | | TEXINPUTS | TeX-kildefiler og figur-/grafikkfiler | | BIBINPUTS, BSTINPUTS | BibTeX-bibliografikildefiler | | TTFONTS | TrueType-konturfonter | | OPENTYPEFONTS | OpenType-konturfonter | `TEXINPUTS` er en særlig viktig konfigurasjonsvariabel fordi den angir hvor en TeX-motor henter inn kildefilene sine. Merk at bildefiler regnes som inndatafiler og også kan søkes etter ved hjelp av banen definert av `TEXINPUTS`. ### Noen Kpathsea-nyanser Som nevnt har Kpathsea mange nyanser som vi ikke kan utforske i detalj her. Her er imidlertid funksjoner noen lesere kanskje vil utforske: * **filnavndatabase:** For å minimere disksøk kan Kpathsea bruke en «eksternt bygget [filnavndatabase med navnet ls-R](http://tug.org/texinfohtml/kpathsea.html#Filename-database) som kobler filer til kataloger». TeX Live leverer en slik og verktøyene for å oppdatere den hvis nye filer legges til. * **miljøvariabler**: I tillegg til «konfigurasjonsvariabler» (slik som `OPENTYPEFONTS`) bruker Kpathsea også på smart vis [miljøvariabler](https://en.wikipedia.org/wiki/Environment_variable); for eksempel kan kjøretidsverdien til miljøvariabler brukes til å definere baneelementer i `texmf.cnf` filen (muligens for å overstyre variabler med samme navn som er definert i `texmf.cnf`). * **programnavn:** Et subtilt, men viktig aspekt ved Kpathseas oppførsel er at den kan bruke navnet på kjørbart program (f.eks. TeX-motoren) til å konstruere programspecifikke søkebanekonstruksjoner. Dette gir betydelig fleksibilitet fordi filsøking kan rettes mot filer for en bestemt TeX-motor. For eksempel, for LuaTeX/LuaLaTeX: ``` TEXINPUTS.lualatex = .;$TEXMF/tex/{lualatex,latex,luatex,generic,}// TEXINPUTS.luatex = .;$TEXMF/tex/{luatex,plain,generic,}// ``` * **finne `texmf.cnf`**: Et spørsmål du kanskje stiller er hvordan Kpathsea vet hvor `texmf.cnf` er lagret? Svaret er en miljøvariabel kalt `TEXMFCNF`. Denne må settes (på enheten/plattformen som kjører TeX) til banen der `texmf.cnf` er lagret. #### Feilsøking av Kpathsea-problemer Brukere av Overleaf har neppe behov for disse funksjonene, men vi lister dem opp for fullstendighet: * **kpsewhich**: Et selvstendig program (inkludert i TeX Live) som kan brukes til å teste innstillingene dine: bestemme verdien av variabler og finne filer. Interessert lesere henvises til [nettbasert dokumentasjon](http://tug.org/texinfohtml/kpathsea.html#Invoking-kpsewhich) for mer informasjon. * **miljøvariabler**: Kpathsea støtter en miljøvariabel kalt [`KPATHSEA_DEBUG`](http://www.tug.org/texinfohtml/kpathsea.html#Debugging) for å hjelpe til med å feilsøke oppførselen. Du kan sette `KPATHSEA_DEBUG` til ulike verdier avhengig av hvor mye feilsøkingsinformasjon du trenger. Å sette `KPATHSEA_DEBUG=-1` vil generere en *betydelig* mengde data. ## Og til slutt: mapper, bildefiler og latexmkrc Så, hvordan henger det ovenstående sammen med latexmkrc? Hvis du leser denne artikkelen [Slik bruker du latexmkrc med Overleaf: eksempler og teknikker](/latex/no/dybdeartikler/28-how-to-use-latexmkrc-with-overleaf.md) kan du se at (Perl-)koden i latexmkrc-eksempelet setter verdien av en miljøvariabel `TEXINPUTS`: ``` $ENV{'TEXINPUTS'}='./tex//:' . $ENV{'TEXINPUTS'}; ``` Merk at kolon (:) brukt her (`./tex//:**:**`) er *ekstremt* er viktig. Hvis du utelater det kolon-tegnet, kan TeX/LaTeX være ute av stand til å finne viktige systemfiler, som LaTeX-pakker! Det denne latexmkrc-filen faktisk gjør, er å legge til en toppnivåmappesti (`./tex` i eksempelet ovenfor) til den systemdefinerte `TEXINPUTS` miljøvariabelen, slik at når Kpathsea bruker variabelen `$TEXINPUTS` vil den da være klar over at mappen `/tex//` skal søkes i for å finne inndatafiler. Hvis du ser nøye etter, vil du se at den faktiske banen som brukes er `./tex//:` den `//` forteller Kpathsea å søke rekursivt i tex-mappen — dvs. se i eventuelle undermapper som finnes i `tex` mappen. Som nevnt har vi også lagt til det viktige kolon-tegnet. Vi kan bruke akkurat samme teknikk for bildefiler. ### En avstikker om BibTeX Som nevnt bruker BibTeX-programmet også Kpathsea til å søke etter inndatafilene sine; særlig: * den `BSTINPUTS` konfigurasjonsvariabelen (søkebanen) brukes til å søke etter `.bst` filer; * og `BIBINPUTS` konfigurasjonsvariabelen (søkebanen) vil bli brukt til å søke etter `.bib` filer. Hvis du legger til nye `.bst` eller `.bib` filer i Overleaf-prosjektet ditt kan du bruke teknikken nedenfor til å fortelle BibTeX hvor den finner disse filene — du må erstatte `TEXINPUTS` med `BSTINPUTS` og/eller `BIBINPUTS`. ### TEXINPUTS og bruk av nestede mapper for grafikkfiler Hvis prosjektet ditt har mange grafikkfiler, kan det være praktisk å opprette et sett med mapper for å lagre og administrere dem. For eksempel viser følgende skjermbilde en del av et Overleaf-prosjekt som bruker en toppnivåmappe kalt **`graphics`**: ![Bilde som viser nestede mapper i et Overleaf-prosjekt](/files/44535eae1911eeafe48120ee2259b7892c11539a) Det finnes mange (nestede) undermapper som inneholder grafikk for ulike deler av dokumentet vårt. Anta at vi har mappestrukturen ovenfor og ønsker å bruke `graphicx` pakken (`\usepackage{graphicx}`) og at vi prøver å gjøre det slik: ```latex \documentclass{article} \usepackage{graphicx} \begin{document} \includegraphics{endlinechar}% beste praksis er å ikke bruke filendelsen \end{document} ``` Det vil ikke fungere, og du får en feil som denne: ``` ! LaTeX-feil: Filen `endlinechar' ble ikke funnet. l.4 \includegraphics{endlinechar} Jeg kunne ikke finne filen med noen av disse filendelsene: .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 ``` Denne feilen oppstår fordi grafikkfilen vår er lagret på et sted som TeX/LaTeX (og Kpathsea) ikke kjenner til, og dermed ikke kan finne — banen til grafikkfilen er: ``` ./graphics/Introduction/Chapter1/Section1/Subsection3/endlinechar.png ``` **Merk**: Det er generelt ansett som beste praksis å ***unngå mellomrom i mappenavnene***. Selv om det absolutt er mulig å ha mellomrom i mappenavn, ved bruk av teknikkene omtalt nedenfor, vil vi advare mot det av hensyn til dokumentportabilitet utenfor Overleaf-plattformen. Som forklart i denne [Overleaf-hjelpeartikkelen](/latex/no/flere-emner/27-inserting-images.md) kan du selvsagt bruke mapper til å lagre grafikken din, men du må fortelle LaTeX hvor de er lagret. Her skal vi se på to løsninger: * Bruke kommandoen \graphicspath; * Bruke vår kunnskap om Kpathsea og `TEXINPUTS`. ### Bruke \graphicspath Den `graphicx` pakken gir `\graphicspath` kommandoen som du kan bruke til å angi stier der grafikken din er plassert; så vi kunne gjøre noe slikt: ```latex \graphicspath{{./graphics/Introduction/Chapter1/Section1/Subsection3/}} ``` og LaTeX vil nå finne all grafikk lagret under den banen. **Merk**: Hvis du *må* har mellomrom i mappenavnene, må du omslutte banene med doble anførselstegn (`"..."`): ```latex \graphicspath{{"./graphics/Introduction/Chapter 1/Section 1/Subsection 3/"}} ``` **Merk**: Du kan deklarere flere baner slik: ```latex \graphicspath{{path1}{path2}{path3}...{pathN}} ``` der `...` betyr flere baner omsluttet av klammer. **Merk**: Vi starter banen med `./graphics` og ikke bare `/graphics`. Punktet (.) forteller operativsystemet at banen er relativ til gjeldende arbeidskatalog. Den `\graphicspath` kommandoen fungerer bra, men hvis du har mange mapper kan det bli ganske tungvint å legge til hver bane; i tillegg vil baner definert via `\graphicspath` ikke lenger fungere hvis du gir mappene nytt navn eller omstrukturerer dem. Finnes det en enklere måte? Ja, du kan bruke en latexmkrc-fil! #### \graphicspath og rekursjon (undermapper) Merk at det finnes nettbaserte diskusjoner/debatter om hvorvidt enkelte systemer støtter/aktiverer `\graphicspath` for å søke rekursivt i undermapper hvis du legger til `//` på slutten av banen: se for eksempel disse diskusjonene på tex.stackexchange: * [Rekursivt søk i LaTeX \graphicspath](https://tex.stackexchange.com/questions/25443/latex-graphicspath-recursive-search); * [Graphicspath for MikTeX](https://tex.stackexchange.com/questions/3131/graphicspath-for-miktex). For størst kompatibilitet bør du anta at `\graphicspath` ikke støtter rekursiv katalogsøk. ### Kpathsea og TEXINPUTS (latexmkrc-fil til unnsetning) **FORBEHOLD:** Merk at følgende teknikk fungerer godt på Overleaf og på lokalt TeX-installasjoner som er riktig konfigurert; **men** hvis du bruker en latexmkrc-fil kan prosjektet ditt bli inkompatibelt med andre TeX-installasjoner, slik som dem som brukes av forlag og nettbaserte innsendinger til tidsskrifter. Tredjeparts TeX-installasjoner støtter eller tillater kanskje, eller kanskje ikke, bruk av latexmkrc. Hvis du trenger å eksportere Overleaf-prosjektet ditt for bruk andre steder, eller ønsker å sende det inn til et tidsskrift, bør du fjerne eventuelle mellomromstegn fra banenavnene og, for bedre kompatibilitet, legge til en `\graphicspath` kommando som definerer alle banene: ```latex \graphicspath{{path1}{path2}{path3}...{pathN}} ``` der `...` betyr flere baner omsluttet av klammer. Teknikken som diskuteres nedenfor (ved bruk av `TEXINPUTS`) har blitt testet vellykket på Overleaf med motorene pdfTeX, XeTeX og LuaTeX (dvs. kompilatoralternativene pdfLaTeX, XeLaTeX og LuaLaTeX i Overleaf-menyen): ![Bilde som viser hvordan du velger LaTeX-kompilator i Overleaf](/files/0ccc5106096ae21d021a9b83084cd6f26762b784) Tilbake til eksemplet vårt ønsker vi å bruke denne koden (med dypt nestede mapper), og vi skal bruke en latexmkrc-fil for å få det til: ```latex \documentclass{article} \usepackage{graphicx} \begin{document} \includegraphics{endlinechar}% beste praksis er å ikke bruke filendelsen \end{document} ``` Her er et skjermbilde som viser at koden ovenfor fungerer uten problemer: LaTeX har funnet grafikkfilen vår (`endlinechar.png`) selv om den er i en dypt nestet mappestruktur (uten noen mellomrom i mappenavnene). ![Bilde som viser et prosjekt med nestede mapper som kompilerer på Overleaf](/files/2ae43eb05d9b1c965c4e7b09e5f567b1a8756a85) Så, hvordan gjorde vi dette? Alt du trenger å gjøre er: * opprette en ny fil, uten filendelse, og kalle den latexmkrc; * legge til følgende linje i den filen: ``` $ENV{'TEXINPUTS'}='./graphics//:'.$ENV{'TEXINPUTS'}; ``` Kpathsea vil nå vite om mappene som finnes under `**graphics**` og på grunn av `//` vil den også se i undermappene. Merk igjen at kolonet i `./graphics//:` er faktisk *ekstremt* er viktig. Hvis du utelater det kolon-tegnet, kan TeX/LaTeX være ute av stand til å finne viktige systemfiler, som LaTeX-pakker! Ved å bruke det enkle prosjekt-eksempelet ovenfor kan du nå kompilere det, og vips! LaTeX finner grafikkfilen din — og du kan gi nytt navn til eller omorganisere mappene under /graphics, og det vil ikke hindre LaTeX i å finne dem. ## Tabell som viser Kpathsea «config-variabler» Følgende tabell er et sammendrag utledet fra [data oppført i Kpathsea-dokumentasjonen](http://tug.org/texinfohtml/kpathsea.html#Supported-file-formats). | | | | | --------------------------------------------------- | -------------------------------------------------------------- | ------------------------------ | | **Kpathsea-konfigurasjonsvariabel** | **Beskrivelse av filtype** | **Filendelse** | | AFMFONTS | Adobe font-metrikker | .afm | | MFBASES, TEXMFINI | Metafont-minnedump | .base | | BIBINPUTS, TEXBIB | BibTeX-bibliografikilde | .bib | | BLTXMLINPUTS | BibLaTeXML-bibliografifiler for Biber | .bltxml | | BSTINPUTS | BibTeX-stil | .bst | | CLUAINPUTS | dynamiske biblioteker for Lua | .dll og .so | | CMAPFONTS | tegnkartfiler | .cmap | | TEXMFCNF | Kjøretidskonfigurasjonsfiler | .cnf | | CWEBINPUTS | CWEB-inndatafiler | .w, .web, .ch | | TEXCONFIG | Dvips 'config.\*'-filer, som config.ps | | | ENCFONTS | kodingsvektorer | .enc | | TEXFORMATS, TEXMFINI | TeX-minnedump | .fmt | | FONTCIDMAPS | CJK-kartlegging | .cid | | FONTFEATURES | primært for OpenType-fonteregenskaper | .fea | | FONTS, GFFONTS, GLYPHFONTS, TEXFONTS | generisk font-bitmap | .gf | | TEXPICTS, TEXINPUTS | innkapslede PostScript-figurer | .eps, .epsi | | TEXINDEXSTYLE, INDEXSTYLE | makeindex-stilfiler | .ist | | LIGFONTS | ligaturdefinisjonsfiler | .lig | | TEXMFDBS | filnavndatabaser | | | TEXFONTMAPS | fontkart | .map | | MPMEMS, TEXMFINI | MetaPost-minnedump | .mem | | MPSUPPORT | MetaPost-støttefiler, brukt av DMP | | | MFINPUTS | Metafont-kilde | .mf | | MFPOOL, TEXMFINI | Metafont-programstrenger | .pool | | MFTINPUTS | MFT-stilfil | .mft | | MISCFONTS | fontrelaterte filer som ikke passer inn i de andre kategoriene | | | MLBIBINPUTS, BIBINPUTS, TEXBIB | MlBibTeX-bibliografikilde | .mlbib, .mlbib | | MLBSTINPUTS, BSTINPUTS | MlBibTeX-stil | .mlbst, .bst | | MPINPUTS | MetaPost-kilde | .mp | | MPPOOL, TEXMFINI | MetaPost-programstrenger | .pool | | OCPINPUTS | Omega-kompilerte prosessfiler | .ocp | | OFMFONTS, TEXFONTS | Omega-font-metrikker | .ofm, .tfm | | OPENTYPEFONTS | OpenType-fonter | | | OPLFONTS, TEXFONTS | Omega-egenskapslister | .opl | | OTPINPUTS | Omega-oversettelsesprosessfiler | .otp | | OVFFONTS, TEXFONTS | Omega-virtuelle fonter | .ovf | | OVPFONTS, TEXFONTS | Omega-virtuelle egenskapslister | .ovp | | PDFTEXCONFIG | PDFTeX-spesifikke konfigurasjonsfiler | | | PROGRAMFONTS, PKFONTS, TEXPKS, GLYPHFONTS, TEXFONTS | pakkede bitmapfonter | .pk | | TEXPSHEADERS, PSHEADERS | nedlastbar PostScript | .pro | | RISINPUTS | RIS-bibliografifiler, primært for Bibe | .ris | | SFDFONTS | subfontdefinisjonsfiler | .sfd | | TEXINPUTS | TeX-kilde | .tex | | TEXDOCS | Dokumentasjonsfiler for TeX-systemet | | | TEXSOURCES | Kildefiler for TeX-systemet | | | TEXMFSCRIPTS | Arkitekturuavhengige kjørbare filer distribuert i texmf-trærne | | | TEXPOOL, TEXMFINI | TeX-programstrenger | .pool | | TFMFONTS, TEXFONTS | TeX-font-metrikker | .tfm | | TRFONTS | Troff-fonter | | | TTFONTS | TrueType-konturfonter | .ttf, ,TTF, .ttc, .TTC, .dfont | | T1FONTS, T1INPUTS, TEXPSHEADERS, DVIPSHEADERS | PostScript-konturfonter av type 1 | .pfa, .pfb | | T42FONTS | PostScript-konturfonter av type 42 | | | VFFONTS, TEXFONTS | virtuelle skrifter | .vf | | WEBINPUTS | WEB-inndatafiler | .web, .ch | | WEB2C | filer spesifikke for web2c-implementeringen | | --- # 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/no/dybdeartikler/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.