> 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/flere-emner/18-how-overleaf-created-the-tex-primitive-reference-data.md).

# Hvordan Overleaf laget referansedataene for TeX-primitiver

Denne artikkelen beskriver metodene og teknikkene som ble brukt for å lage de to kryssreferansetabellene for TeXs primitive kommandoer:

* [TeX-primitive kommandoer oppført etter TeX-motor](/latex/no/flere-emner/46-tex-primitives-listed-by-tex-engine.md) og;
* [TeX-primitive kommandoer oppført etter CJK-TeX-motor](/latex/no/flere-emner/45-tex-primitives-listed-by-cjk-tex-engine.md).

Denne informasjonen er ment for lesere som er interessert i de finere detaljene, men er ikke en forutsetning for å bruke selve kryssreferansetabellen. For å imøtekomme behovene til ulike lesere gir vi en svært kort sammendrags-/oversiktsversjon sammen med en lengre forklaring for dem som ønsker å utforske problemstillingene i større dybde.

## Kort sammendrags-/oversiktsversjon

For å bygge kryssreferansetabellen behandlet Overleaf kildekoden til 9 TeX-motorer for å trekke ut listen over primitive kommandoer som støttes av hver av dem: den prosessen produserte 9 tekstfiler (1 fil per TeX-motor). Disse 9 settene med primitive kommandoer ble kombinert for å lage en «hovedliste», som i praksis var en forening av de enkelte settene med primitive kommandoer: dette ga totalt omtrent 1000 unike primitive kommandoer fordelt på de ulike motorene. For hver motor ble dens egen liste over primitive kommandoer kryssreferert mot hovedfilen (settet av alle kommandoer) for å avgjøre hvilke av disse \~1000 kommandoene den støttet: disse sammenligningene er tabellert i de følgende to tabellene:

* [Kryssreferansedata for TeX-primitive kommandoer](/latex/no/flere-emner/46-tex-primitives-listed-by-tex-engine.md)
* [Kryssreferansedata for TeX-primitive kommandoer (for CJK-motorer)](/latex/no/flere-emner/45-tex-primitives-listed-by-cjk-tex-engine.md)

## «Å bygge programvare» 101: Hva betyr det?

Gjennom resten av denne artikkelen refererer vi til forestillingen om «å bygge TeX-motorer», noe som kan være et ukjent begrep hvis du ikke er programmerer, eller ikke programmerer i kompilerte språk som C eller C++. For våre formål er å bygge programvare – altså TeX-motorer – prosessen med å lage et kjørbart TeX-program fra delene det består av – kildekodefilene skrevet i programmeringsspråket som brukes til å utvikle programmet.

## Full versjon: Vil du ha detaljene? Les videre...

Hver TeX-basert typograferingsmotor støtter en «dialekt» av TeX-språket: et bestemt sett med primitive kommandoer som styrer typograferingsfunksjonene til hver motor og gir byggeklossene for å lage/definere makroer: brukerdefinerte sekvenser av kommandoer. Hver makro, enten den er skrevet for LaTeX, plain TeX eller en annen makropakke, er til syvende og sist bygget opp av primitive kommandoer – selv om du kan måtte gå ganske langt ned, gjennom lag av flere makroer, før du når «grunnfjellet» av TeX-primitive kommandoer. Settet med 9 TeX-motorer som ble analysert for å lage referansedataene for primitive kommandoer, har naturligvis mange kommandoer til felles, men hver TeX-motor har også sine egne primitive kommandoer, lagt til av utviklerne, for å gi støtte for funksjonene som er spesifikke for den «versjonen» av TeX.

De primitive kommandoene i en TeX-motor er innebygd i den kjørbare TeX-programvaren: primitive kommandoer er ikke makroer konstruert av brukere, de er grunnleggende, udelelige/atomære instruksjoner som brukes til å styre typograferingsoppførselen til hver motor. Følgelig er den mest pålitelige måten å lage en definitiv liste over primitive kommandoer som støttes av en hvilken som helst TeX-motor, å undersøke den faktiske kildekoden som de kjørbare TeX-programmene bygges (kompileres) fra, og å trekke ut listen over primitive kommandoer definert i kildekoden. Høres ut som det burde være enkelt, ikke sant? På grunn av TeXs 40 år lange utviklingshistorie er det imidlertid ikke særlig ukomplisert å utforske/gjennomgå kildekodefilene til TeX-motorer (unntatt LuaTeX). Årsaken til disse kompleksitetene ligger i verktøyene, programmeringsspråket (Pascal) og metodikken (litterat programmering) som Knuth brukte til å skrive den opprinnelige TeX-kildekoden – som alle andre motorer til syvende og sist nedstammer fra.

