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

# Wprowadzenie do LuaTeX (Część 1): Czym jest — i co sprawia, że jest tak inny?

LuaTeX to *zestaw narzędzi*—zawiera zaawansowane narzędzia programowe i komponenty, za pomocą których można konstruować (składać) bardzo szeroki zakres dokumentów. Podtytuł tego artykułu stawia też dwa pytania o LuaTeX: Czym on jest — i co sprawia, że jest tak inny? Odpowiedź na pytanie „Czym on jest?” może wydawać się oczywista: „To silnik składu TeX!” I rzeczywiście tak jest, ale szersze spojrzenie, które podziela autor, jest takie, że LuaTeX to niezwykle wszechstronny system oparty na TeX *system konstruowania i inżynierii dokumentów*.

### Wyjaśnianie LuaTeX: od czego zacząć?

Celem tego pierwszego artykułu o LuaTeX jest zapewnienie kontekstu do zrozumienia tego, co ten silnik TeX oferuje oraz dlaczego/jak jego projekt pozwala użytkownikom budować/projektować/tworzyć szeroki zakres rozwiązań złożonych problemów składu i projektowania — być może oferując także pewien stopień „zabezpieczenia na przyszłość”, ponieważ użytkownicy coraz częściej potrzebują oprogramowania opartego na TeX, które potrafi dostosowywać się do stale zmieniającego się ekosystemu technicznego. Zdaniem autora samo wyliczanie i opisywanie jego funkcji/możliwości niekoniecznie jest najlepszym punktem wyjścia do zrozumienia możliwości i potencjału LuaTeX. Takie podejście nie będzie szczególnie pomocne dla czytelników, którzy nie znają innych silników TeX i dla których porównania oparte na funkcjach prawdopodobnie nie będą zbyt znaczące.

Ryzykując wyczerpanie cierpliwości czytelnika („Przejdź wreszcie do sedna!”), przyjmę bardziej „holistyczne” podejście, mając nadzieję dostarczyć użytecznego tła, ale kosztem nieco dodatkowej lektury — i zagłębienia się w kilka zagadnień programistycznych, aby ułatwić zrozumienie. W [Część 2](/latex/pl/artykuly-szczegolowe/09-an-introduction-to-luatex-part-2-understanding-directlua.md) będziemy badać wykorzystanie `\directlua` ale na razie staramy się położyć podstawy do zrozumienia LuaTeX.

Ten artykuł silnie odzwierciedla osobistą „podróż” autora w rozwijaniu zrozumienia i docenienia LuaTeX: wiedząc najpierw coś o filozofii stojącej za rozwojem LuaTeX i widząc go jako kontener na narzędzia programowe, lepiej docenisz rozległe obszary rozwiązań otwierane przez to niesamowite oprogramowanie.

## LuaTeX: nie tylko dla świata akademickiego ani matematyki!

Bogactwo funkcji i możliwości wbudowanych w LuaTeX nie tylko zapewnia wyjątkowo wysoką jakość składu za pośrednictwem tradycyjnego LaTeX, ale także oferuje ogromne możliwości tworzenia niestandardowych rozwiązań, nieopartych na LaTeX, dla złożonych problemów produkcji i inżynierii dokumentów. LuaTeX ma wbudowany potężny język skryptowy Lua, co oznacza na przykład, że możesz używać Lua do ładowania „wtyczek” (zewnętrznych bibliotek oprogramowania) do LuaTeX; to dodatkowo umożliwia wysoki poziom automatyzacji, integrację z istniejącymi systemami oprogramowania lub przepływami pracy oraz wykorzystanie specjalistycznego oprogramowania do przetwarzania danych, tekstu lub grafiki.

