> 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/pl/wiecej-tematow/18-how-overleaf-created-the-tex-primitive-reference-data.md).

# Jak Overleaf stworzył dane referencyjne prymitywów TeX-a

Ten artykuł opisuje metody i techniki użyte do przygotowania dwóch tabel odsyłaczy dla prymitywnych poleceń TeX-a:

* [Prymitywy TeX-a według silnika TeX](/latex/pl/wiecej-tematow/46-tex-primitives-listed-by-tex-engine.md) i;
* [Prymitywy TeX-a według silnika CJK TeX](/latex/pl/wiecej-tematow/45-tex-primitives-listed-by-cjk-tex-engine.md).

Informacje te są udostępnione czytelnikom zainteresowanym bardziej szczegółami, ale nie są warunkiem koniecznym do korzystania z samej tabeli odsyłaczy. Aby odpowiedzieć na potrzeby różnych czytelników, przygotowaliśmy bardzo krótkie podsumowanie, a także dłuższe objaśnienie dla tych, którzy chcą zgłębić temat bardziej szczegółowo.

## Krótka wersja podsumowania/przeglądu

Aby zbudować tabelę odsyłaczy, Overleaf przetworzył kod źródłowy 9 silników TeX-a, aby wyodrębnić listę prymitywów obsługiwanych przez każdy z nich: proces ten dał 9 plików tekstowych (1 plik na silnik TeX-a). Te 9 zestawów prymitywów połączono, aby utworzyć „listę wzorcową”, która w praktyce była sumą zbiorów prymitywów: daje to łącznie około 1000 unikalnych prymitywów rozproszonych po różnych silnikach. Dla każdego silnika jego własną listę prymitywów porównano krzyżowo z plikiem wzorcowym (zbiorem wszystkich poleceń), aby ustalić, które z tych \~1000 poleceń obsługuje: wyniki tych porównań zestawiono w dwóch poniższych tabelach:

* [Dane odsyłaczy dla prymitywów TeX-a](/latex/pl/wiecej-tematow/46-tex-primitives-listed-by-tex-engine.md)
* [Dane odsyłaczy dla prymitywów TeX-a (dla silników CJK)](/latex/pl/wiecej-tematow/45-tex-primitives-listed-by-cjk-tex-engine.md)

## „Budowanie oprogramowania” 101: Co to znaczy?

W dalszej części artykułu odwołujemy się do pojęcia „budowania silników TeX-a”, które może być nieznane, jeśli nie jesteś programistą albo nie programujesz w językach kompilowanych, takich jak C czy C++. Na potrzeby tego artykułu budowanie oprogramowania — tj. silników TeX-a — to proces tworzenia wykonywalnego programu TeX z jego składników, czyli plików kodu źródłowego napisanych w języku programowania użytym do opracowania programu.

## Pełna wersja: Chcesz szczegółów? Czytaj dalej...

Każdy silnik składu oparty na TeX-u obsługuje „dialekt” języka TeX: określony zestaw prymitywnych poleceń, które sterują funkcjami składu każdego silnika i stanowią elementy składowe do tworzenia/definiowania makr: sekwencji poleceń zdefiniowanych przez użytkownika. Każde makro, niezależnie od tego, czy jest napisane dla LaTeX-a, plain TeX-a czy jakiegokolwiek innego pakietu makr, jest ostatecznie zbudowane z prymitywnych poleceń — choć może być konieczne zejście bardzo głęboko, przez warstwy dodatkowych makr, zanim dotrzesz do „warstwy skalnej” prymitywów TeX-a. Zestaw 9 silników TeX-a przeanalizowanych w celu uzyskania danych referencyjnych dotyczących prymitywnych poleceń ma oczywiście wiele poleceń wspólnych, ale każdy silnik TeX-a ma również własne prymitywne polecenia, dodane przez jego twórców, aby zapewnić obsługę funkcji specyficznych dla tej „wersji” TeX-a.

