> 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/da/dybtgaende-artikler/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md).

# En introduktion til LuaTeX (del 1): Hvad er det — og hvad gør det så anderledes?

LuaTeX er et *værktøjssæt*—det indeholder sofistikerede softwareværktøjer og komponenter, som du kan bruge til at konstruere (sætte op) en bred vifte af dokumenter. Undertitlen til denne artikel stiller også to spørgsmål om LuaTeX: Hvad er det—og hvad gør det så anderledes? Svaret på “Hvad er det?” kan synes indlysende: “Det er en TeX-satsmotor!” Det er det ganske rigtigt, men et bredere synspunkt, som denne forfatter tilslutter sig, er, at LuaTeX er et ekstremt alsidigt TeX-baseret *system til dokumentkonstruktion og -engineering*.

### Forklaring af LuaTeX: Hvor skal man begynde?

Målet med denne første artikel om LuaTeX er at give en kontekst for at forstå, hvad denne TeX-motor tilbyder, og hvorfor/hvordan dens design gør det muligt for brugere at bygge/designe/skabe en bred vifte af løsninger til komplekse satsnings- og designproblemer—og måske også tilbyde en vis grad af “fremtidssikring”, i takt med at brugere i stigende grad har brug for TeX-baseret software, som er i stand til at tilpasse sig det stadigt skiftende tekniske økosystem. Efter denne forfatters mening er det ikke nødvendigvis det bedste sted at begynde at liste og beskrive dens funktioner/egenskaber, når man vil udvikle en forståelse af LuaTeX’s muligheder og potentiale. En sådan tilgang vil ikke være særligt hjælpsom for læsere, der ikke er bekendt med andre TeX-motorer, og for hvem funktionsbaserede sammenligninger næppe vil være særligt meningsfulde.

Med risiko for at udtømme læserens tålmodighed (“Bare kom til sagen!”) vil jeg anlægge en mere “holistisk” tilgang, forhåbentlig med nyttig baggrund, men på bekostning af lidt ekstra læsning—og en smule dyk ned i programmeringsemner for at hjælpe forståelsen. I [Del 2](/latex/da/dybtgaende-artikler/09-an-introduction-to-luatex-part-2-understanding-directlua.md) vil vi udforske brugen af `\directlua` men indtil videre forsøger vi at lægge det grundlæggende fundament for at forstå LuaTeX.

Denne artikel afspejler i høj grad forfatterens personlige “rejse” i at udvikle en forståelse for og værdsættelse af LuaTeX: at man ved først at vide noget om filosofien bag LuaTeX’s udvikling og ved at se det som en beholder af softwareværktøjer, vil man bedre kunne værdsætte de omfattende løsningsområder, som denne fantastiske software åbner op for.

## LuaTeX: Ikke kun til akademia eller matematik!

De mange funktioner og muligheder, der er indbygget i LuaTeX, giver ikke blot særdeles høj kvalitet i satsning via traditionel LaTeX, men de tilbyder også et enormt spillerum for at udvikle skræddersyede løsninger, der ikke er baseret på LaTeX, til komplekse problemer inden for dokumentproduktion og -engineering. LuaTeX har det kraftfulde scriptsprog Lua indlejret, hvilket for eksempel betyder, at du kan bruge Lua til at indlæse “plugins” (eksterne softwarebiblioteker) i LuaTeX; dette muliggør yderligere høje niveauer af automatisering, integration i eksisterende softwaresystemer eller workflows og udnyttelse af specialiseret software til data-, tekst- eller billedbehandling.