Historycznie TeX był kojarzony z pisaniem i publikowaniem prac naukowych, zwłaszcza z matematyką, ale LuaTeX w szczególności ma znaczny potencjał zastosowań w wielu innych dziedzinach — w tym w komercyjnej produkcji dokumentów PDF. Jednym z takich przykładów jest [speedata publisher](https://speedata.github.io/publisher/) który używa LuaTeX wyłącznie jako silnika generowania PDF w swoim przepływie pracy opartym na XML — nie używa w ogóle LaTeX-a. Rzeczywiście, speedata publisher zawiera praktycznie żadnego kodu TeX — zapytałem [Patricka Gundlacha](https://twitter.com/patrickgundlach), twórcę speedata publisher, który potwierdził, że łącznie używa on około trzech linii kodu TeX. Jego potężne możliwości składu są zaprojektowane i zaimplementowane w kodzie Lua, z użyciem Lua API LuaTeX (temat ten omówimy później w tym artykule).

## Krótka osobista historia: Jak po raz pierwszy odkryłem LuaTeX

Po raz pierwszy dowiedziałem się o LuaTeX pod koniec 2009 / na początku 2010 roku, gdy był jeszcze w środkowej fazie beta (wersja 0.50). W tym czasie szukałem oprogramowania opartego na TeX, aby składać odręczne notatki wynikające z moich prób nauki arabskiego. Wyszukiwania Google ujawniły zbiór filmów z konferencji TUG 2009 ([obecnie na YouTube](https://www.youtube.com/playlist?list=PL2D4DD50DC9C0BA0E)) które zawierały demonstracje bardzo wysokiej jakości składu arabskiego (za pośrednictwem Hansa Hagena [pakiet ConTeXt](http://wiki.contextgarden.net/Main_Page)). Filmy te obejmowały też wykład zatytułowany [Projekt LuaTeX: w połowie drogi do wersji 1](https://youtu.be/AKv4po9PGW0).

Silnikiem TeX używanym do tworzenia tego przepięknego składu arabskiego było coś, co nazywało się „LuaTeX”. W tym czasie pracowałem w publikacjach naukowych (fizyka), ale choć dobrze znałem TeX/LaTeX, nie słyszałem o LuaTeX: byłem zaintrygowany i chciałem dowiedzieć się więcej o tym nowym silniku TeX. Ponieważ LuaTeX był wciąż na etapie rozwoju beta i rozwijał się bardzo szybko, chciałem być na bieżąco z najnowszymi aktualizacjami, więc najlepszą opcją (dla mnie) było podejście „zrób to sam” polegające na zbudowaniu (skompilowaniu) pliku wykonywalnego LuaTeX z kodu źródłowego. Oprócz samego programu wykonywalnego LuaTeX potrzebujesz także „instalacji TeX”, aby zapewnić środowisko do uruchamiania LuaTeX (np. texmf.cnf, pakiety makr, fonty itd.). Zamiast pobierać i instalować ogromną [TeX Live](https://www.tug.org/texlive/) dystrybucję wybrałem absolutnie minimalną, niestandardową instalację TeX, z którą miałem eksplorować LuaTeX (to „interesujące” ćwiczenie, które [udokumentowałem na swoim osobistym blogu](http://www.readytext.co.uk/?cat=30)). Każdemu nowemu wydaniu LuaTeX towarzyszy jego podręcznik referencyjny (np. dla[wersji 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)) który dokumentuje najnowsze funkcje i możliwości oprogramowania. Jednakże jest to *podręcznik* referencyjny i (z konieczności) dość skąpy w wyjaśnieniach odpowiednich dla początkującego, który chciałby zacząć pracę z tym niesamowitym silnikiem TeX — zakłada się pewien stopień znajomości niskopoziomowych pojęć TeX. Ponieważ odkryłem LuaTeX na stosunkowo wczesnym etapie jego rozwoju, dobre materiały wprowadzające były w tamtym czasie dość trudne do znalezienia, więc zanim elementy zaczęły układać się w całość, trochę czasu zajęły mi poszukiwania, eksperymenty (i trochę frustracji…). Nie trzeba dodawać, że moje studia nad arabskim nagle stanęły, gdy zafascynowałem się tym niesamowitym oprogramowaniem i ostatecznie przeszedłem do pisania LuaTeX [wtyczek do składu arabskiego](http://www.readytext.co.uk/?p=3143) zamiast tego!

Moja własna „podróż z LuaTeX” była z pewnością bardzo nieliniowa, ale po drodze dała mi możliwość poznania (Lua)TeX-a (i instalacji TeX-a) „od podstaw”: mój blog zawiera eklektyczny zbiór [artykułów](http://www.readytext.co.uk/?cat=3) wpisów opartych na różnych tematach, które eksplorowałem i nad którymi pracowałem w tym czasie. Mam nadzieję, że ten artykuł właściwie wykorzystuje ten czas i doświadczenie, pomagając innym zainteresować się rozpoczęciem odkrywania możliwości LuaTeX. LuaTeX jest nadal rozwijany i w chwili pisania tego tekstu osiągnął wersję 1.0.4, wydaną wraz z TeX Live 2017. Twórcy są bardzo aktywni, a wszelkie wykryte błędy są zwykle naprawiane wkrótce po zgłoszeniu — np. za pośrednictwem [listy mailingowej dev-luatex](https://mailman.ntg.nl/mailman/listinfo/dev-luatex) lub za pośrednictwem [internetowego trackeru błędów LuaTeX](http://tracker.luatex.org/my_view_page.php). Na długo przed osiągnięciem wersji 1.0 LuaTeX nadawał się do produkcji — choć oczywiście trzeba było zaakceptować, że funkcje stale się rozwijały i od czasu do czasu zmiany mogły psuć istniejący kod TeX. Dziś LuaTeX jest oczywiście wspierany przez platformy Overleaf i ShareLaTeX (jako LuaLaTeX).

## TeX w zmieniającym się świecie: nowe technologie i przepływy pracy

Oczywiście silniki TeX nie działają w technologicznie statycznym świecie i czasami pojawiają się innowacje, które są natychmiastowymi i oczywistymi kandydatami do włączenia do silników TeX — jedną z takich innowacji są zmienne fonty OpenType, o których krótko mówimy poniżej. Chociaż nie ma prawie wątpliwości, że oprogramowanie do składu oparte na TeX jest niezwykle wszechstronne, silniki TeX działają dziś w szybko zmieniającym się i bardzo zróżnicowanym ekosystemie oprogramowania — nowe przepływy pracy podkreślają potrzebę integracji i elastyczności umożliwiającej wdrażanie szerokiego zakresu rozwiązań dokumentowych/składowych, z których TeX może być tylko jednym komponentem.

TeX musi nie tylko pozostać istotny dla obecnych użytkowników, ale także przyciągać nowych, umożliwiając rozwiązania do tworzenia treści, które pozostaną użyteczne dla nadchodzących pokoleń — ludzi, którzy niekoniecznie chcą używać TeX jako samodzielnego narzędzia, lecz być może jako części większego przepływu pracy za pośrednictwem internetowych platform współpracy, takich jak Overleaf.

Nawet pobieżne przejrzenie [tex.stackexchange](https://tex.stackexchange.com/) pokazuje ogromną różnorodność dokumentów i rozwiązań tworzonych oraz wdrażanych za pomocą oprogramowania opartego na TeX — często z niezwykłą pomysłowością, gdy ludzie znajdują coraz to nowe przypadki użycia i typy treści, które chcą generować. Ponadto potrzeba przepływów pracy, które potrafią przetwarzać znacznik/treść opartą na TeX, aby tworzyć wyniki inne niż PDF (i inne niż DVI) — takie jak MathML/XML i HTML — nigdy nie była większa. Na przykład „konwertowanie” TeX do [JATS XML](https://jats.nlm.nih.gov/) formatu (od dawna używanego w publikowaniu czasopism naukowych), a ostatnio także wraz ze wzrostem znaczenia epub używanego w publikowaniu e-booków.

### Technologia zmiennych fontów — czasy się zmieniają

14 września 2016 r. 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/) i Apple ogłosiły nową technologię fontów: [zmienne fonty OpenType](https://medium.com/@tiro/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369). Nie będziemy tej technologii omawiać szczegółowo, ale wystarczy powiedzieć, że wysoko cenieni eksperci od fontów, tacy jak [Thomas Phinney](https://twitter.com/ThomasPhinney) i [John Hudson](https://twitter.com/TiroTypeworks) , zauważyli ([na Twitterze](https://twitter.com/ThomasPhinney/status/917087509342851072)) że technologia zmiennych fontów jest wdrażana znacznie szybciej niż wiele wcześniejszych innowacji fontowych — najprawdopodobniej napędzana potrzebami projektantów stron internetowych, którzy wymagają responsywnych projektów dostosowujących się do niezliczonych różnych rozmiarów i rozdzielczości ekranów spotykanych w urządzeniach mobilnych.

Oczywiście zmienne fonty OpenType są interesującym i ekscytującym rozwojem technologii fontów, z którego użytkownicy TeX-a niewątpliwie mogliby skorzystać — rzeczywiście, to pytanie nieuchronnie zostało [poruszone na tex.stackexchange](https://tex.stackexchange.com/questions/355104/tex-luatex-xetex-fontspec-support-for-opentype-variable-fonts) a wsparcie LuaTeX omówiono na liście mailingowej LuaTeX [mailingowej](https://www.tug.org/pipermail/luatex/2016-September/006204.html).

Nawiasem mówiąc, warto zauważyć, że technologia fontów oparta na „parametrycznym” tworzeniu fontów nie jest całkowicie nowym pomysłem: METAFONT Knutha i technologie Multiple Master firmy Adobe są w pewnym sensie ich wczesnymi poprzednikami, nawet jeśli szczegóły implementacji są dość różne.

### Zmiennne fonty: kiedy ich chcemy — teraz?

Każdy nowy i użyteczny standard/specyfikacja technologiczna potrzebuje czasu, by „wrosnąć” w swój docelowy ekosystem twórców i implementatorów — w tym czasu na dopracowanie wszelkich niejasności lub interpretacji sformułowań w samej specyfikacji. Twórcy muszą przeczytać i zrozumieć dokumentację, a następnie przekształcić ją w prawdziwe działające oprogramowanie — co tutaj obejmuje tworzenie fontów i technologii do ich używania: kompatybilnych przeglądarek i silników składu. Twórcy TeX będą wyraźnie potrzebowali dostępu do wysokiej jakości zmiennych fontów, które mogą służyć jako wiarygodne „punkty odniesienia” do wdrażania (programowania) obsługi technologii zmiennych fontów.

Implementacja każdej nowej technologii w TeX, takiej jak zmienne fonty, rodzi *potencjalną* potrzebę modyfikacji wnętrza silników TeX — oczywiście potrzeba ta zależy od natury tej technologii i, co kluczowe, od tego, jaki aspekt zachowania TeX ma ulec zmianie. Nie zawsze trzeba modyfikować same silniki TeX; być może wystarczą zmiany w oprogramowaniu wspierającym/pomocniczym, w tym w wszelkich „komponentach” (bibliotekach kodu firm trzecich) używanych w tych programach. Wewnętrznie silniki TeX są *szalenie* złożone — opracowanie zrozumienia kodu źródłowego TeX na tyle, by móc wprowadzać niezawodne modyfikacje, wymaga znacznej i bardzo specjalistycznej wiedzy (której zasób jest bardzo ograniczony). Niezbędne jest również, aby wszelkie modyfikacje nie wpływały niekorzystnie na długoterminową stabilność/zgodność silników TeX — co jest kluczowe dla społeczności TeX i dla tych, którzy później przetwarzają plik(i) (La)TeX autora: przede wszystkim wydawców akademickich oraz usługi chmurowe takie jak Overleaf i ShareLaTeX.

Wielu użytkowników TeX-a prawdopodobnie będzie zainteresowanych wykorzystaniem zmiennych fontów; na przykład wdrażaniem nowych możliwości projektowych lub znajdowaniem rozwiązań trudnych problemów składu. Zatem w pewnym sensie mamy dylemat: użytkownicy TeX-a chcą dostępu do nowej technologii, ale jej implementacja zależy od bardzo ograniczonego zasobu: liczby programistów wykwalifikowanych i zdolnych, by to urzeczywistnić. Modyfikowanie wnętrza TeX jest trudne i zasadniczo należy go unikać, gdzie tylko możliwe, więc czy istnieje inny sposób podejścia do dodawania (pewnych klas) nowych funkcji/możliwości do TeX? Tak! I LuaTeX obrał właśnie tę drogę.

#### Wczesne eksperymenty: zmienne fonty OpenType i LuaTeX

Projekt LuaTeX umożliwił szybkie eksperymenty z technologią zmiennych fontów. Już w kwietniu 2017 r. format TeX ConTeXt, używający LuaTeX, miał [wersję beta](https://mailman.ntg.nl/pipermail/ntg-context/2017/088343.html) implementującą zmienne fonty OpenType. Było to możliwe, ponieważ obsługa fontów w ConTeXt jest zbudowana w kodzie Lua (a ConTeXt ma własny fontloader napisany w Lua).

## LuaTeX: tło i historia

LuaTeX jest, w terminach TeX, „nowym dzieciakiem na bloku”, mimo że jest rozwijany aktywnie od ponad 10 lat. Witryna LuaTeX [dokumentuje](http://www.luatex.org/roadmap.html) że LuaTeX rozpoczął życie w 2005 r., a (jak sądzę) aktywny i stały rozwój rozpoczął się w 2006 r. Ze względu na jego inherentną złożoność i staranność tych, którzy go zbudowali, LuaTeX naprawdę potrzebował 10 lat rozwoju, aby osiągnąć wersję 1.0, którą [ogłosili jego twórcy](https://mailman.ntg.nl/pipermail/dev-luatex/2016-September/005882.html) (Hans Hagen, Hartmut Henkel, Taco Hoekwater, Luigi Scarso) 27 września 2016 r.

W tym ogłoszeniu wydania znajduje się ważne stwierdzenie zasad:

> „Naszym głównym celem jest zapewnienie wariantu TeX, który pozwala na rozszerzenia użytkownika bez potrzeby dostosowywania wewnętrznych mechanizmów.”

To sformułowanie doskonale podsumowuje filozofię stojącą za rozwojem LuaTeX i wskazuje drogę, dzięki której oprogramowanie oparte na TeX może sprostać wyzwaniom, które już wymieniliśmy: przyjmowaniu nowych technologii i zachowywaniu znaczenia dla nowych pokoleń użytkowników.

Nadszedł czas, by odnieść się do drugiego pytania zawartego w podtytule tego artykułu: „co sprawia, że jest tak inny”. Badając znaczenie „...pozwala na rozszerzenia użytkownika bez potrzeby dostosowywania wewnętrznych mechanizmów” możemy lepiej zrozumieć istotę tego, co LuaTeX „wnosi do stołu”.

## LuaTeX: otwieranie „czarnej skrzynki” TeX-a

Oryginalny program TeX Knutha jest wspólnym przodkiem wszystkich współczesnych silników TeX używanych dziś, a LuaTeX jest w istocie najnowszym krokiem ewolucyjnym: wywodzi się z programu pdfTeX, lecz z dodatkiem kilku potężnych komponentów programowych, które zapewniają mu wiele dodatkowej funkcjonalności. Kiedy Knuth pisał oryginalną wersję oprogramowania TeX, udostępnił również język TeX jako sposób sterowania i programowania jego zachowania podczas składu: użytkownikom i twórcom pakietów makr TeX udostępniono około 320 niskopoziomowych poleceń (prymitywów). Polecenia te oferowały różny stopień kontroli lub wpływu na niektóre aspekty zachowania TeX podczas składu, ale znaczną część wewnętrznej funkcjonalności, algorytmów, procesów decyzyjnych, danych i struktur danych TeX ukryto przed użytkownikiem. Można argumentować, że program TeX Knutha nie był całkowicie „czarną skrzynką”, ale z pewnością był bardzo ciemnym odcieniem szarości — trzeba przyznać, że kod źródłowy był dostępny, lecz dla zdecydowanej większości ludzi i to jest czarna skrzynka niezrozumiałości.

Wewnętrzne procesy w TeX można zatem uznać za swego rodzaju „czarną skrzynkę”; jednak LuaTeX otwiera swoje wnętrze oparte na TeX, zapewniając użytkownikom/twórcom znacznie większy dostęp do wielu niegdyś ukrytych procesów zachodzących głęboko wewnątrz silnika TeX. LuaTeX dodaje również wiele nowych poleceń prymitywnych, które zapewniają kontrolę nad nowymi funkcjami.

### LuaTeX: wywodzi się z pdfTeX, ale nie używa kodu pdfTeX

Dla zachowania dokładności ważne jest zaznaczenie, że choć opisaliśmy LuaTeX jako wywodzący się z pdfTeX, LuaTeX nie używa bezpośrednio oryginalnego kodu programu pdfTeX. Jeden z twórców LuaTeX (Taco Hoekwater) podjął naprawdę *herkulowskie* zadanie przepisania głównego silnika TeX LuaTeX na czysty, nowoczesny kod C (CWEB).

#### Uwaga historyczna

Po części ze względu na wiek oryginalnego kodu źródłowego TeX Knutha — z którego wywodzą się jego współczesne potomki — modyfikowanie go w celu dostosowania lub tworzenia nowych silników składu opartych na TeX jest procesem złożonym i zawiłym. Częścią tego procesu jest konwersja kodu Pascal na kod C — co nie jest pozbawione [pewnego stopnia złożoności](http://www.readytext.co.uk/?p=2529). Powstały w ten sposób automatycznie wygenerowany kod C jest niezwykle rozwlekły i bardzo trudny do czytania lub zrozumienia. Jasne jest, że całkowite przepisanie kodu LuaTeX omija cały proces konwersji z Pascal na C.

## Klocki budujące LuaTeX

We wprowadzeniu odwołaliśmy się do LuaTeX jako do „zestawu narzędzi” i opisaliśmy go jako „system konstruowania dokumentów i inżynierii dokumentów”. Widzieliśmy, że w ogłoszeniu LuaTeX 1.0 jego twórcy stwierdzili:

> „Naszym głównym celem jest zapewnienie wariantu TeX, który pozwala na rozszerzenia użytkownika bez potrzeby dostosowywania wewnętrznych mechanizmów.”

Nadszedł czas, by zebrać te wątki i skoncentrować się na szczegółach tego, co to wszystko *tak naprawdę oznacza* w praktyce.

### Układanka LuaTeX

Gdyby zajrzeć „pod maskę”, zobaczylibyśmy, że oprogramowanie LuaTeX, czyli faktyczny program wykonywalny, jest zbudowane z zestawu komponentów programowych, które połączono ze sobą, aby zapewnić ogólną funkcjonalność LuaTeX. Oczywiście nie jest to nic nowego i większość oprogramowania jest tak konstruowana. Tym, co odróżnia LuaTeX od innych silników TeX, jest jednak to, że komponenty te połączono w taki sposób, iż użytkownikom zapewnia się znacznie większy dostęp do wielu aspektów wewnętrznej funkcjonalności TeX: algorytmów składu, procesów decyzyjnych, danych i struktur danych TeX. To otwarcie wnętrza TeX umożliwia użytkownikom konstruowanie nowych rozwiązań składu bez potrzeby modyfikowania samego silnika TeX.

### Lua w LuaTeX: klucz do „czarnej skrzynki”

Lua jest bardzo potężnym, a jednocześnie łatwym do nauczenia językiem skryptowym, który [pochodzi z Brazylii](https://www.lua.org/about.html)—powstał w 1993 r. i nadal jest aktywnie rozwijany. Jedną z mocnych stron Lua jest jego użycie jako języka programowania, za pomocą którego można „skleić” ze sobą różne komponenty programowe, pozwalając używać ich poprzez prosty, lecz wszechstronny język skryptowy. Lua odgrywa centralną rolę w otwieraniu wewnętrznych mechanizmów silnika TeX LuaTeX, ale aby lepiej zrozumieć, jak to się odbywa, warto zrobić mały objazd i bardzo krótko omówić dwa pojęcia programistyczne:

* Interfejs programowania aplikacji (API);
* wiązanie językowe.

Śmiało pomiń ten fragment, jeśli jesteś z tymi pojęciami obeznany. Żaden z tematów nie będzie omówiony szczegółowo — nie dążymy do ścisłej technicznej rygorystyczności, lecz chcemy dostarczyć jedynie tyle tła, by znać te pojęcia: ich znaczenie i związek z LuaTeX.

### Interfejs programowania aplikacji (API)

Wyobraź sobie, że jesteś programistą, który napisał kod, który użytkownicy (inni programiści) mogą uznać za użyteczny, ale twój kod jest złożony i nie chcesz, by użytkownicy twojego kodu musieli martwić się o te niskopoziomowe szczegóły. Zauważ, że ci programiści/twórcy pracują w tym samym języku programowania, którego użyłeś do napisania swojego kodu. Ponadto załóżmy, że planujesz przepisać niektóre części swojego kodu — np. aby był szybszy, wymagał mniej pamięci i tak dalej. Istniejący użytkownicy twojego kodu nie powinni się tym martwić: wszelkie zmiany, które planujesz wprowadzić, nie powinny psuć ich programów. Jaka jest więc odpowiedź?

Odpowiedź leży w czymś zwanym API: jest to *interfejs programowania aplikacji*. Zamiast wymagać od użytkowników (innych programistów), by sięgali do niskopoziomowych szczegółów twojego kodu — które mogą się zmieniać — udostępniasz określony zestaw *funkcji* których inni programiści mogą używać. Te funkcje stanowią *interfejs* do twojego kodu, poprzez który inni twórcy mogą budować *aplikacje* bez potrzeby intymnej znajomości wewnętrznych mechanizmów twojego programu. W pewnym sensie można o tym myśleć jak o dodatkowej warstwie otaczającej twój kod i „izolującej” użytkowników od nieporządnych, niskopoziomowych szczegółów.

Pod warunkiem, że nie zmieniasz tych funkcji (interfejsu), możesz swobodnie modyfikować i aktualizować niższopoziomowe szczegóły swojego oprogramowania bez wpływu na pracę tych, którzy polegają na twoim kodzie przy tworzeniu swoich aplikacji (bez ich psucia): stąd termin interfejs programowania aplikacji.

#### API: analogia z pakietem LaTeX

Gdy używasz poleceń dostarczanych przez pakiet LaTeX, możesz traktować polecenia pakietu jako formę API. Jako użytkownik niekoniecznie interesujesz się magią TeX i LaTeX stojącą za tymi poleceniami (tj. w kodzie pakietu): chcesz po prostu korzystać z funkcjonalności, którą zapewniają.

### Wiązanie języka programowania

Widzieliśmy, że programiści piszący/publikujący zbiór użytecznego kodu (zwany *biblioteką*) mogą udostępnić tzw. interfejs programowania aplikacji (zbiór funkcji), poprzez który inni programiści, używający *tego samego* języka programowania, mogą korzystać z tej biblioteki (zbioru kodu). To jest w porządku, gdy obie strony (twórca biblioteki i jej użytkownicy) używają *tego samego* języka programowania, ale co się dzieje, jeśli programiści używający *innego* języka programowania również chcą korzystać z tej biblioteki? Na przykład możesz pisać skrypty w języku Lua, ale chcieć korzystać z biblioteki napisanej np. w językach programowania takich jak C/C++. W jakiś sposób oba różne języki programowania (Lua i C/C++) potrzebują możliwości „komunikowania się” ze sobą. Jednym z rozwiązań tego problemu jest tzw. [wiązanie językowe](https://en.wikipedia.org/wiki/Language_binding).

Zbadanie technicznych szczegółów wiązania językowego wykracza poza zakres tego artykułu, więc przedstawimy zwięzłe podsumowanie ogólnych zasad. W istocie, dodając odpowiednią dodatkową „warstwę” kodu do oryginalnej biblioteki, może ona „komunikować się” z innym językiem programowania (takim jak Lua): ta warstwa kodu nazywa się *wiązaniem*. Umożliwia ono współdziałanie obu języków za pośrednictwem API, które programiści w drugim języku (np. Lua) mogą wykorzystywać do dostępu do funkcji/usług oferowanych przez bibliotekę.

![Schemat pokazujący pojęcie wiązania językowego.](/files/6a05af99862fecb55693c0b26cdd9d9104f797ee)

**Rysunek 1**: Schemat pokazujący pojęcie wiązania językowego: umożliwienie programowi napisanemu w Lua korzystania z zewnętrznej biblioteki napisanej w innym języku programowania. To właśnie dzięki użyciu wiązań Lua internalne komponenty LuaTeX, a więc i znaczna część wewnętrznej funkcjonalności składu LuaTeX, stają się dostępne dla użytkowników tworzących rozwiązania dla złożonych problemów składu.

## LuaTeX: dwie opcje programowania — TeX i Lua

W istocie LuaTeX jest silnikiem TeX, który obsługuje dwa języki programowania: tradycyjny język oparty na TeX oraz język skryptowy Lua. Oczywiście można używać obu języków w tym samym dokumencie TeX albo, jeśli wolisz, nadal składać wyłącznie w „świecie TeX”: na przykład za pośrednictwem pakietu makr LaTeX (LuaLaTeX). TeX (lub LaTeX) nie jest łatwym językiem programowania do używania ani nauki, a stosunkowo niewiele osób naprawdę opanowało wiele osobliwości TeX-a — pojęcia TeX-a dotyczące [tokeny](https://www.overleaf.com/blog/522-what-is-a-tex-token) i ekspansji są dość obce większości oczekiwań i doświadczeń związanych z językiem programowania.

Dodanie Lua otwiera możliwość korzystania ze składu opartego na TeX za pośrednictwem znacznie bardziej przystępnego i konwencjonalnego języka programowania — jak zauważono na początku tego artykułu, używając Lua API można wykonywać [zaawansowany skład praktycznie bez kodu TeX](http://wiki.luatex.org/index.php/TeX_without_TeX).

### LuaTeX dodaje wiele nowych prymitywów

Każdy silnik TeX udostępnia setki tzw. poleceń prymitywnych: podstawowych cegiełek języka opartego na TeX obsługiwanego przez każdy pojedynczy silnik składu. Oryginalna wersja TeX wydana przez Donalda Knutha dostarczyła około 320 poleceń, ale nowsze silniki TeX (pdfTeX, XeTeX i LuaTeX) dodały wiele nowych prymitywów, aby zapewnić użytkownikom dostęp do dodatkowych funkcji i możliwości każdego silnika. Znaczną liczbę nowych prymitywów LuaTeX dokumentuje jego [podręcznik referencyjny](https://www.tug.org/svn/texlive/tags/texlive-2017.1/Master/texmf-dist/doc/luatex/base/luatex.pdf?revision=44591\&view=co).

Wśród wielu nowych prymitywów wprowadzonych przez LuaTeX jest ten zwany `\directlua{...}` który jest bramą do korzystania z kodu Lua: uzyskiwania dostępu do wnętrza silnika LuaTeX, by budować zaawansowane narzędzia i rozwiązania składu.

### \directlua{...}: Brama do programowania w Lua

Jak omówiono, język skryptowy Lua można postrzegać jako zapewniający „warstwę”, poprzez którą możliwy jest dostęp do opartego na TeX silnika składu LuaTeX i funkcjonalności zapewnianej przez wiele komponentów, z których LuaTeX jest zbudowany. Język Lua jest także mechanizmem umożliwiającym rozszerzalność LuaTeX — dzięki możliwości Lua do ładowania specjalistycznych zewnętrznych bibliotek oprogramowania/kodu.

Łącznie interfejs Lua (zbiór funkcji opartych na Lua) udostępniany przez LuaTeX określa się jako jego *Lua API*: jest to „łącznik komunikacyjny” między wewnętrznym silnikiem/komponentami LuaTeX a dokumentem użytkownika.

### Prosty przykład \directlua{...}

Poniższe *niezwykle prosty* przykład nawet nie zaczyna ocierać się o powierzchnię góry lodowej możliwości. Służy on jednak do zademonstrowania podstawowej idei współdziałania między „sposobem TeX” a „sposobem Lua” uzyskiwania dostępu do parametrów TeX-a.

Zauważ, że:

* `\hsize` jest prymitywem TeX (poleceniem), który ustawia wartość wewnętrznego parametru określającego szerokość składanych wierszy — na przykład zazwyczaj ustawiasz go na odpowiednią wartość w `\vbox{...}`. `\hsize` jest tylko jednym z *wieloma* parametrów TeX, do których możesz uzyskać dostęp i/lub które możesz modyfikować kodem Lua.
* Uzyskiwanie dostępu do parametrów TeX to tylko jeden *maleńki* aspekt Lua API LuaTeX: jest tego o wiele więcej!

```latex

\documentclass{article}
\begin{document}
\let\\\relax % zdefiniuj na nowo znaczenie \\ aby uniknąć problemów z ekspansją
Oto bieżąca wartość {\ttfamily\string\hsize} (przez \LaTeX):
\the\hsize\par
\directlua{
% Pobierz bieżącą wartość \hsize za pomocą Lua API
local hs=tex.hsize
% Użyj funkcji Lua API, aby wypisać trochę
% kodu LaTeX i wartość \hsize
tex.print("Oto wartość {\\ttfamily\\string\\hsize}
zgłoszona przez kod Lua (w punktach skalowanych): ")
tex.print(hs.."\\par")
% Ustaw nową wartość \hsize za pomocą Lua API
tex.hsize="400pt" % lub użyj tex.hsize=400*65536 (w punktach skalowanych)
}%
% Po zakończeniu \directlua poproś LaTeX
% aby podał nam nową wartość \hsize
Oto wartość {\ttfamily\string\hsize} zgłoszona
przez \LaTeX{} po zakończeniu {\tt\string\directlua}:
\the\hsize\par
\end{document}
```

Oto obraz pokazujący wynik składu kodu LaTeX przez LuaTeX (powyżej):

![Wyniki uruchomienia LuaTeX](/files/8027d0bf7783660a9ae5cb223e1a6c88b11574e5)

Zauważ, że TeX-owa „sztuczka” `\let\\\relax` ma na celu uniknięcie problemów spowodowanych „ekspansją” kodu Lua przez LuaTeX: zagadnienie to krótko zaznaczamy poniżej.

### Korzystanie z kodu Lua

Istnieją dwie główne opcje używania kodu Lua w dokumentach TeX/LaTeX:

1. **Wbudowany**: Pisanie kodu Lua bezpośrednio w twoim `.tex` dokumencie (jak w przykładzie powyżej);
2. **Zewnętrzny**: Przechowywanie kodu Lua w zewnętrznych `.lua` plikach kodu i korzystanie z możliwości Lua do ich ładowania i uruchamiania.

Opcja (1) najlepiej nadaje się do krótszych fragmentów kodu Lua. Opcja (2) jest używana dla większych programów lub bibliotek kodu Lua. Ma ona wyraźną zaletę: można uniknąć kłopotliwych kwestii związanych z tak zwanymi `\catcode` wartościami (które mogą być „dość frustrujące”). Powodem tych `\catcode` problemów jest „ekspansja” kodu Lua przed przekazaniem go do wbudowanego interpretera Lua w LuaTeX. Ta ekspansja może być trudna do zrozumienia, więc przyjrzymy się jej bliżej w kolejnym artykule.

Oczywiście istnieją pakiety LaTeX, które pomagają w używaniu kodu Lua w plikach .tex — na przykład możesz użyć [pakietu luacode](https://ctan.org/pkg/luacode?lang=en).

## Podsumowanie i wprowadzenie do Części 2 tego artykułu

Komponenty oprogramowania, z których zbudowano LuaTeX, wraz z wbudowanym językiem skryptowym Lua, tworzą potężne połączenie do budowania rozwiązań zdolnych rozwiązywać szeroki zakres złożonych problemów składu — oraz projektowania przepływów pracy związanych z produkcją dokumentów, które mogą skorzystać na ścisłej integracji z opartym na TeX-ie silnikiem składu. W [Część 2 tego artykułu](/latex/pl/artykuly-szczegolowe/09-an-introduction-to-luatex-part-2-understanding-directlua.md) przyjrzymy się dogłębnie najpotężniejszemu poleceniu oferowanemu przez LuaTeX: `\directlua`.

Do tego czasu, miłego LuaTeXowania!

## Podziękowania

Autor jest niezwykle wdzięczny [Luigi Scarso](https://twitter.com/luigi_scarso), jednemu z twórców LuaTeX-a, za poświęcenie czasu na przeczytanie wersji roboczej tego artykułu i przekazanie wielu bardzo pomocnych uwag oraz sugestii. Wszelkie pozostałe błędy rzeczowe lub pominięcia są oczywiście autorstwa autora. Ponadto chciałbym podziękować [Patricka Gundlacha](https://twitter.com/patrickgundlach), twórcy [speedata publisher](https://speedata.github.io/publisher/), za poświęcony czas na odpowiedź na moje pytania.


---

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