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

# Een inleiding tot LuaTeX (Deel 1): Wat is het — en wat maakt het zo anders?

LuaTeX is een *toolkit*—het bevat geavanceerde softwaretools en componenten waarmee je een breed scala aan documenten kunt opzetten (zetten). De subtitel van dit artikel stelt ook twee vragen over LuaTeX: Wat is het—en wat maakt het zo anders? Het antwoord op “Wat is het?” lijkt misschien voor de hand liggend: “Het is een TeX-opmaakmotor!” Dat is inderdaad zo, maar een bredere visie, en een waaraan deze auteur zich committeert, is dat LuaTeX een uiterst veelzijdige op TeX gebaseerde *systeem voor documentopbouw en engineering*.

### LuaTeX uitleggen: Waar te beginnen?

Het doel van dit eerste artikel over LuaTeX is om een context te bieden voor het begrijpen van wat deze TeX-engine levert en waarom/hoe het ontwerp gebruikers in staat stelt een breed scala aan oplossingen te bouwen/ontwerpen/creëren voor complexe opmaak- en ontwerpproblemen—en mogelijk ook enige mate van “toekomstbestendigheid” te bieden nu gebruikers steeds meer TeX-gebaseerde software nodig hebben die kan meegroeien met het voortdurend veranderende technische ecosysteem. Naar mijn mening is het opsommen en beschrijven van de functies/mogelijkheden niet noodzakelijkerwijs de beste plek om te beginnen bij het ontwikkelen van een begrip van LuaTeX’s mogelijkheden en potentieel. Zo’n aanpak zal weinig behulpzaam zijn voor lezers die niet vertrouwd zijn met andere TeX-engines en voor wie functiegebaseerde vergelijkingen waarschijnlijk niet bijzonder betekenisvol zijn.

Op het risico af het geduld van de lezer uit te putten (“Kom nu maar ter zake!”) ga ik een meer “holistische” aanpak volgen, hopelijk met nuttige achtergrondinformatie, maar ten koste van wat extra leeswerk—en door enkele programmeeronderwerpen te behandelen ter ondersteuning van het begrip. In [Deel 2](/latex/nl/diepgaande-artikelen/09-an-introduction-to-luatex-part-2-understanding-directlua.md) we verkennen het gebruik van `\directlua` maar voorlopig proberen we de basis te leggen voor het begrijpen van LuaTeX.

Dit artikel weerspiegelt sterk de persoonlijke “reis” van de auteur in het ontwikkelen van begrip en waardering voor LuaTeX: dat als je eerst iets weet over de filosofie achter de ontwikkeling van LuaTeX, en het ziet als een container van softwaretools, je de uitgebreide oplossingsdomeinen die deze verbazingwekkende software opent, beter zult waarderen.

## LuaTeX: niet alleen voor de academische wereld, of voor wiskunde!

De rijkdom aan functies en functionaliteit die in LuaTeX is ingebouwd, biedt niet alleen uitzonderlijk hoogwaardige opmaak via traditionele LaTeX, maar biedt ook enorme ruimte voor het ontwikkelen van op maat gemaakte, niet op LaTeX gebaseerde oplossingen voor complexe problemen op het gebied van documentproductie en engineering. LuaTeX heeft de krachtige scripttaal Lua erin ingebed, wat bijvoorbeeld betekent dat je Lua kunt gebruiken om “plugins” (externe softwarebibliotheken) in LuaTeX te laden; dit maakt verdere automatisering mogelijk, integratie in bestaande softwaresystemen of workflows, en het benutten van specialistische software voor gegevens-, tekst- of grafische verwerking.