Historisk set har TeX været forbundet med videnskabelig forfatterskab/udgivelse, især inden for matematik, men LuaTeX har især et betydeligt potentiale til anvendelse inden for mange andre domæner—herunder kommerciel PDF-dokumentproduktion. Et sådant eksempel er [speedata publisher](https://speedata.github.io/publisher/) som udelukkende bruger LuaTeX som PDF-genereringsmotor i sit XML-baserede workflow—det bruger slet ikke LaTeX. Faktisk indeholder speedata publisher praktisk talt ingen TeX-kode—jeg spurgte [Patrick Gundlach](https://twitter.com/patrickgundlach), speedata publishers udvikler, som bekræftede, at det i alt bruger omkring tre linjer TeX-kode. Dets kraftfulde satsningsmuligheder er designet og implementeret i Lua-kode ved hjælp af LuaTeX’s Lua-API (et emne, vi behandler senere i denne artikel).

## En kort personlig historie: Hvordan jeg først opdagede LuaTeX

Jeg fandt første gang ud af LuaTeX i slutningen af 2009/begyndelsen af 2010, da det stadig var i midt-beta-udviklingsfasen (version 0.50). På det tidspunkt ledte jeg efter TeX-baseret software til at sætte de håndskrevne noter op, som blev resultatet af mine bestræbelser på at lære lidt arabisk. Google-søgninger afslørede en samling videoer fra TUG 2009-konferencen ([nu på YouTube](https://www.youtube.com/playlist?list=PL2D4DD50DC9C0BA0E)) som bl.a. indeholdt demonstrationer af meget høj kvalitet i arabisk satsning (via Hans Hagens [ConTeXt-pakke](http://wiki.contextgarden.net/Main_Page)). Disse videoer indeholder også et foredrag med titlen [LuaTeX-projektet: halvvejs til version 1](https://youtu.be/AKv4po9PGW0).

Den TeX-motor, der blev brugt til at frembringe den udsøgte arabiske satsning, var noget, der hed “LuaTeX”. På det tidspunkt arbejdede jeg med videnskabelig (fysik)udgivelse, men selv om jeg var fuldt ud klar over TeX/LaTeX, havde jeg ikke hørt om LuaTeX: jeg blev nysgerrig og ville lære mere om denne nye TeX-motor. Fordi LuaTeX stadig var i beta-udviklingsstadiet og undergik hurtig udvikling, ville jeg følge de allernyeste opdateringer, så den bedste løsning (for mig) var gør-det-selv-vejen med at bygge (kompilere) LuaTeX-eksekverbaren fra dens kildekode. Ud over det eksekverbare LuaTeX-program har du også brug for en “TeX-installation” for at levere det miljø, som LuaTeX kører i (f.eks. texmf.cnf, makropakker, skrifttyper osv.). I stedet for at downloade og installere den enorme [TeX Live](https://www.tug.org/texlive/) distribution valgte jeg at lave en helt minimal, skræddersyet TeX-installation, som jeg kunne udforske LuaTeX med (en “interessant” øvelse, som jeg [dokumenterede på min personlige blog](http://www.readytext.co.uk/?cat=30)). Hver ny udgivelse af LuaTeX ledsages af dens Reference Manual (f.eks. for[version 1.0.4](https://www.tug.org/svn/texlive/tags/texlive-2017.1/Master/texmf-dist/doc/luatex/base/luatex.pdf?revision=44591\&view=co)) som dokumenterer softwarets nyeste funktioner og muligheder. Det er dog en *reference* manual og er (nødvendigvis) ganske sparsom med forklaringer, der er egnede for begynderen, som gerne vil i gang med denne utrolige TeX-motor—en vis fortrolighed med TeX på lavt niveau forudsættes. Da jeg opdagede LuaTeX på et relativt tidligt tidspunkt i dens udvikling, var godt introduktionsmateriale dengang relativt svært at finde, så det krævede lidt udforskning, eksperimentering (og en del frustration…) før brikkerne begyndte at falde på plads. Det siger sig selv, at mine arabiskstudier kom til en brat afslutning, mens jeg blev fascineret af denne fantastiske software og til sidst gik over til at skrive LuaTeX [plugins til arabisk satsning](http://www.readytext.co.uk/?p=3143) i stedet!

Min egen “LuaTeX-rejse” var bestemt meget ikke-lineær, men undervejs gav den mulighed for at lære (Lua)TeX (og TeX-installationer) “fra bunden”: min blog rummer en eklektisk samling af [artiklerne](http://www.readytext.co.uk/?cat=3) baseret på forskellige emner, som jeg udforskede og arbejdede på i den periode. Forhåbentlig gør denne artikel passende brug af den tid og erfaring og hjælper andre med at blive interesserede i at begynde at udforske LuaTeX’s muligheder. LuaTeX bliver fortsat udviklet, og på tidspunktet for skrivningen er det nået version 1.0.4, som blev udgivet med TeX Live 2017. Udviklerne er meget aktive, og eventuelle fejl, der opdages, bliver normalt rettet kort efter, at de er rapporteret—f.eks. via [dev-luatex-mailinglisten](https://mailman.ntg.nl/mailman/listinfo/dev-luatex) eller via den [online LuaTeX-fejlfinder](http://tracker.luatex.org/my_view_page.php). Langt før den nåede version 1.0, var LuaTeX produktionsklar—selvfølgelig måtte man acceptere, at funktioner hele tiden udviklede sig, og at ændringer indimellem kunne ødelægge ens eksisterende TeX-kode. I dag understøttes LuaTeX naturligvis af Overleaf- og ShareLaTeX-platformene (som LuaLaTeX).

## TeX i en foranderlig verden: Nye teknologier og workflows

Det er klart, at TeX-motorer ikke fungerer i en teknologisk statisk verden, og indimellem opstår innovationer, som straks og tydeligt er oplagte kandidater til at blive indarbejdet i TeX-motorer—én sådan innovation er OpenType variable skrifttyper, som vi kort gennemgår nedenfor. Selvom der næppe er tvivl om, at TeX-baseret satsningssoftware er ekstraordinært alsidig, opererer TeX-motorer nu inden for et hurtigt skiftende og meget forskelligt softwareøkosystem—nye workflows understreger behovet for integration og fleksibiliteten til at implementere en bred vifte af dokument-/satsningsløsninger, hvoraf TeX måske kun er én komponent.

TeX skal ikke blot forblive relevant for sine nuværende brugere, men også tiltrække nye ved at muliggøre løsninger til indholdsproduktion, som forbliver nyttige for kommende generationer—mennesker, der måske ikke nødvendigvis ønsker at bruge TeX som et selvstændigt værktøj, men måske som en del af et samlet workflow via online samarbejdsplatforme som Overleaf.

Selv et kort kig på [tex.stackexchange](https://tex.stackexchange.com/) demonstrerer den enorme mangfoldighed af dokumenter og løsninger, der produceres og implementeres med TeX-baseret software—ofte med en utrolig opfindsomhed, efterhånden som folk finder stadig flere anvendelsestilfælde og indholdstyper, de ønsker at generere. Derudover har behovet for workflows, der kan behandle TeX-baseret markup/indhold for at producere output, der ikke er PDF (og ikke DVI), aldrig været større—såsom MathML/XML og HTML. For eksempel at “konvertere” TeX til [JATS XML](https://jats.nlm.nih.gov/) formatet (længe brugt inden for videnskabelig tidsskriftsudgivelse), men også, mere nyligt, fremkomsten af epub brugt inden for e-bogsudgivelse.

### Variabel skrifttype-teknologi—Tiderne skifter

Den 14. september 2016 annoncerede Microsoft, [Google](https://opensource.googleblog.com/2016/09/introducing-opentype-font-variations.html), [Adobe](https://blog.typekit.com/2016/09/14/variable-fonts-a-new-kind-of-font-for-flexible-design/) og Apple en ny skrifttype-teknologi: [OpenType variable skrifttyper](https://medium.com/@tiro/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369). Vi vil ikke udforske denne teknologi i detaljer, men det er nok at sige, at højt respekterede skrifteksperter som [Thomas Phinney](https://twitter.com/ThomasPhinney) og [John Hudson](https://twitter.com/TiroTypeworks) har bemærket ([på Twitter](https://twitter.com/ThomasPhinney/status/917087509342851072)) at variabel-skrifttype-teknologi bliver taget i brug langt hurtigere end mange tidligere skriftnyskabelser—højst sandsynligt drevet af behovene hos webdesignere, der kræver responsive designs, som tilpasser sig de mange forskellige skærmstørrelser/-opløsninger på mobile enheder.

Det er klart, at OpenType variable skrifttyper er en interessant og spændende udvikling inden for skrifttypeteknologier, noget som TeX-brugere uden tvivl kunne få gavn af—faktisk er dette spørgsmål uundgåeligt blevet [rejst på tex.stackexchange](https://tex.stackexchange.com/questions/355104/tex-luatex-xetex-fontspec-support-for-opentype-variable-fonts) med LuaTeX’s understøttelse diskuteret på LuaTeX [mailinglisten](https://www.tug.org/pipermail/luatex/2016-September/006204.html).

I forbifarten er det værd at bemærke, at skrifttype-teknologi baseret på “parametrisk” skrifttypeoprettelse ikke er en helt ny idé: Knuths METAFONT og Adobes Multiple Master-teknologier er på nogle måder tidlige forløbere, selv om implementeringsdetaljerne er ganske forskellige.

### Variable skrifttyper: Hvornår vil vi have dem—nu?

Enhver ny og nyttig teknologistandard/-specifikation har brug for tid til at “bryde ind” i sit måløkosystem af udviklere og implementører—herunder tid til at få afklaret eventuelle tvetydigheder eller fortolkninger af formuleringer i selve specifikationen. Udviklere skal læse og forstå dokumentationen og omsætte den til reel fungerende software—hvilket her inkluderer at skabe skrifttyperne og de teknologier, der bruger dem: kompatible browsere og satsmotorer. TeX-udviklere vil tydeligvis have brug for adgang til variable skrifttyper af høj kvalitet, som kan bruges som pålidelige “benchmarks” til at implementere (programmere) understøttelse af variable skrifttype-teknologier.

Implementeringen af enhver ny teknologi i TeX, såsom variable skrifttyper, rejser det *potentielle* behov for at ændre i TeX-motorernes indre—selvfølgelig afhænger behovet for at gøre det af teknologiens natur og, afgørende, hvilket aspekt af TeX’s opførsel der underkastes ændring. Det er ikke altid nødvendigt at ændre selve TeX-motorerne; det kan måske kun kræve ændringer i understøttende/tilknyttet software, herunder eventuelle “komponenter” (tredjeparts biblioteker af kode), der bruges i disse programmer. Internt er TeX-motorer *djævelsk* komplekse—at udvikle en forståelse af TeX’s kildekode, som er tilstrækkelig til at foretage pålidelige ændringer, kræver betydelig og højt specialiseret ekspertise (hvor der er et meget begrænset udbud). Det er også afgørende, at eventuelle ændringer ikke påvirker TeX-motorernes langsigtede stabilitet/kompatibilitet negativt—hvilket er vitalt for TeX-fællesskabet og for dem, der efterfølgende behandler en forfatters (La)TeX-fil(er): især akademiske forlag og cloud-baserede tjenester som Overleaf og ShareLaTeX.

Mange TeX-brugere vil sandsynligvis være interesserede i at udnytte variable skrifttyper; for eksempel ved at implementere nye designmuligheder eller finde løsninger på vanskelige satsningsproblemer. Så på en måde er der et dilemma: TeX-brugere, der ønsker adgang til en ny teknologi, men dens implementering afhænger af en meget begrænset ressource: antallet af udviklere, der er kvalificerede og i stand til at få det til at ske. Ændring af TeX’s indre er vanskeligt og bør generelt undgås, hvor det er muligt, så findes der en anden måde at tilføje nye funktioner/egenskaber af visse typer til TeX? Ja! og LuaTeX har valgt den vej.

#### Tidlige eksperimenter: OpenType variable skrifttyper og LuaTeX

LuaTeX’s design har muliggjort hurtige eksperimenter med variabel skrifttype-teknologi. Allerede i april 2017 havde ConTeXt TeX-formatet, som bruger LuaTeX, en [betaversion](https://mailman.ntg.nl/pipermail/ntg-context/2017/088343.html) som implementerede OpenType variable skrifttyper. Dette var muligt, fordi ConTeXts skrifttypeunderstøttelse er indbygget i Lua-kode (og ConTeXt har sin egen fontloader skrevet i Lua).

## LuaTeX: Baggrund og historie

LuaTeX er, i TeX-termer, “den nye dreng i klassen”, på trods af at det har været under aktiv udvikling i over 10 år. LuaTeX-webstedet [dokumenterer](http://www.luatex.org/roadmap.html) at LuaTeX begyndte i 2005 med (så vidt jeg ved) aktiv og vedvarende udvikling, der begyndte i 2006. På grund af dens iboende kompleksitet og den omhu, som dem, der byggede det, udviste, tog det virkelig 10 års udvikling, før LuaTeX nåede version 1.0, som blev [annonceret af dens udviklere](https://mailman.ntg.nl/pipermail/dev-luatex/2016-September/005882.html) (Hans Hagen, Hartmut Henkel, Taco Hoekwater, Luigi Scarso) den 27. september 2016.

I denne udgivelsesmeddelelse er der en vigtig principerklæring:

> “Vores hovedmål er at levere en variant af TeX, der tillader brugerudvidelser uden behov for at tilpasse det indre virke.”

Denne formulering indkapsler perfekt filosofien bag LuaTeX’s udvikling og peger på en vej, hvorigennem TeX-baseret software kan håndtere de udfordringer, vi allerede har nævnt: at tage nye teknologier i brug og forblive relevant for nye generationer af brugere.

Det er nu tid til at tage fat på det andet spørgsmål i denne artikels undertitel: “hvad gør det så anderledes”. Ved at udforske betydningen af “...tillader brugerudvidelser uden behov for at tilpasse det indre virke” kan vi bedre forstå essensen af det, LuaTeX “bidrager med”.

## LuaTeX: At åbne TeX’s “black box”

Knuths oprindelige TeX-program er den fælles stamfader til alle moderne TeX-motorer, der bruges i dag, og LuaTeX er i virkeligheden det seneste evolutionære skridt: afledt af pdfTeX-programmet, men med tilføjelsen af nogle kraftfulde softwarekomponenter, som tilfører en stor mængde ekstra funktionalitet. Da Knuth skrev den oprindelige version af TeX-softwaren, leverede han også TeX-sproget som en måde at styre og programmere dets satsningsadfærd på: omkring 320 kommandoer på lavt niveau (primitiver) blev gjort tilgængelige for brugere og udviklere af TeX-makropakker. Disse kommandoer tilbød forskellige grader af kontrol eller indflydelse over visse aspekter af TeX’s satsningsadfærd, men meget af TeX’s interne funktionalitet, algoritmer, beslutningsprocesser, data og datastrukturer var skjult for brugeren. Man kan hævde, at Knuths TeX-program ikke var en helt “black box”, men bestemt en meget mørk grå nuance—det er rigtigt, at kildekoden blev gjort tilgængelig, men for langt de fleste mennesker er det også en black box af uforståelighed.

Vi omtaler de interne processer i TeX som en slags “black box”; LuaTeX åbner imidlertid sine TeX-baserede internals op og giver brugere/udviklere langt større adgang til og kontrol over mange af de engang skjulte processer, der foregår dybt inde i TeX-motoren. LuaTeX tilføjer også mange nye primitive kommandoer, som giver kontrol over de nye funktioner.

### LuaTeX: Afledt af pdfTeX, men bruger ikke pdfTeX’s kode

For at være præcis er det vigtigt at bemærke, at selv om vi beskrev LuaTeX som afledt af pdfTeX, bruger LuaTeX ikke direkte pdfTeX’s oprindelige programkode. En af LuaTeX’s udviklere (Taco Hoekwater) udførte den virkelig *Herkulesagtige* opgave at omskrive LuaTeX’s kerne-TeX-motor i ren, moderne C-kode (CWEB).

#### Historisk note

Delvist på grund af alderen på Knuths oprindelige TeX-kildekode—hvorfra dens moderne efterkommere er afledt—er det en kompleks og indviklet proces at ændre den for at tilpasse eller skabe nye TeX-baserede satsningsmotorer. En del af den proces kræver konvertering af Pascal-kode til C-kode—hvilket ikke er uden en [vis grad af kompleksitet](http://www.readytext.co.uk/?p=2529). Den resulterende maskin-genererede C-kode er usædvanligt ordrig og meget svær at læse eller forstå. Det er klart, at det, at LuaTeX’s kode er omskrevet fuldstændigt, omgår hele Pascal-til-C-konverteringsprocessen.

## LuaTeX’s byggesten

I introduktionen henviste vi til, at LuaTeX er et “værktøjssæt” og beskrev det som et “system til dokumentkonstruktion og -engineering”. Vi har set, at udviklerne i LuaTeX 1.0-annoncen udtalte:

> “Vores hovedmål er at levere en variant af TeX, der tillader brugerudvidelser uden behov for at tilpasse det indre virke.”

Det er nu tid til at samle disse tråde og ideer og fokusere på detaljerne i, hvad alt dette *faktisk betyder* i praksis.

### LuaTeX-puslespillet

Hvis du kiggede “under motorhjelmen”, ville du se, at LuaTeX-softwaren, dvs. det faktiske eksekverbare program, er konstrueret af en samling softwarekomponenter, der er kombineret for at levere LuaTeX’s samlede funktionalitet. Det er naturligvis ikke noget nyt, og det meste software er opbygget sådan. Det, der gør LuaTeX anderledes end andre TeX-motorer, er imidlertid, at disse komponenter er kombineret på en sådan måde, at brugerne får langt større adgang til mange aspekter af TeX’s interne funktionalitet: TeX’s satsningsalgoritmer, beslutningsprocesser, data og datastrukturer. Denne åbning af TeX’s internals gør det muligt for brugerne at konstruere nye satsningsløsninger uden behov for at ændre selve TeX-motoren.

### Lua i LuaTeX: En nøgle til “black box”

Lua er et meget kraftfuldt, men let at lære, scriptsprog, som [har sin oprindelse i Brasilien](https://www.lua.org/about.html)—det blev skabt i 1993 og udvikles stadig aktivt. En af Lúas styrker er dets brug som et programmeringssprog, hvormed man kan “lime” forskellige softwarekomponenter sammen og dermed bruge dem via et simpelt, men alsidigt scriptsprog. Lua spiller en central rolle i at åbne op for LuaTeX-teX-motorens indre virke, men for bedre at forstå, hvordan dette opnås, er det værd at tage en kort afstikker og meget kort diskutere to programmeringsbegreber:

* Application Programming Interface (API);
* binding til et programmeringssprog.

Du er velkommen til at springe dette afsnit over, hvis du er fortrolig med disse begreber. Ingen af emnerne vil blive gennemgået i detaljer—vi sigter ikke efter streng teknisk stringens, men efter at give lige præcis tilstrækkelig baggrund til at være opmærksom på disse begreber: deres betydning og relevans for LuaTeX.

### Application Programming Interface (API)

Forestil dig, at du er en programmør, som har skrevet noget kode, som brugere (andre programmører) kunne finde nyttig, men din kode er kompleks, og du ønsker ikke, at brugerne af din kode skal bekymre sig om de detaljer på lavt niveau. Bemærk, at disse programmører/udviklere arbejder med det samme programmeringssprog, som du brugte til at skrive din kode. Forestil dig desuden, at du har planer om at omskrive dele af din kode—f.eks. for at gøre den hurtigere, kræve mindre hukommelse og så videre. Eksisterende brugere af din kode bør ikke behøve at bekymre sig om det: eventuelle ændringer, du planlægger at foretage, bør ikke ødelægge deres programmer. Hvad er så løsningen?

Svaret ligger i noget, der kaldes en API: en *Application Programming Interface*. I stedet for at kræve, at brugerne (andre programmører) får adgang til de detaljer på lavt niveau i din kode—which kan ændre sig—leverer du et specifikt sæt af *funktioner* som andre programmører kan bruge. Disse funktioner er en *grænseflade* til din kode, som andre udviklere kan bygge *applikationer* uden at have indgående kendskab til dit programs indre virke. På nogle måder kan man tænke på dette som et ekstra lag, der omslutter din kode og “isolerer” brugerne fra de rodede detaljer på lavt niveau.

Forudsat at du ikke ændrer disse funktioner (grænsefladen), står du frit til at ændre og opdatere detaljerne på lavere niveau i din software uden at påvirke (ødelægge) arbejdet for dem, der er afhængige af din kode til at bygge deres applikationer: deraf betegnelsen Application Programming Interface.

#### API’er: en analogi til en LaTeX-pakke

Når du bruger kommandoer, som leveres af en LaTeX-pakke, kan du betragte pakkens kommandoer som en form for API. Som bruger er du ikke nødvendigvis optaget af den TeX- og LaTeX-magi, der ligger bag disse kommandoer (dvs. i pakkens kode): alt, hvad du ønsker, er at bruge den funktionalitet, de leverer.

### Binding til et programmeringssprog

Vi har set, at programmører, der skriver/publicerer en samling nyttig kode (kaldet et *bibliotek*), kan levere en såkaldt Application Programming Interface (et sæt funktioner), hvorigennem andre programmører, der bruger det *samme* programmeringssprog, kan gøre brug af det bibliotek (samling af kode). Det er fint, når begge sider (biblioteksudvikleren og dens brugere) bruger det *samme* programmeringssprog, men hvad sker der, hvis programmører, der bruger et *andet* programmeringssprog, også ønsker at gøre brug af det bibliotek? Du kan for eksempel skrive scripts i Lua-sproget, men ønsker at gøre brug af et bibliotek skrevet i f.eks. programmeringssprog som C/C++. På en eller anden måde skal de to forskellige programmeringssprog (Lua og C/C++) have mulighed for at “kommunikere” med hinanden. En løsning på dette problem er den såkaldte [sprogbinding](https://en.wikipedia.org/wiki/Language_binding).

Undersøgelse af de tekniske detaljer ved sprogbinding ligger uden for denne artikels rammer, så vi giver en kort sammenfatning af de generelle principper. I det væsentlige kan man ved at tilføje et passende ekstra “lag” af kode til det oprindelige bibliotek få det til at “kommunikere” med et andet programmeringssprog (såsom Lua): det lag kode kaldes en *binding*. Det gør det muligt for de to sprog at arbejde sammen via en API, som programmører i det andet sprog (såsom Lua) kan bruge til at få adgang til de funktioner/tjenester, som biblioteket leverer.

![Skematisk diagram, der viser begrebet en sprogbinding.](/files/b9a362f4b9f8f66410b89b28b964aa3407e697c0)

**Figur 1**Skematisk diagram, der viser begrebet en sprogbinding: som gør det muligt for et program skrevet i Lua at bruge et eksternt bibliotek skrevet i et andet programmeringssprog. Det er gennem brugen af Lua-bindinger, at de interne komponenter i LuaTeX, og dermed meget af LuaTeX’s interne satsningsfunktionalitet, bliver gjort tilgængelige, så brugere kan udvikle løsninger til komplekse satsningsproblemer.

## LuaTeX: To muligheder for programmering—TeX og Lua

Grundlæggende er LuaTeX en TeX-motor, der understøtter to programmeringssprog: det traditionelle TeX-baserede sprog og scriptsproget Lua. Du kan naturligvis bruge begge sprog i det samme TeX-dokument eller, hvis du foretrækker det, fortsætte med at sætte op gennem TeX-only-ruten: for eksempel via makropakken LaTeX (LuaLaTeX). TeX (eller LaTeX) er ikke et let programmeringssprog at bruge eller lære, og relativt få mennesker har virkelig mestret TeX’s mange særheder—TeX’s begreber om [tokens](https://www.overleaf.com/blog/522-what-is-a-tex-token) og ekspansion er ret fremmede for de flestes forventninger til og erfaringer med et programmeringssprog.

Tilføjelsen af Lua åbner muligheden for at bruge TeX-baseret satsning via et langt mere tilgængeligt og konventionelt programmeringssprog—som bemærket i begyndelsen af denne artikel kan du ved at bruge Lua-API'et udføre [sofistikeret satsning med praktisk talt ingen TeX-kode](http://wiki.luatex.org/index.php/TeX_without_TeX).

### LuaTeX tilføjer mange nye primitiver

Hver TeX-motor leverer hundredvis af såkaldte primitive kommandoer: de grundlæggende byggesten i det TeX-baserede sprog, som understøttes af hver enkelt satsmotor. Den oprindelige version af TeX, udgivet af Donald Knuth, leverede cirka 320 kommandoer, men nyere TeX-motorer (pdfTeX, XeTeX og LuaTeX) har hver især tilføjet mange nye primitiver for at give brugerne adgang til hver motors ekstra funktioner og muligheder. LuaTeX’s betydelige antal nye primitiver er dokumenteret i dens [Reference Manual](https://www.tug.org/svn/texlive/tags/texlive-2017.1/Master/texmf-dist/doc/luatex/base/luatex.pdf?revision=44591\&view=co).

Blandt de mange nye primitiver, som LuaTeX introducerer, er én, der kaldes `\directlua{...}` som er indgangen til at bruge Lua-kode: adgang til LuaTeX-motorens internals for at bygge sofistikerede satsningsværktøjer og løsninger.

### \directlua{...}: Indgangen til Lua-programmering

Som diskuteret kan Lua-scriptsproget ses som et “lag”, hvorigennem det er muligt at få adgang til LuaTeX’s TeX-baserede satsmotor og den funktionalitet, som leveres af mange af de komponenter, LuaTeX er opbygget af. Lua-sproget er også den mekanisme, som muliggør LuaTeX’s udvidelsesmuligheder—gennem Lúas evne til at indlæse specialiserede eksterne biblioteker af software/kode.

Samlet set omtales den Lua-grænseflade (sæt af Lua-baserede funktioner), som LuaTeX stiller til rådighed, som dens *Lua-API*: det er “kommunikationsforbindelsen” mellem LuaTeX’s interne motor/komponenter og brugerens dokument.

### Et simpelt eksempel på \directlua{...}

Følgende *ekstremt simpelt* eksempel begynder ikke engang at ridse overfladen af mulighedernes isbjerg. Det tjener dog til at demonstrere den grundlæggende idé om samspillet mellem den “TeX-måde” og den “Lua-måde” at få adgang til TeX’s parametre på.

Bemærk at:

* `\hsize` er en TeX-primitive (kommando), som sætter værdien af en intern parameter, der bestemmer bredden af satte linjer—for eksempel sætter man den normalt til en passende værdi i en `\vbox{...}`. `\hsize` er blot én af *mange* TeX-parametre, som du kan få adgang til og/eller ændre ved hjælp af Lua-kode.
* Adgang til TeX-parametre er kun en *lille* del af LuaTeX’s Lua-API: der er så meget mere!

```latex

\documentclass{article}
\begin{document}
\let\\\relax % omdefinér betydningen af \\ for at undgå ekspansionsproblemer
Her er den aktuelle værdi af {\ttfamily\string\hsize} (via \LaTeX):
\the\hsize\par
\directlua{
%Hent den aktuelle værdi af \hsize ved hjælp af Lua-API'et
local hs=tex.hsize
% Brug en Lua-API-funktion til at udskrive noget
% LaTeX-kode og værdien af \hsize
tex.print("Her er værdien af {\\ttfamily\\string\\hsize}
rapporteret fra Lua-kode (i skalerede punkter): ")
tex.print(hs.."\\par")
% Sæt en ny værdi for \hsize ved hjælp af Lua-API'et
tex.hsize="400pt" % eller brug tex.hsize=400*65536 (i skalerede punkter)
}%
% Når \directlua er færdig, så bed LaTeX
% om at fortælle os den nye værdi af \hsize
Her er værdien af {\ttfamily\string\hsize} rapporteret
af \LaTeX{} efter at {\tt\string\directlua} er færdig:
\the\hsize\par
\end{document}
```

Her er et billede, der viser resultatet af LuaTeX's satsning af LaTeX-koden (ovenfor):

![Resultat af kørsel med LuaTeX](/files/08a9907981f9cfd965beb47cdb4989b0d5f745e3)

Bemærk, at TeX-"tricket" med `\let\\\relax` er for at undgå problemer forårsaget af LuaTeX’s “ekspansion” af Lua-koden: et emne, vi kort nævner nedenfor.

### Brug af Lua-kode

Der er to hovedmuligheder for at bruge Lua-kode i dine TeX/LaTeX-dokumenter:

1. **Indlejret**: At skrive Lua-kode direkte i dit `.tex` dokument (som i eksemplet ovenfor);
2. **Ekstern**: At gemme Lua-kode i eksterne `.lua` kodefiler og bruge Lúas faciliteter til at indlæse og køre dem.

Mulighed (1) egner sig bedst til kortere fragmenter af Lua-kode. Mulighed (2) bruges til større programmer eller biblioteker af Lua-kode. Den har den klare fordel, at du kan undgå vanskelige problemer, der involverer TeX’s såkaldte `\catcode` værdier (som kan være “temmelig frustrerende”). Årsagen til disse `\catcode` problemer er “ekspansionen” af Lua-kode, før den fødes ind i LuaTeX’s indbyggede Lua-fortolker. Denne ekspansion kan være vanskelig at forstå, så vi vil udforske den nærmere i en senere artikel.

Der findes naturligvis LaTeX-pakker, som kan hjælpe med at bruge Lua-kode i dine .tex-filer—for eksempel kan du bruge [luacode-pakken](https://ctan.org/pkg/luacode?lang=en).

## Opsummering og introduktion til del 2 af denne artikel

De softwarekomponenter, som LuaTeX er bygget af, sammen med det indlejrede Lua-scriptingsprog, udgør en kraftfuld kombination til at opbygge løsninger, der er i stand til at løse en bred vifte af komplekse satsningsproblemer — og til at udvikle arbejdsflows for dokumentproduktion, som kan drage fordel af tæt integration med en TeX-baseret satsningsmotor. I [Del 2 af denne artikel](/latex/da/dybtgaende-artikler/09-an-introduction-to-luatex-part-2-understanding-directlua.md) ser vi nærmere på den mest kraftfulde kommando, som LuaTeX tilbyder: `\directlua`.

Indtil da, god LuaTeX'ing!

## Tak

Forfatteren er yderst taknemmelig over for [Luigi Scarso](https://twitter.com/luigi_scarso), en af LuaTeX’s udviklere, for at have taget sig tid til at læse et udkast til denne artikel og komme med en række meget hjælpsomme kommentarer og forslag. Eventuelle resterende faktuelle fejl eller udeladelser er naturligvis forfatterens. Derudover vil jeg gerne takke [Patrick Gundlach](https://twitter.com/patrickgundlach), udvikler af [speedata publisher](https://speedata.github.io/publisher/), for at han tog sig tid til at besvare mine spørgsmål.


---

# 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/da/dybtgaende-artikler/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.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.