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

# En introduktion till LuaTeX (Del 1): Vad är det — och vad gör det så annorlunda?

LuaTeX är en *verktygssats*—det innehåller sofistikerade programvaruverktyg och komponenter med vilka du kan konstruera (sätta) ett brett spektrum av dokument. Undertiteln till denna artikel ställer också två frågor om LuaTeX: Vad är det — och vad gör det så annorlunda? Svaret på ”Vad är det?” kan verka självklart: ”Det är en TeX-sättningsmotor!” Det är det verkligen, men en bredare syn, och en som denna författare ansluter sig till, är att LuaTeX är ett extremt mångsidigt TeX-baserat *system för dokumentkonstruktion och ingenjörskonst*.

### Förklara LuaTeX: Var ska man börja?

Målet med denna första artikel om LuaTeX är att erbjuda ett sammanhang för att förstå vad denna TeX-motor tillhandahåller och varför/hur dess design gör det möjligt för användare att bygga/designa/skapa ett brett spektrum av lösningar på komplexa sättnings- och designproblem — kanske också erbjuda en viss grad av ”framtidssäkring” i takt med att användare i allt högre grad behöver TeX-baserad programvara som kan anpassa sig till det ständigt föränderliga tekniska ekosystemet. Enligt denna författare är det inte nödvändigtvis den bästa platsen att börja på när man utvecklar en förståelse för LuaTeX:s kapacitet och potential att lista och beskriva dess funktioner/möjligheter. En sådan metod är inte särskilt hjälpsam för läsare som inte är bekanta med andra TeX-motorer och för vilka funktionsbaserade jämförelser sannolikt inte är särskilt meningsfulla.

Med risken att utmatta läsarens tålamod (”Kom bara till saken!”) kommer jag att använda en mer ”holistisk” ansats, förhoppningsvis ge användbar bakgrund, men till priset av lite extra läsning — och att gå in på några programmeringsämnen för att underlätta förståelsen. I [Del 2](/latex/sv/fordjupade-artiklar/09-an-introduction-to-luatex-part-2-understanding-directlua.md) utforskar vi användningen av `\\directlua` men för nu försöker vi lägga grunden för att förstå LuaTeX.

Denna artikel speglar starkt författarens personliga ”resa” i att utveckla en förståelse för och uppskattning av LuaTeX: att först veta något om filosofin bakom LuaTeX:s utveckling, och att se det som en behållare av mjukvaruverktyg, gör att du bättre kan uppskatta de omfattande lösningsdomäner som öppnas av denna fantastiska programvara.

## LuaTeX: Inte bara för akademin eller matematiken!

Mängden funktioner och funktionalitet inbyggd i LuaTeX ger inte bara exceptionellt högkvalitativ sättning via traditionell LaTeX, utan erbjuder också enorma möjligheter att utveckla skräddarsydda, icke-LaTeX-baserade lösningar på komplexa problem med dokumentproduktion och ingenjörskonst. LuaTeX har det kraftfulla skriptspråket Lua inbäddat i sig, vilket till exempel innebär att du kan använda Lua för att ladda in ”plugins” (externa programvarubibliotek) i LuaTeX; detta möjliggör ytterligare hög grad av automatisering, integration i befintliga programvarusystem eller arbetsflöden och utnyttjande av specialiserad programvara för behandling av data, text eller grafik.

