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

# En introduksjon til LuaTeX (del 1): Hva er det — og hva gjør det så annerledes?

LuaTeX er et *verktøysett*—det inneholder avanserte programvareverktøy og komponenter som du kan bruke til å konstruere (typesette) et bredt spekter av dokumenter. Undertittelen til denne artikkelen stiller også to spørsmål om LuaTeX: Hva er det — og hva gjør det så annerledes? Svaret på «Hva er det?» kan virke opplagt: «Det er en TeX-settemotor!» Det er det riktignok, men et bredere syn, som denne forfatteren deler, er at LuaTeX er et ekstremt allsidig TeX-basert *dokumentkonstruksjons- og ingeniørsystem*.

### Forklaring av LuaTeX: Hvor skal man begynne?

Målet med denne første artikkelen om LuaTeX er å tilby en kontekst for å forstå hva denne TeX-motoren tilbyr og hvorfor/hvordan designet dens gjør det mulig for brukere å bygge/designe/skape et bredt spekter av løsninger på komplekse settek- og designproblemer—kanskje også ved å tilby en viss grad av «framtidssikring» ettersom brukere i økende grad trenger TeX-basert programvare som kan tilpasse seg det stadig skiftende tekniske økosystemet. Etter denne forfatterens mening er det ikke nødvendigvis det beste stedet å begynne å liste opp og beskrive funksjonene/mulighetene når man skal utvikle en forståelse av LuaTeXs kapasiteter og potensial. En slik tilnærming vil ikke være særlig nyttig for lesere som ikke er kjent med andre TeX-motorer, og for hvem funksjonsbaserte sammenligninger neppe vil være spesielt meningsfulle.

Med risiko for å trette ut leserens tålmodighet («Bare kom til poenget!») vil jeg ta en mer «holistisk» tilnærming, forhåpentligvis gi nyttig bakgrunn, men på bekostning av noe ekstra lesing—og gå inn på noen få programmeringstemaer for å hjelpe forståelsen. I [Del 2](/latex/no/dybdeartikler/09-an-introduction-to-luatex-part-2-understanding-directlua.md) vi utforsker bruk av `\directlua` men foreløpig forsøker vi å legge det grunnleggende fundamentet for å forstå LuaTeX.

Denne artikkelen gjenspeiler sterkt forfatterens personlige «reise» i å utvikle en forståelse og verdsettelse av LuaTeX: ved først å vite litt om filosofien bak LuaTeX-utviklingen, og ved å se det som en beholder for programvareverktøy, vil du bedre sette pris på de omfattende løsningsområdene som åpnes av denne fantastiske programvaren.

## LuaTeX: Ikke bare for akademia eller matematikk!

Mengden av funksjoner og funksjonalitet innebygd i LuaTeX gir ikke bare setning av usedvanlig høy kvalitet via tradisjonell LaTeX, men de tilbyr også et enormt spillerom for å utvikle skreddersydde løsninger, basert på annet enn LaTeX, for komplekse problemer knyttet til dokumentproduksjon og -utvikling. LuaTeX har det kraftige skriptspråket Lua innebygd, noe som for eksempel betyr at du kan bruke Lua til å laste inn «plugins» (eksterne programvarebiblioteker) i LuaTeX; dette gjør det videre mulig med høy grad av automatisering, integrasjon i eksisterende programvaresystemer eller arbeidsflyter, og utnyttelse av spesialiserte programvareverktøy for data-, tekst- eller grafikkbehandling.

