Web2C to zestaw programów związanych z TeX-em, tj. sam TeX, metafont, METAPOST, BibTeX itp. Oryginalna implementacja wykonana została przez Tomasa Rokickiego, który w roku 1987 stworzył pierwszy system TeX-to-C, adaptując pliki wymiany (change files) pod Unix-em (pierwotnie były one dziełem Howarda Trickey’a oraz Pavela Curtisa). W czasie gdy Tim Morgan zajmował się systemem, jego nazwa została zmieniona na Web-to-C. W 1990 roku prace nad projektem przejął Karl Berry wraz z dziesiątkami współpracowników, a w roku 1997 pałeczkę przejął Olaf Weber.
Web2C działa na platformach systemowych takich jak Unix (w tym Mac OS X), Windows 9x/NT/2K/XP i innych. System wykorzystuje oryginalne źródła TeX-owe autorstwa Donalda Knutha oraz inne programy napisane w web i tłumaczy je na kod źródłowy C. Ponadto system udostępnia spory zestaw makr i funkcji stworzonych dla zwiększenia funkcjonalności oryginalnych zasobów oprogramowania związanego z TeX-em. Podstawowymi składnikami systemu są:
Dokładny opis funkcji oraz składni tych programów zawarty jest w dokumentacji poszczególnych pakietów samego Web2C. Jednak do optymalnego wykorzystania instalacji Web2C pomocna będzie znajomość kilku zasad rządzących całą rodziną programów.
Wszystkie programy obsługują standardowe opcje GNU:
W celu lokalizacji plików programy Web2C używają biblioteki do przeszukiwania ścieżek zwanej Kpathsea. Dla optymalizacji przeszukiwania TeX-owego drzewa podkatalogów biblioteka ta używa kombinacji zmiennych środowiskowych oraz kilku plików konfiguracyjnych. Web2C potrafi obsługiwać jednocześnie więcej niż jedno drzewo podkatalogów, co jest użyteczne w przypadku, gdy chce się przechowywać standardową dystrybucję TeX-a jak i lokalne rozszerzenia w dwóch różnych drzewach katalogów. Aby przyspieszyć poszukiwanie plików, katalog główny każdego drzewa ma swój plik ls-R, zawierający pozycje określające nazwę i względną ścieżkę dla wszystkich plików zawartych w tym katalogu.
Opiszemy najpierw ogólny mechanizm przeszukiwania ścieżek przez bibliotekę Kpathsea.
Tym, co nazywamy ścieżką przeszukiwania jest, rozdzielona dwukropkami lub średnikami, lista elementów ścieżki, które zasadniczo są nazwami podkatalogów. Ścieżka przeszukiwania może pochodzić z (kombinacji) wielu źródeł. Przykładowo, aby odnaleźć plik „my-file” w ścieżce „.:/dir”, Kpathsea sprawdza, czu istnieje dany element ścieżki w następującej kolejności: najpierw ./my-file, potem /dir/my-file, zwracając pierwszy odnaleziony (lub możliwie wszystkie).
Aby optymalnie zaadaptować się do konwencji wszystkich systemów operacyjnych, na systemach nieunixowych Kpathsea może używać jako separatorów nazw ścieżek znaków innych niż dwukropek („:”) oraz „ciach” („/”).
W celu sprawdzenia konkretnego elementu p ścieżki, Kpathsea najpierw sprawdza, czy zbudowana wcześniej baza danych (patrz „Baza nazw plików” na stronie 72) odnosi sie do p, tj. czy baza danych znajduje się w podkatalogu z prefiksem p. Jeżeli tak, to specyfikacja ścieżki jest porównywana z zawartością bazy.
Jeśli baza danych nie istnieje, lub nie odnosi się do danego elementu ścieżki, albo nie zawiera elementów zgodnych, przeszukiwany jest system plików (jeżeli nie zostało to zabronione przez specyfikację rozpoczynającą się od „!!” oraz jeżeli poszukiwany plik musi istnieć). Kpathsea konstruuje listę podkatalogów, które korespondują z danym elementem ścieżki, a następnie sprawdza w każdym z nich, czy nie ma tam poszukiwanego pliku.
Warunek mówiący, że „plik musi istnieć” dotyczy np. plików „.vf” i plików dołączanych TeX-owym poleceniem \openin. Takiego pliku może nie być (np. cmr10.vf), błędne byłoby zatem poszukiwanie go na dysku. Jeśli więc zapomnisz o aktualizacji ls-R po instalacji nowego pliku „.vf”, nie zostanie on odnaleziony. Każdy element ścieżki sprawdzany jest w następującej kolejności: najpierw w bazie danych, potem na dysku. Jeżeli plik się znajdzie, przeszukiwanie zostanie zatrzymane i zwrócony zostanie wynik.
Ponieważ najprostszym i najbardziej powszechnym elementem ścieżki jest nazwa katalogu, Kpathsea korzysta z dodatkowych możliwości w przeszukiwaniu ścieżek: wielowarstwowych wartości domyślnych, zmiennych środowiskowych, wartości pliku konfiguracyjnego, lokalnych podkatalogów użytkownika oraz rekursywnego przeszukiwanie podkatalogów. Można więc powiedzieć, że Kpathsea rozwija element ścieżki, tzn. transformuje wszystkie specyfikacje do podstawowej nazwy lub nazw katalogów. Jest to opisane w kolejnych akapitach, w kolejności, w jakiej ma to miejsce.
Trzeba zauważyć, że jeżeli nazwa poszukiwanego pliku jest absolutna lub jawnie względna, tj. zaczyna się od „/” lub „./” lub „../”, Kpathsea ogranicza się do sprawdzenia, czy ten plik istnieje.
Nazwa przeszukiwanej ścieżki może pochodzić z wielu źródeł. Oto kolejność, w jakiej Kpathsea ich używa:
Każdą z tych wartości dla danej ścieżki przeszukiwania można zobaczyć, używając opcji diagnostyki błędów (patrz „Diagnostyka błędów” na stronie 80).
Kpathsea szuka ścieżek przeszukiwania i innych definicji w plikach konfiguracyjnych o nazwach texmf.cnf. Ścieżka przeszukiwania używana do znajdowania tych plików określana jest zmienną TEXMFCNF (domyślnie taki plik znajduje się w podkatalogu texmf/web2c). Czytane będą wszystkie pliki texmf.cnf w ścieżce przeszukiwania, a definicje we wcześniejszych plikach zastąpią te w późniejszych. Tak więc w ścieżce .:$TEXMF, wartości pochodzące z ./texmf.cnf zastąpią te z $TEXMF/texmf.cnf.
Dociekliwy czytelnik może być zainteresowany jak same programy znajdują plik texmf.cnf, skoro nie jest obowiązkowe deklarowanie specyficznej zmiennej środowiskowej systemu. Otóż położenie domyślne jest wkompilowane w programy jako względne do ich położenia (określanego, jak wiemy, w ścieżce specyfikowanej przez $PATH): ../../texmf/web2c/ bądź ../texmf/web2c/. Jeśli jawnie deklarujemy zmienną TEXMFCNF, wymagane jest podanie bezwzględnej ścieżki.
Czytając zamieszczony poniżej opis formatu pliku texmf.cnf warto przeglądać jego zawartość. Położenie aktywnego pliku znajdziemy za pomocą polecenia kpsewhich texmf.cnf.
Fragment pliku konfiguracyjnego ilustrujący większość powyższych cech pokazany jest poniżej:
Kpathsea rozpoznaje w ścieżkach przeszukiwania pewne specjalne znaki oraz konstrukcje, podobne do tych, dostępnych w powłokach Unixa. Jako ogólny przykład: złożona ścieżka ~$USER/{foo,bar}//baz rozwija się do wszystkich podkatalogów pod katalogami foo i bar w katalogu głównym $USER, które zawierają katalog lub plik baz. Rozwinięcia te opisane są w poniższych podrozdziałach.
Jeżeli ścieżka przeszukiwania największego uprzywilejowania (patrz „Źródła ścieżek” na stronie 66) zawiera dodatkowy dwukropek (np. na początku, na końcu lub podwójny) to Kpathsea wstawia w tym miejscu następną zdefiniowaną w hierarchii uprzywilejowania ścieżkę przeszukiwania. Jeżeli ta wstawiona ścieżka ma dodatkowy dwukropek, dzieje się dalej to samo. Przykładowo, jeżeli ustawić zmienną środowiskową
Ponieważ nieużytecznym byłoby wstawiać wartość domyślną w więcej niż jedno miejsce, Kpathsea zmienia tylko jeden dodatkowy „:” i pozostawia inne bez zmian; najpierw szuka dwukropków na początku linii, potem na końcu, a następnie podwójnych.
Użyteczną cechą jest możliwość rozwijania nawiasów, co oznacza, że np. v{a,b}w rozwija się do vaw:vbw. Możliwe jest zagnieżdżanie nawiasów. Funkcja ta może być użyta do zaimplementowania różnych hierarchii TeX-owych przez przypisanie listy nawiasów do $TEXMF. Przykładowo, w pliku texmf.cnf znaleźć można następującą definicję:
Używając jej można następnie napisać coś w rodzaju
co oznacza, że po szukaniu w katalogu bieżącym przeszukane będą kolejno $HOMETEXMF/tex, $TEXMFLOCAL/tex, $VARTEXMF/tex i $TEXMFMAIN/tex (wszystkie wraz z katalogami niższego poziomu; dwie ostatnie ścieżki wyłącznie na podstawie zawartości pliku ls-R). Jest to wygodny sposób dla uruchamiania dwóch równoległych struktur TeX-owych, jednej „zamrożonej” (np. na CD-ROM-ie), a drugiej ciągle uaktualnianej nowymi, pojawiającymi się wersjami. Używając zmiennej $TEXMF we wszystkich definicjach, jest się pewnym, że najpierw przeszukiwane jest drzewo uaktualnione.
Dwa lub więcej kolejnych „ciachów” („/”) w elemencie ścieżki, występujących po nazwie katalogu d, zastępowany jest przez wszystkie podkatalogi d: najpierw podkatalogi znajdujące się bezpośrednio pod d, potem te pod powyższymi i tak dalej. Na każdym etapie kolejność, w jakiej przeszukiwane są katalogi, jest nieokreślona.
Jeśli wyszczególni się człony nazwy pliku po „//”, uwzględnione zostaną tylko te podkatalogi, które zawierają powyższe człony. Na przykład „/a//b” rozwija się do katalogów /a/1/b, /a/2/b, /a/1/1/b itd., ale nie do /a/b/c czy /a/1.
Możliwe jest wielokrotne użycie „//” w ścieżce, jednakże „//” występujące na początku ścieżki nie jest brane pod uwagę.
Poniższa lista podsumowuje znaczenie znaków specjalnych w plikach konfiguracyjnych.
Dla celów przeszukiwania Kpathsea stara się zminimalizować dostęp do dysku. Niemniej jednak, w przypadku instalacji ze zbyt dużą liczbą katalogów, przeglądanie każdego możliwego katalogu w poszukiwaniu danego pliku może zabierać sporo czasu (ma to miejsce zwłaszcza, jeżeli przeszukać trzeba setki katalogów z fontami). Dlatego też Kpathsea może używać zewnętrznego pliku z „bazą danych” o nazwie ls-R, który to zawiera przypisania plików do katalogów. Unika się w ten sposób potrzeby wyczerpującego przeszukiwania dysku.
Drugi plik z bazą danych – aliases – pozwala na nadawanie dodatkowych nazw plikom zawartym w ls-R. Może to być pomocne do adaptacji do DOS-owej konwencji „8.3” nazewnictwa plików w plikach źródłowych.
Jak to wytłumaczono powyżej, plik zawierający główną bazę nazw plików musi nosić nazwę ls-R. W katalogu podstawowym każdej hierarchii TeX-owej (domyślnie $TEXMF), którą chcemy włączyć w mechanizm przeszukiwania, umieszczać można po jednym pliku ls-R; w większości przypadków istnieje tylko jedna hierarchia. Kpathsea szuka pliku ls-R w ścieżce TEXMFDBS.
Najlepszym sposobem stworzenia i utrzymywania pliku ls-R jest uruchomienie skryptu mktexlsr, będącego składnikiem dystrybucji. Jest on wywoływany przez różne skrypty typu „mktex...”. W zasadzie skrypt ten jedynie wykonuje polecenie
Jeśli pliku nie ma w bazie danych, Kpathsea domyślnie przechodzi do przeszukiwania dysku. Jeżeli jednak dany element ścieżki zaczyna sie od „!!”, w poszukiwaniu tego elementu sprawdzona zostanie jedynie baza danych, a nigdy dysk.
Przeszukiwanie ścieżek przez program kpsewhich jest niezależne od jakiejkolwiek aplikacji. Może on być przydatny jako rodzaj programu find, za pomocą którego lokalizować można pliki w hierarchiach TeX-owych (jest on używany intensywnie w skryptach „mktex...” tej dystrybucji).
Kpathsea traktuje każdy argument nie będący parametrem jako nazwę pliku i zwraca pierwszą odnalezioną nazwę. Nie ma parametru nakazującego zwracanie wszystkich nazw plików o określonej nazwie (w tym celu można wykorzystać Unix-owy program „find”).
Ważniejsze parametry opisane są poniżej.
Zmienne środowiskowe domyślnie ustawiane są w pliku konfiguracyjnym texmf.cnf. W wypadku gdy chce się unieważnić wartości zmiennych wyszczególnione w tym pliku, można narzucić ich ustawienie w środowisku, w którym uruchamiane są programy.
Zauważyć trzeba, że parametry „--format” oraz „--path” wzajemnie się wykluczają.
Przyjrzyjmy sie teraz jak działa Kpathsea.
Ostatni plik to BibTeX-owa baza bibliograficzna dla artykułów TUGBoat.
Zwrócimy teraz naszą uwagę na pliki nagłówkowe i konfiguracyjne programu dvips. Najpierw szukamy pliku PostScript-owego prologu tex.pro, wykorzystywanego dla potrzeb TeX-a. Drugi przykład pokazuje poszukiwanie pliku konfiguracyjnego config.ps, zaś trzeci – szukanie pliku mapy czcionek PostScriptowych psfonts.map. Jako, że rozszerzenie „.ps” nie jest jednoznaczne, musimy zaznaczyć wyraźnie jaki typ jest wymagany dla pliku config.ps („dvips config”).
Teraz przyjrzyjmy się bliżej plikom pomocniczym fontów Quasi Times (zawierają one m.in. poprawne polskie znaki diakrytyczne). Pierwszy plik, którego szukamy to plik konfiguracyjny, zawierający nazwę pliku z przemapowaniem fontów:
Powyższe przykłady pokazują, jak łatwo można znajdować lokalizację danego pliku. Ważne jest to zwłaszcza, gdy istnieje podejrzenie, że gdzieś zawieruszyła się zła wersja jakiegoś pliku; kpsewhich pokaże tylko pierwszy napotkany plik.
Czasami niezbędne są informacje o tym, jak program radzi sobie z odniesieniami do plików. Aby dało się to wykonywać w wygodny sposób, Kpathsea oferuje różne poziomy diagnostyki błędów:
Wartość -1 ustawia wszystkie powyższe opcje: w praktyce, potrzebując wykryć przyczyny błędów, prawdopodobnie zawsze używać będziesz tych poziomów.
Podobnie, w przypadku programu dvips, ustawiając kombinację przełączników wykrywania błędów, można dokładnie śledzić skąd pochodzą pliki. W wypadku gdy plik nie zostanie odnaleziony, widać, w których katalogach program szukał danego pliku, dzięki czemu można się zorientować w czym problem.
Ogólnie mówiąc, ponieważ programy odwołują się wewnętrznie do biblioteki Kpathsea, opcje wykrywania błędów wybrać można przy użyciu zmiennej środowiskowej KPATHSEA_DEBUG, ustawiając ją na opisaną powyżej wartość (kombinację wartości).
Uwaga dla użytkowników Windows: w systemie tym niełatwo jest przekierować komunikaty programu do pliku. Do celów diagnostycznych można w tym celu ustawić chwilowo zmienne (w oknie DOS/CMD):
Rozważmy na przykład mały LaTeX-owy plik źródłowy hello-world.tex, który zawiera co następuje:
Ten mały plik używa jedynie fontu cmr10. Przyjrzyjmy się jak dvips przygotowuje plik PostScript-owy (chcemy użyć wersji Type1 fontu Computer Modern, stąd opcja -Pcms).
debug:start search(file=texmf.cnf, must_exist=1, find_all=1,
path=.:/usr/local/bin/texlive:/usr/local/bin: /usr/local/bin/texmf/web2c:/usr/local: /usr/local/texmf/web2c:/.:/./teTeX/TeX/texmf/web2c:). kdebug:start search(file=ls-R, must_exist=1, find_all=1, path=~/tex:/usr/local/texmf). kdebug:search(ls-R) =>/usr/local/texmf/ls-R kdebug:start search(file=aliases, must_exist=1, find_all=1, path=~/tex:/usr/local/texmf). kdebug:search(aliases) => /usr/local/texmf/aliases kdebug:start search(file=config.ps, must_exist=0, find_all=0, path=.:~/tex:!!/usr/local/texmf/dvips//). kdebug:search(config.ps) => /usr/local/texmf/dvips/config/config.ps kdebug:start search(file=/root/.dvipsrc, must_exist=0, find_all=0, path=.:~/tex:!!/usr/local/texmf/dvips//). search(file=/home/goossens/.dvipsrc, must_exist=1, find_all=0, path=.:~/tex/dvips//:!!/usr/local/texmf/dvips//). kdebug:search($HOME/.dvipsrc) => kdebug:start search(file=config.cms, must_exist=0, find_all=0, path=.:~/tex/dvips//:!!/usr/local/texmf/dvips//). kdebug:search(config.cms) =>/usr/local/texmf/dvips/cms/config.cms
kdebug:start search(file=texc.pro, must\_exist=0, find\_all=0,
path=.:~/tex/dvips//:!!/usr/local/texmf/dvips//: ~/tex/fonts/type1//:!!/usr/local/texmf/fonts/type1//). kdebug:search(texc.pro) => /usr/local/texmf/dvips/base/texc.pro
kdebug:start search(file=cmr10.tfm, must\_exist=1, find\_all=0,
path=.:~/tex/fonts/tfm//:!!/usr/local/texmf/fonts/tfm//: /var/tex/fonts/tfm//). kdebug:search(cmr10.tfm) => /usr/local/texmf/fonts/tfm/public/cm/cmr10.tfm kdebug:start search(file=texps.pro, must\_exist=0, find\_all=0, ... <texps.pro> kdebug:start search(file=cmr10.pfb, must\_exist=0, find\_all=0, path=.:~/tex/dvips//:!!/usr/local/texmf/dvips//: ~/tex/fonts/type1//:!!/usr/local/texmf/fonts/type1//). kdebug:search(cmr10.pfb) => /usr/local/texmf/fonts/type1/public/cm/cmr10.pfb <cmr10.pfb>[1]
|
Program dvips zaczyna pracę od zlokalizowania potrzebnych mu plików. Najpierw znajduje plik texmf.cnf, który zawiera ścieżki przeszukiwania dla innych plików. Potem znajduje bazę danych ls-R (dla optymalizacji szukania plików), następnie plik aliases, który umożliwia deklarowanie różnych nazw (np. krótkie DOS-owe „8.3” i bardziej naturalne dłuższe wersje) dla tych samych plików. Następnie dvips znajduje podstawowy plik konfiguracyjny config.ps, zanim poszuka pliku z ustawieniami użytkownika .dvipsrc (który w tym wypadku nie zostaje odnaleziony). W końcu dvips lokalizuje plik konfiguracyjny config.cms dla fontów PostScript-owych Computer Modern (jest to inicjowane przez dodanie parametru -Pcms przy uruchamianiu programu). Plik ten zawiera listę plików z „mapami”, które definiują relacje pomiędzy TeX-owymi, PostScript-owymi i systemowymi nazwami fontów.
W tym miejscu dvips zgłasza się użytkownikowi:
Inną użyteczną cechą Web2C jest możliwość ustalania wielu parametrów określających wielkość pamięci za pomocą pliku texmf.cnf. Ustawienia wszystkich parametrów znajdują się w części trzeciej pliku. Najważniejszymi zmiennymi są:
Oczywiście, powyższa możliwość nie zastąpi prawdziwej, dynamicznej alokacji pamięci. Jest to jednak niezwykle trudne do zaimplementowania w obecnej wersji TeX-a i dlatego powyższe parametry stanowią praktyczny kompromis, pozwalając na pewną elastyczność.