> 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/de/weitere-themen/18-how-overleaf-created-the-tex-primitive-reference-data.md). # Wie Overleaf die Referenzdaten für TeX-Primitiven erstellt hat Dieser Artikel beschreibt die Methoden und Techniken, die verwendet wurden, um die beiden Kreuzreferenztabellen der TeX-Primitive zu erstellen: * [TeX-Primitive, aufgelistet nach TeX-Engine](/latex/de/weitere-themen/46-tex-primitives-listed-by-tex-engine.md) und; * [TeX-Primitive, aufgelistet nach CJK-TeX-Engine](/latex/de/weitere-themen/45-tex-primitives-listed-by-cjk-tex-engine.md). Diese Informationen sind für Leser gedacht, die an den feineren Details interessiert sind, sind aber keine Voraussetzung, um die Kreuzreferenztabelle selbst zu verwenden. Um den Bedürfnissen unterschiedlicher Leser gerecht zu werden, bieten wir eine sehr kurze Zusammenfassung sowie eine längere Erläuterung für diejenigen, die die Themen genauer erkunden möchten. ## Kurzfassung/Übersichtsversion Um die Kreuzreferenztabelle zu erstellen, verarbeitete Overleaf den Quellcode von 9 TeX-Engines, um die Liste der von jeder einzelnen unterstützten Primitive zu extrahieren: Dieser Prozess erzeugte 9 Textdateien (1 Datei pro TeX-Engine). Diese 9 Mengen von Primitiven wurden kombiniert, um eine „Masterliste“ zu erstellen, die im Wesentlichen die Vereinigung der einzelnen Mengen von Primitiven war: Das ergab insgesamt etwa 1000 eindeutige Primitive, verteilt über die verschiedenen Engines. Für jede Engine wurde ihre eigene Liste von Primitiven mit der Masterdatei (der Menge aller Befehle) kreuzreferenziert, um zu bestimmen, welche dieser \~1000 Befehle sie unterstützte: Diese Vergleiche sind in den folgenden zwei Tabellen aufgeführt: * [Kreuzreferenzdaten der TeX-Primitive](/latex/de/weitere-themen/46-tex-primitives-listed-by-tex-engine.md) * [Kreuzreferenzdaten der TeX-Primitive (für CJK-Engines)](/latex/de/weitere-themen/45-tex-primitives-listed-by-cjk-tex-engine.md) ## „Software bauen“ 101: Was bedeutet das? Im restlichen Verlauf dieses Artikels beziehen wir uns auf den Begriff „TeX-Engines bauen“, der ein unbekanntes Konzept sein kann, wenn Sie kein Programmierer sind oder nicht in kompilierten Sprachen wie C oder C++ programmieren. Für unsere Zwecke ist das Bauen von Software – d. h. TeX-Engines – der Prozess, aus den Bestandteilen eines ausführbaren TeX-Programms ein ausführbares TeX-Programm zu erstellen: den Quellcodedateien, die in der Programmiersprache geschrieben sind, die zur Entwicklung des Programms verwendet wird. ## Vollständige Version: Möchten Sie die Details? Dann lesen Sie weiter... Jede auf TeX basierende Satz-Engine unterstützt einen „Dialekt“ der TeX-Sprache: eine bestimmte Menge an primitiven Befehlen, die die Satzfunktionen jeder Engine steuern und die Bausteine für das Erstellen/Definieren von Makros bereitstellen: benutzerdefinierte Befehlsfolgen. Jedes Makro, unabhängig davon, ob es für LaTeX, Plain TeX oder ein anderes Makropaket geschrieben ist, besteht letztlich aus primitiven Befehlen – obwohl man sich über viele Ebenen zusätzlicher Makros hinunterarbeiten muss, bevor man die „Grundschicht“ der TeX-Primitive erreicht. Die Menge der 9 untersuchten TeX-Engines, die zur Erstellung der Referenzdaten für Primitive analysiert wurden, haben natürlich viele Befehle gemeinsam, aber jede TeX-Engine besitzt auch eigene primitive Befehle, die von ihren Entwicklern hinzugefügt wurden, um die spezifischen Funktionen dieser „Version“ von TeX zu unterstützen. Die primitiven Befehle einer TeX-Engine sind in die ausführbare TeX-Software eingebaut: Primitive sind keine von Benutzern konstruierten Makros, sondern grundlegende, unteilbare/atomare Anweisungen, die verwendet werden, um das Satzverhalten jeder Engine zu steuern. Folglich ist die zuverlässigste Methode, um eine definitive Liste der von einer beliebigen TeX-Engine unterstützten primitiven Befehle zu erstellen, den tatsächlichen Quellcode zu untersuchen, aus dem die ausführbaren TeX-Programme erstellt (kompiliert) werden, und die im Quellcode definierten Primitive zu extrahieren. Klingt, als sollte das einfach sein, oder? Aufgrund der 40-jährigen Entwicklungsgeschichte von TeX ist das Erkunden/Untersuchen der Quellcodedateien der TeX-Engines (außer LuaTeX) jedoch nicht besonders geradlinig. Der Grund für diese Komplexitäten liegt in den Werkzeugen, der Programmiersprache (Pascal) und der Methodik (literate programming), die Knuth verwendete, um den ursprünglichen TeX-Quellcode zu schreiben – von dem letztlich alle anderen Engines abstammen. Wir weisen für LuaTeX auf eine Ausnahme hin, weil der Kern-Enginedcode in C neu geschrieben wurde, um die Verwendung von Pascal und andere weiter unten beschriebene Altlasten (Web2C) zu entfernen; folglich ist zwar der Quellcode von LuaTeX umfangreich, aber die Art und Weise, wie er „verpackt“ und verteilt wird, deutlich verständlicher als bei anderen TeX-Engines. Daher und basierend auf dem Arbeitsablauf/den Prozessen, mit denen sie aus dem Quellcode gebaut werden, ist es praktisch, TeX-Engines in zwei Kategorien einzuteilen: 1. LuaTeX: benutzerdefinierter (modernerer) Build-Prozess 2. Alle anderen Engines: veralteter (Web2C-)Build-Prozess ## Der Kontext von Legacy-Code: Warum das Bauen (der meisten) TeX-Engines komplex ist Wie wir unten sehen werden, veröffentlichte Knuth seinen ursprünglichen TeX-Quellcode als eine einzige, monolithische Datei mit dem Namen `tex.web` die Knuth weiterhin alle 7 Jahre aktualisiert, um verbliebene Fehler zu beheben – es werden niemals neue Funktionen hinzugefügt, es handelt sich ausschließlich um eine Fehlerbehebung. Die Dateiendung des TeX-Quellcodes (`.web`) ist wahrscheinlich ungewohnt, und Sie fragen sich vielleicht, welche Sprache Knuth verwendet hat, um TeX zu schreiben? Die Antwort ist Pascal, aber die `.web` Endung braucht etwas mehr Erklärung. Knuth entwickelte eine Programmiermethodik, die er [literate programming](https://en.wikipedia.org/wiki/Literate_programming) nannte, bei der der Quellcode eines Programms und die Dokumentation zusammengeführt und als eine einzige zusammengesetzte Datei (Code plus Dokumentation) mit der Endung `.web`veröffentlicht werden: Dieser Dateityp wird als WEB-Datei bezeichnet. WEB-Dateien erklären wir unten etwas ausführlicher. ### Neue TeX-Engines erstellen: Knuths Vorgaben Obwohl Knuth seinen TeX-Quellcode (`tex.web`) seit Langem allen frei zur Verfügung stellt, machte er – was sein gutes Recht ist – eine wesentliche Vorgabe, dass sein (`tex.web`) Quellcode nicht direkt bearbeitet/geändert und unter dem Programmnamen „TeX“ weiterverbreitet werden darf. Im Quellcode schreibt er: ``` % Dieses Programm ist urheberrechtlich geschützt (C) 1982 von D. E. Knuth; alle Rechte vorbehalten. % Das Kopieren dieser Datei ist nur autorisiert, wenn (1) Sie D. E. Knuth sind oder wenn % (2) Sie an Ihrer Kopie absolut keine Änderungen vornehmen. (Das WEB-System bietet % Änderungen über eine Hilfsdatei; die Masterdatei sollte intakt bleiben.) ``` und außerdem: ``` Wenn dieses Programm geändert wird, sollte das resultierende System nicht genannt werden `\TeX'; der offizielle Name `\TeX' allein ist vorbehalten für Softwaresysteme, die vollständig miteinander kompatibel sind. Eine spezielle Testsuite namens der ``\.{TRIP} test'' ist verfügbar, um dabei zu helfen zu bestimmen, ob eine bestimmte Implementierung es verdient, als `\TeX' bekannt zu sein [vgl.~Stanford Computer Science report CS1027, November 1984]. ``` Im Wesentlichen: Nehmen Sie keine Änderungen vor, indem Sie modifizierte Versionen des TeX-Masterquellcodes bearbeiten und verbreiten und ihn weiterhin `tex.web`nennen. Wenn Sie tatsächlich Änderungen vornehmen wollen, z. B. neue Primitive hinzufügen usw., dann müssen Sie diese Änderungen vornehmen, indem Sie „Änderungen über eine Hilfsdatei“ anwenden und Ihrem Programm, einer „Ableitung von TeX“, einen Namen geben, der es von „TeX“ unterscheidet, das in gesetzter Form ($$\mathrm\TeX$$) ein Warenzeichen der American Mathematical Society ist. ### Die Vererbung von Legacy Obwohl es Versuche gegeben hat, TeX mit modernen Programmiersprachen und Methoden vollständig neu zu schreiben – wie etwa die beiden Java-basierten Initiativen [New Typesetting System](https://en.wikipedia.org/wiki/New_Typesetting_System) und [εχTEX](http://www.extex.org/) und andere wie [eine in Clojure](https://www.infoq.com/news/2015/01/implementing-tex-in-clojure), war keiner vollständig erfolgreich. Die Geschichte der Projekte und Initiativen, die darauf abzielen, TeX weiterzuentwickeln, ist ein interessantes Thema, und Leser möchten vielleicht [die UK TeX FAQ besuchen](https://texfaq.org/FAQ-enginedev) für weitere Informationen. Jene Nicht-LuaTeX-Initiativen, die ebenfalls erfolgreich waren, wie e-TeX, pdfTeX, XeTeX und andere Engines, wurden *direkt auf* Knuths ursprünglichem Code aufgebaut: Sie nahmen seinen Quellcode und „wendeten Änderungen an“, um eine neue Engine mit zusätzlichen Fähigkeiten abzuleiten – etwa durch das Hinzufügen neuer Primitive, das Erzeugen von PDF-Ausgabe, die Unterstützung von UTF-8-Textinput und so weiter. Obwohl dieser Weg zu bemerkenswerten Erfolgen geführt hat, bedeutet er auch, dass diese abgeleiteten Engines den Legacy-Code und die Entwicklungstechniken erben, die Knuth vor 40 Jahren geschaffen hat. Die wichtigste Erkenntnis hier ist, dass – abgesehen von LuaTeX – die meisten TeX-Engines, die von Knuths ursprünglichem Quellcode abgeleitet sind, erstellt werden, indem man eine einzelne monolithische Datei (gewöhnlich `tex.web`) nimmt und Änderungen anwendet, die wiederum eine weitere einzelne monolithische Datei erzeugen, die den Kernquellcode dieser neuen Engine enthält. Fortgeschrittene Leser möchten vielleicht zu den einordnenden [Hinweisen zu pdfTeX und XeTeX](#aside-xetex-and-pdftex). ### Einige zusätzliche TeX-Geschichte/Hintergrund TeXs Geburtsmoment war [in Knuths Tagebuch mit dem 30. März 1977 verzeichnet](/latex/de/ausfuhrliche-artikel/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md#the-genesis-of-tex-a-brief-history), also vor mehr als 40 Jahren. Intern ist TeX ein außerordentlich komplexes Programm, dessen Quellcode Knuth sich große Mühe gab, [in außergewöhnlicher Detailtiefe zu dokumentieren](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373). Dazu entwickelte Knuth einen Programmierstil, den er [literate programming](https://en.wikipedia.org/wiki/Literate_programming) nannte, bei dem der Quellcode eines Programms und die Dokumentation zusammengeführt und als zusammengesetzte Datei mit der Endung veröffentlicht werden `.web` (als WEB-Datei bezeichnet). Knuth wählte Pascal als Programmiersprache für seine TeX-Software und verwendete, wenig überraschend, die TeX-Satzsprache, um die endgültige Dokumentation zu schreiben. Folglich wird der Master-Quellcode von Knuths TeX als eine einzige, monolithische Datei veröffentlicht, die `tex.web`heißt: eine Mischung aus Pascal-Quellcode und TeX-Satzcode für die Dokumentation. Wenn ein Programm im literate programming-Stil / mit der Methodik von Knuth geschrieben wird (wie TeX, MetaFont, BibTeX und andere), müssen Sie die WEB-Datei vorverarbeiten, um die Dokumentation oder den Quellcode zu extrahieren. Um auf die Programmdokumentation zuzugreifen, verarbeiten Sie die WEB-Datei (z. B. `tex.web`) mit einem Hilfsprogramm namens [WEAVE](http://tug.org/texinfohtml/web2c.html#weave-invocation) das die Dokumentation als eine `.tex` Datei erzeugt, die Sie setzen können. Um den Pascal-Quellcode zu extrahieren, verwenden Sie ein anderes Hilfsprogramm namens [TANGLE](http://tug.org/texinfohtml/web2c.html#tangle-invocation) das eine Datei mit der Endung `.p` ausgibt, die Pascal-Quellcode enthält. Zum Zeitpunkt des Verfassens (Anfang 2019) ist die neueste Version von Knuths TeX 3.14159265, datiert auf Januar 2014. Auch hier gilt: Knuths TeX-Quellcode ist in nur einer einzigen Datei mit rund 25.000 Zeilen TeX/Pascal-Code enthalten! ### Von Pascal zu C In den mehr als 40 Jahren seit der Entstehung von TeX ist Pascal aus der Mode gekommen, und heute denken nur noch wenige, wenn überhaupt jemand?, daran, TeX aus dem ursprünglichen Pascal-Quellcode zu bauen. Um Knuths Verwendung von Pascal zu umgehen, wurde ein Arbeitsablauf namens [Web2C](http://tug.org/texinfohtml/web2c.html) entworfen (ca. 1987), bei dem TeXs Pascal-Quellcode mechanisch (d. h. per Software) in sein Äquivalent in C-Code umgewandelt wird, der dann verwendet wird, um TeX zu kompilieren und das ausführbare Programm zu bauen. Das funktioniert gut, aber der einzige Nachteil ist, dass der mechanisch erzeugte C-Quellcode nicht für eine beiläufige menschliche Betrachtung gedacht ist: Er ist *extrem* wortreich und nahezu unverständlich, da er für Compiler und nicht für Menschen bestimmt ist – hier ist ein Screenshot, der ein kleines Fragment des aus TeXs Pascal-Quellcode erzeugten C-Codes zeigt: ![](/files/d25bcf31bf22f5d947c34ec3f3b20fd968e44478) ### Noch ein Knuthismus: WEB-Änderungsdateien Wie oben erwähnt, baut man auf Knuths ursprünglichem Quellcode auf, indem man „Änderungen anwendet“ oder, in Knuths Worten, „Änderungen über eine Hilfsdatei“ vornimmt: Aber was bedeutet das eigentlich? Hier kommt der *Mechanismus der Änderungsdateien*. ### Änderungsdateien: der Mechanismus zur Erstellung neuer TeX-Engines Entwickler, die Knuths TeX in irgendeiner Weise erweitern wollen, d. h. auf Knuths ursprünglicher Arbeit aufbauen möchten, wollen typischerweise eine völlig neue „Version“ von TeX erstellen oder eine *Erweiterung* bereitstellen, die zu jeder TeX-Engine hinzugefügt werden kann. Beispiele für Erweiterungen sind [SyncTeX](https://github.com/jlaurens/synctex) und [EncTeX](https://ctan.org/pkg/enctex?lang=en)—SyncTeX zum Beispiel ist eine sehr nützliche Erweiterung, die inzwischen in allen TeX-Engines enthalten ist. Der Bedarf an EncTeX wurde größtenteils durch die Entwicklung Unicode-fähiger TeX-Engines überholt – beachten Sie jedoch, dass EncTeX in pdfTeX eingebaut ist. Unabhängig davon, ob der Wunsch darin besteht, eine neue „Version“ von TeX zu erzeugen (d. h. eine Ableitung von Knuths ursprünglichem TeX) oder eine Erweiterung zu erstellen, beginnen die Entwickler mit Knuths ursprünglichem Quellcode und wenden die notwendigen Änderungen an, um eine neue TeX-Engine (oder eine Add-in-Erweiterung) zu erstellen. Wie oben erwähnt, muss jeder, der das Verhalten von TeX ändern möchte, dies mit „Änderungen über eine Hilfsdatei“ tun, da diese Änderungen/Modifikationen nicht durch *direktes* Bearbeiten von Knuths ursprünglichem Quellcode vorgenommen werden dürfen: Entwickler sind verpflichtet, die sogenannte WEB *Mechanismus der Änderungsdateien*. Der Code zur Änderung von Knuths TeX wird in der WEB-„Sprache“ geschrieben und in einer oder mehreren Codedateien gespeichert (genannt *Change-Dateien*), die anschließend *zusammengeführt* werden mit Knuths ursprünglichem, unverändertem Master-Quellcode. Dieser Zusammenführungsprozess erzeugt eine neue zusammengesetzte WEB-Datei, die nun den *Kern* Quellcode der neuen/geänderten TeX-basierten Software enthält. *Change-Dateien* haben oft die Endung `.ch` aber in der Praxis können sie jede von den Entwicklern gewünschte Endung haben. #### Wie verwendet/man wendet man Change-Dateien an? Heutzutage ist der einfachste Weg, Change-Dateien anzuwenden und eine „Master“-WEB-Datei zu ändern, ein Hilfsprogramm namens [TIE](https://ctan.org/pkg/tie). Angenommen, Sie wollten Knuths TeX modifizieren, indem Sie beispielsweise ein paar neue Primitive hinzufügen, oder Sie wollten das Verhalten eines vorhandenen (Standard-)TeX-Primivs ändern. Sie würden Ihren Code (in Pascal!) mit dem WEB-System des literate programming schreiben und in einer Datei namens beispielsweise `myprim.ch`speichern. Der nächste Schritt besteht darin, Ihren Code (in `myprim.ch`) mit Knuths Master-Quelldatei `tex.web` zu verbinden und eine neue zusammengesetzte WEB-Datei zu erzeugen, die das darstellt, was wir `mytex.web`nennen werden. Dazu führen Sie einfach das TIE-Programm so aus: ``` tie -m mytex.web tex.web myprim.ch ``` Wenn die Zusammenführung erfolgreich ist, ergibt dies eine neue WEB-Datei, `mytex.web`wobei Knuths Master-Quelldatei `tex.web` wie vorgeschrieben vollständig unverändert bleibt. Nehmen wir nun an, jemand anderes gefällt die von Ihnen vorgenommenen Änderungen und möchte Ihre Arbeit modifizieren, um seine Änderungen auf dem auf, oder zusätzlich zu, dem hinzuzufügen, was Sie getan haben. Anstatt Ihre modifizierte Version von TeX (`mytex.web`) zu verbreiten, entscheiden Sie sich, nur die Change-Datei zu veröffentlichen/zu teilen, `myprim.ch`. Jeder, der auf Ihrer Arbeit aufbauen möchte, kann nun seine Change-Datei erstellen und teilen, nennen wir sie beispielsweise `moreprim.ch` die Ihren Code in irgendeiner Weise erweitert. Jeder andere, der beide Change-Dateien nutzen möchte, kann nun eine neue zusammengesetzte WEB-Datei erzeugen, indem er *beide* Change-Dateien mit Knuths ursprünglichem Code zusammenführt, um ein weiteres TeX-Programm zu erzeugen, das etwa `newmytex.web`: ``` tie -m newmytex.web tex.web myprim.ch moreprim.ch ``` ### Echte TeX-Systeme: mehrere Change-Dateien Die obige Beschreibung von TIE kommt der Art und Weise, wie viele TeX-Engines in der Praxis gebaut werden, tatsächlich sehr nahe: Sie beginnen mit Knuths `tex.web` und fügen eine Folge von Change-Dateien hinzu, um die WEB-Quelldatei für diese Engine zu erzeugen. Jede TeX-Engine benötigt ihren eigenen spezifischen Satz von Change-Dateien, die in einer strikten Reihenfolge angewendet/verarbeitet (zusammengeführt) werden müssen: Ist die Reihenfolge falsch, schlägt der Zusammenführungsprozess fehl, weil jede Change-Datei in einer Sequenz auf Änderungen angewiesen ist, die von früher in der Kette auftauchenden Change-Dateien eingeführt wurden. Hier ist ein Beispielaufruf von TIE, der mehrere Change-Dateien auf Knuths `tex.web` anwendet, um `ktex.web`zu erzeugen – die zusammengesetzte WEB-Datei mit Änderungen an Knuths TeX, die sie bereit (geeignet) für die Umwandlung in C über den Web2C-Prozess machen. Beachten Sie auch Folgendes: * `tex.ch` ist eine sehr große Change-Datei, die unter anderem TeX so modifiziert, dass es Kpathsea verwendet; * die SyncTeX-Erweiterung wird über mehrere Change-Dateien hinzugefügt. ``` 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 Dies ist TIE, CWEB Version 2.4. Copyright (c) 1989,1992 by THD/ITI. Alle Rechte vorbehalten. (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.... (Es wurden keine Fehler gefunden.) ``` #### Abseits: XeTeX und pdfTeX Vollständigkeitshalber sollten wir darauf hinweisen, dass der Build-Prozess für pdfTeX und XeTeX tatsächlich nicht mit Knuths `tex.web`beginnt; stattdessen beginnen sie mit Dateien namens `pdftex.web` und `xetex.web` bzw.: vermutlich, weil die Änderungen so umfangreich sind, dass es sinnvoller ist, WEB-Dateien zu teilen/veröffentlichen, die bereits die sehr bedeutenden Änderungen an Knuths ursprünglichem Code enthalten. ### Ein Beispiel: e-upTeX Die japanische TeX-Community hat eine Reihe von TeX-Engines entwickelt, die darauf ausgelegt sind, die Komplexität des Satzes japanischer Texte zu bewältigen: * **pTeX**Knuths TeX-Engine, erweitert um Unterstützung für japanischen Satz; * **e-pTeX**Eine Kombination aus e-TeX und pTeX (plus einigen von pdfTeX eingeführten Primitiven); * **upTeX**Eine Unicode-fähige Version von pTeX plus Erweiterungen für eine bessere Behandlung von CJK (Chinesisch, Japanisch und Koreanisch); * **e-upTeX**Eine Kombination (Zusammenführung) von e-TeX und upTeX. #### Erzeugen der zusammengesetzten Quelldatei für e-upTeX Um die zusammengesetzte WEB-Quelldatei für e-upTeX (mit SyncTeX) zu erstellen, beginnen Sie mit Knuths `tex.web` müssen aber **26** einzelne Change-Dateien in der folgenden Reihenfolge anwenden, um eine einzige zusammengesetzte Datei zu erhalten, aus der die Liste der primitiven Befehle extrahiert werden kann: ``` 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 ``` #### Change-Dateien anwenden: welche Dateien und in welcher Reihenfolge? Wie bereits erwähnt, ist es äußerst wichtig, Change-Dateien in strikter Reihenfolge anzuwenden/verarbeiten – aber wie findet man heraus, welche Dateien benötigt werden und in welcher Reihenfolge sie verarbeitet werden müssen? Glücklicherweise ist diese entscheidende Information in Dateien enthalten, die in der TeX-Live-Distribution enthalten sind, und eine Untersuchung des TeX-Live-Quellcodes hat die Regeln offenbart, die die Build-Anforderungen für jede TeX-Engine bestimmen. Nach diesen Regeln konnte Overleaf die zusammengesetzte WEB-Quelldatei für jede TeX-Engine rekonstruieren und eine Liste von Primitiven für die weitere Datenverarbeitung extrahieren. ## Und schließlich: Wie extrahiert man die Liste der Primitive? Sobald die zusammengesetzte WEB-Datei erstellt wurde, ist die Aufgabe, die Liste der Primitive mithilfe regulärer Ausdrücke zu extrahieren, unkompliziert, da alle primitiven Befehle mit einer einzigen Pascal-Funktion namens definiert („registriert“) werden `primitive(...)`. Hier sind einige echte Beispiele aus Knuths `tex.web` Quellcode: ``` 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) ... ... ``` Wie Sie sehen können, ist die `primitive(...)` Funktion mit regulären Ausdrücken hervorragend für die Textverarbeitung geeignet: Der Name des registrierten Primivs steht in Anführungszeichen (`"..."`) zusammen mit zusätzlichen Daten, die das Verhalten jedes Primivs klassifizieren (darauf gehen wir hier nicht im Detail ein). Nachdem die Liste der Primitive für jede Engine extrahiert wurde, wurden diese Daten von einigen Lua-Skripten verarbeitet, um HTML mit den tabellarischen Ergebnissen zu erzeugen. ### Zurück zu LuaTeX Wir haben festgestellt, dass LuaTeX nicht genau dieselben Build-Prozesse verwendet wie die anderen 8 TeX-Engines. Nachdem wir kurz den Web2C-Prozess, die Umwandlung von Pascal in C und den Mechanismus der Change-Dateien betrachtet haben, können wir nun erklären, worin sich LuaTeX unterscheidet: Die Entwickler von LuaTeX beschlossen, auf den umständlichen Prozess der Umwandlung von Pascal in C zu verzichten – wie in [dem LuaTeX Reference Manual](http://www.pragma-ade.com/general/manuals/luatex): > ...das Kompilierungs-Framework ist web2c und wir verwenden das weiterhin, aber ohne den Pascal-zu-C-Schritt. Die Kern-Engine von LuaTeX wurde in C neu geschrieben, was bedeutet, dass ihr Build-Prozess etwas standardmäßiger und sicherlich wesentlich bequemer ist. Eine nützliche Folge ist, dass die von LuaTeX unterstützten Primitive sauber in einer separaten C-Quelldatei ausgegliedert sind, was die Aufgabe des Zugriffs auf/Auflistens erheblich erleichtert hat. Streng genommen sollten wir auch erwähnen, dass einige der Quellcodedateien von LuaTeX eine Variante von Knuths literate-programming-Methodik verwenden, genannt [CWEB](https://en.wikipedia.org/wiki/CWEB), die auf C und nicht auf Pascal basiert. ### Nicht nur WEB-Dateien: anderer Quellcode ist erforderlich Nachdem die zusammengesetzte WEB-Quelldatei für jede TeX-Engine (außer LuaTeX) erzeugt wurde, muss der Pascal-Quellcode extrahiert und in C-Code umgewandelt werden, aber das ist nicht die Gesamtlösung. Zusätzlich zum aus der WEB-Quelle generierten C-Code (Pascal⮕C) sind bei den meisten TeX-Engines auch eine Reihe zusätzlicher Hilfs-Quelldateien (Bibliotheken) erforderlich, die typischerweise in C geschrieben sind – wie etwa [Kpathsea](https://www.tug.org/kpathsea/). Hilfs-Quelldateien (Bibliotheken) implementieren Funktionalität, die nicht in WEB (Pascal) geschrieben werden muss oder kann. Alles, was in der WEB-„Sprache“ für TeX geschrieben wird, muss die Pascal-Sprache verwenden, die anschließend extrahiert und in maschinell erzeugtes C umgewandelt wird: Wenn man das nicht tun muss, warum dann nicht einfach von vornherein in C oder C++ schreiben. --- # 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/de/weitere-themen/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.