6. Instrukcja obsługi systemu Web2c

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. Ostatnim rezultatem jest Web2c w wersji 7.3, udostępniony w marcu 1999 roku, stanowiący podstawę niniejszej płyty CD-ROM TeX Live.

Web2c 7.3 działa na platformach systemowych takich jak Unix, Windows 3.1, 9x/NT, DOS, Amiga 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ą:

bibtex
tworzenie spisów bibliograficznych;
dmp
konwersja troff do MPX (rysunki METAPOST-owe);
dvicopy
modyfikowanie pliku DVI;
dvitomp
konwersja DVI do MPX (rysunki METAPOST-owe);
dvitype
konwersja DVI na plik tekstowy (ASCII);
gftodvi
zamiana fontu GF na plik DVI;
gftopk
zamiana fontów w formacie GF na font spakowany PK;
gftype
zamiana fontu GF na plik tekstowy (ASCII);
makempx
skład etykiet METAPOST-owych;
mf
generowanie fontów bitmapowych w formacie GF;
mft
skład plików źródłowych Metafont-a;
mpost
tworzenie rysunków oraz diagramów technicznych;
mpto
ekstrakcja etykiet METAPOST-owych;
newer
porównywanie czasów modyfikacji;
patgen
tworzenie wzorców przenoszenia wyrazów;
pktogf
zamiana fontów w formacie PK na fonty GF;
pktype
zamiana fontu PK na plik tekstowy (ASCII);
pltotf
konwersja tekstowej listy właściwości do TFM;
pooltype
wyświetlanie web-owych plików pool;
tangle
konwersja web do języka Pascal;
tex
skład tekstu;
tftopl
konwersja TFM do tekstowej listy właściwości (PL);
vftovp
konwersja fontów wirtualnych do wirtualnej listy właściwości (VPL);
vptovf
konwersja wirtualnej listy właściwości do fontów wirtualnych;
weave
konwersja web do TeX-a.

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:

–help   
podaje podstawowe zasady użytkowania;
–verbose
podaje dokładny raport z działania programu;
–version
podaje informację o wersji, po czym kończy działanie programu.

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 w wersji 7.3 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.

6.1. Przeszukiwanie ścieżek przez Kpathsea

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ł. Aby odnaleźć plik „my-file” w ścieżce „.:/dir”, Kpathsea sprawdza każdy 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 37) 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.

6.1.1 Źródła ścieżek

Nazwa przeszukiwanej ścieżki może pochodzić z wielu źródeł. Oto kolejność, w jakiej Kpathsea ich używa:

  1. Zmienna środowiskowa ustawiana przez użytkownika, np. TEXINPUTS. Zmienne środowiskowe z dołączoną kropką i nazwą programu zastępują inne, np. jeżeli „latex” jest nazwą uruchomionego programu, wtedy zamiast TEXINPUTS wykorzystana zostanie zmienna TEXINPUTS.latex.
  2. Plik konfiguracyjny konkretnego programu, np. linia „S /a:/b” w pliku config.ps programu dvips.
  3. Plik konfiguracyjny Kpathsea texmf.cnf, zawierający taką linię, jak „TEXINPUTS=/c:/d” (patrz poniżej).
  4. Wartości domyślne dla uruchamianych programów.

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

6.1.2 Pliki konfiguracyjne

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.

Czytając zamieszczony poniżej opis formatu pliku texmf.cnf proszę także porównać treść załącznika A, który zaczyna się na stronie 56, i w którym przedstawiono zawartość pliku texmf.cnf niniejszej dystrybucji.

Fragment pliku konfiguracyjnego ilustrujący większość powyższych cech pokazany jest poniżej:


  TEXMF              = {$TEXMFLOCAL;!!$TEXMFMAIN}
  TEXINPUTS.latex    = .;$TEXMF/tex/{latex;generic;}//
  TEXINPUTS.fontinst = .;$TEXMF/tex//;$TEXMF/fonts/afm//
  % e-TeX related files
  TEXINPUTS.elatex   = .;$TEXMF/{etex;tex}/{latex;generic;}//
  TEXINPUTS.etex     = .;$TEXMF/{etex;tex}/{eplain;plain;generic;}//

6.1.3 Rozwijanie ścieżek

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 bar w katalogu głównym $USER, które zawierają katalog lub plik baz. Rozwinięcia te opisane są w poniższych podrozdziałach.

6.1.4 Rozwijanie domyślne

Jeżeli ścieżka przeszukiwania największego uprzywilejowania (patrz „Źródła ścieżek” na stronie 33) 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ą