Historisch gezien wordt TeX geassocieerd met wetenschappelijke auteurschap/publicatie, vooral binnen de wiskunde, maar LuaTeX in het bijzonder heeft een aanzienlijk toepassingspotentieel binnen vele andere domeinen—waaronder commerciële PDF-documentproductie. Een voorbeeld daarvan is [speedata publisher](https://speedata.github.io/publisher/) dat LuaTeX puur gebruikt als de PDF-generatiemotor binnen zijn op XML gebaseerde workflow—het gebruikt helemaal geen LaTeX. Sterker nog, speedata publisher bevat vrijwel geen TeX-code—I vroeg [Patrick Gundlach](https://twitter.com/patrickgundlach), de ontwikkelaar van speedata publisher, die bevestigde dat het in totaal ongeveer drie regels TeX-code gebruikt. De krachtige opmaakmogelijkheden zijn ontworpen en geïmplementeerd in Lua-code, gebruikmakend van LuaTeX’s Lua-API (een onderwerp dat we later in dit artikel bespreken).

## Een kort persoonlijk verhaal: hoe ik LuaTeX voor het eerst ontdekte

Ik kwam LuaTeX voor het eerst tegen eind 2009/begin 2010, toen het nog in een midden-bètafase zat (versie 0.50). In die tijd was ik op zoek naar op TeX gebaseerde software om de handgeschreven notities op te maken die voortkwamen uit mijn pogingen om wat Arabisch te leren. Google-zoekopdrachten brachten een verzameling video's aan het licht van de TUG 2009-conferentie ([nu op YouTube](https://www.youtube.com/playlist?list=PL2D4DD50DC9C0BA0E)) die demonstraties bevatte van zeer hoogwaardige Arabische opmaak (via Hans Hagen’s [ConTeXt-pakket](http://wiki.contextgarden.net/Main_Page)). Die video's bevatten ook een lezing met de titel [Het LuaTeX-project: halverwege versie 1](https://youtu.be/AKv4po9PGW0).

De TeX-engine die werd gebruikt om die prachtige Arabische opmaak te produceren was iets dat “LuaTeX” heette. In die tijd werkte ik in de wetenschappelijke (natuurkunde)uitgeverij, maar hoewel ik TeX/LaTeX goed kende, had ik nog nooit van LuaTeX gehoord: ik was geïntrigeerd en wilde meer leren over deze nieuwe TeX-engine. Omdat LuaTeX zich nog in de bètadevelopfase bevond en snel evolueerde, wilde ik op de hoogte blijven van de allerlaatste updates, dus de beste optie (voor mij) was de doe-het-zelfroute: het LuaTeX-uitvoerbare bestand bouwen (compileren) uit de broncode. Naast het uitvoerbare LuaTeX-programma heb je ook een “TeX-installatie” nodig om de omgeving te bieden waarin LuaTeX draait (bijv. texmf.cnf, macropakketten, lettertypen enz.). In plaats van de enorme [TeX Live](https://www.tug.org/texlive/) distributie te downloaden en te installeren, koos ik ervoor een absoluut minimale aangepaste TeX-installatie te maken waarmee ik LuaTeX kon verkennen (een “interessante” oefening die ik [op mijn persoonlijke blog heb gedocumenteerd](http://www.readytext.co.uk/?cat=30)). Elke nieuwe release van LuaTeX wordt vergezeld door de Reference Manual (bijv. voor[versie 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)) die de nieuwste functies en mogelijkheden van de software documenteert. Het is echter een *referentie* handleiding en (noodzakelijkerwijs) tamelijk karig in uitleg die geschikt is voor de beginner die met deze ongelooflijke TeX-engine wil beginnen—een zekere vertrouwdheid met laag-niveau TeX-concepten wordt verondersteld. Gezien het feit dat ik LuaTeX relatief vroeg in zijn ontwikkeling ontdekte, was goed inleidend materiaal destijds relatief moeilijk te vinden, dus het kostte wat uitzoeken, experimenteren (en enige frustratie…) voordat de puzzelstukjes op hun plaats vielen. Onnodig te zeggen dat mijn Arabische studies abrupt tot stilstand kwamen toen ik gefascineerd raakte door deze verbazingwekkende software en uiteindelijk begon met het schrijven van LuaTeX [plugins voor het opmaken van Arabisch](http://www.readytext.co.uk/?p=3143) in plaats daarvan!

Mijn eigen “LuaTeX-reis” verliep zeker heel niet-lineair, maar onderweg bood het wel de kans om (Lua)TeX (en TeX-installaties) “van onderaf” te leren kennen: mijn blog herbergt een eclectische verzameling van [artikelen](http://www.readytext.co.uk/?cat=3) gebaseerd op uiteenlopende onderwerpen die ik in die tijd onderzocht en waaraan ik werkte. Hopelijk maakt dit artikel passend gebruik van die tijd en ervaring, en helpt het anderen geïnteresseerd te raken om de mogelijkheden van LuaTeX te gaan verkennen. LuaTeX wordt nog steeds verder ontwikkeld en ten tijde van het schrijven heeft het versie 1.0.4 bereikt, die werd uitgebracht met TeX Live 2017. De ontwikkelaars zijn zeer actief en eventuele gevonden bugs worden meestal kort nadat ze zijn gemeld opgelost—bijv. via de [dev-luatex mailinglijst](https://mailman.ntg.nl/mailman/listinfo/dev-luatex) of via de [online LuaTeX-bugtracker](http://tracker.luatex.org/my_view_page.php). Ruim voordat het versie 1.0 bereikte, was LuaTeX al productieklaar—hoewel je natuurlijk moest accepteren dat functies voortdurend evolueerden en dat veranderingen af en toe je bestaande TeX-code konden breken. Tegenwoordig wordt LuaTeX uiteraard ondersteund door de platforms Overleaf en ShareLaTeX (als LuaLaTeX).

## TeX in een veranderende wereld: nieuwe technologieën en workflows

Het is duidelijk dat TeX-engines niet opereren in een technologisch statische wereld en dat er af en toe innovaties ontstaan die directe en voor de hand liggende kandidaten zijn om in TeX-engines te worden opgenomen—een dergelijke innovatie zijn OpenType-variabele lettertypen, die we hieronder kort bespreken. Hoewel er weinig twijfel over bestaat dat TeX-gebaseerde opmaaksoftware buitengewoon veelzijdig is, functioneren TeX-engines nu binnen een snel veranderend en zeer divers software-ecosysteem—nieuwe workflows benadrukken de behoefte aan integratie en flexibiliteit om een breed scala aan document-/opmaakoplossingen te implementeren, waarvan TeX misschien slechts één component is.

TeX moet niet alleen relevant blijven voor zijn huidige gebruikers, maar ook nieuwe gebruikers aantrekken door inhoudcreatie-oplossingen mogelijk te maken die bruikbaar blijven voor komende generaties—mensen die TeX misschien niet per se als een zelfstandig hulpmiddel willen gebruiken, maar wellicht als onderdeel van een totale workflow via online samenwerkingsplatforms zoals Overleaf.

Zelfs een korte blik op [tex.stackexchange](https://tex.stackexchange.com/) laat de enorme verscheidenheid zien aan documenten en oplossingen die met op TeX gebaseerde software worden geproduceerd en geïmplementeerd—vaak met ongelooflijke inventiviteit, terwijl mensen steeds meer use-cases en contenttypes vinden die ze willen genereren. Bovendien is de behoefte aan workflows die op TeX gebaseerde markup/content kunnen verwerken om niet-PDF- (en niet-DVI-) uitvoer te produceren nog nooit zo groot geweest—zoals MathML/XML en HTML. Bijvoorbeeld het “converteren” van TeX naar het [JATS XML](https://jats.nlm.nih.gov/) formaat (al lang gebruikt binnen de publicatie van academische tijdschriften), maar ook recenter de opkomst van epub, gebruikt binnen ebook-publicatie.

### Variabele-lettertypetechnologie—De tijden veranderen

Op 14 september 2016 kondigden 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/) en Apple een nieuwe lettertypetechnologie aan: [OpenType-variabele lettertypen](https://medium.com/@tiro/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369). We zullen deze technologie niet in detail verkennen, maar het volstaat te zeggen dat zeer gerespecteerde lettertype-experts zoals [Thomas Phinney](https://twitter.com/ThomasPhinney) en [John Hudson](https://twitter.com/TiroTypeworks) hebben opgemerkt ([op Twitter](https://twitter.com/ThomasPhinney/status/917087509342851072)) dat variabele-lettertypetechnologie veel sneller wordt geadopteerd dan veel eerdere lettertype-innovaties—waarschijnlijk gedreven door de behoeften van webdesigners die responsieve ontwerpen nodig hebben die zich aanpassen aan de talloze verschillende schermformaten/resoluties op mobiele apparaten.

Het is duidelijk dat OpenType-variabele lettertypen een interessante en spannende ontwikkeling zijn in lettertypetechnologieën, waarvan TeX-gebruikers ongetwijfeld kunnen profiteren—sterker nog, deze vraag is onvermijdelijk al [op tex.stackexchange aan de orde gesteld](https://tex.stackexchange.com/questions/355104/tex-luatex-xetex-fontspec-support-for-opentype-variable-fonts) met LuaTeX-ondersteuning besproken in de LuaTeX [mailinglijst](https://www.tug.org/pipermail/luatex/2016-September/006204.html).

Terzijde is het de moeite waard op te merken dat lettertypetechnologie gebaseerd op “parametrische” lettertypecreatie geen volledig nieuw idee is: Knuths METAFONT en Adobe’s Multiple Master-technologieën zijn in zekere zin vroege voorlopers, ook al verschillen de implementatiedetails behoorlijk.

### Variabele lettertypen: wanneer willen we ze—nu?

Elke nieuwe en nuttige technologiestandaard/specifcatie heeft tijd nodig om zich te “nestelen” in het beoogde ecosysteem van ontwikkelaars en implementatoren—waaronder tijd om eventuele dubbelzinnigheden of interpretaties van bewoordingen binnen de specificatie zelf glad te strijken. Ontwikkelaars moeten de documentatie lezen en begrijpen en deze omzetten in echt werkende software—waaronder hier het maken van de lettertypen en technologieën om ze te gebruiken: compatibele browsers en opmaak-engines. TeX-ontwikkelaars zullen duidelijk toegang nodig hebben tot hoogwaardige variabele lettertypen die kunnen dienen als betrouwbare “benchmarks” voor het implementeren (programmeren) van ondersteuning voor variabele-lettertypetechnologieën.

Het implementeren van een nieuwe technologie binnen TeX, zoals variabele lettertypen, roept de *mogelijke* behoefte op om de internals van TeX-engines aan te passen—natuurlijk hangt de noodzaak daartoe af van de aard van die technologie en, cruciaal, welk aspect van TeX’s gedrag aan verandering wordt onderworpen. Het is niet altijd nodig om de TeX-engines zelf aan te passen; soms zijn alleen wijzigingen nodig in ondersteunende/hulpsoftware, inclusief eventuele “componenten” (softwarebibliotheken van derden) die in die programma’s worden gebruikt. Intern zijn TeX-engines *duivels* complex—een voldoende begrip van TeX’s broncode ontwikkelen om betrouwbare aanpassingen te kunnen doen vereist aanzienlijke en zeer gespecialiseerde expertise (waarvan er maar heel weinig beschikbaar is). Het is ook essentieel dat eventuele wijzigingen de langetermijnstabiliteit/compatibiliteit van TeX-engines niet nadelig beïnvloeden—wat van vitaal belang is voor de TeX-gemeenschap en voor degenen die vervolgens een (La)TeX-bestand(en) van een auteur verwerken: met name academische uitgevers en cloudgebaseerde diensten zoals Overleaf en ShareLaTeX.

Veel TeX-gebruikers zullen waarschijnlijk geïnteresseerd zijn in het benutten van variabele lettertypen; bijvoorbeeld om nieuwe ontwerpmogelijkheden te realiseren of oplossingen te vinden voor lastige opmaakproblemen. Er is dus in zekere zin een dilemma: TeX-gebruikers willen toegang tot een nieuwe technologie, maar de implementatie ervan hangt af van een zeer beperkte hulpbron: het aantal ontwikkelaars dat gekwalificeerd is en in staat is om het te realiseren. Het aanpassen van TeX’s internals is moeilijk en moet in het algemeen zoveel mogelijk worden vermeden, dus is er een andere manier om nieuwe functies/mogelijkheden aan TeX toe te voegen? Ja! en LuaTeX heeft dat pad gekozen.

#### Vroege experimenten: OpenType-variabele lettertypen en LuaTeX

Het ontwerp van LuaTeX heeft snel experimenteren met variabele-lettertypetechnologie mogelijk gemaakt. Al in april 2017 had het ConTeXt TeX-formaat, dat LuaTeX gebruikt, een [bèta-versie](https://mailman.ntg.nl/pipermail/ntg-context/2017/088343.html) die OpenType-variabele lettertypen implementeerde. Dit was mogelijk omdat ConTeXt’s lettertypeondersteuning in Lua-code is ingebouwd (en ConTeXt heeft zijn eigen fontloader geschreven in Lua).

## LuaTeX: achtergrond en geschiedenis

LuaTeX is, in TeX-termen, “de nieuwe jongen op het blok” ondanks dat het al meer dan 10 jaar actief wordt ontwikkeld. De LuaTeX-website [documenteert](http://www.luatex.org/roadmap.html) dat LuaTeX in 2005 is begonnen (ik meen) met actieve en duurzame ontwikkeling vanaf 2006. Vanwege de inherente complexiteit en de toewijding van degenen die het hebben gebouwd, heeft LuaTeX echt 10 jaar ontwikkeling nodig gehad om versie 1.0 te bereiken, die werd [aangekondigd door de ontwikkelaars](https://mailman.ntg.nl/pipermail/dev-luatex/2016-September/005882.html) (Hans Hagen, Hartmut Henkel, Taco Hoekwater, Luigi Scarso) op 27 september 2016.

In die release-aankondiging staat een belangrijke principiële uitspraak:

> “Ons belangrijkste doel is een variant van TeX te bieden die gebruikersuitbreidingen mogelijk maakt zonder dat de interne werking hoeft te worden aangepast.”

Deze formulering vat de filosofie achter de ontwikkeling van LuaTeX perfect samen en wijst op een route waarlangs op TeX gebaseerde software de uitdagingen die we al hebben genoemd kan aanpakken: het omarmen van nieuwe technologieën en relevant blijven voor nieuwe generaties gebruikers.

Het is nu tijd om de tweede vraag in de subtitel van dit artikel aan te pakken: “wat maakt het zo anders”. Door de betekenis van “...gebruikersuitbreidingen mogelijk maakt zonder dat de interne werking hoeft te worden aangepast” te verkennen, kunnen we de essentie van wat LuaTeX “te bieden heeft” beter begrijpen.

## LuaTeX: TeX’s “black box” openbreken

Knuths oorspronkelijke TeX-programma is de gemeenschappelijke voorouder van alle moderne TeX-engines die vandaag in gebruik zijn en LuaTeX is in feite de nieuwste evolutionaire stap: afgeleid van het pdfTeX-programma, maar met de toevoeging van enkele krachtige softwarecomponenten die veel extra functionaliteit bieden. Toen Knuth de oorspronkelijke versie van de TeX-software schreef, leverde hij ook de TeX-taal als een manier om het opmaakgedrag te sturen en te programmeren: ongeveer 320 laag-niveau commando’s (primitives) werden beschikbaar gemaakt voor gebruikers en ontwikkelaars van TeX-macropakketten. Die commando’s boden verschillende graden van controle of invloed op bepaalde aspecten van TeX’s opmaakgedrag, maar veel van TeX’s interne functionaliteit, algoritmen, besluitvormingsprocessen, gegevens en datastructuren waren verborgen voor de gebruiker. Je zou kunnen stellen dat Knuths TeX-programma niet volledig een “black box” was, maar zeker een heel donkergrijze versie ervan—weliswaar was de broncode beschikbaar gemaakt, maar voor de overgrote meerderheid van de mensen is ook dat een black box van onbegrijpelijkheid.

We noemen de interne processen binnen TeX enigszins een “black box”; LuaTeX opent echter zijn op TeX gebaseerde internals, zodat gebruikers/ontwikkelaars veel betere toegang krijgen tot, en controle over, veel van de ooit verborgen processen diep in de TeX-engine. LuaTeX voegt ook vele nieuwe primitieve commando’s toe die controle bieden over de nieuwe functies.

### LuaTeX: afgeleid van pdfTeX maar gebruikt niet de code van pdfTeX

Omwille van de nauwkeurigheid is het belangrijk op te merken dat hoewel we LuaTeX hebben beschreven als afgeleid van pdfTeX, LuaTeX niet rechtstreeks de oorspronkelijke programmatuurcode van pdfTeX gebruikt. Een van LuaTeX’s ontwikkelaars (Taco Hoekwater) verrichtte de werkelijk *Herculeaanse* taak om de kern-TeX-engine van LuaTeX in schone, moderne C-code (CWEB) te herschrijven.

#### Historische noot

Gedeeltelijk vanwege de leeftijd van Knuths oorspronkelijke TeX-broncode—waaruit de moderne afstammelingen zijn voortgekomen—is het aanpassen ervan om nieuwe op TeX gebaseerde opmaak-engines aan te passen of te creëren een complex en omslachtig proces. Een deel van dat proces vereist de conversie van Pascal-code naar C-code—wat niet zonder een [zekere mate van complexiteit](http://www.readytext.co.uk/?p=2529)is. De daaruit voortkomende door de machine gegenereerde C-code is buitengewoon uitvoerig en zeer moeilijk te lezen of te begrijpen. Duidelijk maakt het volledig herschrijven van LuaTeX’s code het hele Pascal-naar-C-conversieproces overbodig.

## De bouwstenen van LuaTeX

In de inleiding verwezen we naar LuaTeX als een “toolkit” en beschreven we het als een “systeem voor documentopbouw en engineering”. We hebben gezien dat in de LuaTeX 1.0-aankondiging de ontwikkelaars stelden:

> “Ons belangrijkste doel is een variant van TeX te bieden die gebruikersuitbreidingen mogelijk maakt zonder dat de interne werking hoeft te worden aangepast.”

Het is nu tijd om deze draden samen te brengen en ons te richten op de details van wat dit alles *eigenlijk betekent* in de praktijk.

### De LuaTeX-puzzel

Als je “onder de motorkap” zou kijken, zou je zien dat de LuaTeX-software, d.w\.z. het daadwerkelijke uitvoerbare programma, is opgebouwd uit een verzameling softwarecomponenten die samen worden gevoegd om de algehele functionaliteit van LuaTeX te leveren. Natuurlijk is daar niets nieuws aan en de meeste software is zo opgebouwd. Wat LuaTeX echter anders maakt dan andere TeX-engines, is dat deze componenten zo worden gecombineerd dat gebruikers veel ruimere toegang krijgen tot vele aspecten van TeX’s interne functionaliteit: TeX’s opmaakalgoritmen, besluitvormingsprocessen, gegevens en datastructuren. Deze opening van TeX’s internals stelt gebruikers in staat nieuwe opmaakoplossingen te construeren zonder dat de daadwerkelijke TeX-engine zelf hoeft te worden aangepast.

### De Lua in LuaTeX: een sleutel tot de “black box”

Lua is een zeer krachtige, maar gemakkelijk te leren scripttaal die [uit Brazilië afkomstig is](https://www.lua.org/about.html)—het werd in 1993 gemaakt en wordt nog steeds actief ontwikkeld. Een van Lua’s sterke punten is het gebruik als programmeertaal waarmee uiteenlopende softwarecomponenten kunnen worden “samengekoppeld”, zodat je ze via een eenvoudige maar veelzijdige scripttaal kunt gebruiken. Lua speelt een centrale rol in het openbreken van de interne werking van de LuaTeX TeX-engine, maar om beter te begrijpen hoe dit wordt bereikt, is het de moeite waard even af te wijken om heel kort twee programmeerconcepten te bespreken:

* Application Programming Interface (API);
* programmeertaal-binding.

Sla dit gedeelte gerust over als je je prettig voelt bij die concepten. Geen van beide onderwerpen zal in detail worden behandeld—we streven niet naar strikte technische nauwkeurigheid, maar willen alleen voldoende achtergrond bieden om zich bewust te zijn van deze concepten: hun betekenis en relevantie voor LuaTeX.

### Application Programming Interface (API)

Stel je voor dat je een programmeur bent die code heeft geschreven die gebruikers (andere programmeurs) nuttig zouden kunnen vinden, maar je code is complex en je wilt niet dat gebruikers van je code zich zorgen hoeven te maken over die laag-niveau details. Merk op dat die programmeurs/ontwikkelaars werken met dezelfde programmeertaal die jij hebt gebruikt om je code te schrijven. Stel bovendien dat je plannen hebt om delen van je code te herschrijven—bijv. om het sneller te maken, minder geheugen te laten gebruiken en dergelijke. Bestaande gebruikers van je code zouden zich daar geen zorgen over moeten maken: eventuele wijzigingen die je van plan bent aan te brengen, mogen hun programma’s niet breken. Wat is dan de oplossing?

Het antwoord ligt in iets dat een API heet: een *Application Programming Interface*. In plaats van gebruikers (andere programmeurs) te verplichten toegang te krijgen tot de laag-niveau details van je code—die kunnen veranderen—bied je een specifieke set *functies* aan die andere programmeurs kunnen gebruiken. Die functies vormen een *interface* op je code, waarlangs andere ontwikkelaars *toepassingen* kunnen bouwen zonder intieme kennis van de interne werking van je programma nodig te hebben. Op sommige manieren kun je dit zien als een extra laag die je code omringt en gebruikers “isoleert” van de rommelige details op laag niveau.

Zolang je die functies (de interface) niet verandert, ben je vrij om de details op een lager niveau van je software aan te passen en bij te werken zonder het werk te beïnvloeden (of te breken) van degenen die op je code vertrouwen om hun toepassingen te bouwen: vandaar de term Application Programming Interface.

#### API’s: een analogie met een LaTeX-pakket

Wanneer je commando’s gebruikt die door een LaTeX-pakket worden geleverd, kun je de commando’s van het pakket zien als een vorm van API. Als gebruiker maak je je niet per se druk over de TeX- en LaTeX-toverkunst achter die commando’s (d.w\.z. in de code van het pakket): je wilt alleen gebruikmaken van de functionaliteit die ze bieden.

### Programmeertaal-binding

We hebben gezien dat programmeurs die een hoeveelheid nuttige code schrijven/publiceren (een *bibliotheek*) een zogenaamde Application Programming Interface kunnen aanbieden (een set functies) waarmee andere programmeurs, die dezelfde *zelfde* programmeertaal gebruiken, gebruik kunnen maken van die bibliotheek (verzameling code). Dat is prima wanneer beide kanten (bibliotheekontwikkelaar en gebruikers) dezelfde *zelfde* programmeertaal *gebruiken, maar wat gebeurt er als programmeurs die een* andere [programmeertaal](https://en.wikipedia.org/wiki/Language_binding).

willen gebruiken ook gebruik willen maken van die bibliotheek? Je kunt bijvoorbeeld scripts schrijven in de Lua-taal, maar gebruik willen maken van een bibliotheek geschreven in bijvoorbeeld programmeertalen zoals C/C++. Op de een of andere manier moeten die twee verschillende programmeertalen (Lua en C/C++) met elkaar kunnen “communiceren”. Een oplossing voor dit probleem is de zogenaamde *binding*. Het stelt de twee talen in staat via een API samen te werken, waarmee programmeurs in de tweede taal (zoals Lua) de functies/diensten die door de bibliotheek worden geleverd kunnen gebruiken.

![Schematisch diagram om het concept van een taal-binding weer te geven.](/files/2448fbde357758fae289b6679a8a5475f104829d)

**Figuur 1**: Schematisch diagram om het concept van een taal-binding weer te geven: het mogelijk maken dat een programma geschreven in Lua een externe bibliotheek geschreven in een andere programmeertaal gebruikt. Door het gebruik van Lua-bindings worden de interne componenten van LuaTeX, en daarmee een groot deel van LuaTeX’s interne opmaakfunctionaliteit, beschikbaar gemaakt zodat gebruikers oplossingen kunnen ontwikkelen voor complexe opmaakproblemen.

## LuaTeX: twee opties voor programmeren—TeX en Lua

In wezen is LuaTeX een TeX-engine die twee programmeertalen ondersteunt: de traditionele op TeX gebaseerde taal en de Lua-scripttaal. Natuurlijk kun je beide talen in hetzelfde TeX-document gebruiken of, als je dat liever hebt, doorgaan met opmaken via de route van alleen TeX: bijvoorbeeld via het LaTeX-(LuaLaTeX) macropakket. TeX (of LaTeX) is geen eenvoudige programmeertaal om te gebruiken of te leren, en relatief weinig mensen hebben de vele eigenaardigheden van TeX echt onder de knie—TeX’s concepten van [tokens](https://www.overleaf.com/blog/522-what-is-a-tex-token) en expansie zijn voor de meeste mensen behoorlijk vreemd in vergelijking met hun verwachtingen en ervaringen van een programmeertaal.

De toevoeging van Lua opent de mogelijkheid om op TeX gebaseerde opmaak te gebruiken via een veel toegankelijkere en meer conventionele programmeertaal—zoals aan het begin van dit artikel al opgemerkt, kun je met behulp van de Lua-API [geavanceerde opmaak uitvoeren met vrijwel geen TeX-code](http://wiki.luatex.org/index.php/TeX_without_TeX).

### LuaTeX voegt veel nieuwe primitives toe

Elke TeX-engine biedt honderden zogenaamde primitieve commando’s: de fundamentele bouwstenen van de op TeX gebaseerde taal die door elke afzonderlijke opmaak-engine wordt ondersteund. De oorspronkelijke versie van TeX, uitgebracht door Donald Knuth, bood ongeveer 320 commando’s, maar nieuwere TeX-engines (pdfTeX, XeTeX en LuaTeX) hebben elk veel nieuwe primitives toegevoegd om gebruikers toegang te geven tot de extra functies en mogelijkheden van elke engine. Het aanzienlijke aantal nieuwe primitives van LuaTeX wordt gedocumenteerd in de [Reference Manual](https://www.tug.org/svn/texlive/tags/texlive-2017.1/Master/texmf-dist/doc/luatex/base/luatex.pdf?revision=44591\&view=co).

Onder de vele nieuwe primitives die door LuaTeX zijn geïntroduceerd, bevindt zich er een genaamd `\directlua{...}` dat de toegangspoort is tot het gebruik van Lua-code: toegang tot de internals van de LuaTeX-engine om geavanceerde opmaakhulpmiddelen en oplossingen te bouwen.

### \directlua{...}: De toegangspoort tot programmeren in Lua

Zoals besproken kan de Lua-scripttaal worden gezien als een “laag” waardoor het mogelijk is toegang te krijgen tot de op TeX gebaseerde opmaakengine van LuaTeX en tot de functionaliteit van veel van de componenten waaruit LuaTeX is opgebouwd. De Lua-taal is ook het mechanisme dat de uitbreidbaarheid van LuaTeX mogelijk maakt—door Lua’s vermogen om gespecialiseerde externe bibliotheken van software/code te laden.

Gezamenlijk wordt de Lua-interface (set Lua-gebaseerde functies) die door LuaTeX wordt aangeboden, aangeduid als de *Lua-API*: het is de “communicatielijn” tussen de interne engine/componenten van LuaTeX en het document van de gebruiker.

### Een eenvoudig voorbeeld van \directlua{...}

De volgende *uiterst eenvoudige* voorbeeld begint nog niet eens de tip van de ijsberg van mogelijkheden aan te raken. Het dient echter om het basisidee te demonstreren van de wisselwerking tussen de “TeX-manier” en de “Lua-manier” om toegang te krijgen tot TeX-parameters.

Merk op dat:

* `\hsize` is een TeX-primitief (commando) dat de waarde instelt van een interne parameter die de breedte van gezette regels bepaalt—je zet die bijvoorbeeld meestal op een geschikte waarde binnen een `\vbox{...}`. `\hsize` is slechts één van *veel* TeX-parameters waartoe je via Lua-code toegang hebt en/of die je ermee kunt wijzigen.
* Toegang krijgen tot TeX-parameters is slechts een *klein* aspect van LuaTeX’s Lua-API: er is nog zoveel meer!

```latex

\documentclass{article}
\begin{document}
\let\\\relax %herdefinieer de betekenis van \\ om expansieproblemen te vermijden
Hier is de huidige waarde van {\ttfamily\string\hsize} (via \LaTeX):
\the\hsize\par
\directlua{
%Haal de huidige waarde van \hsize op met de Lua-API
local hs=tex.hsize
% Gebruik een Lua-API-functie om wat
% LaTeX-code en de waarde van \hsize
tex.print("Hier is de waarde van {\\ttfamily\\string\\hsize}
gerapporteerd door Lua-code (in geschaalde punten): ")
tex.print(hs.."\\par")
%Stel een nieuwe waarde voor \hsize in met de Lua-API
tex.hsize="400pt" % of gebruik tex.hsize=400*65536 (in geschaalde punten)
}%
% Nadat \directlua is afgelopen, vraag LaTeX
% om ons de nieuwe waarde van \hsize te vertellen
Hier is de waarde van {\ttfamily\string\hsize} gerapporteerd
door \LaTeX{} nadat {\tt\string\directlua} is afgelopen:
\the\hsize\par
\end{document}
```

Hier is een afbeelding die het resultaat laat zien van het opmaken van de LaTeX-code (hierboven) met LuaTeX:

![Resultaten van het uitvoeren van LuaTeX](/files/afc2269a81993a539d89f930d7b87468376c5e9a)

Merk op dat de TeX-“truc” van `\let\\\relax` is om problemen te vermijden die worden veroorzaakt door LuaTeX’s “expansie” van de Lua-code: een onderwerp waar we hieronder kort op terugkomen.

### Lua-code gebruiken

Er zijn twee hoofdopties voor het gebruik van Lua-code in je TeX-/LaTeX-documenten:

1. **Inline**: Lua-code rechtstreeks in je `.tex` document schrijven (zoals in het voorbeeld hierboven);
2. **Extern**: Lua-code opslaan in externe `.lua` codebestanden en gebruikmaken van Lua’s mogelijkheden om ze te laden en uit te voeren.

Optie (1) is het meest geschikt voor kortere fragmenten Lua-code. Optie (2) wordt gebruikt voor grotere programma’s of bibliotheken van Lua-code. Het heeft een duidelijk voordeel doordat je lastige problemen kunt vermijden met TeX’s zogenaamde `\catcode` waarden (wat behoorlijk frustrerend kan zijn). De reden voor deze `\catcode` problemen is de “expansie” van Lua-code voordat die aan LuaTeX’s ingebouwde Lua-interpreter wordt gevoed. Deze expansie kan lastig te begrijpen zijn, dus we zullen dit later in een vervolgartikel verder verkennen.

Natuurlijk zijn er LaTeX-pakketten die helpen bij het gebruik van Lua-code in je .tex-bestanden—je kunt bijvoorbeeld het [luacode-pakket](https://ctan.org/pkg/luacode?lang=en).

## Samenvatting en inleiding van deel 2 van dit artikel

De softwarecomponenten waaruit LuaTeX is opgebouwd, samen met de ingebedde Lua-scripttaal, vormen een krachtige combinatie voor het bouwen van oplossingen die in staat zijn een breed scala aan complexe zetproblemen op te lossen — en voor het ontwikkelen van workflows voor documentproductie die kunnen profiteren van nauwe integratie met een op TeX gebaseerde zetmachine. In [Deel 2 van dit artikel](/latex/nl/diepgaande-artikelen/09-an-introduction-to-luatex-part-2-understanding-directlua.md) gaan we diepgaand kijken naar het krachtigste commando dat LuaTeX biedt: `\directlua`.

Tot dan: veel LuaTeX-plezier!

## Dankwoord

De auteur is Luigi Scarso bijzonder dankbaar [Luigi Scarso](https://twitter.com/luigi_scarso), een van de ontwikkelaars van LuaTeX, dat hij de tijd nam om een conceptversie van dit artikel te lezen en een aantal zeer nuttige opmerkingen en suggesties te maken. Eventuele resterende feitelijke fouten of weglatingen zijn uiteraard van de auteur. Daarnaast wil ik graag [Patrick Gundlach](https://twitter.com/patrickgundlach), ontwikkelaar van [speedata publisher](https://speedata.github.io/publisher/), bedanken voor zijn tijd om mijn vragen te beantwoorden.


---

# 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/nl/diepgaande-artikelen/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.