> 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/36-pandora-s-hbox-using-luatex-to-lift-the-lid-of-tex-boxes.md).

# Pandoras \hbox: Bruke LuaTeX til å løfte lokket av TeX-bokser

## Innledning

Bokser og lim er to nøkkelbegreper som danner grunnlaget for TeXs satsmodell og muligheter. Med utgangspunkt i innledningsmaterialet i et tidligere innlegg, [Bokser og lim: En kort, men visuell, introduksjon med LuaTeX](/latex/no/dybdeartikler/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md), undersøker denne rikt illustrerte artikkelen bokser og lim nærmere. Vi presenterer også et nytt LuaTeX-basert [Overleaf-prosjekt](https://www.overleaf.com/latex/examples/exploring-the-structure-of-tex-boxes-with-luatex/pwdrypmtdbgs) som lar deg utforske den dype indre strukturen til TeX-bokser—og gir innsikt som vil hjelpe deg til virkelig å forstå hvordan de oppfører seg. Opprettelsen av Overleaf-prosjektet ble i stor grad tilrettelagt av arbeidet til Patrick Gundlach, så vi takker ham [vår takk til ham](#credits-thanks-patrick).

## Hvorfor velge LuaTeX?

Først er det verdt å gjenta forskjellen mellom LuaTeX og LuaLaTeX:

* LuaTeX er navnet på en kjørbar, TeX-basert satsmotor;
* LuaLaTeX viser til bruken av LaTeX-makropakken med LuaTeX-motoren.

Denne forskjellen er ekstremt viktig fordi vi i denne artikkelen utnytter de innebygde egenskapene til selve LuaTeX-motoren, og ikke bare bruker funksjonene/virkemåten til kommandoer som tilbys av LaTeX-makropakken.

Lesere som er usikre på forskjellen mellom en TeX-motor og LaTeX-makropakken, kan ha nytte av å lese en av våre tidligere publiserte artikler, [Hva er i et navn: En guide til de mange TeX-variantene](/latex/no/dybdeartikler/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md)som forklarer disse forskjellene noe nærmere. Den samme artikkelen diskuterer også «TeX» som programmeringsspråk og at TeX-baserte satsmotorer (f.eks. pdfTeX, XeTeX og LuaTeX) ikke bare varierer i funksjoner og virkemåte, men også har variasjoner i «smaken» av TeX-språket de støtter. Dette bringer oss til vårt valg av LuaTeX. I tillegg til å støtte et TeX-basert programmeringsspråk, har LuaTeX også skriptspråket Lua innebygd—noe som gir tilgang til et enkelt, men svært kraftig, tradisjonelt programmeringsspråk. Gjennom Lua, og LuaTeXs innebygde funksjonalitet, kan du utforske og kontrollere satsaktivitetene til LuaTeX på måter ingen andre TeX-motorer tilbyr—og dette inkluderer muligheten til å undersøke de indre strukturene til TeX-bokser; derfor er LuaTeX det ideelle (og eneste) valget for denne artikkelen og det tilhørende Overleaf-prosjektet.

### pdfTeX/XeTeX mot LuaTeX: i bilder

Følgende *skjemaene* er ment å fremheve en viktig sammenligning mellom utformingen av pdfTeX/XeTeX og LuaTeX. Både pdfTeX og XeTeX lar selvfølgelig brukere skrive TeX-kode som kan påvirke satsoppførselen; men de dypere interne strukturene som finnes i disse TeX-motorene, og lavnivådata som konstrueres under satsprosessen, er stort sett utilgjengelige for brukerkommandoer og makroer. I den forstand er de *relativt* lukkede systemer sammenlignet med LuaTeX.

#### pdfTeX/XeTeX

![{{{alt}}}](/files/ce31863d4274dc543d1b783c3c6a27d35c504134)

#### LuaTeX

LuaTeX introduserer en ny primitiv kommando kalt `\directlua{...}` som du kan skrive kode gjennom, som ikke bare gir full tilgang til Lua-språket, men også lar deg utvide LuaTeXs muligheter ved å skrive plug-ins med språk som C og C++. På Windows kalles slike utvidelser *dynamiske koblingsbiblioteker* (.DLL); på Linux er de kjent som *delte objektbiblioteker* (.so). Men LuaTeXs virkelige kraft kommer fra et enormt sett innebygde Lua-funksjoner som gir tilgang til LuaTeXs indre—og muliggjør ekstremt sofistikert kontroll og programmering av TeX-basert sats. Et slikt funksjonssett kalles et API (Application Programming Interface), og det er gjennom LuaTeXs API at du bruker Lua-programmer til å kommunisere med dens TeX-baserte satsmotor og datastrukturer.

![{{{alt}}}](/files/e10d624cbffe4a776dc34a09da82a1b0bfa04569)

Med LuaTeXs `\directlua{...}` \directlua{}

## Bokser og lim: En kort påminnelse

Som introdusert i artikkelen [Bokser og lim: En kort, men visuell, introduksjon med LuaTeX](https://www.overleaf.com/blog/511-boxes-and-glue-a-brief-but-visual-introduction-using-luatex) bokser og lim er to nøkkelbegreper som underbygger TeXs satsmuligheter. Følgende diagram er ment som en svært kort huskelapp om oppførselen til TeXs horisontale og vertikale bokstyper. Merk: horisontale bokser kan selvfølgelig inneholde tekst satt i høyre-til-venstre-språk, som arabisk eller hebraisk, noe som betyr at retningen boksen vokser i kan være motsatt av det som vises for den horisontale boksen i diagrammet nedenfor.

![{{{alt}}}](/files/baa4749afb9504313fc0be98718e4185f054d3fb)

### TeX-primitiver for bokskonstruksjon

I dag forbereder de fleste TeX-dokumentene sine ved hjelp av LaTeX-makropakken, som er utformet for å tilby kommandoer som skjermer brukerne fra mye av TeXs lavnivåspråk—de såkalte *primitivene*—kjernekommandoene innebygd i TeX-motorer (se artikkelen [Hva er i et navn: En guide til de mange TeX-variantene](/latex/no/dybdeartikler/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) for en diskusjon av TeX-primitiver). LaTeX-makrosamlingen tilbyr en rekke makroer for å opprette og lagre bokser, men hvis du fjerner all makrokoden vil du oppdage at det bare finnes fire lavnivå primitive kommandoer for bokskonstruksjon:

For å opprette horisontale lister:

* \hbox{...}

For å opprette og stable vertikale lister:

* \vbox{...}
* \vtop{...}
* \vcenter{...}

Vi kommer ikke til å forklare hvordan man bruker alle disse bokskommandoene fordi det finnes mange eksempler og veiledninger andre steder på nettet eller i TeX-/LaTeX-bøker—men vi skal se nærmere på hvordan bokser representeres og lagres inne i TeX-datastrukturer.

### Lim: fleksibel avstand

Lim er i praksis en form for avstand som TeX bruker for å avstand/plassere elementer horisontalt eller vertikalt. Som TeX-brukere kan vi be TeX sette inn noe lim med fast størrelse, eller vi kan bruke lim som er fleksibelt—med så mye fleksibilitet som vi trenger, enten til å strekke seg eller krympe avhengig av kravene våre. En av TeXs kommandoer for å lage lim for horisontal avstand heter `\hskip` som har formen

`**\hskip** <naturlig bredde> **plus** <mengde å strekke> **minus** <mengde å krympe>`

`**plus**` og `**minus**` er TeX-nøkkelord, men du trenger ikke bruke dem for hvert lim. Hvis `**plus**` eller `**minus**` er utelatt, antas den tilsvarende `<mengde å strekke>` eller `<mengde å krympe>` å være null. For eksempel, `\hskip 3pt` setter inn et lim med fast bredde uten strekk- eller krympkomponent.

For øyeblikket kan du tenke på `<mengde å strekke>` og `<mengde å krympe>` som våre *anbefalinger* til TeX fordi den nøyaktige mengden strekk eller krymp vil bli beregnet av TeX.

Den `<naturlig bredde>` er lengden på fjæren når det ikke er noen spenning (strekk) eller kompresjon (krymping). Den `<mengde å strekke>` og `<mengde å krympe>` vises relativt til fjærens naturlige lengde.

![{{{alt}}}](/files/b69507eb00f752d19522545caccc8fdcfec919a8)

#### Et \hbox-eksempel

Anta at vi ønsker å lage en `\hbox{...}` som bare inneholder bokstavene A, B, C og D, og vi trenger at denne boksen skal være 100pt (100 TeX-punkter) bred. I tillegg kan vi trygt anta at den totale bredden til disse fire tegnene er langt mindre enn 100pt, noe som indikerer at TeX trenger en eller annen måte å fylle opp den gjenværende plassen inne i boksen: vi skal bruke litt lim til det. Men fordi vi ikke vet den nøyaktige mengden lim som kreves for å fylle boksen, er det lurt å legge til noe fleksibelt lim og la TeX ta seg av å beregne hvor mye plass disse limene må oppta. I følgende kodeutdrag, legg merke til bruken av «%» for å undertrykke mellomrom mellom ord som oppstår fra linjeslutttegnene.

```
\hbox to100pt{%
A\hskip4pt plus3pt minus 2pt B%
\hskip 0pt plus 2fil C%
\hskip 0pt plus 2fill D%
\hskip 0pt plus 3fill}
```

Den resulterende boksen ser slik ut (forstørret for klarhet):

![{{{alt}}}](/files/1e104fcdb5b626fbaf0777e128c233ef48f4fc17)

Denne `\hbox` er overlagt med stiplete bokser (i rødt) for å indikere bredden til tegnene (slik TeX ser dem). For satsformål betraktes tegn som små bokser, og mengden lim som kreves for å fylle denne `\hbox`bestemmes (beregnes) ved å ta hensyn til breddene til hvert tegn.

Det viser seg at TeX ikke strekte eller krympet limet mellom A og B (satt til 4pt), og det er ikke noe lim mellom B og C (satt til 0pt). Men limet mellom C og D og limet mellom D og slutten av boksen har begge strukket seg betydelig fordi disse limene har den mest fleksible strekkkomponenten—i praksis absorberte disse limene all strekkingen som var nødvendig for å fylle boksen.

## Tilbake til LuateX

Så langt har vi utforsket bokser og lim og sett at LuaTeX gir tilgang til interne TeX-strukturer som er skjult for innsyn i pdfTeX og XeTeX. Det er på tide med et eksempel for å gjøre dette mer konkret, men først må vi kort gjøre oss kjent med måten TeX lagrer bokser i minnet på—vi begynner med en analogi.

### Hvordan TeX lagrer bokser i minnet: en analogi

Anta at du av en eller annen grunn trengte å lage en datamodell som beskriver en fysisk boks. Hvilke data kunne du velge å bruke for en slik beskrivelse? En tilnærming du kunne bruke er å dele informasjonen i to deler: data om selve den fysiske boksen og data som gir en liste over boksens innhold. Så vår enkle modell kunne se slik ut:

1. Data om den fysiske boksen («metadata»):

* width
* høyde
* dybde
* vekt
* farge
* type (tre, plast, papp)

3. Data om boksens innhold: en eller annen form for liste som beskriver objektene den inneholder—sannsynligvis oppført i ingen bestemt rekkefølge.

Og det finnes en svært nær analogi med måten TeX lagrer bokser på.

### Hvordan TeX lagrer bokser i minnet: hlists og vlists

Internt oppretter TeX «beholdere» kalt *hlists* (horisontale lister) og *vlists* (vertikale lister) som representerer hboxes og vboxes henholdsvis. Disse hlist-/vlist-objektene gir en samling av «metadata» om boksen, og de gir også tilgang til listen over objekter som boksen faktisk inneholder—den listen kalles en *node-liste*. I motsetning til en fysisk boks, der du kan plassere objekter inni den i hvilken som helst rekkefølge, er rekkefølgen på boksens innhold ekstremt viktig i TeX—de er elementer som skal settes. Hvis du har noe programmerings- eller informatikkbakgrunn, vil du ikke bli overrasket over å høre at objektene i en TeX-boks lagres, og at rekkefølgen de ble opprettet i bevares, ved hjelp av en såkalt [dobbeltlenket liste](https://en.wikipedia.org/wiki/Doubly_linked_list). Vi kommer ikke til å diskutere lenkede lister i mer detalj fordi nettet bugner av veiledninger, eksempler og forklaringer.

Begrepet noder og node-lister er et grunnleggende aspekt ved hvordan TeX fungerer, men for denne artikkelens formål gir vi bare en kort oversikt. Noder er i bunn og grunn en slags «minibeholder», og (per LuaTeX 1.04) finnes det rundt 50 forskjellige nodetyper: som gjenspeiler de indre datatypene og komponentene som LuaTeX bruker til sats. For eksempel finnes det noder som representerer: glyfer (som stammer fra «tegn»), lim, horisontale/vertikale streker, straffer, «whatsits», kerns og så videre. Alt satt materiale vil til slutt bli en del av en enorm node-liste, og LuaTeX gir deg direkte tilgang til disse indre datastrukturene. LuaTeX lar deg også legge til, redigere, endre eller opprette node-lister slik at du for eksempel kan lage bokser direkte inne i Lua-kode uten å måtte bruke TeX-kode i det hele tatt. Men å skrive om det er for en annen dag.

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

Følgende eksempel lager en `\hbox` og lagrer den i boksregister 0. Deretter rapporterer vi boksens bredde ved hjelp av tradisjonell TeX-kode og får samme informasjon ved hjelp av en andre metode via `\directlua{}`. Her kjører vi et lite Lua-skript som får tilgang til TeXs interne bokslagringsområde for å hente boksens bredde—selvfølgelig er de to verdiene identiske: 2412092sp (sp=scaled point: 65536sp = 1 TeX-punkt). Til syvende og sist, i dette svært enkle eksempelet, undersøker både TeX-koden og Lua-koden de samme interne datastrukturene for å få boksens bredde, men det er gjennom den direkte tilgangsveien at LuaTeX åpner døren til et vell av informasjon og kontroll som ikke er tilgjengelig med andre motorer.

![{{{alt}}}](/files/0ff297f42c5c7054ca517f1ec33d25f8fe3027c2)

```latex
\documentclass{article}
\begin{document}
\setbox0=\hbox{A\hskip 5pt B\hskip 10pt C}
\fontsize{18}{22}\selectfont
\noindent Ved hjelp av \TeX{}-kode har boks 0 bredde \number\wd0\relax \space sp\par
\noindent Vi kan også bruke Lua og kalle en av Lua\TeXs funksjoner for å få den samme
informasjonen.\vskip10mm
\noindent Fra Lua-kode har boks 0 bredde
\directlua{
local boxwidth = tex.box[0].width
tex.print(boxwidth.." sp")
} som selvfølgelig er identisk med verdien oppnådd fra \TeX{}-kode.
\end{document}
```

## Alt samlet: Et Overleaf-prosjekt

Vi har bemerket at TeX internt representerer bokser som «beholdere» kalt hlists/vlists som lagrer «metadata» om boksen og gir tilgang til listen over komponenter som boksen er bygget opp av. Med LuaTeX kan du få tilgang til boksens «metadata» og listen over elementene som er inneholdt i en TeX-boks: glyfer, lim, straffer, andre bokser og så videre. Ved hjelp av Lua-skript er det mulig å undersøke en boks som ligger i TeXs minne og lage en detaljert representasjon av hva den boksen inneholder. En passende representasjon av en TeX-boks og innholdet dens oppnås ved hjelp av *nodegrafer* og vi har laget et [Overleaf-prosjekt](https://www.overleaf.com/latex/examples/exploring-the-structure-of-tex-boxes-with-luatex/pwdrypmtdbgs) som gjør det ved å utnytte et utmerket Lua-skript skrevet av Patrick Gundlach (se krediteringene). Vi kommer ikke til å beskrive de detaljerte prosessene som kreves for å undersøke bokser og generere nodegrafer—bortsett fra å merke at ethvert program-/skript som behandler TeX-bokser må være *rekursive* fordi bokser kan være nestet: dvs. du kan ha hboxes inni vboxes, inni hboxes… og kombinere alle boktypene til et svært dypt nivå av innkapsling.

![{{{alt}}}](/files/84590cfc5c2efa359a6c71d755ed941be251b311)

### Hva tilbyr prosjektet?

Det implementerer bare én kommando kalt `\dobox{bokskommando}`, for eksempel:

```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{...}` kommandoen utfører en rekke oppgaver:

1. inne i dokumentet setter den ordrett TeX-koden for boksen din;
2. den genererer en SVG-grafikk av TeX-boksen—du kan bygge den inn i en nettside (slik vi har gjort i dette blogginnlegget);
3. den genererer en SVG-grafikk av node-listen—som du også kan bygge inn i nettsider (slik vi har gjort i dette blogginnlegget);
4. den skriver ut en PDF-grafikk av node-listen, som deretter importeres i hoved-PDF-dokumentet som produseres av prosjektet.

Nodegrafer kan svært raskt bli ekstremt store på grunn av den enorme mengden data som LuaTeX må lagre for å representere komplekse TeX-bokser—slik som siden som for øyeblikket er under konstruksjon, eller satt matematikk. For større node-lister kan den importerte PDF-grafikken bli avkuttet av sidemargen i dokumentet ditt—hvis du vil se en stor nodegraf kan du laste ned en ZIP-fil av prosjektet og trekke ut den aktuelle PDF-grafikken. Når du laster ned prosjektets ZIP-fil, må du sørge for å velge «Input and Output Files» fra nedtrekkslisten:

![{{{alt}}}](/files/6111ce310483e5b317728df59de4e06bf1b396f4)

### Grafikk fra Overleaf-prosjektet: En kort beskrivelse

Før vi viser noen eksempler, er det verdt å gjøre noen observasjoner om grafikken som produseres av Overleaf-prosjektet—vi bruker det samme `\hbox` eksemplet som ble nevnt tidligere i artikkelen. Her er det pakket inn i prosjektets `\dobox{...}` kommandoen:

```latex
\dobox{\hbox to100pt{%
A\hskip4pt plus3pt minus 2pt
B\hskip 0pt plus 2fil
C\hskip 0pt plus 2fill
D\hskip 0pt plus 3fill}}
```

Her er `\hbox` som ble produsert av TeX—for klarhetens skyld er boksen skalert opp, men rammen er inkludert i grafikken produsert av Overleaf-prosjektet.

![{{{alt}}}](/files/b7845a52f6490b47ae1a800cbdbdcfc98a590df9)

Her er en *annotert* SVG-diagram av node-listen som representerer boksen ovenfor—annoteringer ble lagt til for å fremheve boksens «metadata» og listen over objekter den inneholder: disse annoteringene finnes ikke i grafikken produsert av Overleaf-prosjektet.

[![{{{alt}}}](/files/7ecdc91c5d10bf1a2614fd1b1d41f721a026943f)](https://www.filepicker.io/api/file/ZSwIylUR66eFYPMo0suX)

Hvis du ser på «metadata»-delen, kan du legge merke til noen ukjente parametere:

* `glue_set`
* `glue_sign`
* `glue_order`

Disse parameterne er innstillingene som brukes av TeX for å beregne hvor mye limet må strekkes eller krympes innenfor denne boksen, og er bare ett eksempel på data du enkelt kan få tak i via LuaTeX, men ikke med andre TeX-motorer. Legg merke til at limnoder som finnes i boksens komponenter *beholder* de opprinnelige limverdiene vi skrev inn da vi opprettet boksen. Dette er essensielt fordi TeX tilbyr kommandoene `\unhbox`, `\unvbox`, `\unhcopy`, `\unvcopy` som «unbokser» boksens innhold og slipper det tilbake inn i inndatastrømmen slik at det igjen kan delta i satsoperasjoner. Det er først når TeX til slutt sender boksen ut (ships out) til en PDF- eller DVI-fil at `glue_set`, `glue_sign` og `glue_order` anvendes på eventuelle lim i boksen—for å beregne den faktiske mengden strekk eller krymp som trengs for å plassere komponentene i boksen, og deretter generere passende PDF-data eller DVI-opkoder.

En annen parameter som er oppført i «metadata» er `shift`: dette er verdien for forskyvning av boksen som følge av å bruke TeX-kommandoene:

* `\raise`, `\lower` (brukt på en `\hbox`);
* `\moveleft`, `\moveright` (brukt på en `\vbox`).

I vårt eksempel er `shift` 0pt fordi vi ikke forskjøv `\hbox` fra sin naturlige posisjon.

Den [Overleaf-prosjekt](https://www.overleaf.com/latex/examples/exploring-the-structure-of-tex-boxes-with-luatex/pwdrypmtdbgs) utskriver også nodegraf-diagrammer i PDF-format: her er en lenke for å laste ned en [PDF-filversjon](https://www.filepicker.io/api/file/bezigXESC2FSasvjoh8A) av nodegrafen ovenfor.

### Hvordan lager Overleaf-prosjektet disse grafikkene?

Overleaf-prosjektet utnytter muligheten til å kjøre programvareverktøy og verktøy installert på Overleafs servere—se [dette blogginnlegget](/latex/no/dybdeartikler/52-using-luatex-to-run-tools-and-utilities-installed-on-overleaf-s-servers.md) for flere detaljer og et eksempelprosjekt. For å produsere en SVG-grafikk som representerer en TeX-boks, skrives boksens TeX-kode ut til en liten fil som deretter settes med pdfTeX for å generere en DVI-fil—merk at pdfTeX-programmet kjøres av LuaTeX gjennom bruk av noen få linjer Lua-skript. Den DVI-filen konverteres i sanntid til SVG ved hjelp av `dvisvgm` verktøyet—som leveres med TeX Live-distribusjonen installert på Overleafs servere. `dvisvgm` kjøres med kommandolinjevalg `-n` for å sikre at all satt tekst konverteres til linjer/kurver slik at korrekt gjengivelse av SVG-filen ikke avhenger av at TeX-fonter er installert.

For å lage nodegrafene bruker vi et Lua-skript kalt `hiviznodelist.lua` som er basert på arbeidet til Patrick Gundlach. Det skriptet skriver ut en såkalt `.gv` (Graphviz)-fil som er en tekstfil som inneholder en nodegraf beskrevet i `dot` -språket.  `.gv` Filen `dot` behandles av et hjelpeprogram kalt

### som skriver ut et nodediagram i både PDF- og SVG-filformater.

Her er noen flere eksempler med SVG-grafikk produsert ved hjelp av Overleaf-prosjektet. Bokser som inneholder mye tekst (f.eks. i en \vbox), eller kompleks matematikk, vil produsere enorme nodegrafer—hvis du utforsker Overleaf-prosjektet, er det lurt å ikke bruke unødvendig komplekse bokser for å demonstrere funksjonene du er interessert i.

#### \vbox to 25pt{A}

Dette eksemplet demonstrerer effekten av å plassere tekst direkte inn i en `\vbox`: merk at nodestrukturen er ganske kompleks, selv for en så enkel boks. Grunnen til denne kompleksiteten er at tekst plassert direkte i en `\vbox` fører til at TeX utfører linjebryting. Du kan se at `\vbox` er 345pt bred: verdien av `\hsize` på det tidspunktet denne boksen ble opprettet. Legg også merke til at tegnet «A» er inneholdt i en `hlist` som også er 345 punkter bred, og legg merke til den store straffen (10000) sammen med `\parfillskip` og `\rightskip` lim ved slutten av boksinnholdet. Denne straffen og de to lim-elementene settes inn av TeXs linjebrytingsaktivitet. Hvis du ser på `glue_set` verdien for avsnittslinjen (`hlist`) som inneholder bokstaven «A», vil du se at den er ekstremt stor (322.500000): hvorfor er det slik? Det er fordi avsnittslinjen er 345pt bred, men bare inneholder en `\parindent` og bokstaven «A»: den gjenværende plassen må fylles av `\parfillskip` limet, som må strekke seg et betydelig stykke for å fylle den gjenværende plassen på linjen.

![{{{alt}}}](/files/414b5d2f0d00657d7dea96bbe2162cc4bee4d8de)

[![{{{alt}}}](/files/005213754a6e5b2d14c4be17d51033fd70075331)](https://www.filepicker.io/api/file/pVtHsNGSQ4m09vBZuOpQ)

[Last ned PDF-fil](https://www.filepicker.io/api/file/nBS0uDs2QjqKCKljAm7r)

#### \vbox to 25pt{\hbox{A}}

Det er svært opplysende å sammenligne dette eksemplet med det forrige. Her er ikke bare nodegrafen betydelig mindre, men bredden på `\vbox` er bare 7.50002pt: samme bredde som tegnet «A». Grunnen er at «A» er pakket inn i en `\hbox` som hindrer `\vbox` i å få TeX til å utføre linjebryting—en viktig egenskap ved bokser opprettet med `\vbox`.

![{{{alt}}}](/files/13765b8b62a663ee1497370cf53a06043ed886a5)

[![{{{alt}}}](/files/17f8ad4a55165fbc57f256174ade11a20fcb576e)](https://www.filepicker.io/api/file/LHepknjnRGOVEdghW4qH)

[Last ned PDF-fil](https://www.filepicker.io/api/file/Yk3uCCQR5ao8Yd3TJCdE)

#### Enkel matematikk: \hbox{$$\displaystyle \int f(x) dx$$}, kompleks boks!

Dette eksemplet viser at selv svært enkel satt matematikk skaper en detaljert bokstruktur: sats av matematikk produserer *ekstremt* komplekse datastrukturer i TeX!

![{{{alt}}}](/files/bf97cb9b779c7c85e0ea65de3e915628058daefb)

[![{{{alt}}}](/files/779c8d5730ebc8be5c65a34711835e94e0e364a9)](https://www.filepicker.io/api/file/oVFNNvCqT0eZP0qS2odk)

[Last ned PDF-fil](https://www.filepicker.io/api/file/D5TepsdaSdeYZvkuSEJt)

## Kreditering: takk Patrick!

Vår takk til [Patrick Gundlach](https://twitter.com/patrickgundlach) som har gitt Overleaf tillatelse til å bruke og distribuere en modifisert versjon av hans Lua-skript, `viznodelist.lua`, som behandler TeX-bokser og skriver ut en fil (i `dot` -språket) som kan behandles for å tegne en nodegraf. Overleaf-prosjektet inneholder et Lua-skript kalt `hiviznodelist.lua`—en omdøpt og modifisert versjon av Patricks opprinnelige kode, som er tilgjengelig på [Github](http://gist.github.com/556247). Patrick har laget et åpen kildekode-basert satsystem for LuaTeX kalt [speedata Publisher](https://speedata.github.io/publisher/index.html) som du kan laste ned og bruke gratis—kommersielle støttealternativer er også tilgjengelige.


---

# 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/36-pandora-s-hbox-using-luatex-to-lift-the-lid-of-tex-boxes.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.