>> setenv TEXINPUTS /home/karl:
oraz wartość TEXINPUTS pobraną z texmf.cnf


  .:$TEXMF//tex
końcową wartością użytą w przeszukiwaniu będzie:


  /home/karl:.:$TEXMF//tex

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.

6.1.5 Rozwijanie nawiasów

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ę:


    TEXMF = {$HOMETEXMF,$TEXMFLOCAL,!!$VARTEXMF,!!$TEXMFMAIN}

Używając jej można następnie napisać coś w rodzaju


    TEXINPUTS = .;$TEXMF/tex//

co oznacza, że po szukaniu w katalogu bieżącym przeszukane będą kolejno tylko $HOMETEXMF/tex, $TEXMFLOCAL/tex, $VARTEXMF/tex $TEXMFMAIN/tex (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.

6.1.6 Rozwijanie podkatalogów

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ę.

6.1.7 Lista znaków specjalnych i ich znaczeń – podsumowanie

Poniższa lista podsumowuje znaczenie znaków specjalnych w plikach konfiguracyjnych.

:
znak rozdzielający w specyfikacji ścieżki; umieszczony na początku lub na końcu ścieżki zastępuje domyślne rozwinięcie ścieżki;
;
znak rozdzielający dla systemów nieUnix-owych (działa tak jak :);
$
rozwijanie zmiennej;
~
oznacza katalog główny użytkownika;
{...}
rozwijanie nawiasów, np. a{1,2}b zmieni się w a1b:a2b;
//
rozwijanie podkatalogów (może wystąpić gdziekolwiek w ścieżce, poza jej początkiem);
%
początek komentarza;
\
znak kontynuacji (pozwala na przełamanie wiersza z wyrażeniem);
!!
przeszukiwanie tylko bazy danych, a nie dysku.

6.2. Bazy nazw plików

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.

6.2.1 Baza nazw plików

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


cd /your/texmf/root  && ls -LAR ./ >ls-R
zakładając, że polecenie ls danego systemu utworzy właściwy format strumienia wyjściowego (GNU ls działa prawidłowo). Aby mieć pewność, że baza danych jest zawsze aktualna, wygodnie jest przebudowywać ją regularnie za pomocą demona cron.

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.

6.2.2 kpsewhich – program do przeszukiwania ścieżek

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


>> kpsewhich opcje ... nazwa-pliku ...
Parametry wyszczególnione w „opcje ” mogą zaczynać się zarówno od „-” jak i od „–”, i dozwolony jest każdy jednoznaczny skrót.

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.

–dpi=num
Ustaw rozdzielczość na „num ”; ma to tylko wpływ na przeszukiwanie fontów „gf” i „pk”. Dla zgodności z dvips parametr „-D” działa identycznie. Domyślną wartością jest 600.
–format=nazwa
Ustawienie formatu (typu pliku) przeszukiwania na „nazwa ”. Domyślnie format odgadywany jest z nazwy pliku. Dla formatów, które nie mają przydzielonego jednoznacznego rozszerzenia, takich jak niektóre pliki METAPOST-owe, czy pliki konfiguracyjne dvips-a, należy wyszczególnić nazwę, którą znaleźć można w pierwszej kolumnie tabeli 1. Zawiera ona spis aktualnie rozpoznawanych nazw, opis, przypisane zmienne środowiskowe1, oraz możliwe rozszerzenia nazw.


Tabela 1Typy plików Kpathsea
Nazwa
Opis
Zmienne
Rozszerzenia








afm
Metryki czcionek Adobe
AFMFONTS
.afm
base
Bazy (formaty) Metafont-a
MFBASES, TEXMFINI
.base
bib
Źródła bibliograficzne BIBTeX-a
BIBINPUTS, TEXBIB
.bib
bst
Pliki stylu BIBTeX
BSTINPUTS
.bst
cnf
Pliki konfiguracyjne
TEXMFCNF
.cnf
dvips config
Pliki konfiguracyjne dvips-a, np. config.ps i psfonts.map
TEXCONFIG
.map
fmt
Formaty TeX-a
TEXFORMATS, TEXMFINI
.fmt, .efmt, .efm
gf
fonty GF (bitmapowe)
FONTS, GFFONTS, GLYPHFONTS, TEXFONTS
.gf
graphic/figure
Rysunki w formacie EPS
TEXPICTS, TEXINPUTS
.eps, .epsi
ist
Pliki stylów makeindex
TEXINDEXSTYLE, INDEXSTYLE
.ist
ls-R
Bazy nazw plików
TEXMFDBS
map
Mapy fontowe
TEXFONTMAPS
.map
mem
Bazy METAPOST-owe
MPMEMS, TEXMFINI
.mem
mf
Pliki źródłowe Metafont-a
MFINPUTS
.mf
mfpool
pliki napisów Metafont-a
MFPOOL, TEXMFINI
.pool
mft
Pliki stylu MFT
MFTINPUTS
.mft
mp
Pliki źródłowe METAPOST-a
MPINPUTS
.mp
mppool
pliki napisów METAPOST-a
MPPOOL, TEXMFINI
.pool
MetaPost support
pliki pomocnicze METAPOST-a
MPSUPPORT
ocp
Omega – skompilowane pliki pomocnicze
OCPINPUTS
.ocp
ofm
Metryki fontów Omega
OFMFONTS, TEXFONTS
.ofm, .tfm
opl
Omega – listy właściwości
OPLFONTS, TEXFONTS
.opl
otp
Omega – pliki przekodowań
OTPINPUTS
.otp
ovf
Fonty wirtualne Omega
OVFFONTS, TEXFONTS
.ovf
ovp
Wirtualne listy właściwości Omega
OVPFONTS, TEXFONTS
.ovp
pk
Fonty spakowane (PK)
programFONTS (gdzie program to XDVI, etc.), PKFONTS, TEXPKS, GLYPHFONTS, TEXFONTS
.pk
PostScript header
Ładowalne programy PostScript-owe
TEXPSHEADERS, PSHEADERS
.pro, .enc
tex
Pliki źródłowe dla TeX-a
TEXINPUTS
.tex, .cls, .sty, .clo, .def
TeX system documentation
Dokumentacja systemu TeX
TEXDOCS
TeX system sources
Pliki źródłowe systemu TeX
TEXSOURCES
texpool
pliki napisów TeX-a
TEXPOOL, TEXMFINI
.pool
tfm
Metryki fontów TeX-owych
TFMFONTS, TEXFONTS
.tfm
Troff fonts
Fonty dla Troff, używane przez DMP
TRFONTS
truetype fonts
Fonty TrueType
TTFONTS
.ttf, .ttc
type1 fonts
Fonty Type 1 (PostScript-owe)
T1FONTS, T1INPUTS, TEXPSHEADERS, DVIPSHEADERS
.pfa, .pfb
type42 fonts
Fonty Type 42 (PostScript-owe)
T42FONTS
vf
Fonty wirtualne
VFFONTS, TEXFONTS
.vf
web2c files
Pomocnicze pliki Web2c
WEB2C
other text files
Pliki tekstowe użytkownika foo
FOOINPUTS
other binary files
Pliki binarne użytkownika foo
FOOINPUTS

Ostatnie dwie pozycje w tabeli 1 to przypadki szczególne, gdzie ścieżki i zmienne środowiskowe zależą od nazwy programu: nazwa zmiennej budowana jest poprzez zapisanie nazwy programu wersalikami a następnie dodanie INPUTS.

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ą.

–mode=napis
Ustaw nazwę trybu na „napis ”; dotyczy to jedynie szukania fontów „gf” oraz „pk”. Brak jest wartości domyślnej – odnaleziony zostanie dowolny wyszczególniony tryb.
–must-exist
Zrób wszystko co możliwe aby odnaleźć pliki, włączając w to przede wszystkim przeszukanie dysku. Domyślnie, w celu zwiększeniu efektywności działania, sprawdzana jest tylko baza ls-R.
–path=napis
Szukaj w ścieżce „napis ” (rozdzielonej, jak zwykle, dwukropkami), zamiast zgadywać ścieżkę przeszukiwania z nazwy pliku. „//” i wszystkie zwykłe rozszerzenia są możliwe. Parametry „–path” oraz „–format” wzajemnie się wykluczają.
–progname=nazwa
Ustaw nazwę programu na „nazwa ”. Może to mieć wpływ na ścieżkę przeszukiwania poprzez „.program ” w plikach konfiguracyjnych. Ustawieniem domyślnym jest „kpsewhich”.
–show-path=nazwa
Pokazuje ścieżkę używaną do poszukiwania plików typu „nazwa ”. Użyte może być zarówno rozszerzenie („.pk”, „.vf”, etc.), jak i nazwa pliku, tak jak w przypadku parametru „–format”.
–debug=num
ustawia parametry wykrywania błędów na „num ”.

6.2.3 Przykłady użycia

Przyjrzyjmy sie teraz jak działa Kpathsea.


>> kpsewhich  article.cls
/usr/local/texmf/tex/latex/base/article.cls
Szukamy pliku article.cls. Ponieważ rozszerzenie „.cls” jest jednoznaczne, nie musimy zaznaczać, że poszukujemy pliku typu „tex” (katalogi plików źródłowych TeX-a). Znajdujemy go w podkatalogu tex/latex/base pod katalogiem nadrzędnym „TEXMF”. Podobnie wszystkie poniższe pliki odnajdywane są bezproblemowo dzięki swoim jednoznacznym rozszerzeniom.


>> kpsewhich array.sty
   /usr/local/texmf/tex/latex/tools/array.sty
>> kpsewhich latin1.def
   /usr/local/texmf/tex/latex/base/latin1.def
>> kpsewhich size10.clo
   /usr/local/texmf/tex/latex/base/size10.clo
>> kpsewhich small2e.tex
   /usr/local/texmf/tex/latex/base/small2e.tex
>> kpsewhich tugboat.bib
   /usr/local/texmf/bibtex/bib/beebe/tugboat.bib

Ostatni plik to BIBTeX-owa baza bibliograficzna dla artykułów TUGBoat.


>> kpsewhich cmr10.pk
Pliki czcionek bitmapowych typu .pk używane są przez sterowniki takie jak dvips oraz xdvi. W tym wypadku nie zostaną zwrócone żadne rezultaty przeszukiwania, ponieważ w systemie brak gotowych wygenerowanych czcionek „.pk” Computer Modern (wynika to z faktu używania na CD-ROM-ie fontów PostScript-owych Type1).


>> kpsewhich ecrm1000.pk
   /usr/local/texmf/fonts/pk/ljfour/jknappen/ec/ecrm1000.600pk
Dla plików rozszerzonych Computer Modern musieliśmy wygenerować pliki „.pk”, a ponieważ domyślnym Metafont-owym trybem naszej instalacji jest ljfour z podstawową rozdzielczością 600dpi, zwracany jest taki właśnie rezultat.


>> kpsewhich -dpi=300 ecrm1000.pk
W tym wypadku, kiedy zaznaczamy, że interesujemy się rozdzielczością 300dpi (-dpi=300) widzimy, że taka czcionka nie jest dostępna w naszej instalacji. Program taki jak dvips czy xdvi zatrzymałby się aby utworzyć pliki .pk w wymaganej rozdzielczości (używając skryptu mktexpk).

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


>> kpsewhich tex.pro
   /usr/local/texmf/dvips/base/tex.pro
>> kpsewhich --format="dvips config" config.ps
   /usr/local/texmf/config/config.ps
>> kpsewhich psfonts.map
   /usr/local/texmf/dvips/base/psfonts.map

Teraz przyjrzyjmy się bliżej plikom pomocniczym URW Times PostScript. Ich nazwą w schemacie nazewnictwa fontów (zaproponowanym przez K. Berry'ego) jest „utm”. Pierwszy plik, którego szukamy to plik konfiguracyjny, zawierający nazwę pliku z przemapowaniem fontów:


>> kpsewhich --format="dvips config" config.utm
/usr/local/texmf/dvips/psnfss/config.utm
W pliku tym znajduje się wiersz


  p +utm.map
wskazujący na plik utm.map, który chcemy zlokalizować w następnej kolejności.


>> kpsewhich --format="dvips config" utm.map
   /usr/local/texmf/dvips/psnfss/utm.map
Ten plik z przemapowaniem definiuje nazwy czcionek PostScriptowych Type1 w zestawie URW, zaś jego zawartość wygląda następująco (pokazane są tylko fragmenty linii):


  utmb8r  NimbusRomNo9L-Medi    ... <utmb8a.pfb
  utmbi8r NimbusRomNo9L-MediItal... <utmbi8a.pfb
  utmr8r  NimbusRomNo9L-Regu    ... <utmr8a.pfb
  utmri8r NimbusRomNo9L-ReguItal... <utmri8a.pfb
  utmbo8r NimbusRomNo9L-Medi    ... <utmb8a.pfb
  utmro8r NimbusRomNo9L-Regu    ... <utmr8a.pfb
Weźmy na przykład font Times Regular utmr8a.pfb i znajdźmy jego miejsce w drzewie katalogów texmf, używając przeszukiwania plików z fontami Type1:


>> kpsewhich utmr8a.pfb
   /usr/local/texmf/fonts/type1/urw/utm/utmr8a.pfb

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.

6.2.4 Diagnostyka błędów

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 zmienną: SET KPATHSEA_DEBUG_OUTPUT=err.log.)

Rozważmy na przykład mały LaTeX-owy plik źródłowy hello-world.tex, który zawiera co następuje:


    \documentclass{article}
    \begin{document}
    Hello World!
    \end{document}

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


>> dvips -d4100 hello-world -Pcms -o
Mamy tu do czynienia jednocześnie z czwartą klasą wykrywania błędów programu dvips (ścieżki fontowe) oraz z rozwijaniem elementu ścieżki przez Kpathsea (patrz Dvips Reference Manual, texmf/doc/html/dvips/dvips_toc.html). Komunikaty z uruchomienia programu (lekko zmodyfikowane) znajdują się na rys. 4.

  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

Rysunek 4Szukanie pliku konfiguracyjnego

  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


Rysunek 5Szukanie pliku prologu

  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]


