> 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/36-pandora-s-hbox-using-luatex-to-lift-the-lid-of-tex-boxes.md). # Pandora’s \hbox: LuaTeX gebruiken om het deksel van TeX-boxen te lichten ## Inleiding Boxen en lijm zijn twee kernconcepten die de basis vormen voor TeX’ zetmodel en mogelijkheden. Voortbouwend op het inleidende materiaal in een eerdere post, [Boxen en lijm: een korte, maar visuele, introductie met LuaTeX](/latex/nl/diepgaande-artikelen/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md), gaat dit rijk geïllustreerde artikel dieper in op boxen en lijm. We presenteren ook een nieuw op LuaTeX gebaseerd [Overleaf-project](https://www.overleaf.com/latex/examples/exploring-the-structure-of-tex-boxes-with-luatex/pwdrypmtdbgs) dat je in staat stelt de diepere interne structuur van TeX-boxen te verkennen—met inzichten die je helpen hun gedrag echt te begrijpen. De totstandkoming van het Overleaf-project werd sterk vergemakkelijkt door het werk van Patrick Gundlach, dus bieden wij [onze dank aan hem](#credits-thanks-patrick). ## Waarom kiezen voor LuaTeX? Ten eerste is het de moeite waard om opnieuw het verschil tussen LuaTeX en LuaLaTeX te noemen: * LuaTeX is de naam van een uitvoerbare op TeX gebaseerde zetmachine; * LuaLaTeX verwijst naar het gebruik van het LaTeX-macropakket met de LuaTeX-engine. Dit onderscheid is uiterst belangrijk omdat we in dit artikel gebruikmaken van de ingebouwde mogelijkheden van de LuaTeX-engine zelf, en niet alleen de functies/mogelijkheden benutten van commando’s die door het LaTeX-macropakket worden geleverd. Lezers die onzeker zijn over het verschil tussen een TeX-engine en het LaTeX-macropakket kunnen een van onze eerder gepubliceerde artikelen lezen, [Wat zit er in een naam: een gids voor de vele varianten van TeX](/latex/nl/diepgaande-artikelen/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md), die die verschillen enigszins gedetailleerd uitlegt. In datzelfde artikel wordt ook “TeX” als programmeertaal besproken en wordt uitgelegd dat op TeX gebaseerde zetmachines (bijv. pdfTeX, XeTeX en LuaTeX) niet alleen verschillen in hun functies en mogelijkheden, maar ook variaties hebben in de “smaak” van de TeX-taal die ze ondersteunen. Dit brengt ons bij onze keuze voor LuaTeX. Naast ondersteuning van een op TeX gebaseerde programmeertaal heeft LuaTeX ook de Lua-scripttaal erin ingebed—waardoor toegang wordt geboden tot een eenvoudige, maar zeer krachtige, conventionele programmeertaal. Via Lua en de ingebouwde functionaliteit van LuaTeX kun je de zetactiviteiten van LuaTeX op manieren verkennen en aansturen die geen enkele andere TeX-engine biedt—en daaronder valt ook de mogelijkheid om de interne structuren van TeX-boxen te onderzoeken; daarom is LuaTeX de ideale (en enige) keuze voor dit artikel en het bijbehorende Overleaf-project. ### pdfTeX/XeTeX versus LuaTeX: in beelden De volgende *schema’s* zijn bedoeld om een belangrijk verschil te benadrukken tussen het ontwerp van pdfTeX/XeTeX en LuaTeX. Zowel pdfTeX als XeTeX stellen gebruikers natuurlijk in staat TeX-code te schrijven die het zetgedrag kan beïnvloeden; de diepere interne structuren in die TeX-engines, en low-level data die tijdens het zetproces worden opgebouwd, zijn echter grotendeels ontoegankelijk voor gebruikerscommando’s en macro’s. In die zin zijn ze *relatief* gesloten systemen in vergelijking met LuaTeX. #### pdfTeX/XeTeX ![{{{alt}}}](/files/3311a044b9d78ef97a2f3a9e5c3fca2dae734e12) #### LuaTeX LuaTeX introduceert een nieuw primitief commando genaamd `\directlua{...}` waarmee je code kunt schrijven die niet alleen volledige toegang tot de Lua-taal geeft, maar je ook in staat stelt de mogelijkheden van LuaTeX uit te breiden door plug-ins te schrijven in talen zoals C en C++. Op Windows worden zulke plug-ins genoemd *Dynamic Link Libraries* (.DLL); op Linux staan ze bekend als *Shared Object Libraries* (.so). De echte kracht van LuaTeX komt echter voort uit een enorme set ingebouwde Lua-functies die toegang geven tot de interne werking van LuaTeX—waardoor uiterst geavanceerde besturing en programmering van op TeX gebaseerde zetting mogelijk wordt. Een verzameling van zulke functies wordt een API (Application Programming Interface) genoemd, en via de API van LuaTeX gebruik je Lua-programma’s om te communiceren met de op TeX gebaseerde zetmachine en datastructuren. ![{{{alt}}}](/files/b98e975063ca30b2003658d8689eaad765b64f30) Met LuaTeX’s `\directlua{...}` commando kun je bijvoorbeeld low-level interne TeX-datastructuren benaderen die verborgen zijn voor andere TeX-engines. Bovendien kun je Lua-scripts gebruiken om allerlei programmeerberekeningen, tekenreeksmanipulatie enz. uit te voeren en de resultaten terug te geven aan TeX: de mogelijkheden zijn vrijwel eindeloos. Dit artikel is echter niet bedoeld als een gedetailleerde uiteenzetting of handleiding over LuaTeX—al is het verleidelijk voorbeelden te geven die de ongelooflijke veelzijdigheid van deze verbazingwekkend krachtige TeX-engine overbrengen. ## Boxen en lijm: een korte herinnering Zoals geïntroduceerd in het artikel [Boxen en lijm: een korte, maar visuele, introductie met LuaTeX](https://www.overleaf.com/blog/511-boxes-and-glue-a-brief-but-visual-introduction-using-luatex) boxen en lijm zijn twee kernconcepten die de zetmogelijkheden van TeX ondersteunen. Het volgende diagram dient als een zeer korte geheugensteun voor het gedrag van TeX’ horizontale en verticale boxtypen. Let op: horizontale boxen kunnen natuurlijk tekst bevatten die is gezet in van rechts naar links geschreven talen, zoals Arabisch of Hebreeuws, wat betekent dat de groeirichting van de box tegengesteld kan zijn aan die welke hieronder voor de horizontale box wordt getoond. ![{{{alt}}}](/files/3292ee30e24b89e1859afc8a26c370f68081515b) ### TeX-primitieven voor boxconstructie Tegenwoordig maken de meeste mensen hun TeX-documenten op met het LaTeX-macropakket, dat is ontworpen om commando’s te bieden die gebruikers afschermen van een groot deel van TeX’ low-level taal—de zogenoemde *primitieven*—de kerncommando’s die in TeX-engines zijn ingebouwd (zie het artikel [Wat zit er in een naam: een gids voor de vele varianten van TeX](/latex/nl/diepgaande-artikelen/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) voor een bespreking van TeX-primitieven). De LaTeX-macrocollectie biedt verschillende macro’s voor het maken en opslaan van boxen, maar als je alle macrocode wegneemt, zul je zien dat er slechts 4 low-level primitieve commando’s voor boxconstructie zijn: Voor het maken van horizontale lijsten: * \hbox{...} Voor het maken en stapelen van verticale lijsten: * \vbox{...} * \vtop{...} * \vcenter{...} We zullen niet uitleggen hoe je al deze boxcommando’s gebruikt, omdat er elders op het web of in TeX-/LaTeX-boeken plenty aan voorbeelden en tutorials te vinden zijn—maar we zullen wel bekijken hoe boxen worden weergegeven en opgeslagen binnen TeX-datastructuren. ### Lijm: flexibele spatiëring Lijm is in feite een vorm van spatiëring die door TeX wordt gebruikt om elementen horizontaal of verticaal te positioneren/van ruimte te voorzien. Als TeX-gebruiker kunnen we TeX instrueren om een bepaalde hoeveelheid lijm met een vaste grootte in te voegen, of we kunnen flexibele lijm gebruiken—met zoveel flexibiliteit als we nodig hebben, om uit te rekken of in te krimpen afhankelijk van onze behoeften. Een van TeX’ commando’s om lijm voor horizontale spatiëring te maken heet `\hskip` die de vorm heeft `**\hskip** **plus** **minus** ` `**plus**` en `**minus**` zijn TeX-sleutelwoorden, maar je hoeft ze niet voor elke lijm te gebruiken. Als `**plus**` of `**minus**` ontbreken, dan wordt het overeenkomstige `` of `` verondersteld nul te zijn. Bijvoorbeeld, `\hskip 3pt` voegt een lijm met vaste breedte in zonder uitrek- of inkrimpcomponent. Zie voorlopig `` en `` als onze *aanbevelingen* aan TeX, omdat de exacte hoeveelheid uitrekken of inkrimpen door TeX zal worden berekend. Ter ondersteuning van deze ideeën is hier een diagram dat lijm als een veer voorstelt. De `` is de lengte van de veer wanneer er geen spanning (uitrekken) of compressie (inkrimpen) is. De `` en `` worden getoond ten opzichte van de natuurlijke lengte van de veer. ![{{{alt}}}](/files/1d8ba9556b5165c090d6ece06991f14a95da6f56) #### Een \hbox-voorbeeld Stel dat we een `\hbox{...}` met alleen de letters A, B, C en D zouden willen maken en we hebben nodig dat deze box 100pt (100 TeX-punten) breed is. Bovendien mag worden aangenomen dat de totale breedte van die vier tekens veel kleiner is dan 100pt, wat aangeeft dat TeX een manier nodig heeft om de resterende ruimte binnen de box op te vullen: daarvoor zullen we wat lijm gebruiken. Omdat we echter niet precies weten hoeveel lijm nodig is om de box te vullen, is het raadzaam enkele flexibele lijmsoorten toe te voegen en TeX de hoeveelheid ruimte te laten berekenen die die lijm moet innemen. Let in het volgende codefragment op het gebruik van “%” om spaties tussen woorden als gevolg van de regeleindetekens te onderdrukken. ``` \hbox to100pt{% A\hskip4pt plus3pt minus 2pt B% \hskip 0pt plus 2fil C% \hskip 0pt plus 2fill D% \hskip 0pt plus 3fill} ``` De resulterende box ziet er als volgt uit (vergroot ter verduidelijking): ![{{{alt}}}](/files/cfa7a9ba9303e8071dfdc3cd9b2cd01f08817fc1) Dit `\hbox` wordt overdekt met gestippelde vakken (in rood) om de breedte van de tekens aan te geven (zoals TeX ze ziet). Voor zetdoeleinden worden tekens beschouwd als kleine boxen en de hoeveelheid lijm die nodig is om deze `\hbox`wordt bepaald (berekend) door rekening te houden met de breedtes van elk teken. Het blijkt dat TeX de lijm tussen A en B niet heeft uitgerekt of ingekrompen (ingesteld op 4pt) en dat er geen lijm tussen B en C zit (ingesteld op 0pt). De lijm tussen C en D en de lijm tussen D en het einde van de box zijn echter beide aanzienlijk uitgerekt, omdat die lijmsoorten de meest flexibele uitrekcomponent hebben—in feite hebben die lijmsoorten alle uitrekking geabsorbeerd die nodig was om de box te vullen. ## Terug naar LuaTeX Tot nu toe hebben we boxen en lijm verkend en gezien dat LuaTeX toegang biedt tot interne TeX-structuren die verborgen blijven in pdfTeX en XeTeX. Het is tijd voor een voorbeeld om dit explicieter te maken, maar eerst moeten we ons kort vertrouwd maken met de manier waarop TeX boxen in het geheugen opslaat—we beginnen met een analogie. ### Hoe TeX boxen in het geheugen opslaat: een analogie Stel dat je om de een of andere reden een datamodel moest maken dat een fysieke box beschrijft. Welke gegevens zou je kiezen om zo’n beschrijving te geven? Een aanpak die je kunt volgen is de informatie op te splitsen in twee delen: gegevens over de fysieke box zelf en gegevens die een lijst van de inhoud van de box geven. Ons eenvoudige model zou er dan zo uit kunnen zien: 1. Gegevens over de fysieke box (“metadata”): * breedte * hoogte * diepte * gewicht * kleur * type (houten, plastic, karton) 3. Gegevens over de inhoud van de box: een of andere vorm van lijst die de items beschrijft die deze bevat—waarschijnlijk in willekeurige volgorde. En er is een zeer sterke analogie met de manier waarop TeX boxen opslaat. ### Hoe TeX boxen in het geheugen opslaat: hlists en vlists Intern maakt TeX “containers” aan die *hlists* (horizontale lijsten) en *vlists* (verticale lijsten) die respectievelijk hboxen en vboxen vertegenwoordigen. Deze hlist/vlist-objecten bieden een verzameling “metadata” over de box, plus toegang tot de lijst van objecten die de box daadwerkelijk bevat—die lijst wordt een *nodelijst*. In tegenstelling tot een fysieke box, waarin je objecten in willekeurige volgorde kunt plaatsen, is voor TeX de volgorde van de boxinhoud uiterst belangrijk—het zijn items die moeten worden gezet. Als je enige achtergrond hebt in programmeren of informatica, zal het je niet verbazen te horen dat de objecten binnen een TeX-box worden opgeslagen, waarbij hun volgorde van creatie behouden blijft, met behulp van een zogenoemde [dubbel gelinkte lijst](https://en.wikipedia.org/wiki/Doubly_linked_list). We zullen gekoppelde lijsten hier niet verder bespreken, omdat het web wemelt van tutorials, voorbeelden en verklaringen. Het concept van nodes en nodelijsten is een fundamenteel aspect van hoe TeX werkt, maar voor dit artikel geven we slechts een kort overzicht. Nodes zijn in wezen een soort “mini-container” en (vanaf LuaTeX 1.04) zijn er zo’n 50 verschillende soorten node: een weerspiegeling van de interne gegevenstypen en componenten die LuaTeX gebruikt voor zetwerk. Er zijn bijvoorbeeld nodes om glyphs (voortkomend uit “tekens”), lijm, horizontale/verticale regels, penalties, “whatsits”, kerns enzovoort voor te stellen. Al het gezette materiaal wordt uiteindelijk deel van een enorme nodelijst en LuaTeX geeft je directe toegang tot die interne datastructuren. LuaTeX stelt je ook in staat nodelijsten toe te voegen, te bewerken, aan te vullen of te maken, zodat je bijvoorbeeld boxen rechtstreeks in Lua-code kunt maken zonder überhaupt enige TeX-code te hoeven gebruiken. Daarover schrijven is echter voor een andere dag. ### Een eenvoudig voorbeeld van \directlua{...} in actie Het volgende voorbeeld maakt een `\hbox` en slaat deze op in boxregister 0. Vervolgens rapporteren we de breedte van de box met traditionele TeX-code en verkrijgen we dezelfde informatie met een tweede methode via `\directlua{}`. Hier voeren we een klein Lua-script uit dat toegang krijgt tot TeX’ interne opslaggebied voor boxen om de breedte van de box te verkrijgen—natuurlijk zijn de twee waarden identiek: 2412092sp (sp=scaled point: 65536sp = 1 TeX-punt). Uiteindelijk onderzoeken zowel de TeX-code als de Lua-code in dit uiterst eenvoudige voorbeeld dezelfde interne datastructuren om de breedte van de box te verkrijgen, maar via de directe toegangsroute opent LuaTeX de deur naar een schat aan informatie en controle die niet beschikbaar is bij andere engines. ![{{{alt}}}](/files/0bd2c618369023565bfeb183ca4f62d39dd74fc1) ```latex \documentclass{article} \begin{document} \setbox0=\hbox{A\hskip 5pt B\hskip 10pt C} \fontsize{18}{22}\selectfont \noindent Met \TeX{}-code heeft box 0 een breedte van \number\wd0\relax \space sp\par \noindent We kunnen ook Lua gebruiken en een van Lua\TeX’s functies aanroepen om dezelfde informatie op te halen.\vskip10mm \noindent Volgens Lua-code heeft box 0 een breedte van \directlua{ local boxwidth = tex.box[0].width tex.print(boxwidth.." sp") } wat natuurlijk identiek is aan de waarde verkregen uit \TeX{}-code. \end{document} ``` ## Alles bij elkaar: een Overleaf-project We hebben opgemerkt dat TeX intern boxen weergeeft als “containers” die hlists/vlists worden genoemd en die “metadata” over de box opslaan en toegang bieden tot de lijst van componenten waaruit de box is opgebouwd. Met LuaTeX kun je de box-“metadata” en de lijst van items in een TeX-box benaderen: glyphs, lijm, penalties, andere boxen, enzovoort. Met Lua-scripts is het mogelijk een box in TeX’ geheugen te onderzoeken en een gedetailleerde weergave te maken van wat die box bevat. Een geschikte weergave van een TeX-box en zijn inhoud wordt verkregen met *nodediagrammen* en we hebben een [Overleaf-project](https://www.overleaf.com/latex/examples/exploring-the-structure-of-tex-boxes-with-luatex/pwdrypmtdbgs) voorbereid dat dat doet door gebruik te maken van een uitstekend Lua-script geschreven door Patrick Gundlach (zie credits). We zullen de gedetailleerde processen die nodig zijn om boxen te onderzoeken en nodediagrammen te genereren niet beschrijven—behalve op te merken dat elk programma/script dat TeX-boxen verwerkt *recursief* moet zijn, omdat boxen genest kunnen zijn: dat wil zeggen, je kunt hboxen binnen vboxen hebben, binnen hboxen… waarbij alle boxtypen tot een zeer diepe nestingsgraad worden gecombineerd. ![{{{alt}}}](/files/0092dd67e35aac661adc94da90ffe5a0494f5499) ### Wat biedt het project? Het implementeert slechts 1 commando genaamd `\dobox{box command}`, bijvoorbeeld: ```latex \dobox{\hbox to100pt{% A\hskip4pt plus3pt minus 2pt B\hskip 0pt plus 2fil C\hskip 0pt plus 2fill D\hskip 0pt plus 3fill}} ``` De `\dobox{...}` commando voert een aantal taken uit: 1. binnen je document zet het de letterlijke TeX-code voor je box; 2. het genereert een SVG-afbeelding van de TeX-box—je kunt deze in een webpagina insluiten (zoals we in deze blogpost hebben gedaan); 3. het genereert een SVG-afbeelding van de nodelijst—die je ook in webpagina’s kunt insluiten (zoals we in deze blogpost hebben gedaan); 4. het genereert een PDF-afbeelding van de nodelijst die vervolgens wordt geïmporteerd in het hoofd-PDF-document dat door het project wordt geproduceerd. Nodediagrammen kunnen al snel extreem groot worden vanwege de enorme hoeveelheid data die LuaTeX moet opslaan om complexe TeX-boxen weer te geven—zoals de pagina die momenteel wordt opgebouwd, of gezette wiskunde. Bij grotere nodelijsten kan de geïmporteerde PDF-afbeelding worden afgekapt door de paginarand van je document—als je een groot nodediagram wilt bekijken, kun je een ZIP-bestand van het project downloaden en de gewenste PDF-afbeelding uitpakken. Wanneer je het ZIP-bestand van het project downloadt, zorg er dan voor dat je “Input and Output Files” kiest uit de keuzelijst: ![{{{alt}}}](/files/c0e941f190cf8038e6dad9886d4e708e59561d32) ### Afbeeldingen uit het Overleaf-project: een korte beschrijving Voordat we enkele voorbeelden laten zien, is het de moeite waard om een paar observaties te maken over de afbeeldingen die door het Overleaf-project worden geproduceerd—we gebruiken hetzelfde `\hbox` voorbeeld dat eerder in het artikel werd genoemd. Hier is het verpakt in het project’s `\dobox{...}` commando: ```latex \dobox{\hbox to100pt{% A\hskip4pt plus3pt minus 2pt B\hskip 0pt plus 2fil C\hskip 0pt plus 2fill D\hskip 0pt plus 3fill}} ``` Hier is de `\hbox` geproduceerd door TeX—ter verduidelijking is de box vergroot, maar de rand is opgenomen in afbeeldingen die door het Overleaf-project worden geproduceerd. ![{{{alt}}}](/files/8fbdc60ee78ed1ebc2b0bf4b8dd19fed219cab41) Hier is een *geannoteerde* SVG-diagram van de nodelijst die de bovenstaande box weergeeft—annotaties zijn toegevoegd om de box-“metadata” en de lijst met objecten die deze bevat te benadrukken: die annotaties komen niet voor in de afbeeldingen die door het Overleaf-project worden geproduceerd. [![{{{alt}}}](/files/ed5151cbc02a3661e0620c7850bba88d33d754d8)](https://www.filepicker.io/api/file/ZSwIylUR66eFYPMo0suX) Als je naar de sectie “metadata” kijkt, kun je enkele onbekende parameters opmerken: * `glue_set` * `glue_sign` * `glue_order` Deze parameters zijn de instellingen die door TeX worden gebruikt om te berekenen hoeveel de lijm binnen deze box moet uitrekken of inkrimpen en zijn slechts één voorbeeld van data die je eenvoudig via LuaTeX kunt verkrijgen, maar niet met andere TeX-engines. Merk op dat lijm-nodes in de boxcomponenten *behouden* de oorspronkelijke lijmwaarden die we invoerden om de box te maken. Dit is essentieel omdat TeX de commando’s biedt `\unhbox`, `\unvbox`, `\unhcopy`, `\unvcopy` die de inhoud van de box “unboxen” en terug vrijgeven aan de invoerstroom om opnieuw deel te nemen aan zethandelingen. Pas wanneer TeX de box uiteindelijk uitvoert (ships out) naar een PDF- of DVI-bestand worden `glue_set`, `glue_sign` en `glue_order` toegepast op alle lijm in de box—om de daadwerkelijke hoeveelheid uitrekken of inkrimpen te berekenen die nodig is om componenten binnen de box te positioneren en vervolgens de juiste PDF-data of DVI-opcodes te genereren. Een andere parameter die in de “metadata” wordt vermeld is `shift`: dit is de waarde van de boxverplaatsing als gevolg van het toepassen van TeX-commando’s: * `\raise`, `\lower` (toegepast op een `\hbox`); * `\moveleft`, `\moveright` (toegepast op een `\vbox`). In ons voorbeeld, `shift` is 0pt omdat we de `\hbox` niet uit zijn natuurlijke positie hebben verplaatst. De [Overleaf-project](https://www.overleaf.com/latex/examples/exploring-the-structure-of-tex-boxes-with-luatex/pwdrypmtdbgs) genereert ook nodediagrammen in PDF-formaat: hier is een link om een [PDF-bestandsversie](https://www.filepicker.io/api/file/bezigXESC2FSasvjoh8A) van het bovenstaande nodediagram te downloaden. ### Hoe maakt het Overleaf-project die afbeeldingen? Het Overleaf-project maakt gebruik van de mogelijkheid om softwaretools en hulpprogramma’s uit te voeren die op de servers van Overleaf zijn geïnstalleerd—zie [deze blogpost](/latex/nl/diepgaande-artikelen/52-using-luatex-to-run-tools-and-utilities-installed-on-overleaf-s-servers.md) voor meer details en een voorbeeldproject. Om een SVG-afbeelding te maken die een TeX-box weergeeft, wordt de TeX-code van de box weggeschreven naar een klein bestand dat vervolgens met pdfTeX wordt gezet om een DVI-bestand te genereren—merk op dat het pdfTeX-programma wordt uitgevoerd door LuaTeX via enkele regels Lua-script. Dat DVI-bestand wordt on-the-fly omgezet naar SVG met behulp van de `dvisvgm` hulpapplicatie—die wordt meegeleverd met de TeX Live-distributie die op de servers van Overleaf is geïnstalleerd. `dvisvgm` wordt uitgevoerd met de commandoregeloptie `-n` om ervoor te zorgen dat alle gezette tekst wordt omgezet in lijnen/curven, zodat de correcte weergave van het SVG-bestand niet afhankelijk is van geïnstalleerde TeX-lettertypen. Om de nodediagrammen te maken, gebruiken we een Lua-script genaamd `hiviznodelist.lua` dat is gebaseerd op het werk van Patrick Gundlach. Dat script schrijft een zogenoemd `.gv` (Graphviz)-bestand weg, een tekstbestand met een nodediagram beschreven in de `dot` taal. Het `.gv` bestand wordt verwerkt door een hulpprogramma genaamd `dot` dat een nodediagram uitvoert in zowel PDF- als SVG-bestandsformaten. ### Projectvoorbeelden Hier zijn enkele aanvullende voorbeelden met SVG-afbeeldingen die zijn geproduceerd met behulp van het Overleaf-project. Boxen met veel tekst (bijv. in een \vbox), of complexe wiskunde, zullen enorme nodediagrammen opleveren—als je het Overleaf-project verkent, is het raadzaam geen onnodig complexe boxen te gebruiken om de voor jou interessante functies te demonstreren. #### \vbox to 25pt{A} Dit voorbeeld toont het effect van het direct plaatsen van tekst in een `\vbox`: merk op dat de nodestructuur vrij complex is, zelfs voor zo’n eenvoudige box. De reden voor deze complexiteit is dat tekst die rechtstreeks in een `\vbox` zorgt ervoor dat TeX regelafbreking toepast. Je kunt zien dat de `\vbox` 345pt breed is: de waarde van `\hsize` op het moment dat deze box werd gemaakt. Merk ook op dat het teken “A” zich in een `hlist` bevindt dat ook 345 punten breed is, en let op de grote penalty (10000) samen met `\parfillskip` en `\rightskip` lijm aan het einde van de boxinhoud. Die penalty en de twee lijmitems worden door TeX’ regelafbrekingsactiviteiten ingevoegd. Als je kijkt naar de `glue_set` waarde voor de alinea-regel (`hlist`) met de letter “A” zul je zien dat deze extreem groot is (322.500000): waarom is dat? Omdat de alinea-regel 345pt breed is maar slechts een `\parindent` en de letter “A” bevat: de resterende ruimte moet worden opgevuld door de `\parfillskip` lijm die een aanzienlijke afstand moet uitrekken om de resterende ruimte op de regel op te vullen. ![{{{alt}}}](/files/a00d86364bb3f9b8128c6be6d027cebe98e457b8) [![{{{alt}}}](/files/43edc87ef9f34d1baf2c502e71f50fa2d6fd420c)](https://www.filepicker.io/api/file/pVtHsNGSQ4m09vBZuOpQ) [PDF-bestand downloaden](https://www.filepicker.io/api/file/nBS0uDs2QjqKCKljAm7r) #### \vbox to 25pt{\hbox{A}} Het is zeer leerzaam om dit voorbeeld met het vorige te vergelijken. Hier is niet alleen het nodediagram aanzienlijk kleiner, maar de breedte van de `\vbox` is slechts 7.50002pt: dezelfde breedte als het teken “A”. De reden is dat de “A” is omgeven door een `\hbox` wat voorkomt dat de `\vbox` TeX ertoe aanzet regelafbreking uit te voeren—een belangrijk kenmerk van boxen die zijn gemaakt met `\vbox`. ![{{{alt}}}](/files/b706c78459c3dec37227a3ed782771403596d2d0) [![{{{alt}}}](/files/4ef488b0e359107abb04491537eaa94bcf7c5643)](https://www.filepicker.io/api/file/LHepknjnRGOVEdghW4qH) [PDF-bestand downloaden](https://www.filepicker.io/api/file/Yk3uCCQR5ao8Yd3TJCdE) #### Eenvoudige wiskunde: \hbox{$$\displaystyle \int f(x) dx$$}, complexe box! Dit voorbeeld laat zien dat zelfs zeer eenvoudige gezette wiskunde een gedetailleerde boxstructuur creëert: het zetten van wiskunde produceert *extreem* complexe datastructuren binnen TeX! ![{{{alt}}}](/files/e5e8e0ae2de24a9e85dfbda7d0d570bda9efcf7f) [![{{{alt}}}](/files/3efb7bd42ad11017fb0936a59b0ec8061cdfe4d6)](https://www.filepicker.io/api/file/oVFNNvCqT0eZP0qS2odk) [PDF-bestand downloaden](https://www.filepicker.io/api/file/D5TepsdaSdeYZvkuSEJt) ## Credits: dank je, Patrick! Onze dank aan [Patrick Gundlach](https://twitter.com/patrickgundlach) die Overleaf toestemming heeft gegeven om een aangepaste versie van zijn Lua-script te gebruiken en te verspreiden, `viznodelist.lua`, dat TeX-boxen verwerkt en een bestand uitvoert (in de `dot` taal) dat kan worden verwerkt om een nodediagram te tekenen. Het Overleaf-project bevat een Lua-script genaamd `hiviznodelist.lua`—een hernoemde en aangepaste versie van Patrick’s originele code, die beschikbaar is op [Github](http://gist.github.com/556247). Patrick heeft een open-source op LuaTeX gebaseerd zet­systeem gemaakt genaamd [speedata Publisher](https://speedata.github.io/publisher/index.html) dat je gratis kunt downloaden en gebruiken—commerciële ondersteuningsopties zijn ook beschikbaar. --- # 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/36-pandora-s-hbox-using-luatex-to-lift-the-lid-of-tex-boxes.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.