> 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/sv/fordjupade-artiklar/36-pandora-s-hbox-using-luatex-to-lift-the-lid-of-tex-boxes.md). # Pandoras \hbox: Att använda LuaTeX för att lyfta på locket till TeX-rutor ## Introduktion Boxar och glue är två nyckelbegrepp som utgör grunden för TeX:s sättningsmodell och möjligheter. Med utgångspunkt i det inledande materialet i ett tidigare inlägg, [Boxar och glue: En kort, men visuell, introduktion med LuaTeX](/latex/sv/fordjupade-artiklar/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md), utforskar denna rikt illustrerade artikel boxar och glue mer ingående. Vi presenterar också ett nytt LuaTeX-baserat [Overleaf-projekt](https://www.overleaf.com/latex/examples/exploring-the-structure-of-tex-boxes-with-luatex/pwdrypmtdbgs) som låter dig utforska den djupa interna strukturen hos TeX-boxar — vilket ger insikter som hjälper dig att verkligen förstå deras beteende. Skapandet av Overleaf-projektet underlättades i hög grad av Patrick Gundlachs arbete, så vi framför [vårt tack till honom](#credits-thanks-patrick). ## Varför välja LuaTeX? För det första är det värt att återigen slå fast skillnaden mellan LuaTeX och LuaLaTeX: * LuaTeX är namnet på en körbar TeX-baserad sättningsmotor; * LuaLaTeX syftar på användningen av LaTeX-makropaketet tillsammans med LuaTeX-motorn. Denna distinktion är oerhört viktig eftersom vi i den här artikeln utnyttjar själva LuaTeX-motorns inbyggda möjligheter, och inte bara drar nytta av funktionerna hos kommandon som tillhandahålls av LaTeX-makropaketet. Läsare som är osäkra på skillnaden mellan en TeX-motor och LaTeX-makropaketet kan vilja läsa en av våra tidigare publicerade artiklar, [Vad finns i ett namn: En guide till TeX:s många varianter](/latex/sv/fordjupade-artiklar/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md), som förklarar dessa skillnader ganska utförligt. Samma artikel diskuterar också “TeX” som programmeringsspråk och att TeX-baserade sättningsmotorer (t.ex. pdfTeX, XeTeX och LuaTeX) inte bara skiljer sig åt i sina funktioner och sin funktionalitet, utan också har variationer i den “variant” av TeX-språket de stöder. Detta för oss till vårt val av LuaTeX. Förutom att stödja ett TeX-baserat programmeringsspråk har LuaTeX också skriptspråket Lua inbäddat i sig — vilket ger tillgång till ett enkelt, men mycket kraftfullt, konventionellt programmeringsspråk. Genom Lua och LuaTeX:s inbyggda funktionalitet kan du utforska och styra sättningsarbetet i LuaTeX på sätt som ingen annan TeX-motor erbjuder — och detta inkluderar möjligheten att undersöka de inre strukturerna hos TeX-boxar; därför är LuaTeX det idealiska (enda) valet för denna artikel och det tillhörande Overleaf-projektet. ### pdfTeX/XeTeX kontra LuaTeX: i bilder Följande *scheman* är avsedda att belysa en viktig jämförelse mellan utformningen av pdfTeX/XeTeX och LuaTeX. Både pdfTeX och XeTeX tillåter naturligtvis användare att skriva TeX-kod som kan påverka sättningsbeteendet; dock är de djupare interna strukturer som finns i dessa TeX-motorer, och låg-nivådata som konstrueras under sättningsprocessen, i stort sett otillgängliga för användarkommandon och makron. I den meningen är de *relativt* slutna system jämfört med LuaTeX. #### pdfTeX/XeTeX ![{{{alt}}}](/files/54c237d67b07a973228b1292b0b7f0a8290d169d) #### LuaTeX LuaTeX introducerar ett nytt primitivt kommando som kallas `\directlua{...}` genom vilket du kan skriva kod som inte bara ger full tillgång till Lua-språket utan också låter dig utöka LuaTeX:s kapacitet genom att skriva insticksmoduler med språk som C och C++. På Windows kallas sådana insticksmoduler för *dynamiska länkbibliotek* (.DLL); på Linux kallas de *delade objektbibliotek* (.so). LuaTeX:s verkliga kraft härrör dock från en enorm uppsättning inbyggda Lua-funktioner som ger tillgång till LuaTeX:s inre — vilket möjliggör extremt sofistikerad styrning och programmering av TeX-baserad sättning. En sådan uppsättning funktioner kallas ett API (Application Programming Interface), och det är via LuaTeX:s API som du använder Lua-program för att kommunicera med dess TeX-baserade sättningsmotor och datastrukturer. ![{{{alt}}}](/files/4b1ea1208bd947646d3fe9bf409e8449fc63c2a0) Med LuaTeX:s `\directlua{...}` kommando kan du till exempel få tillgång till interna TeX-datastrukturer på låg nivå som döljs från insyn i andra TeX-motorer. Dessutom kan du använda Lua-skript för att utföra alla möjliga programmeringsberäkningar, strängmanipulering etc. och skicka resultaten tillbaka till TeX: möjligheterna är nästan oändliga. Den här artikeln är dock inte tänkt som en detaljerad genomgång eller handledning i LuaTeX — även om det är frestande att ge exempel som förmedlar den otroliga mångsidigheten hos denna häpnadsväckande kraftfulla TeX-motor. ## Boxar och glue: en kort påminnelse Som introducerades i artikeln [Boxar och glue: En kort, men visuell, introduktion med LuaTeX](https://www.overleaf.com/blog/511-boxes-and-glue-a-brief-but-visual-introduction-using-luatex) är boxar och glue två nyckelbegrepp som ligger till grund för TeX:s sättningsmöjligheter. Följande diagram erbjuds som en mycket kort hjälp att minnas beteendet hos TeX:s horisontella och vertikala boxtyper. Obs: horisontella boxar kan naturligtvis innehålla text satt på höger-till-vänster-språk, såsom arabiska eller hebreiska, vilket innebär att riktningen för boxens tillväxt kan vara motsatt den som visas för den horisontella boxen i diagrammet nedan. ![{{{alt}}}](/files/1383ba44385b206689a7fe696958d770a2dfd26d) ### TeX-primitiver för boxkonstruktion I dag förbereder de flesta sina TeX-dokument med LaTeX-makropaketet, som är utformat för att tillhandahålla kommandon som skyddar användarna från stora delar av TeX:s låg-nivåspråk — dess så kallade *primitiver*— kärnkommandona inbyggda i TeX-motorer (se artikeln [Vad finns i ett namn: En guide till TeX:s många varianter](/latex/sv/fordjupade-artiklar/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) för en diskussion om TeX-primitiver). LaTeX-makrosamlingen tillhandahåller en mängd makron för att skapa och lagra (spara) boxar, men om du tar bort all makrokod hittar du att det bara finns fyra låg-nivå primitiva kommandon för boxkonstruktion: För att skapa horisontella listor: * \hbox{...} För att skapa och stapla vertikala listor: * \vbox{...} * \vtop{...} * \vcenter{...} Vi kommer inte att förklara hur man använder alla dessa boxkommandon eftersom det finns gott om exempel och handledningar på webben eller i TeX-/LaTeX-böcker — men vi kommer att titta på hur boxar representeras och lagras inuti TeX:s datastrukturer. ### Glue: flexibel avståndshållning Glue är i praktiken en form av avstånd som TeX använder för att placera objekt horisontellt eller vertikalt. Som TeX-användare kan vi instruera TeX att infoga viss glue som har en fast storlek eller så kan vi använda glue som är flexibel — med så mycket flexibilitet som vi behöver, antingen för att sträckas ut eller krympa beroende på våra krav. Ett av TeX:s kommandon för att skapa glue för horisontellt avstånd kallas `\hskip` och har formen `**\hskip** **plus** **minus** ` `**plus**` och `**minus**` är TeX-nyckelord, men du behöver inte använda dem för all glue. Om `**plus**` eller `**minus**` saknas antas motsvarande `` eller `` vara noll. Till exempel, `\hskip 3pt` infogar glue med fast bredd utan komponent för sträckning eller krympning. För tillfället kan du tänka på `` och `` som våra *rekommendationer* till TeX eftersom den exakta mängden utsträckning eller krympning kommer att beräknas av TeX. För att hjälpa till med dessa idéer finns här ett diagram som representerar glue som en fjäder. `` är fjäderns längd när det inte finns någon spänning (sträckning) eller kompression (krympning). `` och `` visas i förhållande till fjäderns naturliga längd. ![{{{alt}}}](/files/285ce1b293f54abd31dd56af1f671ab748bcd7ca) #### Ett exempel med \hbox Anta att vi vill skapa en `\hbox{...}` som bara innehåller bokstäverna A, B, C och D och att vi behöver att denna box ska vara 100pt (100 TeX-punkter) bred. Dessutom kan man anta att den totala bredden för dessa fyra tecken är långt mindre än 100pt, vilket visar att TeX behöver något sätt att fylla upp det återstående utrymmet i boxen: vi kommer att använda lite glue för att göra det. Men eftersom vi inte vet den exakta mängd glue som krävs för att fylla boxen är det lämpligt att lägga till lite flexibel glue och låta TeX sköta beräkningen av den mängd utrymme dessa glue-element behöver uppta. I följande kodsnutt, lägg märke till användningen av “%” för att undertrycka ordmellanrum som uppstår från radsluts-tecknen. ``` \hbox to100pt{% A\hskip4pt plus3pt minus 2pt B% \hskip 0pt plus 2fil C% \hskip 0pt plus 2fill D% \hskip 0pt plus 3fill} ``` Den resulterande boxen ser ut så här (förstorad för tydlighet): ![{{{alt}}}](/files/97a8a47c2ea9c84eb8a12777374d6196cb02f1ae) Denna `\hbox` läggs ett streckat boxlager ovanpå (i rött) för att ange tecknens bredd (så som TeX ser dem). För sättningsändamål betraktas tecken som små boxar och mängden glue som krävs för att fylla denna `\hbox`bestäms (beräknas) genom att ta hänsyn till bredden på varje tecken. Det visar sig att TeX varken sträckte eller krympte glue mellan A och B (satt till 4pt) och att det inte finns något glue mellan B och C (satt till 0pt). Däremot har glue mellan C och D och glue mellan D och slutet av boxen båda sträckts avsevärt eftersom dessa glue-element har den mest flexibla sträckkomponenten — i praktiken tog dessa glue-element upp all den sträckning som krävdes för att fylla boxen. ## Tillbaka till LuateX Hittills har vi utforskat boxar och glue och sett att LuaTeX ger tillgång till interna TeX-strukturer som döljs från insyn med pdfTeX och XeTeX. Det är dags för ett exempel för att göra detta mer tydligt, men först behöver vi kort bekanta oss med hur TeX lagrar boxar i sitt minne — vi börjar med en analogi. ### Hur TeX lagrar boxar i minnet: en analogi Anta att du av någon anledning behövde skapa en datamodell som beskriver en fysisk låda. Vilka data skulle du kunna välja för att ge en sådan beskrivning? Ett tillvägagångssätt du skulle kunna använda är att dela upp informationen i två delar: data om själva den fysiska lådan och data som ger en lista över lådans innehåll. Så vår enkla modell skulle kunna se ut så här: 1. Data om den fysiska lådan (“metadata”): * width * höjd * djup * vikt * färg * typ (trä, plast, kartong) 3. Data om lådans innehåll: någon form av lista som beskriver de föremål den innehåller — sannolikt listade i ingen särskild ordning. Och det finns en mycket nära analogi med hur TeX lagrar boxar. ### Hur TeX lagrar boxar i minnet: hlists och vlists Internt skapar TeX “behållare” som kallas *hlists* (horisontella listor) och *vlists* (vertikala listor) som representerar hboxes respektive vboxes. Dessa hlist-/vlist-objekt tillhandahåller en samling “metadata” om boxen, plus att de ger tillgång till listan av objekt som boxen faktiskt innehåller — den listan kallas en *nodlista*. Till skillnad från en fysisk låda, där du kan placera föremål i den i vilken ordning som helst, är ordningen på boxens innehåll oerhört viktig för TeX — de är objekt som ska sättas. Om du har någon bakgrund inom programmering eller datavetenskap kommer det inte som någon överraskning att objekten i en TeX-box lagras, och att deras skapelseordning bevaras, med hjälp av en så kallad [dubbellänkad lista](https://en.wikipedia.org/wiki/Doubly_linked_list). Vi kommer inte att diskutera länkade listor i ytterligare detalj eftersom webben myllrar av handledningar, exempel och förklaringar. Begreppet noder och nodlistor är en grundläggande aspekt av hur TeX fungerar men för den här artikelns syften ger vi bara en kort översikt. Noder är i själva verket en sorts “minibehållare” och (från och med LuaTeX 1.04) finns det omkring 50 olika typer av nod: de återspeglar de interna datatyper och komponenter som LuaTeX använder för sättning. Till exempel finns det noder för att representera: glypher (som uppstår från “tecken”), glue, horisontella/vertikala regler, straff, “whatsits”, kerns och så vidare. Allt material som sätts kommer så småningom att bli en del av en enorm nodlista och LuaTeX ger dig direkt tillgång till dessa inre datastrukturer. LuaTeX låter dig också lägga till, redigera, ändra eller skapa nodlistor så att du till exempel kan skapa boxar direkt inuti Lua-kod utan att behöva använda någon TeX-kod alls. Att skriva om det är dock för en annan dag. ### Ett enkelt exempel på \directlua{...} i praktiken Följande exempel skapar en `\hbox` och sparar den i boxregister 0. Vi rapporterar sedan boxens bredd med traditionell TeX-kod och får samma information med en andra metod via `\directlua{}`. Här kör vi ett litet Lua-skript som kommer åt TeX:s interna lagringsområde för boxar för att hämta boxens bredd — naturligtvis är de två värdena identiska: 2412092sp (sp = scaled point: 65536sp = 1 TeX-punkt). I slutändan undersöker både TeX-koden och Lua-koden i detta mycket enkla exempel samma interna datastrukturer för att hämta boxens bredd, men det är genom den direkta åtkomstvägen som LuaTeX öppnar dörren till en mängd information och kontroll som inte finns i andra motorer. ![{{{alt}}}](/files/5799fcef1843951cd9a1c4ed3eed5fb50fe46e8b) ```latex \documentclass{article} \begin{document} \setbox0=\hbox{A\hskip 5pt B\hskip 10pt C} \fontsize{18}{22}\selectfont \noindent Med \TeX{}-kod har box 0 bredden \number\wd0\relax \space sp\par \noindent Vi kan också använda Lua och anropa en av Lua\TeX:s funktioner för att få samma information.\vskip10mm \noindent Från Lua-kod har box 0 bredden \directlua{ local boxwidth = tex.box[0].width tex.print(boxwidth.." sp") } vilket naturligtvis är identiskt med värdet som erhålls från \TeX{}-kod. \end{document} ``` ## Sammanfattning: Ett Overleaf-projekt Vi har noterat att TeX internt representerar boxar som “behållare” som kallas hlists/vlists, vilka lagrar “metadata” om boxen och ger tillgång till listan av komponenter som boxen är uppbyggd av. Med LuaTeX kan du komma åt boxens “metadata” och listan av objekt som finns i en TeX-box: glypher, glue, straff, andra boxar och så vidare. Med Lua-skript är det möjligt att undersöka en box som ligger i TeX:s minne och rita en detaljerad representation av vad den boxen innehåller. En lämplig representation av en TeX-box och dess innehåll åstadkoms med *nodgrafer* och vi har förberett ett [Overleaf-projekt](https://www.overleaf.com/latex/examples/exploring-the-structure-of-tex-boxes-with-luatex/pwdrypmtdbgs) som gör det genom att utnyttja ett utmärkt Lua-skript skrivet av Patrick Gundlach (se tack). Vi kommer inte att beskriva de detaljerade processer som krävs för att undersöka boxar och generera nodgrafer — förutom att notera att alla program/skript som bearbetar TeX-boxar måste vara *rekursiva* eftersom boxar kan vara nästlade: dvs. du kan ha hboxes inuti vboxes, inuti hboxes … vilket kombinerar alla boxtyper till mycket djup nästling. ![{{{alt}}}](/files/24c0895e6332778680001120445a9c258d5f5c43) ### Vad tillhandahåller projektet? Det implementerar bara ett kommando som kallas `\dobox{boxkommando}`, till exempel: ```latex \dobox{\hbox to100pt{% A\hskip4pt plus3pt minus 2pt B\hskip 0pt plus 2fil C\hskip 0pt plus 2fill D\hskip 0pt plus 3fill}} ``` Den `\dobox{...}` kommandot utför ett antal uppgifter: 1. i ditt dokument sätter det den ordagranna TeX-koden för din box; 2. det genererar en SVG-grafik av TeX-boxen — du kan bädda in detta i en webbsida (som vi har gjort i det här blogginlägget); 3. det genererar en SVG-grafik av nodlistan — som du också kan bädda in i webbsidor (som vi har gjort i det här blogginlägget); 4. det genererar en PDF-grafik av nodlistan som sedan importeras i det huvudsakliga PDF-dokumentet som projektet producerar. Nodgrafer kan mycket snabbt bli extremt stora på grund av den enorma mängd data som LuaTeX behöver lagra för att representera komplexa TeX-boxar — såsom den sida som för närvarande byggs upp, eller satt matematik. För större nodlistor kan den importerade PDF-grafiken bli avklippt av ditt dokuments sidgräns — om du vill visa en stor nodgraf kan du ladda ner en ZIP-fil av projektet och extrahera den PDF-grafik du är intresserad av. När du laddar ner projektets ZIP-fil, se till att välja “Input and Output Files” från rullgardinsmenyn: ![{{{alt}}}](/files/8fefa4c1e1a68a75f89a39a6a9e3f995c1c13e83) ### Grafik från Overleaf-projektet: en kort beskrivning Innan vi visar några exempel är det värt att göra några iakttagelser om den grafik som produceras av Overleaf-projektet — vi använder samma `\hbox` exempel som nämndes tidigare i artikeln. Här är det inramat i projektets `\dobox{...}` kommandot: ```latex \dobox{\hbox to100pt{% A\hskip4pt plus3pt minus 2pt B\hskip 0pt plus 2fil C\hskip 0pt plus 2fill D\hskip 0pt plus 3fill}} ``` Här är `\hbox` som producerats av TeX — för tydlighetens skull har boxen skalats upp, men kanten ingår i den grafik som produceras av Overleaf-projektet. ![{{{alt}}}](/files/166bb5538697f9da96bee671f04b8658e233aee6) Här är en *animerad* SVG-diagram över nodlistan som representerar boxen ovan — annoteringar har lagts till för att framhäva boxens “metadata” och listan av objekt den innehåller: dessa annoteringar finns inte i grafiken som produceras av Overleaf-projektet. [![{{{alt}}}](/files/59c5478e4c54c319ff8872e22e82ea321bfcdf2e)](https://www.filepicker.io/api/file/ZSwIylUR66eFYPMo0suX) Om du tittar på avsnittet “metadata” kanske du lägger märke till några obekanta parametrar: * `glue_set` * `glue_sign` * `glue_order` Dessa parametrar är de inställningar som TeX använder för att beräkna hur mycket glue som måste sträckas eller krympas inom denna box och är bara ett exempel på data som du lätt kan få via LuaTeX men inte med andra TeX-motorer. Observera att glue-noder som finns i boxens komponenter *behåller* de ursprungliga glue-värden vi skrev in för att skapa boxen. Detta är viktigt eftersom TeX tillhandahåller kommandona `\unhbox`, `\unvbox`, `\unhcopy`, `\unvcopy` som “boxar upp” innehållet i boxen och släpper tillbaka det i inmatningsströmmen för att återigen delta i sättningsoperationer. Det är först när TeX slutligen skickar ut (shippar ut) boxen till en PDF- eller DVI-fil som `glue_set`, `glue_sign` och `glue_order` tillämpas på alla glue-element som finns i boxen — för att beräkna den faktiska mängden sträckning eller krympning som krävs för att positionera komponenterna inom boxen och sedan generera lämpliga PDF-data eller DVI-opkoder. En annan parameter som listas i “metadata” är `shift`: detta är värdet för boxförskjutning som uppstår när TeX-kommandona * `\raise`, `\lower` (tillämpas på en `\hbox`); * `\moveleft`, `\moveright` (tillämpas på en `\vbox`). I vårt exempel, `shift` är 0pt eftersom vi inte försköt `\hbox` från dess naturliga position. Den [Overleaf-projekt](https://www.overleaf.com/latex/examples/exploring-the-structure-of-tex-boxes-with-luatex/pwdrypmtdbgs) utger också nodgrafdiagram i PDF-format: här är en länk för att ladda ner en [PDF-filversion](https://www.filepicker.io/api/file/bezigXESC2FSasvjoh8A) av nodgrafen ovan. ### Hur skapar Overleaf-projektet den där grafiken? Overleaf-projektet utnyttjar möjligheten att köra programvaruverktyg och utiliteter som är installerade på Overleafs servrar — se [det här blogginlägget](/latex/sv/fordjupade-artiklar/52-using-luatex-to-run-tools-and-utilities-installed-on-overleaf-s-servers.md) för mer detaljer och ett exempelprojekt. För att skapa en SVG-grafik som representerar en TeX-box skrivs boxens TeX-kod ut till en liten fil som sedan sätts med pdfTeX för att generera en DVI-fil — notera att pdfTeX-programmet körs av LuaTeX genom användning av några rader Lua-skript. Den DVI-filen konverteras i farten till SVG med hjälp av `dvisvgm` verktyget — som levereras med TeX Live-distributionen som är installerad på Overleafs servrar. `dvisvgm` körs med kommandoradsalternativet `-n` för att säkerställa att all satt text konverteras till linjer/kurvor så att korrekt rendering av SVG-filen inte är beroende av att TeX-typsnitt är installerade. För att skapa nodgraferna använder vi ett Lua-skript som kallas `hiviznodelist.lua` som bygger på arbete av Patrick Gundlach. Det skriptet skriver ut en så kallad `.gv` (Graphviz)-fil, som är en textfil innehållande en nodgraf beskriven i språket `dot` . Filen `.gv` bearbetas av ett verktygsprogram som kallas `dot` som ger ut ett nodiagram i både PDF- och SVG-filformat. ### Exempel från projektet Här är några ytterligare exempel med SVG-grafik som producerats med hjälp av Overleaf-projektet. Boxar som innehåller mycket text (t.ex. i en \vbox) eller komplex matematik kommer att ge enorma nodgrafer — om du utforskar Overleaf-projektet är det lämpligt att inte använda onödigt komplexa boxar för att demonstrera de funktioner du är intresserad av. #### \vbox to 25pt{A} Detta exempel visar effekten av att lägga text direkt i en `\vbox`: lägg märke till att nodstrukturen är ganska komplex, även för en så enkel box. Orsaken till denna komplexitet är att text som placeras direkt i en `\vbox` orsakar att TeX utför radbrytning. Du kan se att `\vbox` är 345pt bred: värdet på `\hsize` vid den tidpunkt då denna box skapades. Lägg också märke till att tecknet “A” finns inuti en `hlist` som också är 345 punkter bred, och observera den stora straffsumman (10000) tillsammans med `\parfillskip` och `\rightskip` glue-element i slutet av boxens innehåll. Denna straff och de två glue-elementen infogas av TeX:s radbrytningsarbete. Om du tittar på `glue_set` värdet för paragrafens rad (`hlist`) som innehåller bokstaven “A” ser du att det är extremt stort (322.500000): varför det? Det beror på att paragrafens rad är 345pt bred men bara innehåller en `\parindent` och bokstaven “A”: det återstående utrymmet måste fyllas av `\parfillskip` glue-elementet som måste sträckas ut en ansenlig sträcka för att fylla det återstående utrymmet på raden. ![{{{alt}}}](/files/b15f5562c7d4746698d4ea8e800449d76fbf7587) [![{{{alt}}}](/files/5233b468d207b132d9551d7e29850820413d82ab)](https://www.filepicker.io/api/file/pVtHsNGSQ4m09vBZuOpQ) [Ladda ner PDF-fil](https://www.filepicker.io/api/file/nBS0uDs2QjqKCKljAm7r) #### \vbox to 25pt{\hbox{A}} Det är mycket lärorikt att jämföra detta exempel med det föregående. Här är inte bara nodgrafen betydligt mindre, utan bredden på `\vbox` är bara 7.50002pt: samma bredd som tecknet “A”. Orsaken är att “A” har omslutits av en `\hbox` vilket förhindrar `\vbox` att utlösa TeX att utföra radbrytning — en viktig egenskap hos boxar som skapas med `\vbox`. ![{{{alt}}}](/files/02d6fad05d5e5aa4127df2755478f59e0e412ce7) [![{{{alt}}}](/files/1c4faac88977cd5dd144addc7413a20399d4d43a)](https://www.filepicker.io/api/file/LHepknjnRGOVEdghW4qH) [Ladda ner PDF-fil](https://www.filepicker.io/api/file/Yk3uCCQR5ao8Yd3TJCdE) #### Enkelt matte: \hbox{$$\displaystyle \int f(x) dx$$}, komplex box! Detta exempel visar att även mycket enkel satt matematik skapar en detaljerad boxstruktur: sättning av matematik producerar *extremt* komplexa datastrukturer inom TeX! ![{{{alt}}}](/files/f84412e33b17223dda855b1ebdfc16eacaef1f0a) [![{{{alt}}}](/files/b6040894d2a30380c4aaf817ba57d35e426a3da5)](https://www.filepicker.io/api/file/oVFNNvCqT0eZP0qS2odk) [Ladda ner PDF-fil](https://www.filepicker.io/api/file/D5TepsdaSdeYZvkuSEJt) ## Tack: tack Patrick! Vårt tack till [Patrick Gundlach](https://twitter.com/patrickgundlach) som har gett Overleaf tillstånd att använda och distribuera en modifierad version av hans Lua-skript, `viznodelist.lua`, som bearbetar TeX-boxar och ger ut en fil (i `dot` språket) som kan bearbetas för att rita en nodgraf. Overleaf-projektet innehåller ett Lua-skript kallat `hiviznodelist.lua`— en omdöpt och modifierad version av Patricks ursprungliga kod, som finns tillgänglig på [Github](http://gist.github.com/556247). Patrick har skapat ett öppen källkod-baserat sättningssystem med LuaTeX kallat [speedata Publisher](https://speedata.github.io/publisher/index.html) som du kan ladda ner och använda gratis — kommersiella supportalternativ finns också tillgängliga. --- # 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/sv/fordjupade-artiklar/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.