Rysunek 6Szukanie fontu

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.


>> more /usr/local/texmf/dvips/cms/config.cms
   p +ams.map
   p +cms.map
   p +cmbkm.map
   p +amsbkm.map
W ten sposób dvips wyszukuje wszystkie te pliki oraz główny plik z przemapowaniem psfonts.map, który ładowany jest zawsze (zawiera on deklaracje często używanych fontów PostScript-owych; więcej szczegółów odnośnie PostScript-owych plików przemapowań fontów można znaleźć w ostatniej części rozdziału 6.2.3).

W tym miejscu dvips zgłasza się użytkownikowi:


This is dvips 5.83 Copyright 1998 Radical Eye Software (www.radicaleye.com)
. . . potem szuka pliku prologu texc.pro,


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
Po znalezieniu szukanego pliku, dvips podaje datę i czas oraz informuje o generowaniu pliku hello-world.ps. Ponieważ potrzebuje pliku z fontem cmr10, a jest on zadeklarowany jako dostępny, wyświetla komunikat:


TeX output 1999.02.26:1204' -> hello-world.ps
Defining font () cmr10 at 10.0pt
Font cmr10 <CMR10> is resident.
Teraz trwa poszukiwanie pliku cmr10.tfm, który zostaje znaleziony, a następnie dvips powołuje się na kilka innych plików startowych (nie pokazanych). W końcu przykładowy font Type1 cmr10.pfb zostaje zlokalizowany i dołączony do pliku wynikowego (patrz ostatnia linia).


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]

