> 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/meer-onderwerpen/18-how-overleaf-created-the-tex-primitive-reference-data.md). # Hoe Overleaf de referentiegegevens voor TeX-primitieven heeft gemaakt Dit artikel beschrijft de methoden en technieken die zijn gebruikt om de twee kruisverwijzingstabellen van TeX-primitieve commando's te maken: * [TeX-primitieven vermeld per TeX-engine](/latex/nl/meer-onderwerpen/46-tex-primitives-listed-by-tex-engine.md) en; * [TeX-primitieven vermeld per CJK-TeX-engine](/latex/nl/meer-onderwerpen/45-tex-primitives-listed-by-cjk-tex-engine.md). Deze informatie is bedoeld voor lezers die geïnteresseerd zijn in de fijne details, maar is geen voorwaarde om de kruisverwijzingstabel zelf te gebruiken. Om aan de behoeften van verschillende lezers tegemoet te komen, bieden we een zeer korte samenvattende versie samen met een uitgebreidere uitleg voor wie de zaken in meer diepte wil verkennen. ## Korte samenvattende/overzichtsversie Om de kruisverwijzingstabel te bouwen, heeft Overleaf de broncode van 9 TeX-engines verwerkt om de lijst met primitieve commando's van elk daarvan te extraheren: dat proces leverde 9 tekstbestanden op (1 bestand per TeX-engine). Die 9 sets primitieven werden gecombineerd om een 'masterlijst' te maken, die in feite een unie was van de afzonderlijke sets primitieven: in totaal ongeveer 1000 unieke primitieven verspreid over de verschillende engines. Voor elke engine werd de eigen lijst met primitieve commando's gekruist met het masterbestand (de set van alle commando's) om te bepalen welke van die \~1000 commando's werden ondersteund: die vergelijkingen zijn weergegeven in de volgende twee tabellen: * [Kruisverwijzingsgegevens van TeX-primitieven](/latex/nl/meer-onderwerpen/46-tex-primitives-listed-by-tex-engine.md) * [Kruisverwijzingsgegevens van TeX-primitieven (voor CJK-engines)](/latex/nl/meer-onderwerpen/45-tex-primitives-listed-by-cjk-tex-engine.md) ## 'Software bouwen' 101: wat betekent dat? In de rest van dit artikel verwijzen we naar het concept 'TeX-engines bouwen', wat misschien een onbekend begrip is als u geen programmeur bent, of niet programmeert in gecompileerde talen zoals C of C++. Voor ons doel is software bouwen—dat wil zeggen TeX-engines—het proces van het maken van een uitvoerbaar TeX-programma uit de bestanddelen ervan: de broncodebestanden geschreven in de programmeertaal die gebruikt wordt om het programma te ontwikkelen. ## Volledige versie: wilt u de details weten? Lees verder... Elke op TeX gebaseerde zetengine ondersteunt een 'dialect' van de TeX-taal: een bepaalde set primitieve commando's die de zetfunctionaliteit van elke engine aanstuurt en de bouwstenen levert voor het maken/definiëren van macro's: door de gebruiker gedefinieerde reeksen commando's. Elke macro, of die nu geschreven is voor LaTeX, plain TeX of een ander macro-pakket, is uiteindelijk opgebouwd uit primitieve commando's—hoewel u wellicht behoorlijk diep moet graven, door lagen van extra macro's heen, voordat u de 'moederlaag' van TeX-primitieven bereikt. De set van 9 TeX-engines die zijn geanalyseerd om de referentiegegevens voor primitieve commando's te produceren, hebben natuurlijk veel commando's gemeen, maar elke TeX-engine heeft ook zijn eigen primitieve commando's, toegevoegd door de ontwikkelaars, om ondersteuning te bieden voor de functies die specifiek zijn voor die 'versie' van TeX. De primitieve commando's van een TeX-engine zijn ingebouwd in de uitvoerbare TeX-software: primitieven zijn geen macro's die door gebruikers worden opgebouwd, maar fundamentele, ondeelbare/atomische instructies die worden gebruikt om het zetgedrag van elke engine aan te sturen. Daarom is de meest betrouwbare manier om een definitieve lijst te maken van primitieve commando's die door een TeX-engine worden ondersteund, het bestuderen van de werkelijke broncode waaruit de uitvoerbare TeX-programma's worden gebouwd (gecompileerd) en het extraheren van de lijst met primitieven die in de broncode zijn gedefinieerd. Klinkt alsof dat eenvoudig zou moeten zijn, toch? Door de 40-jarige ontwikkelingsgeschiedenis van TeX is het echter niet bijzonder eenvoudig om de broncodebestanden van TeX-engines (behalve LuaTeX) te verkennen/bestuderen. De reden voor die complexiteit ligt in de hulpmiddelen, de programmeertaal (Pascal) en de methode (literair programmeren) die Knuth gebruikte om de oorspronkelijke TeX-broncode te schrijven—waarvan alle andere engines uiteindelijk zijn afgeleid. We merken een uitzondering op voor LuaTeX omdat de kerncode van die engine opnieuw is geschreven in C om het gebruik van Pascal en andere hieronder beschreven erfgoedcomplexiteiten (Web2C) te verwijderen; daardoor is, hoewel de broncode van LuaTeX omvangrijk is, de manier waarop deze wordt 'verpakt' en verspreid veel begrijpelijker in vergelijking met andere TeX-engines. Als gevolg daarvan, en op basis van de werkstroom/processen die worden gebruikt om ze uit broncode te bouwen, is het handig om TeX-engines in twee categorieën in te delen: 1. LuaTeX: aangepast (moderner) bouwproces 2. Alle andere engines: erfelijk (Web2C) bouwproces ## De context van erfgoedcode: waarom het bouwen van (de meeste) TeX-engines complex is Zoals we hieronder zullen verkennen, bracht Knuth zijn oorspronkelijke TeX-broncode uit als één enkel, monolithisch bestand genaamd `tex.web` dat Knuth nog steeds eens in de 7 jaar bijwerkt om resterende bugs te verhelpen—er worden nooit nieuwe functies toegevoegd; het is puur een bugfix-oefening. De bestandsextensie van TeX's broncode (`.web`) is waarschijnlijk niet bekend en u vraagt zich misschien af welke taal Knuth gebruikte om TeX te schrijven? Het antwoord is Pascal, maar de `.web` extensie heeft wat meer uitleg nodig. Knuth ontwikkelde een programmeermethode die hij noemde [literair programmeren](https://en.wikipedia.org/wiki/Literate_programming) waarbij de broncode en documentatie van een programma samen worden gecombineerd en als één samengesteld bestand (code plus documentatie) met extensie `.web`: dat bestandstype wordt een WEB-bestand genoemd. We leggen WEB-bestanden hieronder wat gedetailleerder uit. ### Nieuwe TeX-engines maken: Knuths voorwaarden Hoewel Knuth zijn TeX-broncode (`tex.web`) al lang gratis beschikbaar stelt aan iedereen, stelde hij, zoals zijn volste recht, een belangrijke voorwaarde: zijn (`tex.web`) broncode mag niet rechtstreeks worden bewerkt/aangepast en opnieuw worden verspreid met de programmanaam 'TeX'. In de broncode schrijft hij: ``` % Dit programma is auteursrechtelijk beschermd (C) 1982 door D. E. Knuth; alle rechten voorbehouden. % Kopiëren van dit bestand is alleen geautoriseerd als (1) u D. E. Knuth bent, of als % (2) u absoluut geen wijzigingen aanbrengt in uw kopie. (Het WEB-systeem biedt % mogelijkheden voor aanpassingen via een aanvullend bestand; het masterbestand moet intact blijven.) ``` en ook: ``` Als dit programma wordt gewijzigd, mag het resulterende systeem niet worden genoemd `\TeX'; de officiële naam `\TeX' op zichzelf is gereserveerd voor softwaresystemen die volledig compatibel zijn met elkaar. Er is een speciale testsuite genaamd de ``\.{TRIP} test'' beschikbaar om te helpen bepalen of een bepaalde implementatie het verdient om `\TeX' genoemd te worden [vgl.~Stanford Computer Science report CS1027, november 1984]. ``` In wezen: breng geen wijzigingen aan door aangepaste versies van de master-TeX-broncode te bewerken en te verspreiden en blijf het `tex.web`. Als u wel wijzigingen wilt aanbrengen, bijvoorbeeld nieuwe primitieven toevoegen enz., dan moet u die wijzigingen doorvoeren via 'aanpassingen via een aanvullend bestand' en uw 'afgeleide van TeX'-programma een naam geven die het onderscheidt van 'TeX', dat, in zetvorm ($$\mathrm\TeX$$), een handelsmerk is van de American Mathematical Society. ### De overerving van erfgoed Hoewel er pogingen zijn gedaan om TeX volledig opnieuw te schrijven met moderne programmeertalen en methodologieën—zoals de twee op Java gebaseerde initiatieven [New Typesetting System](https://en.wikipedia.org/wiki/New_Typesetting_System) en [εχTEX](http://www.extex.org/) en andere zoals [een in Clojure](https://www.infoq.com/news/2015/01/implementing-tex-in-clojure)—is geen daarvan volledig succesvol geweest. De geschiedenis van projecten en initiatieven die bedoeld zijn om TeX verder te ontwikkelen is een interessant onderwerp en lezers willen misschien [de UK TeX FAQ bezoeken](https://texfaq.org/FAQ-enginedev) voor meer informatie. Die niet-LuaTeX-initiatieven die ook succesvol zijn geweest, zoals e-TeX, pdfTeX, XeTeX en andere engines, zijn *rechtstreeks bovenop* de oorspronkelijke code van Knuth gebouwd: ze nemen zijn broncode en 'passen wijzigingen toe' om een nieuwe engine met extra mogelijkheden af te leiden—zoals het toevoegen van nieuwe primitieven, het produceren van PDF-uitvoer, ondersteuning voor UTF-8-tekstinvoer enzovoort. Hoewel die aanpak tot opmerkelijke successen heeft geleid, betekent het ook dat die afgeleide engines de erfgoedcode en ontwikkeltechnieken erven die Knuth 40 jaar geleden creëerde. De belangrijkste conclusie hier is dat, afgezien van LuaTeX, de meeste TeX-engines die zijn afgeleid van Knuths oorspronkelijke broncode worden gemaakt door één enkel monolithisch bestand te nemen (meestal `tex.web`) en wijzigingen toe te passen die opnieuw een ander enkel monolithisch bestand genereren dat de kernbroncode van die nieuwe engine bevat. Gevorderde lezers willen misschien vooruit springen naar de toelichtende [notities over pdfTeX en XeTeX](#aside-xetex-and-pdftex). ### Enige aanvullende TeX-geschiedenis/achtergrond TeX's scheppingsmoment was [in Knuths dagboek vastgelegd als 30 maart 1977](/latex/nl/diepgaande-artikelen/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md#the-genesis-of-tex-a-brief-history), inmiddels meer dan 40 jaar geleden. Intern is TeX een buitengewoon complex programma waarvan Knuth veel moeite deed om de broncode [uitzonderlijk gedetailleerd te documenteren](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373). Om dat te doen ontwikkelde Knuth een programmeerstijl die hij noemde [literair programmeren](https://en.wikipedia.org/wiki/Literate_programming) waarbij de broncode en documentatie van een programma samen worden gecombineerd en als een samengesteld bestand worden uitgebracht met extensie `.web` (ook wel een WEB-bestand genoemd). Knuth koos Pascal als programmeertaal voor het schrijven van zijn TeX-software en gebruikte, niet verrassend, de TeX-zettaal om de uiteindelijke documentatie te schrijven. Bijgevolg wordt de masterbroncode van Knuths TeX gepubliceerd als één enkel, monolithisch bestand genaamd `tex.web`: een mengeling van Pascal-broncode en TeX-zetcode voor de documentatie. Als een programma is geschreven met behulp van Knuths literair-programmeringsstijl/methodologie (zoals TeX, MetaFont, BibTeX en anderen), moet u het WEB-bestand voorbewerken om de documentatie of broncode te extraheren. Om toegang te krijgen tot de documentatie van het programma verwerkt u het WEB-bestand (bijv., `tex.web`) met een hulpprogramma genaamd [WEAVE](http://tug.org/texinfohtml/web2c.html#weave-invocation) dat de documentatie produceert als een `.tex` bestand dat u kunt zetten. Om de broncode in Pascal te extraheren gebruikt u een ander hulpprogramma genaamd [TANGLE](http://tug.org/texinfohtml/web2c.html#tangle-invocation) dat een bestand met extensie `.p` uitvoert dat Pascal-broncode bevat. Op het moment van schrijven (begin 2019) is de nieuwste versie van Knuths TeX 3.14159265, gedateerd januari 2014. Nogmaals, let op dat Knuths TeX-broncode slechts in één enkel bestand zit met ongeveer 25.000 regels TeX/Pascal-code! ### Van Pascal naar C In de meer dan 40 jaar die zijn verstreken sinds het ontstaan van TeX, raakte Pascal uit de mode en tegenwoordig overwegen weinig, zo niet geen?, mensen nog om TeX te bouwen vanuit de oorspronkelijke Pascal-broncode. Om Knuths gebruik van Pascal te omzeilen, werd een werkstroom ontworpen genaamd [Web2C](http://tug.org/texinfohtml/web2c.html) waarin TeX's Pascal-broncode mechanisch (d.w\.z. via software) wordt omgezet naar het equivalent in C-code, die vervolgens wordt gebruikt om TeX te compileren en het uitvoerbare programma te bouwen. Het werkt goed, maar het enige nadeel is dat de mechanisch gegenereerde C-broncode niet bedoeld is voor vluchtige menselijke inspectie: het is *extreem* uitvoerig en bijna ondoordringbaar, bedoeld voor compilers en niet voor mensen—hier is een schermafbeelding die een klein fragment toont van de C-code die is gegenereerd uit TeX's Pascal-broncode: ![](/files/ba785f808ba4d8d163ef64cfbd3bb21ac5ffa84c) ### Nog een Knuthisme: WEB-wijzigingsbestanden Zoals hierboven opgemerkt, bouwt u op Knuths oorspronkelijke broncode voort door 'wijzigingen toe te passen' of, in Knuths woorden, 'aanpassingen via een aanvullend bestand' te maken: maar wat betekent dat eigenlijk? Maak kennis met het *wijzigingsbestandmechanisme*. ### Wijzigingsbestanden: het mechanisme voor het maken van nieuwe TeX-engines Ontwikkelaars die Knuths TeX op de een of andere manier willen uitbreiden, dat wil zeggen voortbouwen op Knuths oorspronkelijke werk, willen doorgaans een geheel nieuwe 'versie' van TeX maken of een *uitbreiding* leveren die aan elke TeX-engine kan worden toegevoegd. Voorbeelden van uitbreidingen zijn [SyncTeX](https://github.com/jlaurens/synctex) en [EncTeX](https://ctan.org/pkg/enctex?lang=en)—SyncTeX is bijvoorbeeld een zeer nuttige uitbreiding die nu in alle TeX-engines is opgenomen. De behoefte aan EncTeX is grotendeels ingehaald door de evolutie van Unicode-bewuste TeX-engines—maar let op dat EncTeX ingebouwd is in pdfTeX. Of de wens nu is om een nieuwe 'versie' van TeX te maken (d.w\.z. een afgeleide van Knuths oorspronkelijke TeX), of om een uitbreiding te maken, hun ontwikkelaars beginnen met Knuths oorspronkelijke broncode en passen de noodzakelijke wijzigingen toe om een nieuwe TeX-engine (of een uitbreidingsmodule) te creëren. Zoals hierboven opgemerkt, moet iedereen die het gedrag van TeX wil wijzigen dat doen met 'aanpassingen via een aanvullend bestand', omdat die wijzigingen/modificaties niet mogen worden toegepast door *rechtstreeks* Knuths oorspronkelijke broncode te bewerken: ontwikkelaars zijn verplicht de zogeheten WEB *wijzigingsbestandmechanisme*. De code om Knuths TeX te wijzigen wordt geschreven in de WEB-'taal' en opgeslagen in een of meer codebestanden (genaamd *wijzigingsbestanden*) die vervolgens worden *samengevoegd* met Knuths oorspronkelijke, onaangetaste, masterbroncode. Dat samenvoegingsproces creëert een nieuw samengesteld WEB-bestand dat nu de *kern* broncode van de nieuwe/gemodificeerde op TeX gebaseerde software bevat. *Wijzigingsbestanden* hebben vaak extensie `.ch` maar in de praktijk kunnen ze elke door de ontwikkelaars gewenste extensie hebben. #### Hoe gebruikt/past u wijzigingsbestanden toe? Tegenwoordig is de eenvoudigste manier om wijzigingsbestanden toe te passen en een 'master' WEB-bestand te wijzigen met een hulpprogramma genaamd [TIE](https://ctan.org/pkg/tie). Stel bijvoorbeeld dat u Knuths TeX wilt aanpassen door bijvoorbeeld een paar nieuwe primitieven toe te voegen of dat u het gedrag van een bestaande (standaard) TeX-primitief wilt wijzigen. U zou uw code (in Pascal!) schrijven met behulp van het WEB-systeem van literair programmeren en die opslaan in een bestand genaamd, zeg, `myprim.ch`. De volgende stap is om uw code (in `myprim.ch`) samen te voegen met Knuths masterbronbestand `tex.web` en een nieuw, samengesteld, WEB-bestand te produceren dat wat wij zullen noemen `mytex.web`. Om dit te doen voert u simpelweg het TIE-programma als volgt uit: ``` tie -m mytex.web tex.web myprim.ch ``` Als de samenvoeging succesvol is, resulteert dit in een nieuw WEB-bestand, `mytex.web`waarbij Knuths masterbronbestand `tex.web` volledig onveranderd blijft, zoals vereist. Laten we nu aannemen dat iemand anders de door u aangebrachte wijzigingen waardeert en uw werk wil aanpassen om zijn/haar wijzigingen bovenop, of naast, wat u hebt gedaan toe te voegen. In plaats van uw aangepaste versie van TeX (`mytex.web`) te verspreiden besluit u alleen het wijzigingsbestand te publiceren/delen, `myprim.ch`. Iedereen die op uw werk wil voortbouwen kan nu zijn/haar wijzigingsbestand maken en delen, genaamd bijvoorbeeld `moreprim.ch` dat uw code op een of andere manier uitbreidt. Iedereen die vervolgens gebruik wil maken van beide wijzigingsbestanden kan een nieuw samengesteld WEB-bestand genereren door *beide* wijzigingsbestanden in Knuths oorspronkelijke bestand samen te voegen om weer een ander TeX-programma te genereren, genaamd bijvoorbeeld `newmytex.web`: ``` tie -m newmytex.web tex.web myprim.ch moreprim.ch ``` ### Echte TeX-systemen: meerdere wijzigingsbestanden De bovenstaande beschrijving van TIE komt eigenlijk heel dicht in de buurt van de manier waarop veel TeX-engines in de praktijk worden gebouwd: ze beginnen met Knuths `tex.web` en voegen een reeks wijzigingsbestanden toe om het WEB-bronbestand voor die engine te genereren. Elke TeX-engine vereist zijn eigen specifieke set wijzigingsbestanden, die in een strikte volgorde moeten worden toegepast/verwerkt (samengevoegd): als u de volgorde verkeerd hebt, mislukt het samenvoegingsproces omdat elk wijzigingsbestand in een reeks afhankelijk is van wijzigingen die zijn geïntroduceerd door wijzigingsbestanden die eerder in de keten voorkomen. Hier is een voorbeeld van een TIE-uitvoering die meerdere wijzigingsbestanden toepast op Knuths `tex.web` om `ktex.web`te genereren—het samengestelde WEB-bestand met wijzigingen aan Knuths TeX dat het gereed (geschikt) maakt voor omzetting naar C via het Web2C-proces. Let ook op het volgende: * `tex.ch` is een zeer groot wijzigingsbestand dat onder meer TeX aanpast om Kpathsea te gebruiken; * de SyncTeX-uitbreiding wordt toegevoegd via meerdere wijzigingsbestanden. ``` tie -m ktex.web tex.web tex.ch enctex.ch synctex-def.ch0 synctex-mem.ch0 synctex-mem.ch2 synctex-rec.ch0 synctex-rec.ch1 synctex-rec.ch2 tex-binpool.ch Dit is TIE, CWEB versie 2.4. Auteursrecht (c) 1989,1992 door THD/ITI. Alle rechten voorbehouden. (tex.web) (tex.ch) (enctex.ch) (synctex-def.ch0) (synctex-mem.ch0) (synctex-mem.ch2) (synctex-rec.ch0) (synctex-rec.ch1) (synctex-rec.ch2) (tex-binpool.ch) ....500....1000....1500....2000....2500....3000....3500....4000....4500 ....5000....5500....6000....6500....7000....7500....8000....8500....9000 ....9500....10000....10500....11000....11500....12000....12500....13000 ....13500....14000....14500....15000....15500....16000....16500....17000 ....17500....18000....18500....19000....19500....20000....20500....21000 ....21500....22000....22500....23000....23500....24000....24500.... (Er zijn geen fouten gevonden.) ``` #### Terzijde: XeTeX en pdfTeX Voor de volledigheid moeten we opmerken dat het bouwproces voor pdfTeX en XeTeX niet daadwerkelijk begint met Knuths `tex.web`; in plaats daarvan beginnen ze met bestanden genaamd `pdftex.web` en `xetex.web` respectievelijk: vermoedelijk omdat de wijzigingen zo omvangrijk zijn dat het logischer is om WEB-bestanden te delen/publiceren die al de zeer significante aanpassingen bevatten die aan Knuths oorspronkelijke code zijn aangebracht. ### Een voorbeeld: e-upTeX De Japanse TeX-gemeenschap heeft een aantal TeX-engines ontwikkeld die ontworpen zijn om aan de complexiteit van het zetten van Japanse tekst tegemoet te komen: * **pTeX**: Knuths TeX-engine uitgebreid om Japans zetten te ondersteunen; * **e-pTeX**: Een combinatie van e-TeX en pTeX (plus een paar primitieve commando's geïntroduceerd door pdfTeX); * **upTeX**: Een Unicode-bewuste versie van pTeX plus uitbreidingen voor betere verwerking van CJK (Chinees, Japans en Koreaans); * **e-upTeX**: Een combinatie (samensmelting) van e-TeX en upTeX. #### Het samengestelde bronbestand voor e-upTeX genereren Om het samengestelde WEB-bronbestand voor e-upTeX te maken (met SyncTeX) begint u met Knuths `tex.web` maar moet u **26** afzonderlijke wijzigingsbestanden in de volgende volgorde toepassen om één samengesteld bestand te krijgen waaruit de lijst van primitieve commando's kan worden geëxtraheerd: ``` etex.ch, tex.ch0, tex.ch, tex.ech, etex.ch0, ptex-base.ch, uptex-m.ch, euptex.ch0, eptex.ech, etex.ch1, euptex.ch1, synctex-def.ch0, synctex-ep-mem.ch0, synctex-mem.ch0, synctex-e-mem.ch0, synctex-ep-mem.ch1, synctex-p-rec.ch0, synctex-rec.ch0, synctex-rec.ch1, synctex-e-rec.ch0, synctex-p-rec.ch1, fam256.ch, pdfstrcmp-eup-pre.ch, pdfutils.ch, pdfstrcmp-eup-post.ch, tex-binpool.ch ``` #### Wijzigingsbestanden toepassen: welke bestanden en in welke volgorde? Zoals opgemerkt is het uiterst belangrijk om wijzigingsbestanden in een strikte volgorde toe te passen/verwerken—maar hoe komt u erachter welke bestanden nodig zijn en in welke volgorde ze moeten worden verwerkt? Gelukkig is die cruciale informatie vastgelegd in bestanden die zich in de TeX Live-distributie bevinden, en een verkenning van de broncode van TeX Live onthulde de regels die de bouwvereisten voor elke TeX-engine bepalen. Door die regels te volgen kon Overleaf het samengestelde WEB-broncodebestand voor elke TeX-engine reconstrueren en een lijst van primitieve commando's extraheren voor verdere gegevensverwerking. ## En ten slotte: hoe extraheren we de lijst met primitieve commando's? Zodra het samengestelde WEB-bestand is opgebouwd, is de taak om de lijst met primitieve commando's te extraheren, met behulp van reguliere expressies, eenvoudig omdat alle primitieve commando's worden gedefinieerd ('geregistreerd') met behulp van één enkele Pascal-functie genaamd `primitive(...)`. Hier zijn enkele echte voorbeelden uit Knuths `tex.web` broncode: ``` primitive("lineskip",assign_glue,glue_base+line_skip_code) primitive("baselineskip",assign_glue,glue_base+baseline_skip_code) primitive("parskip",assign_glue,glue_base+par_skip_code) primitive("abovedisplayskip",assign_glue,glue_base+above_display_skip_code) primitive("belowdisplayskip",assign_glue,glue_base+below_display_skip_code) primitive("abovedisplayshortskip",assign_glue,glue_base+above_display_short_skip_code) ... ... ``` Zoals u kunt zien, is de `primitive(...)` functie zeer geschikt voor tekstverwerking met reguliere expressies: de naam van het primitieve commando dat wordt geregistreerd staat tussen aanhalingstekens (`"..."`) samen met aanvullende gegevens die het gedrag van elk primitief commando classificeren (daar gaan we hier niet in detail op in). Nadat de lijst met primitieve commando's voor elke engine was geëxtraheerd, werden die gegevens door enkele Lua-scripts verwerkt om HTML te genereren met de getabelleerde resultaten. ### Terug naar LuaTeX We hebben opgemerkt dat LuaTeX niet precies hetzelfde bouwproces gebruikt als de andere 8 TeX-engines. Nadat we kort het Web2C-proces, de omzetting van Pascal naar C en het mechanisme van wijzigingsbestanden hebben verkend, kunnen we nu uitleggen waarin LuaTeX verschilt: de ontwikkelaars van LuaTeX besloten af te zien van het omslachtige proces van het omzetten van Pascal naar C—zoals opgemerkt in [De LuaTeX-Referentiehandleiding](http://www.pragma-ade.com/general/manuals/luatex): > ...het compilatiekader is web2c en we blijven dat gebruiken, maar zonder de stap van Pascal naar C. De kern van de LuaTeX-engine is herschreven in C, wat betekent dat het bouwproces enigszins standaarder en zeker veel handiger is. Een nuttig gevolg is dat de primitieven die door LuaTeX worden ondersteund netjes zijn ondergebracht in een afzonderlijk C-broncodebestand, wat de taak om ze te benaderen/op te sommen aanzienlijk vergemakkelijkte. Strikt genomen moeten we ook opmerken dat sommige broncodebestanden van LuaTeX een variant van Knuths literair-programmeringsmethode gebruiken, genaamd [CWEB](https://en.wikipedia.org/wiki/CWEB), die gebaseerd is op C en niet op Pascal. ### Niet alleen WEB-bestanden: andere broncode is vereist Nadat voor een TeX-engine (behalve LuaTeX) het samengestelde WEB-bronbestand is gegenereerd, moet de Pascal-broncode worden geëxtraheerd en omgezet naar C-code, maar dat is niet de totale oplossing. Naast de C-code die uit de WEB-broncode (Pascal⮕C) wordt gegenereerd, vertrouwen de meeste TeX-engines ook op (vereisen ze) een aantal extra hulpbroncodebestanden (bibliotheken) die doorgaans in C zijn geschreven—zoals [Kpathsea](https://www.tug.org/kpathsea/). Hulpbronbestanden (bibliotheken) implementeren functionaliteit die niet in WEB (Pascal) hoeft te worden geschreven, of niet geschreven kan worden. Alles wat in de WEB-'taal' voor TeX wordt geschreven, moet de Pascal-taal gebruiken, die vervolgens wordt geëxtraheerd en omgezet naar machinaal gegenereerde C: als u dat niet hoeft te doen, waarom zou u het dan niet gewoon in de eerste plaats in C of C++ schrijven. --- # 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/meer-onderwerpen/18-how-overleaf-created-the-tex-primitive-reference-data.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.