Vi gjør et unntak for LuaTeX fordi kjernemotoren ble skrevet om i C for å fjerne bruken av Pascal og andre historiske kompleksiteter beskrevet nedenfor (Web2C); følgelig er LuaTeXs kildekode riktignok omfattende, men måten den er «pakket» og distribuert på er langt mer oversiktlig sammenlignet med andre TeX-motorer. Som en konsekvens, og basert på arbeidsflyten/prosessene som brukes til å bygge dem fra kildekode, er det praktisk å gruppere TeX-motorer i to kategorier:

1. LuaTeX: tilpasset (mer moderne) byggeprosess
2. Alle andre motorer: tradisjonell (Web2C) byggeprosess

## Konteksten for eldre kode: Hvorfor det er komplekst å bygge (de fleste) TeX-motorer

Som vi skal utforske nedenfor, ga Knuth ut sin opprinnelige TeX-kildekode som én enkelt, monolittisk fil kalt `tex.web` som Knuth fortsetter å oppdatere hvert 7. år for å rette eventuelle gjenværende feil – ingen nye funksjoner legges noen gang til, det er utelukkende en feilrettingsøvelse.

Filendelsen til TeXs kildekode (`.web`) er neppe kjent, og du lurer kanskje på hvilket språk Knuth brukte for å skrive TeX? Svaret er Pascal, men `.web` filendelsen trenger litt mer forklaring. Knuth utviklet en programmeringsmetodikk som han kalte [litterat programmering](https://en.wikipedia.org/wiki/Literate_programming) der et programs kildekode og dokumentasjon kombineres og utgis som én sammensatt fil (kode pluss dokumentasjon) med filendelsen `.web`: denne filtypen omtales som en WEB-fil. Vi forklarer WEB-filer litt nærmere nedenfor.

### Å lage nye TeX-motorer: Knuths krav

Selv om Knuth lenge har gjort TeX-kildekoden sin (`tex.web`) fritt tilgjengelig for alle, satte han, noe som er hans fulle rett, en viktig betingelse om at hans (`tex.web`) kildekode ikke må redigeres/endres direkte og redistribueres med programnavnet «TeX». I kildekoden skriver han:

```
% Dette programmet er opphavsrettslig beskyttet (C) 1982 av D. E. Knuth; alle rettigheter forbeholdes.
% Kopiering av denne filen er bare autorisert hvis (1) du er D. E. Knuth, eller hvis
% (2) du ikke gjør noen som helst endringer i kopien din. (WEB-systemet gir
% mulighet for endringer via en hjelpefil; masterfilen skal forbli intakt.)
```

og også:

```
Hvis dette programmet endres, skal det resulterende systemet ikke kalles
`\TeX'; det offisielle navnet `\TeX' alene er reservert
for programvaresystemer som er fullt kompatible med hverandre.
En spesiell testpakke kalt ``\.{TRIP} test'' er tilgjengelig for
å hjelpe til med å avgjøre om en bestemt implementasjon fortjener å bli
kalt `\TeX' [jf.~Stanford Computer Science-rapport CS1027,
november 1984].
```

Kort sagt: ikke gjør endringer ved å redigere og distribuere modifiserte versjoner av den opprinnelige TeX-kildekoden og fortsette å kalle den `tex.web`. Hvis du vil gjøre endringer, f.eks. legge til nye primitive kommandoer osv., må du bruke disse endringene ved å gjøre «endringer via en hjelpefil» og gi programmet ditt «TeX-derivat» et navn som skiller det fra «TeX», som i typografisk form ($$\mathrm\TeX$$), er et varemerke tilhørende American Mathematical Society.

### Arven fra eldre kode

Selv om det har vært forsøk på å skrive TeX helt om ved hjelp av moderne programmeringsspråk og metodikker – som de to Java-baserte initiativene [New Typesetting System](https://en.wikipedia.org/wiki/New_Typesetting_System) og [εχTEX](http://www.extex.org/) og andre som for eksempel [ett i Clojure](https://www.infoq.com/news/2015/01/implementing-tex-in-clojure), har ingen vært helt vellykkede. Historien til prosjekter og initiativer som er utformet for å videreutvikle TeX er et interessant tema, og lesere kan ønske å [besøke UK TeX FAQ](https://texfaq.org/FAQ-enginedev) for mer informasjon.

De ikke-LuaTeX-initiativene som også har vært vellykkede, som e-TeX, pdfTeX, XeTeX og andre motorer, har bygget *direkte oppå* Knuths opprinnelige kode: ved å ta kildekoden hans og «bruke endringer» for å avlede en ny motor med ekstra funksjoner – som å legge til nye primitive kommandoer, produsere PDF-utdata, støtte UTF-8-tekstinnlesing og så videre. Selv om denne veien har ført til betydelige suksesser, betyr det også at disse avledede motorene arver den eldre koden og de utviklingsteknikkene Knuth skapte for 40 år siden.

Det viktigste her er at, bortsett fra LuaTeX, blir de fleste TeX-motorer avledet fra Knuths opprinnelige kildekode laget ved å ta én enkelt monolittisk fil (vanligvis `tex.web`) og bruke endringer som genererer nok en enkelt monolittisk fil som inneholder den nye motorens kjernekildekode. Lesere med mer forkunnskap kan ønske å hoppe videre til de kvalifiserende [notatene om pdfTeX og XeTeX](#aside-xetex-and-pdftex).

### Noe mer TeX-historikk/bakgrunn

TeXs skapelsesøyeblikk var [nedtegnet i Knuths dagbok som 30. mars 1977](/latex/no/dybdeartikler/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md#the-genesis-of-tex-a-brief-history), for over 40 år siden. Internt er TeX et usedvanlig komplekst program hvis kildekode Knuth gjorde store anstrengelser for å [dokumentere i eksepsjonell detalj](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373). For å gjøre det utviklet Knuth en programmeringsstil som han kalte [litterat programmering](https://en.wikipedia.org/wiki/Literate_programming) der et programs kildekode og dokumentasjon kombineres og utgis som en sammensatt fil med filendelsen `.web` (omtalt som en WEB-fil). Knuth valgte Pascal som programmeringsspråk for å skrive TeX-programvaren sin og brukte, ikke overraskende, TeX-typograferingsspråket til å skrive den endelige dokumentasjonen. Følgelig publiseres hovedkildekoden til Knuths TeX som én enkelt, monolittisk fil kalt `tex.web`: en blanding av Pascal-kildekode og TeX-typograferingskode for dokumentasjonen.

Hvis et program er skrevet ved hjelp av Knuths stil/metodikk for litterat programmering (slik TeX, MetaFont, BibTeX og andre er), må du forprosessere WEB-filen for å trekke ut dokumentasjonen eller kildekoden. For å få tilgang til programmets dokumentasjon behandler du WEB-filen (f.eks., `tex.web`) med et verktøy kalt [WEAVE](http://tug.org/texinfohtml/web2c.html#weave-invocation) som produserer dokumentasjonen som en `.tex` fil som du kan sette. For å trekke ut kildekoden i Pascal bruker du et annet verktøy kalt [TANGLE](http://tug.org/texinfohtml/web2c.html#tangle-invocation) som skriver ut en fil med filendelsen `.p` som inneholder Pascal-kildekode.

Da dette ble skrevet (tidlig i 2019) er den nyeste versjonen av Knuths TeX 3.14159265, datert januar 2014. Merk igjen at Knuths TeX-kildekode er samlet i bare én enkelt fil som inneholder rundt 25 000 linjer med TeX/Pascal-kode!

### Fra Pascal til C

I løpet av de over 40 årene som har gått siden TeX ble til, falt Pascal ut av moten, og i dag er det få, om noen?, som vurderer å bygge TeX fra den opprinnelige Pascal-kildekoden. For å omgå Knuths bruk av Pascal ble en arbeidsflyt kalt [Web2C](http://tug.org/texinfohtml/web2c.html) ble utviklet (omkring 1987), der TeXs Pascal-kildekode mekanisk (dvs. via programvare) konverteres til tilsvarende C-kode, som deretter brukes til å kompilere TeX og bygge det kjørbare programmet. Det fungerer bra, men den eneste ulempen er at den maskinelt genererte C-kildekoden ikke er ment for tilfeldig menneskelig gjennomlesning: den er *ekstremt* utførlig og nesten ugjennomtrengelig, ettersom den er beregnet på kompilatorer, ikke mennesker – her er et skjermbilde som viser et lite utdrag av C-koden generert fra TeXs Pascal-kilde:

![](/files/6246f273fc9c86518e0a281ee25e1e36230846b4)

### En annen Knuthisme: WEB-endringsfiler

Som nevnt ovenfor, for å bygge videre på Knuths opprinnelige kildekode «bruker du endringer» eller, med Knuths ord, gjør «endringer via en hjelpefil»: men hva betyr egentlig dette? Her kommer *mekanismen for endringsfiler*.

### Endringsfiler: mekanismen for å lage nye TeX-motorer

Utviklere som ønsker å utvide Knuths TeX på en eller annen måte, dvs. bygge videre på hans opprinnelige arbeid, ønsker vanligvis å lage en helt ny «versjon» av TeX eller tilby en *utvidelse* som kan legges til i enhver TeX-motor. Eksempler på utvidelser inkluderer [SyncTeX](https://github.com/jlaurens/synctex) og [EncTeX](https://ctan.org/pkg/enctex?lang=en)—SyncTeX er for eksempel en svært nyttig utvidelse som nå er inkludert i alle TeX-motorer. Behovet for EncTeX er i stor grad blitt overflødiggjort av utviklingen av TeX-motorer som er Unicode-bevisste – men merk at EncTeX er innebygd i pdfTeX.

Enten ønsket er å produsere en ny «versjon» av TeX (dvs. en avledning av Knuths opprinnelige TeX), eller å lage en utvidelse, starter utviklerne med Knuths opprinnelige kildekode og bruker de endringene som er nødvendige for å lage en ny TeX-motor (eller en tilleggutvidelse). Men som nevnt ovenfor må enhver som ønsker å endre TeXs oppførsel gjøre det ved hjelp av «endringer via en hjelpefil», fordi disse endringene/modifikasjonene ikke må gjøres ved *direkte* redigering av Knuths opprinnelige kildekode: utviklerne er pålagt å bruke den såkalte WEB *mekanismen for endringsfiler*. Koden for å modifisere Knuths TeX skrives i WEB-«språket» og lagres i én eller flere kodefiler (kalt *endringsfiler*) som deretter *slås sammen* med Knuths opprinnelige, urørte hovedkildekode. Denne sammenslåingsprosessen skaper en ny sammensatt WEB-fil som nå inneholder *kjerne-* kildekoden til den nye/modifiserte TeX-baserte programvaren. *Endringsfiler* har ofte filendelsen `.ch` men i praksis kan de ha hvilken som helst filendelse utviklerne ønsker.

#### Hvordan bruker/anvender du endringsfiler?

I dag er den enkleste måten å bruke endringsfiler på og endre en «master» WEB-fil ved hjelp av et hjelpeprogram kalt [TIE](https://ctan.org/pkg/tie). For eksempel kan vi anta at du ønsket å modifisere Knuths TeX ved å legge til, for eksempel, et par nye primitive kommandoer, eller at du ønsket å endre oppførselen til en eksisterende (standard) TeX-primitive. Du ville skrive koden din (i Pascal!) ved hjelp av WEB-systemet for litterat programmering og lagre den i en fil kalt, for eksempel, `myprim.ch`. Neste steg er å slå sammen koden din (i `myprim.ch`Pascal!) med Knuths hovedkildefil `tex.web` og produsere en ny, sammensatt, WEB-fil som representerer det vi vil kalle `mytex.web`. For å gjøre dette kjører du bare TIE-programmet slik:

```
tie -m mytex.web tex.web myprim.ch
```

Hvis sammenslåingen lykkes, vil dette resultere i en ny WEB-fil, `mytex.web`newmytex.web `tex.web` samtidig som Knuths hovedkildefil

La oss nå anta at noen andre liker endringene du gjorde og ønsker å modifisere arbeidet ditt for å legge sine endringer oppå, eller i tillegg til, det du har gjort. I stedet for å distribuere den modifiserte versjonen din av TeX (`mytex.web`mytex.web `myprim.ch`) bestemmer du deg for å publisere/dele bare endringsfilen, `moreprim.ch` som utvider koden din på en eller annen måte. Alle andre som ønsker å dra nytte av begge endringsfilene kan nå generere en ny sammensatt WEB-fil ved å slå sammen *begge* endringsfilene med Knuths original for å generere enda et TeX-program kalt, for eksempel, `newmytex.web`:

```
tie -m newmytex.web tex.web myprim.ch moreprim.ch
```

### Ekte TeX-systemer: flere endringsfiler

Beskrivelsen ovenfor av TIE ligger faktisk svært nær måten mange TeX-motorer bygges på i praksis: de starter med Knuths `tex.web` og legger til en rekke endringsfiler for å generere WEB-kildefilen for den motoren. Hver TeX-motor krever sitt eget spesifikke sett med endringsfiler, som må brukes/behandles (slås sammen) i en streng rekkefølge: får du rekkefølgen feil, vil sammenslåingsprosessen mislykkes fordi hver endringsfil i en sekvens er avhengig av endringer introdusert av endringsfiler som står tidligere i kjeden.

Her er en eksempelkjøring av TIE som bruker flere endringsfiler på Knuths `tex.web` for å generere `ktex.web`– den sammensatte WEB-filen med endringer i Knuths TeX som gjør den klar (egnet) for konvertering til C via Web2C-prosessen. Merk også følgende:

* `tex.ch` er en svært stor endringsfil som blant annet modifiserer TeX til å bruke Kpathsea;
* SyncTeX-utvidelsen legges til via flere endringsfiler.

```
tie -m ktex.web tex.web tex.ch enctex.ch synctex-def.ch0 synctex-mem.ch0 synctex-mem.ch2 synctex-rec.ch0 synctex-rec.ch1 synctex-rec.ch2 tex-binpool.ch
Dette er TIE, CWEB-versjon 2.4.
Opphavsrett (c) 1989,1992 av THD/ITI. Alle rettigheter forbeholdes.
(tex.web)
(tex.ch)
(enctex.ch)
(synctex-def.ch0)
(synctex-mem.ch0)
(synctex-mem.ch2)
(synctex-rec.ch0)
(synctex-rec.ch1)
(synctex-rec.ch2)
(tex-binpool.ch)
....500....1000....1500....2000....2500....3000....3500....4000....4500
....5000....5500....6000....6500....7000....7500....8000....8500....9000
....9500....10000....10500....11000....11500....12000....12500....13000
....13500....14000....14500....15000....15500....16000....16500....17000
....17500....18000....18500....19000....19500....20000....20500....21000
....21500....22000....22500....23000....23500....24000....24500....
(Det ble ikke funnet noen feil.)
```

#### Tillegg: XeTeX og pdfTeX

For fullstendighetens skyld bør vi merke oss at byggeprosessen for pdfTeX og XeTeX faktisk ikke starter med Knuths `tex.web`; i stedet starter de med filer kalt `pdftex.web` og `xetex.web` henholdsvis: antakelig fordi endringene er så omfattende at det gir mer mening å dele/publisere WEB-filer som allerede inneholder de svært betydelige modifikasjonene som er gjort i Knuths opprinnelige kode.

### Et eksempel: e-upTeX

Det japanske TeX-miljøet har utviklet en rekke TeX-motorer som er utformet for å håndtere kompleksiteten ved typografering av japansk tekst:

* **pTeX**: Knuths TeX-motor utvidet for å støtte japansk typografering;
* **e-pTeX**: en kombinasjon av e-TeX og pTeX (pluss noen få primitive kommandoer introdusert av pdfTeX);
* **upTeX**: en Unicode-bevisst versjon av pTeX pluss utvidelser for bedre håndtering av CJK (kinesisk, japansk og koreansk);
* **e-upTeX**: en kombinasjon (sammenslåing) av e-TeX og upTeX.

#### Generering av den sammensatte kildefilen for e-upTeX

For å lage den sammensatte WEB-kildefilen for e-upTeX (med SyncTeX) starter du med Knuths `tex.web` men må bruke **26** enkeltstående endringsfiler, i følgende rekkefølge, for å få én enkelt sammensatt fil som listen over primitive kommandoer kan trekkes ut fra:

```
etex.ch, tex.ch0, tex.ch, tex.ech, etex.ch0,
ptex-base.ch, uptex-m.ch, euptex.ch0, eptex.ech,
etex.ch1, euptex.ch1, synctex-def.ch0, synctex-ep-mem.ch0,
synctex-mem.ch0, synctex-e-mem.ch0, synctex-ep-mem.ch1,
synctex-p-rec.ch0, synctex-rec.ch0, synctex-rec.ch1,
synctex-e-rec.ch0, synctex-p-rec.ch1, fam256.ch,
pdfstrcmp-eup-pre.ch, pdfutils.ch, pdfstrcmp-eup-post.ch,
tex-binpool.ch
```

#### Bruk av endringsfiler: hvilke filer og i hvilken rekkefølge?

Som nevnt er det kritisk viktig å bruke/behandle endringsfiler i en streng rekkefølge – men hvordan finner du ut hvilke filer som trengs, og i hvilken rekkefølge de skal behandles? Heldigvis er denne avgjørende informasjonen registrert i filer som inngår i TeX Live-distribusjonen, og en gjennomgang av TeX Live-kildekoden avdekket reglene som styrer byggekravene for hver TeX-motor. Ved å følge disse reglene klarte Overleaf å rekonstruere den sammensatte WEB-kildefilen for hver TeX-motor og trekke ut en liste over primitive kommandoer for videre databehandling.

## Og til slutt: Hvordan trekker man ut listen over primitive kommandoer?

Når den sammensatte WEB-filen er konstruert, er oppgaven med å trekke ut listen over primitive kommandoer ved hjelp av regulære uttrykk enkel, fordi alle primitive kommandoer defineres («registreres») ved hjelp av én enkelt Pascal-funksjon kalt `primitive(...)`. Her er noen virkelige eksempler hentet fra Knuths `tex.web` kildekode:

```
primitive("lineskip",assign_glue,glue_base+line_skip_code)
primitive("baselineskip",assign_glue,glue_base+baseline_skip_code)
primitive("parskip",assign_glue,glue_base+par_skip_code)
primitive("abovedisplayskip",assign_glue,glue_base+above_display_skip_code)
primitive("belowdisplayskip",assign_glue,glue_base+below_display_skip_code)
primitive("abovedisplayshortskip",assign_glue,glue_base+above_display_short_skip_code)
...
...
```

Som du kan se, er `primitive(...)` funksjonen svært godt egnet for tekstbehandling med regulære uttrykk: navnet på den primitive kommandoen som registreres står i anførselstegn (`"..."`) sammen med tilleggsdata som klassifiserer oppførselen til hver primitive kommando (det skal vi ikke gå nærmere inn på). Etter at listen over primitive kommandoer for hver motor var trukket ut, ble disse dataene behandlet av noen Lua-skript for å generere HTML som inneholder de tabellerte resultatene.

### Tilbake til LuaTeX

Vi har merket oss at LuaTeX ikke bruker akkurat de samme byggeprosessene som de andre åtte TeX-motorene. Etter å kort ha utforsket Web2C-prosessen, konverteringen fra Pascal til C og mekanismen med endringsfiler, kan vi nå forklare hvor LuaTeX skiller seg ut: utviklerne av LuaTeX bestemte seg for å droppe den omstendelige prosessen med å konvertere Pascal til C – som det bemerkes i [LuaTeX Reference Manual](http://www.pragma-ade.com/general/manuals/luatex):

> ... kompileringsrammeverket er web2c, og vi fortsetter å bruke det, men uten steget fra Pascal til C.

Kjernen i LuaTeX-motoren ble skrevet om i C, noe som betyr at byggeprosessen er noe mer standard og definitivt langt mer praktisk. En nyttig konsekvens er at de primitive kommandoene som støttes av LuaTeX, er pent skilt ut i en egen C-kildekodefil, noe som i betydelig grad forenklet oppgaven med å få tilgang til/oppføre dem.

Strengt tatt bør vi også merke oss at noen av LuaTeXs kildekodefiler bruker en variant av Knuths metodikk for litterat programmering, kalt [CWEB](https://en.wikipedia.org/wiki/CWEB), som er basert på C og ikke Pascal.

### Ikke bare WEB-filer: annen kildekode er nødvendig

Etter å ha generert den sammensatte WEB-kildefilen for enhver TeX-motor (unntatt LuaTeX) må Pascal-kildekoden trekkes ut og konverteres til C-kode, men det er ikke hele løsningen. I tillegg til C-koden som genereres fra WEB-kilden (Pascal⮕C), er de fleste TeX-motorer også avhengige av (krever) en rekke ytterligere tilleggsfiler med kildekode (biblioteker) som vanligvis er skrevet i C—slik som [Kpathsea](https://www.tug.org/kpathsea/). Tilleggsfiler med kildekode (biblioteker) implementerer funksjonalitet som ikke trenger, eller ikke kan, skrives i WEB (Pascal). Alt som skrives i WEB-«språket» for TeX må bruke Pascal-språket, som deretter trekkes ut og konverteres til maskin-generert C: hvis du ikke trenger å gjøre det, hvorfor ikke bare skrive det i C eller C++ fra begynnelsen av.


---

# 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/flere-emner/18-how-overleaf-created-the-tex-primitive-reference-data.md?ask=<question>&goal=<endgoal>
```

`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.