6.3. Parametry kontrolujące działanie programów

Inną użyteczną cechą Web2c jest możliwość ustalania wielu parametrów określających wielkość pamięci za pomocą pliku texmf.cnf. Załącznik A zaczynający się na stronie 56 zawiera listing pliku texmf.cnf. Ustawienia wszystkich parametrów znajdują się w części trzeciej pliku. Najważniejszymi zmiennymi są:

main_memory
Całkowita wielkość pamięci dostępnej dla TeX-a, Metafont-a i METAPOST-a. Dla każdego nowego ustawienia tej zmiennej należy wykonać nowy format. Przykładowo, możesz wygenerować „ogromną” wersję formatu TeX i nazwać taki plik hugetex.fmt. Dzięki standardowemu sposobowi nazywania programów przez Kpathsea, określona wartość zmiennej main_memory będzie przeczytana z pliku texmf.cnf (por. wartość standardową oraz wartość „ogromną”, wykorzystywaną przez program hugetex, itd.).
extra_mem_bot
Dodatkowa wielkość pamięci przeznaczona na „duże” struktury danych TeX-a, takie jak: pudełka, kleje itd.; przydatna, zwłaszcza w przypadku korzystania z pakietu PiCTeX.
font_mem_size
Wielkość pamięci przeznaczona przez TeX-a na informacje o fontach. Jest to mniej więcej ogólna wielkość wczytywanych przez TeX-a plików TFM (linia 343).
hash_extra
Dodatkowa wielkość pamięci przeznaczona na tablicę zawierającą nazwy instrukcji. Tablica główna może zmieścić w przybliżeniu 10000 nazw; wielkość ta może okazać się zbyt mała, np. w wypadku obszernej książki zawierającej liczne odsyłacze. Odpowiednie wiersze pliku texmf.cnf pokazują, że uruchomienie programów hugetex pdflatex wymaga dodatkowej pamięci dla 15000 nazw instrukcji.

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ść.