Prymitywne polecenia silnika TeX-a są wbudowane w wykonywalne oprogramowanie TeX: prymitywy nie są makrami tworzonymi przez użytkowników, lecz fundamentalnymi, niepodzielnymi/atomowymi instrukcjami służącymi do sterowania zachowaniem składu każdego silnika. W konsekwencji najbardziej niezawodnym sposobem stworzenia wiążącej listy prymitywnych poleceń obsługiwanych przez dowolny silnik TeX-a jest zbadanie rzeczywistego kodu źródłowego, z którego kompilowane są wykonywalne programy TeX, i wyodrębnienie listy prymitywów zdefiniowanych w kodzie źródłowym. Brzmi, jakby miało być łatwo, prawda? Jednak z powodu 40-letniej historii rozwoju TeX-a eksplorowanie/badanie plików kodu źródłowego silników TeX-a (z wyjątkiem LuaTeX-a) nie jest szczególnie proste. Powód tych zawiłości leży w narzędziach, języku programowania (Pascal) i metodologii (programowanie literackie), których Knuth użył do napisania oryginalnego kodu źródłowego TeX-a — od którego ostatecznie wywodzą się wszystkie pozostałe silniki.

Zaznaczamy wyjątek dla LuaTeX-a, ponieważ jego kod rdzenia został przepisany w C, aby usunąć użycie Pascala i innych opisanych poniżej dziedzicznych zawiłości (Web2C); w konsekwencji, choć kod źródłowy LuaTeX-a jest obszerny, sposób, w jaki jest „pakowany” i rozpowszechniany, jest znacznie bardziej zrozumiały niż w przypadku innych silników TeX-a. W rezultacie, oraz ze względu na przepływy pracy/procesy używane do budowania ich z kodu źródłowego, wygodnie jest podzielić silniki TeX-a na dwie kategorie:

1. LuaTeX: niestandardowy (bardziej nowoczesny) proces budowania
2. Wszystkie pozostałe silniki: starszy proces budowania (Web2C)

## Kontekst starszego kodu: dlaczego budowanie (większości) silników TeX-a jest złożone

Jak wyjaśnimy poniżej, Knuth opublikował swój oryginalny kod źródłowy TeX-a jako pojedynczy, monolityczny plik o nazwie `tex.web` który Knuth nadal co 7 lat aktualizuje, aby poprawić wszelkie pozostałe błędy — nigdy nie dodaje się nowych funkcji, jest to wyłącznie praca nad poprawianiem błędów.

Rozszerzenie pliku źródłowego TeX-a (`.web`) raczej nie będzie Ci znane i możesz się zastanawiać, w jakim języku Knuth napisał TeX-a? Odpowiedź brzmi: Pascal, ale rozszerzenie wymaga nieco więcej wyjaśnienia. Knuth opracował metodologię programowania, którą nazwał `.web` programowaniem literackim [w której kod źródłowy programu i dokumentacja są łączone i publikowane jako pojedynczy plik złożony (kod plus dokumentacja) z rozszerzeniem](https://en.wikipedia.org/wiki/Literate_programming) : ten typ pliku określa się jako plik WEB. Poniżej wyjaśniamy pliki WEB nieco dokładniej. `.web`Tworzenie nowych silników TeX-a: założenia Knutha

### Chociaż Knuth od dawna udostępnia swój kod źródłowy TeX-a (

) wszystkim bezpłatnie, ustanowił — co było jego absolutnym prawem — kluczowe zastrzeżenie, że jego (`tex.web`kod źródłowy`tex.web`) nie może być bezpośrednio edytowany/modyfikowany i redystrybuowany pod nazwą programu „TeX”. W kodzie źródłowym pisze:

```
% Ten program jest chroniony prawami autorskimi (C) 1982 przez D. E. Knutha; wszelkie prawa zastrzeżone.
% Kopiowanie tego pliku jest dozwolone tylko, jeśli (1) jesteś D. E. Knuthem albo jeśli
% (2) nie wprowadzasz absolutnie żadnych zmian do swojej kopii. (System WEB zapewnia
% możliwość wprowadzania zmian za pośrednictwem pliku pomocniczego; plik główny powinien pozostać nienaruszony.)
```