Historiskt sett har TeX förknippats med vetenskapligt författarskap/publicering, särskilt inom matematiken, men LuaTeX, i synnerhet, har betydande potential för tillämpning inom många andra områden — inklusive kommersiell PDF-dokumentproduktion. Ett sådant exempel är [speedata publisher](https://speedata.github.io/publisher/) som använder LuaTeX enbart som PDF-genereringsmotorn inom sitt XML-baserade arbetsflöde — det använder inte LaTeX alls. Faktum är att speedata publisher nästan inte innehåller någon TeX-kod — jag frågade [Patrick Gundlach](https://twitter.com/patrickgundlach), speedata publishers utvecklare, som bekräftade att den totalt sett använder omkring tre rader TeX-kod. Dess kraftfulla sättningskapacitet är utformad och implementerad i Lua-kod, med hjälp av LuaTeX:s Lua-API (ett ämne vi diskuterar senare i denna artikel).

## En kort personlig berättelse: Hur jag först upptäckte LuaTeX

Jag fick först reda på LuaTeX i slutet av 2009/början av 2010, när det fortfarande var i mitten av betafasen (version 0.50). Vid den tiden letade jag efter TeX-baserad programvara för att sätta de handskrivna anteckningar som blev resultatet av mina ansträngningar att lära mig lite arabiska. Google-sökningar avslöjade en samling videor från TUG-konferensen 2009 ([nu på YouTube](https://www.youtube.com/playlist?list=PL2D4DD50DC9C0BA0E)) som inkluderade demonstrationer av arabisksättning av mycket hög kvalitet (via Hans Hagens [ConTeXt-paket](http://wiki.contextgarden.net/Main_Page)). Dessa videor innehåller också ett föredrag med titeln [LuaTeX-projektet: halvvägs till version 1](https://youtu.be/AKv4po9PGW0).

TeX-motorn som användes för att producera den utsökta arabiska sättningen var något som kallades ”LuaTeX”. Vid den tiden arbetade jag inom vetenskaplig (fysik-)publicering men även om jag var fullt medveten om TeX/LaTeX hade jag inte hört talas om LuaTeX: jag blev nyfiken och ville lära mig mer om denna nya TeX-motor. Eftersom LuaTeX fortfarande var i beta-utvecklingsstadiet, och utvecklades snabbt, ville jag hålla mig uppdaterad med de allra senaste nyheterna så det bästa alternativet (för mig) var att själv bygga (kompilera) LuaTeX-exekverbart program från dess källkod. Förutom det körbara LuaTeX-programmet behöver du också en ”TeX-installation” för att tillhandahålla miljön där LuaTeX kan köras (t.ex. texmf.cnf, makropaket, typsnitt osv.). I stället för att ladda ner och installera den enorma [TeX Live](https://www.tug.org/texlive/) distributionen valde jag att skapa en helt minimal anpassad TeX-installation med vilken jag kunde utforska LuaTeX (en ”intressant” övning som jag [dokumenterade på min personliga blogg](http://www.readytext.co.uk/?cat=30)). Varje ny utgåva av LuaTeX åtföljs av sin referensmanual (t.ex. för[version 1.0.4](https://www.tug.org/svn/texlive/tags/texlive-2017.1/Master/texmf-dist/doc/luatex/base/luatex.pdf?revision=44591\&view=co)) som dokumenterar programvarans senaste funktioner och funktionalitet. Det är emellertid en *referens* manual och (nödvändigtvis) ganska sparsam med förklaringar som passar nybörjaren som vill komma igång med denna otroliga TeX-motor — en viss bekantskap med lågnivåkoncept i TeX förutsätts. Eftersom jag hade upptäckt LuaTeX i ett relativt tidigt skede av dess utveckling var bra introduktionsmaterial vid den tiden relativt svårt att hitta, så det krävdes lite utforskning, experimenterande (och en del frustration…) innan bitarna började falla på plats. Det behöver knappast sägas att mina arabiskastudier kom till ett abrupt slut när jag blev fascinerad av denna fantastiska programvara och så småningom gick över till att skriva LuaTeX [plugins för arabisksättning](http://www.readytext.co.uk/?p=3143) i stället!

Min egen ”LuaTeX-resa” var verkligen mycket icke-linjär, men längs vägen gav den en möjlighet att lära sig om (Lua)TeX (och TeX-installationer) ”från grunden”: min blogg rymmer en eklektisk samling av [artiklarna](http://www.readytext.co.uk/?cat=3) inlägg baserade på olika ämnen som jag utforskade och arbetade med under den tiden. Förhoppningsvis använder denna artikel den tiden och erfarenheten på ett lämpligt sätt och hjälper andra att bli intresserade av att börja utforska LuaTeX:s kapacitet. LuaTeX fortsätter att utvecklas och, vid tidpunkten för skrivandet, har det nått version 1.0.4 som släpptes med TeX Live 2017. Utvecklarna är mycket aktiva och eventuella buggar som upptäcks åtgärdas vanligtvis kort efter att de rapporterats — t.ex. via [dev-luatex-mejllistan](https://mailman.ntg.nl/mailman/listinfo/dev-luatex) eller via [den webbaserade LuaTeX-buggspåraren](http://tracker.luatex.org/my_view_page.php). Långt innan det nådde version 1.0 var LuaTeX produktionsdugligt — även om du förstås behövde acceptera att funktioner ständigt utvecklades och att ändringar ibland kunde bryta din befintliga TeX-kod. I dag stöds LuaTeX naturligtvis av plattformarna Overleaf och ShareLaTeX (som LuaLaTeX).

## TeX i en föränderlig värld: Ny teknik och nya arbetsflöden

Det är uppenbart att TeX-motorer inte verkar i en tekniskt statisk värld och ibland uppstår innovationer som omedelbara och självklara kandidater för att införas i TeX-motorer — en sådan innovation är variabla OpenType-typsnitt, som vi kort diskuterar nedan. Även om det råder liten tvekan om att TeX-baserad sättningsprogramvara är oerhört mångsidig, verkar TeX-motorer nu inom ett snabbt föränderligt och mycket mångsidigt mjukvaruekosystem — nya arbetsflöden accentuerar behovet av integration och flexibilitet för att implementera ett brett spektrum av lösningar för dokument/sättning, där TeX bara kan vara en komponent.

TeX måste inte bara förbli relevant för sina nuvarande användare utan också locka nya genom att möjliggöra lösningar för innehållsskapande som förblir användbara för kommande generationer — människor som kanske inte nödvändigtvis vill använda TeX som ett fristående verktyg utan kanske som en del av ett övergripande arbetsflöde via online-samarbetsplattformar som Overleaf.

Även en snabb blick på [tex.stackexchange](https://tex.stackexchange.com/) visar den enorma variationen av dokument och lösningar som produceras och implementeras med TeX-baserad programvara — ofta med otrolig uppfinningsrikedom när människor hittar allt fler användningsfall och innehållstyper som de vill generera. Dessutom har behovet av arbetsflöden som kan bearbeta TeX-baserad markup/innehåll för att producera utdata som inte är PDF (och inte DVI) aldrig varit större — såsom MathML/XML och HTML. Till exempel att ”konvertera” TeX till [JATS XML](https://jats.nlm.nih.gov/) formatet (länge använt inom publicering av vetenskapliga tidskrifter) men också, på senare tid, framväxten av epub som används inom publicering av e-böcker.

### Variabel fontteknik — tiderna förändras

Den 14 september 2016 meddelade 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/) och Apple en ny typsnittsteknik: [variabla OpenType-typsnitt](https://medium.com/@tiro/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369). Vi kommer inte att utforska denna teknik i detalj, men det räcker att säga att högt respekterade typsnittsexperter som [Thomas Phinney](https://twitter.com/ThomasPhinney) och [John Hudson](https://twitter.com/TiroTypeworks) har konstaterat ([på Twitter](https://twitter.com/ThomasPhinney/status/917087509342851072)) att variabel fontteknik införs mycket snabbare än många tidigare typsnittsinnovationer — sannolikt drivet av behoven hos webbdesigners som kräver responsiva designer som anpassar sig till de otaliga olika skärmstorlekar/upplösningar som finns på mobila enheter.

Det är tydligt att variabla OpenType-typsnitt är en intressant och spännande utveckling inom typsnittsteknik, något som TeX-användare utan tvekan skulle kunna dra nytta av — i själva verket har denna fråga oundvikligen [tagits upp på tex.stackexchange](https://tex.stackexchange.com/questions/355104/tex-luatex-xetex-fontspec-support-for-opentype-variable-fonts) med LuaTeX:s stöd diskuterat i LuaTeX [mejllista](https://www.tug.org/pipermail/luatex/2016-September/006204.html).

För övrigt är det värt att notera att typsnittsteknik som bygger på ”parametrisk” typsnittsskapande inte är en helt ny idé: Knuths METAFONT och Adobes Multiple Master-tekniker är på sätt och vis tidiga föregångare, även om implementeringsdetaljerna är ganska annorlunda.

### Variabla typsnitt: När vill vi ha dem — nu?

Varje ny och användbar teknisk standard/specifikation behöver tid för att ”sätta sig” i sitt målekosystem av utvecklare och implementatörer — inklusive tid att reda ut eventuella oklarheter eller tolkningar av formuleringar i själva specifikationen. Utvecklare måste läsa och förstå dokumentationen och förvandla den till verklig fungerande programvara — vilket här inkluderar att skapa typsnitten och teknikerna för att använda dem: kompatibla webbläsare och sättningsmotorer. TeX-utvecklare kommer uppenbarligen att behöva tillgång till högkvalitativa variabla typsnitt som kan användas som tillförlitliga ”referenser” för att implementera (programmera) stöd för variabel typsnittsteknik.

Att implementera en ny teknik inom TeX, såsom variabla typsnitt, väcker *den potentiella* behovet av att ändra TeX-motorernas inre delar — naturligtvis beror behovet av att göra det på teknikens art och, avgörande nog, vilken aspekt av TeX:s beteende som ska ändras. Det är inte alltid nödvändigt att ändra själva TeX-motorerna, kanske krävs bara ändringar i stödjande/biträdande programvara, inklusive eventuella ”komponenter” (kodbibliotek från tredje part) som används i dessa program. Internt är TeX-motorer *fruktansvärt* komplexa — att utveckla en förståelse för TeX:s källkod som är tillräcklig för att göra tillförlitliga ändringar kräver betydande och mycket specialiserad expertis (av vilken det finns ett mycket begränsat utbud). Det är också viktigt att eventuella ändringar inte negativt påverkar den långsiktiga stabiliteten/kompatibiliteten hos TeX-motorer — vilket är avgörande för TeX-gemenskapen och för dem som därefter bearbetar en författares (La)TeX-fil(er): framför allt akademiska förlag och molnbaserade tjänster som Overleaf och ShareLaTeX.

Många TeX-användare är sannolikt intresserade av att utnyttja variabla typsnitt; till exempel för att implementera nya designmöjligheter eller hitta lösningar på knepiga sättningsproblem. Så i viss mening finns det ett dilemma: TeX-användare som vill ha tillgång till en ny teknik men dess implementering beror på en mycket begränsad resurs: antalet utvecklare som är kvalificerade och kapabla att få det att hända. Att modifiera TeX:s inre delar är svårt, och bör i allmänhet undvikas där det är möjligt, så finns det ett annat sätt att närma sig att lägga till (vissa klasser av) nya funktioner/möjligheter till TeX? Ja! och LuaTeX har tagit den vägen.

#### Tidiga experiment: variabla OpenType-typsnitt och LuaTeX

LuaTeX:s design har möjliggjort snabba experiment med variabel typsnittsteknik. Redan i april 2017 hade ConTeXt-TeX-formatet, som använder LuaTeX, en [betaversion](https://mailman.ntg.nl/pipermail/ntg-context/2017/088343.html) som implementerade variabla OpenType-typsnitt. Detta var möjligt eftersom ConTeXts typsnittsstöd är byggt i Lua-kod (och ConTeXt har sin egen fontladdare skriven i Lua).

## LuaTeX: Bakgrund och historia

LuaTeX är, i TeX-termer, ”den nya killen i kvarteret” trots att det har varit under aktiv utveckling i över 10 år. LuaTeX:s webbplats [dokumenterar](http://www.luatex.org/roadmap.html) att LuaTeX började sin tillvaro 2005 med (tror jag) aktiv och ihållande utveckling som började 2006. På grund av dess inneboende komplexitet, och omsorgen hos dem som byggde det, tog det verkligen 10 års utveckling innan LuaTeX nådde version 1.0, vilken [meddelades av dess utvecklare](https://mailman.ntg.nl/pipermail/dev-luatex/2016-September/005882.html) (Hans Hagen, Hartmut Henkel, Taco Hoekwater, Luigi Scarso) den 27 september 2016.

I det utgivningsmeddelandet finns ett viktigt principuttalande:

> ”Vårt huvudmål är att tillhandahålla en variant av TeX som tillåter användartillägg utan behov av att anpassa det inre arbetet.”

Denna formulering sammanfattar perfekt filosofin bakom LuaTeX:s utveckling och pekar på en väg genom vilken TeX-baserad programvara kan möta de utmaningar vi redan har nämnt: att anta ny teknik och förbli relevant för nya generationer av användare.

Det är nu dags att ta itu med den andra frågan i denna artikels undertitel: ”vad gör det så annorlunda”. Genom att utforska betydelsen av ”...tillåter användartillägg utan behov av att anpassa det inre arbetet” kan vi bättre förstå kärnan i vad LuaTeX ”bidrar med”.

## LuaTeX: Att öppna TeX:s ”svarta låda”

Knuths ursprungliga TeX-program är den gemensamma förfadern till alla moderna TeX-motorer som används i dag och LuaTeX är i praktiken det senaste evolutionära steget: det härstammar från pdfTeX-programmet men med tillägget av några kraftfulla programvarukomponenter som ger en hel del extra funktionalitet. När Knuth skrev den ursprungliga versionen av TeX-programvaran tillhandahöll han också TeX-språket som ett sätt att styra och programmera dess sättningsbeteende: omkring 320 lågnivåkommandon (primitiver) gjordes tillgängliga för användare och utvecklare av TeX-makropaket. Dessa kommandon erbjöd varierande grad av kontroll eller inflytande över vissa aspekter av TeX:s sättningsbeteende, men mycket av TeX:s interna funktionalitet, algoritmer, beslutsprocesser, data och datastrukturer var dolda för användaren. Man skulle kunna hävda att Knuths TeX-program inte var en helt ”svart låda” men visst en mycket mörk nyans av grått — visserligen gjordes källkoden tillgänglig, men för de allra flesta människor är även det en svart låda av obegriplighet.

Vi brukar beskriva de interna processerna inom TeX som något av en ”svart låda”; LuaTeX öppnar dock upp sina TeX-baserade internals för att ge användare/utvecklare mycket större tillgång till, och kontroll över, många av de tidigare dolda processer som äger rum djupt inne i TeX-motorn. LuaTeX lägger också till många nya primitiva kommandon som ger kontroll över de nya funktionerna.

### LuaTeX: Härledd från pdfTeX men använder inte pdfTeX:s kod

För att vara korrekt är det viktigt att notera att även om vi beskrev LuaTeX som härlett från pdfTeX, använder LuaTeX inte direkt pdfTeX:s ursprungliga programkod. En av LuaTeX:s utvecklare (Taco Hoekwater) utförde den verkligen *herkuliska* uppgiften att skriva om LuaTeX:s kärn-TeX-motor i ren, modern C-kod (CWEB).

#### Historisk notering

Delvis på grund av åldern på Knuths ursprungliga TeX-källkod — från vilken dess moderna efterföljare härstammar — är det en komplex och snårig process att modifiera den för att anpassa eller skapa nya TeX-baserade sättningsmotorer. En del av den processen kräver konvertering av Pascal-kod till C-kod — vilket inte är utan en [viss grad av komplexitet](http://www.readytext.co.uk/?p=2529). Den resulterande maskinskapade C-koden är oerhört omständlig och mycket svår att läsa eller förstå. Det är tydligt att en fullständig omskrivning av LuaTeX:s kod kringgår hela Pascal-till-C-konverteringsprocessen.

## LuaTeX:s byggstenar

I inledningen hänvisade vi till LuaTeX som en ”verktygssats” och beskrev det som ett ”system för dokumentkonstruktion och ingenjörskonst”. Vi har sett att i LuaTeX 1.0-meddelandet angav dess utvecklare:

> ”Vårt huvudmål är att tillhandahålla en variant av TeX som tillåter användartillägg utan behov av att anpassa det inre arbetet.”

Det är nu dags att samla ihop dessa trådar och idéer och fokusera på detaljerna i vad allt detta *egentligen betyder* i praktiken.

### LuaTeX-pusslet

Om du tittade ”under huven” skulle du se att LuaTeX-programvaran, dvs. det faktiska körbara programmet, är uppbyggd av en samling programvarukomponenter som kombineras för att ge LuaTeX:s övergripande funktionalitet. Naturligtvis är detta inget nytt och det mesta mjukvaran är uppbyggd på det sättet. Men det som gör LuaTeX annorlunda än andra TeX-motorer är att dessa komponenter kombineras på ett sådant sätt att användarna får mycket större tillgång till många aspekter av TeX:s interna funktionalitet: TeX:s sättningsalgoritmer, beslutsprocesser, data och datastrukturer. Denna öppning av TeX:s internals gör det möjligt för användare att konstruera nya sättningslösningar utan behov av att ändra själva TeX-motorn.

### Lua i LuaTeX: En nyckel till ”svarta lådan”

Lua är ett mycket kraftfullt, men ändå lättlärt, skriptspråk som [har sitt ursprung i Brasilien](https://www.lua.org/about.html)—det skapades 1993 och utvecklas fortfarande aktivt. En av Luanas styrkor är dess användning som programmeringsspråk för att ”limma ihop” skilda programvarukomponenter, så att du kan använda dem genom ett enkelt men mångsidigt skriptspråk. Lua spelar en central roll i att öppna upp de inre mekanismerna i LuaTeX:s TeX-motor, men för att bättre förstå hur detta åstadkoms är det värt att göra en liten avstickare för att mycket kort diskutera två programmeringsbegrepp:

* Application Programming Interface (API);
* bindning mellan programmeringsspråk.

Hoppa gärna över det här avsnittet om du känner dig bekväm med dessa begrepp. Inget av ämnena kommer att behandlas i detalj — vi siktar inte på strikt teknisk stringens utan snarare på att ge precis tillräcklig bakgrund för att bli medveten om dessa begrepp: deras betydelse och relevans för LuaTeX.

### Application Programming Interface (API)

Föreställ dig att du är en programmerare som har skrivit lite kod som användare (andra programmerare) kanske finner användbar, men din kod är komplex och du vill inte att användarna av din kod ska behöva oroa sig för dessa lågnivådetaljer. Observera att dessa programmerare/utvecklare arbetar med samma programmeringsspråk som du använde för att skriva din kod. Anta vidare att du har planer på att skriva om vissa delar av din kod — t.ex. för att göra den snabbare, kräva mindre minne och så vidare. Befintliga användare av din kod ska inte behöva oroa sig för det: alla ändringar du planerar att göra ska inte bryta deras program. Så vad är lösningen?

Svaret ligger i något som kallas ett API: ett *Application Programming Interface*. I stället för att kräva att användarna (andra programmerare) får tillgång till de lågnivådetaljer i din kod som kan komma att ändras, tillhandahåller du en specifik uppsättning *funktioner* som andra programmerare kan använda. Dessa funktioner är ett *gränssnitt* till din kod, genom vilket andra utvecklare kan bygga *applikationer* utan att behöva intim kännedom om din programs inre funktioner. På vissa sätt kan du tänka på detta som ett extra lager som omger din kod och ”isolerar” användare från de röriga lågnivådetaljerna.

Så länge du inte ändrar dessa funktioner (gränssnittet) är du fri att modifiera och uppdatera de lägre nivåernas detaljer i din programvara utan att påverka (förstöra) arbetet för dem som förlitar sig på din kod för att bygga sina applikationer: därav termen Application Programming Interface.

#### API:er: En analogi med ett LaTeX-paket

När du använder kommandon som tillhandahålls av ett LaTeX-paket kan du tänka på paketets kommandon som en form av API. Som användare är du inte nödvändigtvis bekymrad över den TeX- och LaTeX-magi som ligger bakom dessa kommandon (dvs. i paketets kod): allt du vill är att använda den funktionalitet de tillhandahåller.

### Bindning mellan programmeringsspråk

Vi har sett att programmerare som skriver/publicerar en mängd användbar kod (kallad en *bibliotek*) kan tillhandahålla ett så kallat Application Programming Interface (en uppsättning funktioner) genom vilket andra programmerare, som använder samma *samma* programmeringsspråk, kan ta del av det biblioteket (kodsamlingen). Detta är bra när båda sidor (biblioteksutvecklaren och dess användare) använder samma *samma* programmeringsspråk, men vad händer om programmerare som använder ett *annat* programmeringsspråk också vill använda det biblioteket? Du kanske till exempel skriver skript med Lua-språket men vill använda ett bibliotek skrivet i till exempel programmeringsspråk som C/C++. På något sätt behöver de två olika programmeringsspråken (Lua och C/C++) kunna ”kommunicera” med varandra. En lösning på detta problem är så kallad [språkbinding](https://en.wikipedia.org/wiki/Language_binding).

Att gå igenom de tekniska detaljerna kring språkbinding ligger utanför ramen för denna artikel så vi ger en kortfattad sammanfattning av de allmänna principerna. I huvudsak kan man, genom att lägga till ett lämpligt extra ”lager” kod till det ursprungliga biblioteket, få det att ”kommunicera” med ett annat programmeringsspråk (såsom Lua): det kodlagret kallas en *bindning*. Det gör att de två språken kan samverka via ett API genom vilket programmerare i det andra språket (såsom Lua) kan använda för att komma åt de funktioner/tjänster som biblioteket tillhandahåller.

![Schematiskt diagram som visar konceptet med en språkbinding.](/files/4bf5cb7c5f5f864dfc866515d6ea6c618ef4325e)

**Figur 1**: Schematiskt diagram som visar konceptet med en språkbinding: att göra det möjligt för ett program skrivet i Lua att använda ett externt bibliotek skrivet i ett annat programmeringsspråk. Det är genom användningen av Lua-bindningar som de interna komponenterna i LuaTeX, och därmed mycket av LuaTeX:s interna sättningsfunktionalitet, görs tillgängliga för användare för att utveckla lösningar på komplexa sättningsproblem.

## LuaTeX: Två alternativ för programmering — TeX och Lua

I grund och botten är LuaTeX en TeX-motor som stöder två programmeringsspråk: det traditionella TeX-baserade språket och skriptspråket Lua. Naturligtvis kan du använda båda språken i samma TeX-dokument eller, om du föredrar det, fortsätta att sätta via enbart TeX-vägen: till exempel via makropaketet LaTeX (LuaLaTeX). TeX (eller LaTeX) är inte ett lätt programmeringsspråk att använda eller lära sig, och relativt få människor har verkligen bemästrat TeX:s många egenheter — TeX:s begrepp om [tokens](https://www.overleaf.com/blog/522-what-is-a-tex-token) och expansion är ganska främmande för de flesta människors förväntningar och erfarenheter av ett programmeringsspråk.

Tillägget av Lua öppnar upp möjligheten att använda TeX-baserad sättning via ett mycket mer tillgängligt och konventionellt programmeringsspråk — som nämnts nära början av denna artikel kan du, genom att använda Lua-API:t, utföra [sofistikerad sättning med praktiskt taget ingen TeX-kod](http://wiki.luatex.org/index.php/TeX_without_TeX).

### LuaTeX lägger till många nya primitiver

Varje TeX-motor tillhandahåller hundratals så kallade primitiva kommandon: de grundläggande byggstenarna i det TeX-baserade språket som stöds av varje enskild sättningsmotor. Den ursprungliga versionen av TeX som släpptes av Donald Knuth gav ungefär 320 kommandon, men nyare TeX-motorer (pdfTeX, XeTeX och LuaTeX) har var och en lagt till många nya primitiver för att ge användare tillgång till varje motors ytterligare funktioner och funktionalitet. LuaTeX:s betydande antal nya primitiver dokumenteras i dess [Referensmanual](https://www.tug.org/svn/texlive/tags/texlive-2017.1/Master/texmf-dist/doc/luatex/base/luatex.pdf?revision=44591\&view=co).

Bland de många nya primitiver som introducerats av LuaTeX finns en som kallas `\directlua{...}` vilken är porten till att använda Lua-kod: att komma åt LuaTeX-motorns internals för att bygga sofistikerade verktyg och lösningar för sättning.

### \directlua{...}: Porten till Lua-programmering

Som diskuterats kan Lua-skriptspråket ses som ett ”lager” genom vilket det är möjligt att få tillgång till LuaTeX:s TeX-baserade sättningsmotor och den funktionalitet som tillhandahålls av många av de komponenter av vilka LuaTeX är uppbyggt. Lua-språket är också den mekanism som möjliggör LuaTeX:s utbyggbarhet — genom Luanas förmåga att ladda specialiserade externa bibliotek av programvara/kod.

Sammantaget kallas det Lua-gränssnitt (uppsättning av Lua-baserade funktioner) som tillhandahålls av LuaTeX för dess *Lua-API*: det är ”kommunikationslänken” mellan LuaTeX:s interna motor/komponenter och användarens dokument.

### Ett enkelt exempel på \directlua{...}

Följande *extremt enkelt* exempel börjar inte ens skrapa på ytan av toppen av isberget av möjligheter. Det tjänar dock till att demonstrera grundidén med samspelet mellan ”TeX-sättet” och ”Lua-sättet” att komma åt TeX:s parametrar.

Observera att:

* `\hsize` är en TeX-primitiv (kommando) som sätter värdet på en intern parameter som bestämmer bredden på satta rader — du ställer till exempel vanligtvis in den till ett lämpligt värde inom en `\vbox{...}`. `\hsize` är bara en av *många* TeX-parametrar som du kan komma åt och/eller ändra med Lua-kod.
* Att komma åt TeX-parametrar är bara en *liten* aspekt av LuaTeX:s Lua-API: det finns så mycket mer!

```latex

\documentclass{article}
\begin{document}
\let\\\relax %omdefiniera betydelsen av \\ för att undvika expansionsproblem
Här är det aktuella värdet för {\ttfamily\string\hsize} (via \LaTeX):
\the\hsize\par
\directlua{
%Hämta det aktuella värdet för \hsize med Lua-API:t
local hs=tex.hsize
% Använd en funktion i Lua-API:t för att skriva ut lite
% LaTeX-kod och värdet på \hsize
tex.print("Här är värdet av {\\ttfamily\\string\\hsize}
rapporterat från Lua-koden (i skalade punkter): ")
tex.print(hs.."\\par")
% Ställ in ett nytt värde för \hsize med Lua-API:t
tex.hsize="400pt" % eller använd tex.hsize=400*65536 (i skalade punkter)
}%
% När \directlua har avslutats, be LaTeX
% att tala om för oss det nya värdet på \hsize
Här är värdet av {\ttfamily\string\hsize} som rapporterats
av \LaTeX{} efter att {\tt\string\directlua} har avslutats:
\the\hsize\par
\end{document}
```

Här är en bild som visar resultatet av LuaTeX:s sättning av LaTeX-koden (ovan):

![Resultat av att köra LuaTeX](/files/46301ad34178b5aec682fa29cba4998d9c820ec1)

Observera att TeX-”tricket” med `\let\\\relax` är att undvika problem som orsakas av LuaTeX:s ”expansion” av Lua-koden: ett ämne vi kort nämner nedan.

### Att använda Lua-kod

Det finns två huvudsakliga alternativ för att använda Lua-kod i dina TeX/LaTeX-dokument:

1. **Inbäddad**: Att skriva Lua-kod direkt i ditt `.tex` dokument (som i exemplet ovan);
2. **Extern**: Att lagra Lua-kod i externa `.lua` kodfiler och använda Luanas funktioner för att ladda och köra dem.

Alternativ (1) passar bäst för kortare fragment av Lua-kod. Alternativ (2) används för större program eller bibliotek av Lua-kod. Det har en tydlig fördel genom att du kan undvika knepiga problem som involverar TeX:s så kallade `\\catcode` värden (vilket kan vara ”ganska frustrerande”). Orsaken till dessa `\\catcode` problem är ”expansionen” av Lua-kod innan den matas in i LuaTeX:s inbyggda Lua-tolk. Denna expansion kan vara knepig att förstå, så vi kommer att utforska den vidare i en senare artikel.

Självklart finns det LaTeX-paket som hjälper till med att använda Lua-kod i dina .tex-filer — du kan till exempel använda [luacode-paketet](https://ctan.org/pkg/luacode?lang=en).

## Sammanfattning och introduktion till del 2 av denna artikel

Mjukvarukomponenterna som LuaTeX är uppbyggt av, tillsammans med det inbäddade skriptspråket Lua, utgör en kraftfull kombination för att bygga lösningar som kan lösa ett brett spektrum av komplexa sättningsproblem — och konstruera arbetsflöden för dokumentproduktion som kan dra nytta av en nära integration med en TeX-baserad sättningsmotor. I [Del 2 av denna artikel](/latex/sv/fordjupade-artiklar/09-an-introduction-to-luatex-part-2-understanding-directlua.md) vi gör en ingående genomgång av det mest kraftfulla kommandot som tillhandahålls av LuaTeX: `\\directlua`.

Tills dess, ha så kul med LuaTeX!

## Tack

Författaren är mycket tacksam mot [Luigi Scarso](https://twitter.com/luigi_scarso), en av LuaTeX:s utvecklare, för att ha tagit sig tid att läsa ett utkast till denna artikel och för att ha lämnat ett antal mycket användbara kommentarer och förslag. Eventuella kvarvarande sakfel eller utelämnanden är, naturligtvis, författarens. Dessutom vill jag tacka [Patrick Gundlach](https://twitter.com/patrickgundlach), utvecklaren av [speedata publisher](https://speedata.github.io/publisher/), för att han tog sig tid att besvara mina frågor.


---

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