Historisk sett har TeX vært forbundet med vitenskapelig forfatterskap/publisering, særlig innen matematikk, men LuaTeX har spesielt et betydelig potensial for anvendelse innen mange andre domener—inkludert kommersiell PDF-dokumentproduksjon. Ett slikt eksempel er [speedata publisher](https://speedata.github.io/publisher/) som bruker LuaTeX utelukkende som PDF-genereringsmotor i sin XML-baserte arbeidsflyt—den bruker ikke LaTeX i det hele tatt. Faktisk inneholder speedata publisher praktisk talt ingen TeX-kode—jeg spurte [Patrick Gundlach](https://twitter.com/patrickgundlach), speedata publishers utvikler, som bekreftet at det totalt bruker rundt tre linjer TeX-kode. De kraftige settemulighetene er utformet og implementert i Lua-kode, ved bruk av LuaTeXs Lua-API (et tema vi diskuterer senere i denne artikkelen).

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

Jeg hørte først om LuaTeX sent i 2009/tidlig i 2010, da det fortsatt var i midt i betaversjonsfasen (versjon 0.50). På den tiden lette jeg etter TeX-basert programvare for å sette de håndskrevne notatene som ble resultatet av mine forsøk på å lære litt arabisk. Google-søk avdekket en samling videoer fra TUG-konferansen i 2009 ([nå på YouTube](https://www.youtube.com/playlist?list=PL2D4DD50DC9C0BA0E)) som inkluderte demonstrasjoner av svært høy kvalitet arabisk setning (via Hans Hagens [ConTeXt-pakke](http://wiki.contextgarden.net/Main_Page)). Disse videoene inkluderer også et foredrag med tittelen [LuaTeX-prosjektet: halvveis til versjon 1](https://youtu.be/AKv4po9PGW0).

TeX-motoren som ble brukt til å produsere den utsøkte arabiske setningen, var noe som het «LuaTeX». På den tiden jobbet jeg med vitenskapelig (fysikk) publisering, men selv om jeg var fullt klar over TeX/LaTeX, hadde jeg ikke hørt om LuaTeX: jeg ble nysgjerrig og ville lære mer om denne nye TeX-motoren. Siden LuaTeX fortsatt var i betautviklingsstadiet, og under rask utvikling, ville jeg holde meg oppdatert på de aller siste endringene, så det beste alternativet (for meg) var gjør-det-selv-løsningen med å bygge (kompilere) LuaTeX-programfilen fra kildekoden. I tillegg til selve LuaTeX-programmet trenger du også en «TeX-installasjon» for å gi miljøet der LuaTeX kan kjøres (f.eks. texmf.cnf, makropakker, fonter osv.). I stedet for å laste ned og installere den enorme [TeX Live](https://www.tug.org/texlive/) distribusjonen valgte jeg å lage en helt minimal tilpasset TeX-installasjon som jeg kunne utforske LuaTeX med (en «interessant» øvelse som jeg [dokumenterte på den personlige bloggen min](http://www.readytext.co.uk/?cat=30)). Hver nye utgivelse av LuaTeX ledsages av sin referansemanual (f.eks. for[versjon 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 den nyeste funksjonaliteten i programvaren. Men det er en *referanse* manual og er (nødvendigvis) ganske sparsom med forklaringer som passer for nybegynnere som ønsker å komme i gang med denne utrolige TeX-motoren—en viss kjennskap til TeXs lavnivåkoncepter forutsettes. Siden jeg oppdaget LuaTeX på et relativt tidlig stadium i utviklingen, var godt introduksjonsmateriale på den tiden relativt vanskelig å finne, så det tok litt utforsking, eksperimentering (og en del frustrasjon…) før brikkene begynte å falle på plass. Det sier seg selv at studiene mine i arabisk kom til en brå slutt da jeg ble fascinert av denne fantastiske programvaren og til slutt gikk over til å skrive LuaTeX [utvidelser for setning av arabisk](http://www.readytext.co.uk/?p=3143) i stedet!

Min egen «LuaTeX-reise» var absolutt svært ikke-lineær, men underveis ga den en anledning til å lære om (Lua)TeX (og TeX-installasjoner) «fra bunnen av»: bloggen min rommer en eklektisk samling av [artiklene](http://www.readytext.co.uk/?cat=3) basert på ulike temaer jeg utforsket og arbeidet med i løpet av den tiden. Forhåpentligvis gjør denne artikkelen passende bruk av den tiden og erfaringen, og hjelper andre til å bli interessert i å begynne å utforske mulighetene i LuaTeX. LuaTeX fortsetter å bli utviklet, og på skrivetidspunktet har det nådd versjon 1.0.4, som ble utgitt med TeX Live 2017. Utviklerne er svært aktive, og eventuelle feil som oppdages blir vanligvis rettet kort tid etter at de blir rapportert—for eksempel via [dev-luatex-postlisten](https://mailman.ntg.nl/mailman/listinfo/dev-luatex) eller via [den nettbaserte LuaTeX-feiltrackeren](http://tracker.luatex.org/my_view_page.php). Lang tid før det nådde versjon 1.0 var LuaTeX produksjonsklart—selvfølgelig måtte du akseptere at funksjoner var under kontinuerlig utvikling, og at endringer av og til kunne ødelegge eksisterende TeX-kode. I dag støttes LuaTeX selvsagt av plattformene Overleaf og ShareLaTeX (som LuaLaTeX).

## TeX i en verden i endring: Ny teknologi og arbeidsflyter

Det er tydelig at TeX-motorer ikke opererer i en teknologisk statisk verden, og av og til oppstår innovasjoner som er umiddelbare og opplagte kandidater for inkludering i TeX-motorer—én slik innovasjon er variable OpenType-fonter, som vi kort diskuterer nedenfor. Selv om det er liten tvil om at TeX-basert settekprogramvare er usedvanlig allsidig, opererer TeX-motorer nå i et raskt skiftende og svært mangfoldig programvareøkosystem—nye arbeidsflyter understreker behovet for integrasjon og fleksibilitet til å implementere et bredt spekter av dokument-/setteløsninger, hvor TeX kanskje bare er én komponent.

TeX må ikke bare forbli relevant for sine nåværende brukere, men også tiltrekke seg nye ved å muliggjøre løsninger for innholdsproduksjon som forblir nyttige for kommende generasjoner—mennesker som ikke nødvendigvis ønsker å bruke TeX som et frittstående verktøy, men kanskje som en del av en helhetlig arbeidsflyt via nettbaserte samarbeidsplattformer som Overleaf.

Selv et kort blikk på [tex.stackexchange](https://tex.stackexchange.com/) demonstrerer det enorme mangfoldet av dokumenter og løsninger som produseres og implementeres med TeX-basert programvare—ofte med utrolig oppfinnsomhet når folk finner stadig flere bruksområder og innholdstyper de ønsker å generere. I tillegg har behovet for arbeidsflyter som kan behandle TeX-basert markup/innhold for å produsere utdata som ikke er PDF (og ikke DVI), aldri vært større—som MathML/XML og HTML. For eksempel å «konvertere» TeX til [JATS XML](https://jats.nlm.nih.gov/) formatet (lenge brukt innen akademisk tidsskriftpublisering) men også, mer nylig, fremveksten av epub brukt innen bokpublisering.

### Variabel fontteknologi—tidene er i endring

Den 14. september 2016 annonserte 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 fontteknologi: [variable OpenType-fonter](https://medium.com/@tiro/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369). Vi skal ikke utforske denne teknologien i detalj, men det er nok å si at høyt respekterte fonteksperter som [Thomas Phinney](https://twitter.com/ThomasPhinney) og [John Hudson](https://twitter.com/TiroTypeworks) har observert ([på Twitter](https://twitter.com/ThomasPhinney/status/917087509342851072)) at teknologi for variable fonter blir tatt i bruk mye raskere enn mange tidligere fonnyvinninger—ganske sannsynlig drevet av behovene til nettdesignere som trenger responsive design som tilpasser seg mylderet av ulike skjermstørrelser/-oppløsninger på mobile enheter.

Klart nok er variable OpenType-fonter en interessant og spennende utvikling innen fontteknologi, en utvikling TeX-brukere utvilsomt kunne dra nytte av—faktisk har dette spørsmålet uunngåelig blitt [tatt opp på tex.stackexchange](https://tex.stackexchange.com/questions/355104/tex-luatex-xetex-fontspec-support-for-opentype-variable-fonts) med LuaTeXs støtte diskutert i LuaTeX [postlisten](https://www.tug.org/pipermail/luatex/2016-September/006204.html).

For øvrig er det verdt å merke seg at fontteknologi basert på «parametrisk» fontskaping ikke er en helt ny idé: Knuths METAFONT og Adobes Multiple Master-teknologier er på noen måter tidlige forløpere, selv om implementasjonsdetaljene er ganske forskjellige.

### Variable fonter: Når vil vi ha dem—nå?

Enhver ny og nyttig teknologistandard/spesifikasjon trenger tid til å «sette seg» i sitt måløkosystem av utviklere og implementører—inkludert tid til å rydde opp i eventuelle uklarheter eller tolkninger av formuleringene i selve spesifikasjonen. Utviklere må lese og forstå dokumentasjonen og gjøre den om til virkelig fungerende programvare—som her inkluderer å lage fontene og teknologiene for å bruke dem: kompatible nettlesere og settemotorer. TeX-utviklere vil tydeligvis trenge tilgang til variable fonter av høy kvalitet som kan brukes som pålitelige «benkmerker» for å implementere (programmere) støtte for variable fontteknologier.

Implementeringen av enhver ny teknologi i TeX, som variable fonter, reiser *potensielle* behovet for å endre innsiden av TeX-motorene—selvfølgelig avhenger behovet for dette av teknologienes natur og, helt avgjørende, hvilket aspekt av TeXs oppførsel som skal endres. Det er ikke alltid nødvendig å endre TeX-motorene selv; kanskje trengs det bare endringer i støttende/tilleggsprogramvare, inkludert eventuelle «komponenter» (tredjeparts kodebiblioteker) som brukes i disse programmene. Internt er TeX-motorer *forbløffende* komplekse—å utvikle en forståelse av TeXs kildekode som er tilstrekkelig til å gjøre pålitelige endringer krever betydelig, og svært spesialisert, ekspertise (som det finnes svært lite av). Det er også essensielt at eventuelle endringer ikke påvirker den langsiktige stabiliteten/kompatibiliteten til TeX-motorene negativt—noe som er avgjørende for TeX-fellesskapet og for dem som senere behandler en forfatters (La)TeX-fil(er): særlig akademiske forlag og skybaserte tjenester som Overleaf og ShareLaTeX.

Mange TeX-brukere vil trolig være interessert i å utnytte variable fonter; for eksempel ved å implementere nye designmuligheter eller finne løsninger på vanskelige settekproblemer. Så på en måte finnes det et dilemma: TeX-brukere ønsker tilgang til en ny teknologi, men implementeringen av den avhenger av en svært begrenset ressurs: antallet utviklere som er kvalifiserte og i stand til å få det til. Endring av TeXs indre er vanskelig, og bør generelt unngås så langt det er mulig, så finnes det en annen måte å legge til nye funksjoner/muligheter (av visse slag) i TeX på? Ja! og LuaTeX har valgt den veien.

#### Tidlige eksperimenter: variable OpenType-fonter og LuaTeX

LuaTeXs design har muliggjort rask eksperimentering med variabel fontteknologi. Allerede i april 2017 hadde ConTeXt TeX-formatet, som bruker LuaTeX, en [beta-versjon](https://mailman.ntg.nl/pipermail/ntg-context/2017/088343.html) som implementerte variable OpenType-fonter. Dette var mulig fordi ConTeXts fontstøtte er bygget i Lua-kode (og ConTeXt har sin egen fontlaster skrevet i Lua).

## LuaTeX: Bakgrunn og historie

LuaTeX er i TeX-termer «den nye ungen i gata», til tross for at den har vært under aktiv utvikling i over 10 år. LuaTeX-nettstedet [dokumenterer](http://www.luatex.org/roadmap.html) at LuaTeX startet i 2005 med (tror jeg) aktiv og vedvarende utvikling som begynte i 2006. På grunn av sin iboende kompleksitet, og grundigheten til dem som bygde det, tok det virkelig 10 års utvikling før LuaTeX nådde versjon 1.0, som ble [kunngjort av utviklerne](https://mailman.ntg.nl/pipermail/dev-luatex/2016-September/005882.html) (Hans Hagen, Hartmut Henkel, Taco Hoekwater, Luigi Scarso) den 27. september 2016.

I den utgivelseskunngjøringen finnes en viktig prinsipperklæring:

> «Vårt hovedmål er å tilby en variant av TeX som tillater brukerutvidelser uten at det er nødvendig å tilpasse den indre funksjonsmåten.»

Denne formuleringen sammenfatter perfekt filosofien bak LuaTeXs utvikling og peker mot en vei der TeX-basert programvare kan møte utfordringene vi allerede har nevnt: å ta i bruk ny teknologi og forbli relevant for nye generasjoner brukere.

Det er nå på tide å ta opp det andre spørsmålet som finnes i undertittelen til denne artikkelen: «hva gjør den så annerledes». Ved å utforske betydningen av «...tillater brukerutvidelser uten at det er nødvendig å tilpasse den indre funksjonsmåten» kan vi bedre forstå essensen av hva LuaTeX «bidrar med».

## LuaTeX: Å åpne TeXs «svarte boks»

Knuths opprinnelige TeX-program er den felles stamfaren til alle moderne TeX-motorer i bruk i dag, og LuaTeX er i praksis det siste evolusjonære steget: avledet fra pdfTeX-programmet, men med tillegg av noen kraftige programvarekomponenter som bringer med seg mye ekstra funksjonalitet. Da Knuth skrev den opprinnelige versjonen av TeX-programvaren, ga han også TeX-språket som en måte å styre og programmere seteatferden på: rundt 320 lavnivåkommandoer (primitiver) ble gjort tilgjengelige for brukere og utviklere av TeX-makropakker. Disse kommandoene ga ulik grad av kontroll eller innflytelse over visse aspekter av TeXs seteatferd, men mye av TeXs interne funksjonalitet, algoritmer, beslutningsprosesser, data og datastrukturer var skjult for brukeren. Knuths TeX-program var riktignok ikke en helt «svart boks», men absolutt en veldig mørk gråtone—kildekoden ble riktignok gjort tilgjengelig, men for de aller fleste mennesker er også den en svart boks av uforståelighet.

Vi omtaler de interne prosessene i TeX som noe av en «svart boks»; imidlertid åpner LuaTeX opp de TeX-baserte interne mekanismene og gir brukere/utviklere mye større tilgang til, og kontroll over, mange av de tidligere skjulte prosessene som foregår dypt inne i TeX-motoren. LuaTeX legger også til mange nye primitive kommandoer som gir kontroll over de nye funksjonene.

### LuaTeX: Avledet fra pdfTeX, men bruker ikke pdfTeXs kode

For nøyaktighetens skyld er det viktig å merke seg at selv om vi beskrev LuaTeX som avledet fra pdfTeX, bruker ikke LuaTeX pdfTeXs opprinnelige programkode direkte. En av LuaTeXs utviklere (Taco Hoekwater) utførte den virkelig *herkulesaktige* oppgaven med å skrive om LuaTeXs kjernekjerne i ren, moderne C-kode (CWEB).

#### Historisk notat

Delvis på grunn av alderen til Knuths opprinnelige TeX-kildekode—som de moderne etterkommerne er avledet fra—er det en kompleks og innviklet prosess å modifisere den for å tilpasse eller lage nye TeX-baserte settemotorer. En del av den prosessen krever konvertering av Pascal-kode til C-kode—noe som ikke er uten en [viss grad av kompleksitet](http://www.readytext.co.uk/?p=2529). Den resulterende maskin-genererte C-koden er usedvanlig ordrik og svært vanskelig å lese eller forstå. Det er tydelig at det å ha LuaTeXs kode fullstendig omskrevet omgår hele Pascal-til-C-konverteringsprosessen.

## LuaTeXs byggeklosser

I innledningen refererte vi til LuaTeX som et «verktøysett» og beskrev det som et «system for dokumentkonstruksjon og -utvikling». Vi har sett at utviklerne i kunngjøringen av LuaTeX 1.0 uttalte:

> «Vårt hovedmål er å tilby en variant av TeX som tillater brukerutvidelser uten at det er nødvendig å tilpasse den indre funksjonsmåten.»

Det er nå på tide å samle disse trådene og ideene og fokusere på detaljene i hva alt dette *egentlig betyr* i praksis.

### LuaTeX-puslespillet

Hvis du skulle se «under panseret», ville du se at LuaTeX-programvaren, dvs. selve kjørbare programmet, er bygget opp av en samling programvarekomponenter som kombineres for å gi LuaTeXs samlede funksjonalitet. Dette er selvfølgelig ikke noe nytt, og det meste programvare er bygd opp på den måten. Men det som gjør LuaTeX annerledes enn andre TeX-motorer, er at disse komponentene kombineres på en slik måte at brukerne får mye større tilgang til mange sider ved TeXs interne funksjonalitet: TeXs setmealoritmer, beslutningsprosesser, data og datastrukturer. Denne åpningen av TeXs indre gjør det mulig for brukere å konstruere nye setteløsninger uten å måtte endre selve TeX-motoren.

### Lua i LuaTeX: En nøkkel til «svarte boksen»

Lua er et svært kraftig, men samtidig lettlært, skriptspråk som [har sin opprinnelse i Brasil](https://www.lua.org/about.html)—det ble opprettet i 1993 og er fortsatt aktivt under utvikling. En av Lūs styrker er bruken som et programmeringsspråk for å «lime sammen» ulike programvarekomponenter, slik at du kan bruke dem gjennom et enkelt, men allsidig, skriptspråk. Lua spiller en sentral rolle i å åpne opp den indre funksjonsmåten til LuaTeXs TeX-motor, men for bedre å forstå hvordan dette oppnås, er det verdt å ta en liten omvei for svært kort å diskutere to programmeringsbegreper:

* Application Programming Interface (API);
* programmeringsspråk-binding.

Du kan gjerne hoppe over denne delen hvis du er komfortabel med disse begrepene. Ingen av temaene vil bli behandlet i detalj—vi sikter ikke mot streng teknisk nøyaktighet, men heller mot å gi akkurat nok bakgrunn til å være oppmerksom på disse begrepene: deres betydning og relevans for LuaTeX.

### Application Programming Interface (API)

Tenk deg at du er en programmerer som har skrevet noe kode som brukere (andre programmerere) kan finne nyttig, men koden din er kompleks og du ønsker ikke at brukerne av koden din skal måtte bekymre seg for disse lavnivådetaljene. Merk at disse programmererne/utviklerne arbeider med det samme programmeringsspråket som du brukte til å skrive koden din. Anta videre at du har planer om å skrive om noen deler av koden din—f.eks. for å gjøre den raskere, kreve mindre minne og så videre. Eksisterende brukere av koden din skal ikke trenge å bekymre seg for det: eventuelle endringer du planlegger å gjøre, bør ikke ødelegge programmene deres. Så hva er løsningen?

Svaret ligger i noe som kalles en API: en *Application Programming Interface*. I stedet for å kreve at brukere (andre programmerere) får tilgang til lavnivådetaljene i koden din—som kan endre seg—gir du et bestemt sett med *funksjoner* som andre programmerere kan bruke. Disse funksjonene er et *grensesnitt* til koden din, hvorigjennom andre utviklere kan bygge *applikasjoner* uten å måtte ha inngående kjennskap til programmets indre funksjonsmåte. På noen måter kan du tenke på dette som et ekstra lag som omgir koden din og «isolere» brukerne fra de rotete, lavnivådetaljene.

Forutsatt at du ikke endrer disse funksjonene (grensesnittet), står du fritt til å modifisere og oppdatere de lavere detaljene i programvaren din uten å påvirke (ødelegge) arbeidet til dem som er avhengige av koden din for å bygge sine applikasjoner: derav betegnelsen Application Programming Interface.

#### API-er: En analogi med en LaTeX-pakke

Når du bruker kommandoer som tilbys av en LaTeX-pakke, kan du tenke på pakkens kommandoer som en form for API. Som bruker er du ikke nødvendigvis opptatt av TeX- og LaTeX-magiens bak disse kommandoene (dvs. i pakkens kode): alt du ønsker, er å bruke funksjonaliteten de gir.

### Binding for programmeringsspråk

Vi har sett at programmerere som skriver/publiserer en mengde nyttig kode (kalt et *bibliotek*) kan tilby et såkalt Application Programming Interface (et sett med funksjoner) som andre programmerere, som bruker det *samme* programmeringsspråket, kan bruke biblioteket (samlingen av kode). Dette er greit når begge sider (bibliotekutvikler og brukere) bruker det *samme* programmeringsspråket, men hva skjer hvis programmerere som bruker et *annet* programmeringsspråk også ønsker å bruke det biblioteket? For eksempel kan du skrive skript ved hjelp av Lua-språket, men ønsker å bruke et bibliotek skrevet i for eksempel programmeringsspråk som C/C++. På en eller annen måte må de to forskjellige programmeringsspråkene (Lua og C/C++) kunne «kommunisere» med hverandre. Én løsning på dette problemet er såkalt [språkbinding](https://en.wikipedia.org/wiki/Language_binding).

Å undersøke de tekniske detaljene ved språkbinding ligger utenfor rammen av denne artikkelen, så vi gir en kortfattet oppsummering av de generelle prinsippene. I hovedsak kan et passende ekstra «lag» av kode legges til det opprinnelige biblioteket slik at det kan «kommunisere» med et annet programmeringsspråk (for eksempel Lua): dette kodelaget kalles en *binding*. Det gjør det mulig for de to språkene å samhandle via et API som programmerere i det andre språket (for eksempel Lua) kan bruke til å få tilgang til funksjonene/tjenestene som biblioteket tilbyr.

![Skjematisk diagram som viser konseptet språkbinding.](/files/1bcbea48936b8b9224c0295b2658432ab016e6dd)

**Figur 1**: Skjematisk diagram som viser konseptet språkbinding: som gjør det mulig for et program skrevet i Lua å bruke et eksternt bibliotek skrevet i et annet programmeringsspråk. Det er gjennom bruk av Lua-bindinger at de interne komponentene i LuaTeX, og dermed mye av LuaTeXs interne setefunksjonalitet, gjøres tilgjengelig for at brukere kan utvikle løsninger på komplekse setproblemer.

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

I praksis er LuaTeX en TeX-motor som støtter to programmeringsspråk: det tradisjonelle TeX-baserte språket og Lua-skriptspråket. Du kan selvfølgelig bruke begge språkene i det samme TeX-dokumentet, eller, hvis du foretrekker det, fortsette å sette via kun-TeX-ruten: for eksempel gjennom LaTeX (LuaLaTeX)-makropakken. TeX (eller LaTeX) er ikke et enkelt programmeringsspråk å bruke eller lære, og relativt få mennesker har virkelig mestret TeXs mange særegenheter—TeXs begreper om kontroll [tokens](https://www.overleaf.com/blog/522-what-is-a-tex-token) og ekspansjon er ganske fremmede for de flestes forventninger og erfaringer med et programmeringsspråk.

Tillegget av Lua åpner muligheten til å bruke TeX-basert setning via et mye mer tilgjengelig og konvensjonelt programmeringsspråk—som nevnt nær starten av denne artikkelen kan du ved å bruke Lua-API utføre [avansert setning med praktisk talt ingen TeX-kode](http://wiki.luatex.org/index.php/TeX_without_TeX).

### LuaTeX legger til mange nye primitiver

Hver TeX-motor gir hundrevis av såkalte primitive kommandoer: de grunnleggende byggeklossene i det TeX-baserte språket som støttes av hver enkelt settemotor. Den opprinnelige versjonen av TeX utgitt av Donald Knuth ga omtrent 320 kommandoer, men nyere TeX-motorer (pdfTeX, XeTeX og LuaTeX) har hver lagt til mange nye primitiver for å gi brukerne tilgang til hver motors ekstra funksjoner og muligheter. LuaTeXs betydelige antall nye primitiver er dokumentert i dens [referansemanual](https://www.tug.org/svn/texlive/tags/texlive-2017.1/Master/texmf-dist/doc/luatex/base/luatex.pdf?revision=44591\&view=co).

Blant de mange nye primitive kommandoene introdusert av LuaTeX er en som kalles `\directlua{...}` som er inngangsporten til å bruke Lua-kode: tilgang til innsiden av LuaTeX-motoren for å bygge avanserte seteverktøy og løsninger.

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

Som diskutert kan Lua-skriptspråket ses på som et «lag» gjennom hvilket det er mulig å få tilgang til LuaTeXs TeX-baserte settemotor og funksjonaliteten som tilbys av mange av komponentene som LuaTeX er bygget opp av. Lua-språket er også mekanismen som gjør LuaTeXs utvidbarhet mulig—gjennom Lūs evne til å laste inn spesialiserte eksterne biblioteker av programvare/kode.

Samlet sett omtales Lua-grensesnittet (settet av Lua-baserte funksjoner) som LuaTeX tilbyr, som dets *Lua-API*: det er «kommunikasjonslinjen» mellom LuaTeXs interne motor/komponenter og brukerens dokument.

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

Følgende *ekstremt enkelt* eksempel begynner ikke engang å skrape overflaten av isfjellet av muligheter. Det tjener imidlertid til å demonstrere den grunnleggende ideen om samspillet mellom «TeX-måten» og «Lua-måten» å få tilgang til TeXs parametere.

Merk at:

* `\hsize` er en TeX-primitive (kommando) som setter verdien av en intern parameter som bestemmer bredden på satte linjer—for eksempel setter du den vanligvis til en passende verdi innen en `\vbox{...}`. `\hsize` er bare én av *mange* TeX-parametere som du kan få tilgang til og/eller endre med Lua-kode.
* Å få tilgang til TeX-parametere er bare én *liten* side ved LuaTeXs Lua-API: det er så mye mer!

```latex

\documentclass{article}
\begin{document}
\let\\relax %endre betydningen av \\ for å unngå ekspansjonsproblemer
Her er den gjeldende verdien av {\ttfamily\string\hsize} (via \LaTeX):
\the\hsize\par
\directlua{
%Hent gjeldende verdi av \hsize ved bruk av Lua-API-et
local hs=tex.hsize
% Bruk en Lua-API-funksjon til å skrive ut noe
% LaTeX-kode og verdien av \hsize
tex.print("Her er verdien av {\\ttfamily\\string\\hsize}
rapportert fra Lua-kode (i skalapunkter): ")
tex.print(hs.."\\par")
% Sett en ny verdi for \hsize ved bruk av Lua-API-et
tex.hsize="400pt" % eller bruk tex.hsize=400*65536 (i skalapunkter)
}%
% Etter at \directlua er ferdig, be LaTeX
% om å fortelle oss den nye verdien av \hsize
Her er verdien av {\ttfamily\string\hsize} rapportert
av \LaTeX{} etter at {\tt\string\directlua} er ferdig:
\the\hsize\par
\end{document}
```

Her er et bilde som viser resultatet av at LuaTeX setter LaTeX-koden (ovenfor):

![Resultater av å kjøre LuaTeX](/files/b782ce20b599abcdb2c7904413e315e004d6a0ce)

Merk at TeX-«trikset» med `\let\\\relax` er å unngå problemer forårsaket av LuaTeXs «ekspansjon» av Lua-koden: et tema vi kort nevner nedenfor.

### Bruke Lua-kode

Det finnes to hovedalternativer for å bruke Lua-kode i TeX/LaTeX-dokumentene dine:

1. **Innebygd**: Å skrive Lua-kode direkte i dokumentet ditt `.tex`  (som i eksemplet ovenfor);
2. **Ekstern**: Å lagre Lua-kode i eksterne `.lua` kodefiler og bruke Lūs funksjoner til å laste dem inn og kjøre dem.

Alternativ (1) passer best for kortere biter av Lua-kode. Alternativ (2) brukes for større programmer eller biblioteker av Lua-kode. Det har den klare fordelen at du kan unngå vanskelige problemer som involverer TeXs såkalte `\catcode` verdier (som kan være «ganske frustrerende»). Årsaken til disse `\catcode` problemene er «ekspansjonen» av Lua-kode før den mates inn i LuaTeXs innebygde Lua-tolker. Denne ekspansjonen kan være vanskelig å forstå, så vi skal utforske det videre i en senere artikkel.

Selvfølgelig finnes det LaTeX-pakker som hjelper til med å bruke Lua-kode i .tex-filene dine—for eksempel kan du bruke [luacode-pakken](https://ctan.org/pkg/luacode?lang=en).

## Sammendrag og innledning til del 2 av denne artikkelen

Programvarekomponentene som LuaTeX er bygget opp av, sammen med det innebygde Lua-skriptspråket, utgjør en kraftig kombinasjon for å bygge løsninger som er i stand til å løse et bredt spekter av komplekse typografiproblemer — og for å utvikle arbeidsflyter for dokumentproduksjon som kan dra nytte av tett integrasjon med en TeX-basert typografimotor. I [Del 2 av denne artikkelen](/latex/no/dybdeartikler/09-an-introduction-to-luatex-part-2-understanding-directlua.md) tar vi en grundig titt på den kraftigste kommandoen som tilbys av LuaTeX: `\directlua`.

Inntil da, god LuaTeX-ing!

## Takk

Forfatteren er svært takknemlig overfor [Luigi Scarso](https://twitter.com/luigi_scarso), en av utviklerne av LuaTeX, for at han tok seg tid til å lese et utkast av denne artikkelen og komme med en rekke svært nyttige kommentarer og forslag. Eventuelle gjenværende feil, enten faktiske feil eller utelatelser, er selvfølgelig forfatterens. I tillegg vil jeg gjerne takke [Patrick Gundlach](https://twitter.com/patrickgundlach), utvikler av [speedata publisher](https://speedata.github.io/publisher/), for at han tok seg tid til å svare på spørsmålene mine.


---

# 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/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.