oraz także:

```
Jeśli ten program zostanie zmieniony, powstały system nie powinien być nazywany
`\TeX'; oficjalna nazwa `\TeX' sama w sobie jest zastrzeżona
dla systemów oprogramowania, które są wzajemnie w pełni zgodne.
Specjalny zestaw testów zwany „\.{TRIP} test” jest dostępny w celu
pomocy w ustaleniu, czy dana implementacja zasługuje na to, by być
nazywana `\TeX' [por.~raport Wydziału Informatyki Stanforda CS1027,
listopad 1984].
```

W istocie: nie wprowadzaj zmian, edytując i rozpowszechniając zmodyfikowane wersje głównego kodu źródłowego TeX-a i nadal nazywając go `tex.web`. Jeśli chcesz wprowadzać zmiany, np. dodać nowe prymitywy itp., musisz zastosować te zmiany, „wprowadzając modyfikacje za pośrednictwem pliku pomocniczego”, i nadać swojemu programowi będącemu „pochodną TeX-a” nazwę odróżniającą go od „TeX-a”, który w postaci składu ($$\mathrm\TeX$$), jest znakiem towarowym American Mathematical Society.

### Dziedzictwo starszego kodu

Chociaż podejmowano próby całkowitego przepisania TeX-a przy użyciu nowoczesnych języków programowania i metodologii — takich jak dwie inicjatywy oparte na Javie [New Typesetting System](https://en.wikipedia.org/wiki/New_Typesetting_System) i [εχTEX](http://www.extex.org/) oraz inne, takie jak [jedna w Clojure](https://www.infoq.com/news/2015/01/implementing-tex-in-clojure)na żadnej nie udało się w pełni. Historia projektów i inicjatyw mających na celu dalszy rozwój TeX-a jest interesującym tematem i czytelnicy mogą zechcieć [odwiedzić brytyjskie FAQ TeX-a](https://texfaq.org/FAQ-enginedev) w celu uzyskania dalszych informacji.

Te inicjatywy inne niż LuaTeX, które również odniosły sukces, takie jak e-TeX, pdfTeX, XeTeX i inne silniki, bazowały *bezpośrednio* na oryginalnym kodzie Knutha: pobierając jego kod źródłowy i „wprowadzając zmiany”, aby wyprowadzić nowy silnik z dodatkowymi możliwościami — takimi jak dodawanie nowych prymitywów, generowanie wyjścia PDF, obsługa wejścia tekstowego UTF-8 itd. Choć ta droga przyniosła znaczące sukcesy, oznacza też, że te silniki pochodne dziedziczą starszy kod i techniki rozwoju, które Knuth stworzył 40 lat temu.

Kluczowy wniosek jest taki, że poza LuaTeX-em większość silników TeX-a wywodzących się z oryginalnego kodu Knutha jest tworzona przez pobranie pojedynczego monolitycznego pliku (zwykle `tex.web`) i zastosowanie zmian, które generują kolejny pojedynczy monolityczny plik zawierający kod źródłowy rdzenia tego nowego silnika. Zaawansowani czytelnicy mogą chcieć przejść od razu do wyjaśniających [uwag o pdfTeX i XeTeX](#aside-xetex-and-pdftex).

### Dodatkowa historia/opracowanie o TeX-ie

Moment narodzin TeX-a miał miejsce [został odnotowany w dzienniku Knutha jako 30 marca 1977](/latex/pl/artykuly-szczegolowe/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md#the-genesis-of-tex-a-brief-history), czyli ponad 40 lat temu. Wewnętrznie TeX jest niezwykle złożonym programem, którego kod źródłowy Knuth z wielką starannością [udokumentował z wyjątkową szczegółowością](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373). Aby to zrobić, Knuth opracował styl programowania, który nazwał [w której kod źródłowy programu i dokumentacja są łączone i publikowane jako pojedynczy plik złożony (kod plus dokumentacja) z rozszerzeniem](https://en.wikipedia.org/wiki/Literate_programming) w którym kod źródłowy programu i dokumentacja są łączone i publikowane jako plik złożony z rozszerzeniem `.web` (określany jako plik WEB). Knuth wybrał Pascala jako język programowania do napisania swojego oprogramowania TeX, i, co nie dziwi, użył języka składu TeX do napisania końcowej dokumentacji. W związku z tym główny kod źródłowy TeX-a Knutha jest publikowany jako pojedynczy, monolityczny plik o nazwie `tex.web`: mieszanka kodu źródłowego Pascala i kodu składu TeX dla dokumentacji.

Jeśli program jest napisany przy użyciu literackiego stylu/metodologii programowania Knutha (tak jak TeX, MetaFont, BibTeX i inne), trzeba wstępnie przetworzyć plik WEB, aby wyodrębnić dokumentację lub kod źródłowy. Aby uzyskać dostęp do dokumentacji programu, przetwarza się plik WEB (np. `tex.web`) za pomocą narzędzia o nazwie [WEAVE](http://tug.org/texinfohtml/web2c.html#weave-invocation) które generuje dokumentację jako `.tex` plik, który można złożyć. Aby wyodrębnić kod źródłowy w Pascalu, używa się innego narzędzia o nazwie [TANGLE](http://tug.org/texinfohtml/web2c.html#tangle-invocation) które tworzy plik z rozszerzeniem `.p` zawierający kod źródłowy Pascala.

W chwili pisania tego tekstu (początek 2019 r.) najnowsza wersja TeX-a Knutha to 3.14159265, datowana na styczeń 2014 r. Ponownie warto zauważyć, że kod źródłowy TeX-a Knutha mieści się w jednym tylko pliku zawierającym około 25 000 linii kodu TeX/Pascal!

### Od Pascala do C

W ciągu ponad 40 lat, które upłynęły od narodzin TeX-a, Pascal wyszedł z mody i dziś niewiele, jeśli w ogóle ktokolwiek, osób rozważa budowanie TeX-a z jego oryginalnego źródła w Pascalu. Aby obejść użycie Pascala przez Knutha, zaprojektowano przepływ pracy zwany [Web2C](http://tug.org/texinfohtml/web2c.html) w którym źródłowy kod Pascala TeX-a jest mechanicznie (tj. za pomocą oprogramowania) przekształcany do odpowiadającego mu kodu w C, który następnie służy do kompilacji TeX-a i zbudowania programu wykonywalnego. Działa to dobrze, ale jedyną wadą jest to, że mechanicznie wygenerowany kod źródłowy w C nie jest przeznaczony do swobodnej ludzkiej inspekcji: jest *skrajnie* rozwlekły i prawie nieprzenikniony, przeznaczony dla kompilatorów, nie dla ludzi — oto zrzut ekranu pokazujący mały fragment kodu w C wygenerowanego z pascalowego źródła TeX-a:

![](/files/a07a4d0cc4c9ce8349b6fa5bada871558f27828c)

### Kolejny knuthizm: pliki zmian WEB

Jak wspomniano powyżej, aby budować na oryginalnym kodzie źródłowym Knutha, „wprowadza się zmiany” lub, słowami Knutha, „wprowadza się modyfikacje za pośrednictwem pliku pomocniczego”: ale co to właściwie oznacza? Oto *mechanizm pliku zmian*.

### Pliki zmian: mechanizm tworzenia nowych silników TeX-a

Programiści chcący w jakiś sposób rozszerzyć TeX-a Knutha, tj. rozwijać jego oryginalną pracę, zwykle chcą stworzyć zupełnie nową „wersję” TeX-a albo dostarczyć *rozszerzenie* które można dodać do dowolnego silnika TeX-a. Przykłady rozszerzeń obejmują [SyncTeX](https://github.com/jlaurens/synctex) i [EncTeX](https://ctan.org/pkg/enctex?lang=en)—SyncTeX na przykład jest bardzo użytecznym rozszerzeniem, które jest obecnie dołączane do wszystkich silników TeX-a. Potrzeba EncTeX została w dużej mierze zastąpiona przez rozwój silników TeX-aware Unicode — ale zauważ, że EncTeX jest wbudowany w pdfTeX.

Niezależnie od tego, czy celem jest stworzenie nowej „wersji” TeX-a (tj. pochodnej oryginalnego TeX-a Knutha), czy utworzenie rozszerzenia, jego twórcy zaczynają od oryginalnego kodu źródłowego Knutha i stosują modyfikacje niezbędne do stworzenia nowego silnika TeX-a (lub rozszerzenia dołączanego). Jednak, jak wspomniano wyżej, każdy, kto chce zmodyfikować zachowanie TeX-a, musi to zrobić przy użyciu „modyfikacji za pośrednictwem pliku pomocniczego”, ponieważ tych zmian/modyfikacji nie wolno wprowadzać przez *bezpośrednie* edytowanie oryginalnego kodu źródłowego Knutha: programiści muszą używać tak zwanego WEB *mechanizm pliku zmian*. Kod do modyfikacji TeX-a Knutha jest pisany w „języku” WEB i zapisywany do jednego lub kilku plików kodu (zwanych *plikami zmian*), które następnie są *łączone* z oryginalnym, niezmienionym kodem źródłowym Knutha. Ten proces łączenia tworzy nowy złożony plik WEB, który teraz zawiera *rdzeń* kod źródłowy nowego/modyfikowanego oprogramowania opartego na TeX-u. *Pliki zmian* często mają rozszerzenie `.ch` ale w praktyce mogą mieć dowolne rozszerzenie wybrane przez programistów.

#### Jak używać/stosować pliki zmian?

Obecnie najprostszym sposobem zastosowania plików zmian i modyfikacji „głównego” pliku WEB jest użycie programu narzędziowego o nazwie [TIE](https://ctan.org/pkg/tie). Na przykład załóżmy, że chcesz zmodyfikować TeX-a Knutha, dodając, powiedzmy, kilka nowych prymitywów albo zmieniając zachowanie istniejącego (standardowego) prymitywu TeX-a. Napisałbyś swój kod (w Pascalu!) używając systemu WEB programowania literackiego i zapisał go do pliku o nazwie, powiedzmy, `myprim.ch`. Następny krok to połączenie twojego kodu (w `myprim.ch`WEB) z głównym plikiem źródłowym Knutha `tex.web` i utworzenie nowego, złożonego pliku WEB reprezentującego to, co nazwiemy `mytex.web`. Aby to zrobić, wystarczy uruchomić program TIE w taki sposób:

```
tie -m mytex.web tex.web myprim.ch
```

Zakładając, że połączenie się powiedzie, spowoduje to powstanie nowego pliku WEB, `mytex.web`, pozostawiając główny plik źródłowy Knutha `tex.web` całkowicie niezmieniony, zgodnie z wymaganiami.

Załóżmy teraz, że komuś podobają się wprowadzone przez ciebie zmiany i chce zmodyfikować twoją pracę, dodając własne zmiany ponad to, co zrobiłeś, lub oprócz tego. Zamiast rozpowszechniać twoją zmodyfikowaną wersję TeX-a (`mytex.web`) postanawiasz opublikować/udostępnić tylko plik zmian, `myprim.ch`. Każdy, kto chce rozwijać twoją pracę, może teraz utworzyć i udostępnić własny plik zmian o nazwie, powiedzmy, `moreprim.ch` który w jakiś sposób rozszerza twój kod. Każdy inny, kto chce skorzystać z obu plików zmian, może teraz wygenerować nowy złożony plik WEB, łącząc *oba* pliki zmian z oryginałem Knutha, aby wygenerować kolejny program TeX o nazwie, powiedzmy, `newmytex.web`:

```
tie -m newmytex.web tex.web myprim.ch moreprim.ch
```

### Prawdziwe systemy TeX: wiele plików zmian

Powyższy opis TIE jest w rzeczywistości bardzo zbliżony do sposobu, w jaki wiele silników TeX-a jest budowanych w praktyce: zaczynają od Knutha `tex.web` i dodają kolejne pliki zmian, aby wygenerować plik źródłowy WEB dla danego silnika. Każdy silnik TeX-a wymaga własnego, określonego zestawu plików zmian, które muszą być stosowane/przetwarzane (łączone) w ściśle określonej kolejności: jeśli kolejność będzie błędna, proces łączenia zakończy się niepowodzeniem, ponieważ każdy plik zmian w sekwencji opiera się na zmianach wprowadzonych przez pliki zmian pojawiające się wcześniej w łańcuchu.

Oto przykładowe uruchomienie TIE zastosowującego wiele plików zmian do Knutha `tex.web` w celu wygenerowania `ktex.web`—złożonego pliku WEB zawierającego modyfikacje TeX-a Knutha, które przygotowują go (czynią odpowiednim) do konwersji do C za pomocą procesu Web2C. Zwróć też uwagę na następujące kwestie:

* `tex.ch` to bardzo duży plik zmian, który między innymi modyfikuje TeX-a tak, aby używał Kpathsea;
* rozszerzenie SyncTeX jest dodawane za pośrednictwem wielu plików zmian.

```
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
To jest TIE, CWEB wersja 2.4.
Prawa autorskie (c) 1989,1992 należą do THD/ITI. Wszelkie prawa zastrzeżone.
(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....
(Nie znaleziono żadnych błędów.)
```

#### Dygresja: XeTeX i pdfTeX

Dla pełności należy zauważyć, że proces budowania pdfTeX i XeTeX w rzeczywistości nie zaczyna się od Knutha `tex.web`; zamiast tego zaczyna się od plików o nazwie `pdftex.web` i `xetex.web` odpowiednio: zapewne dlatego, że zmiany są tak rozległe, iż ma większy sens udostępnianie/publikowanie plików WEB, które już zawierają bardzo znaczące modyfikacje wprowadzone do oryginalnego kodu Knutha.

### Przykład: e-upTeX

Japońska społeczność TeX opracowała szereg silników TeX-a zaprojektowanych tak, aby sprostać złożoności składu tekstu japońskiego:

* **pTeX**: silnik TeX-a Knutha rozszerzony o obsługę składu japońskiego;
* **e-pTeX**: Połączenie e-TeX i pTeX (plus kilka prymitywów wprowadzonych przez pdfTeX);
* **upTeX**: Wersja pTeX uwzględniająca Unicode, z rozszerzeniami zapewniającymi lepszą obsługę CJK (chińskiego, japońskiego i koreańskiego);
* **e-upTeX**: Połączenie (scalenie) e-TeX i upTeX.

#### Generowanie złożonego pliku źródłowego dla e-upTeX

Aby utworzyć złożony plik źródłowy WEB dla e-upTeX (z SyncTeX) zaczynasz od Knutha `tex.web` ale musisz zastosować **26** pojedyncze pliki zmian, w następującej kolejności, aby uzyskać pojedynczy złożony plik, z którego można wyodrębnić listę poleceń prymitywnych:

```
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
```

#### Stosowanie plików zmian: które pliki i w jakiej kolejności?

Jak wspomniano, niezwykle ważne jest stosowanie/przetwarzanie plików zmian w ścisłej kolejności — ale skąd dowiedzieć się, które pliki są potrzebne i w jakiej kolejności je przetwarzać? Na szczęście te kluczowe informacje są zapisane w plikach znajdujących się w dystrybucji TeX Live, a analiza kodu źródłowego TeX Live ujawniła reguły rządzące wymaganiami budowy każdego silnika TeX-a. Kierując się tymi regułami, Overleaf był w stanie odtworzyć złożony plik źródłowy WEB dla każdego silnika TeX-a i wyodrębnić listę prymitywów do dalszego przetwarzania danych.

## I wreszcie: jak wyodrębnić listę prymitywów?

Gdy złożony plik WEB został już zbudowany, zadanie wyodrębnienia listy prymitywów za pomocą wyrażeń regularnych jest proste, ponieważ wszystkie polecenia prymitywne są definiowane („rejestrowane”) za pomocą jednej funkcji Pascala o nazwie `primitive(...)`. Oto kilka rzeczywistych przykładów zaczerpniętych z kodu źródłowego Knutha: `tex.web` kod źródłowy:

```
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)
...
...
```

Jak widać, `primitive(...)` funkcja ta bardzo dobrze nadaje się do przetwarzania tekstu za pomocą wyrażeń regularnych: nazwa rejestrowanego prymitywu znajduje się w cudzysłowie (`"..."`) wraz z dodatkowymi danymi klasyfikującymi zachowanie każdego prymitywu (nie będziemy tego tutaj szczegółowo omawiać). Po wyodrębnieniu listy prymitywów dla każdego silnika dane te zostały przetworzone przez skrypty Lua w celu wygenerowania HTML zawierającego wyniki w formie tabelarycznej.

### Powracając do LuaTeX

Zauważyliśmy, że LuaTeX nie używa dokładnie takich samych procesów budowania jak pozostałe 8 silników TeX-a. Po krótkim omówieniu procesu Web2C, konwersji Pascala do C i mechanizmu plików zmian możemy teraz wyjaśnić, czym LuaTeX się różni: twórcy LuaTeX-a zdecydowali się zrezygnować z kłopotliwego procesu konwersji Pascala do C — jak zauważono w [Podręczniku referencyjnym LuaTeX](http://www.pragma-ade.com/general/manuals/luatex):

> ...ramy kompilacji to web2c i nadal z nich korzystamy, ale bez kroku Pascal do C.

Główny silnik LuaTeX został przepisany w C, co oznacza, że jego proces budowania jest nieco bardziej standardowy i zdecydowanie wygodniejszy. Jedną z użytecznych konsekwencji jest to, że obsługiwane przez LuaTeX prymitywy są ładnie wyodrębnione do osobnego pliku źródłowego C, co znacznie ułatwiło zadanie ich dostępu/listowania.

Ściśle rzecz biorąc, należy też zauważyć, że niektóre pliki źródłowe LuaTeX używają odmiany knuthowskiej metodologii programowania literackiego, zwanej [CWEB](https://en.wikipedia.org/wiki/CWEB), która opiera się na C, a nie na Pascalu.

### Nie tylko pliki WEB: potrzebny jest inny kod źródłowy

Po wygenerowaniu złożonego pliku źródłowego WEB dla dowolnego silnika TeX-a (z wyjątkiem LuaTeX-a) trzeba wyodrębnić kod źródłowy Pascala i przekonwertować go do C, ale to nie jest pełne rozwiązanie. Oprócz kodu C wygenerowanego ze źródła WEB (Pascal⮕C) większość silników TeX-a opiera się również na (wymaga) szeregu dodatkowych pomocniczych plików źródłowych (bibliotek), które zazwyczaj są napisane w C — takich jak [Kpathsea](https://www.tug.org/kpathsea/). Pomocnicze pliki źródłowe (biblioteki) implementują funkcjonalność, której nie trzeba lub nie da się zapisać w WEB (Pascalu). Wszystko, co jest napisane w „języku” WEB dla TeX-a, musi używać języka Pascal, który jest następnie wyodrębniany i konwertowany do generowanego maszynowo C: jeśli nie trzeba tego robić, to dlaczego po prostu nie napisać tego od razu w C albo C++.


---

# 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/pl/wiecej-tematow/18-how-overleaf-created-the-tex-primitive-reference-data.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.