Toto je text knihy v klikací verzi ve formátu PDF. Další informace o knize naleznete na adrese

Transkript

1 TEXbook naruby

2 Toto je text knihy v klikací verzi ve formátu PDF. Další informace o knize naleznete na adrese Verze tohoto textu přesně odpovídá textu druhého vydání knihy v nakladatelství Konvoj, spol. s r. o., Berkova 22, , Brno. Knihu je možné u tohoto nakladatelství objednat, viz konvoj@konvoj.cz, tel./fax: Jsem si vědom některých nedostatků, které zůstaly ve formátu PDF neodstraněny. Systém záložek, který obsahuje strukturovaný obsah, je zapsán česky, což se nemusí na všech implementacích Acroreaderu správně zobrazovat. Přesto zůstává systém záložek celkem čitelný a tedy použitelný. Podrobněji o problematice klikací verze této knihy, viz článek Jak jsem dělal knihu klikací například v souboru tbnklik.tex. PDF formát knihy byl připraven pomocí volně dostupné modifikace TEXu pdftex. Viz například

3 TEXbook naruby Petr Olšák Konvoj, CSTUG Brno 2001

4 Autorem programů TEX a METAFONT je profesor Donald Knuth. TEX je ochranná známka American Mathematical Society. METAFONT je ochranná známka Addison Wesley Publishing Company. Ostatní v knize použité názvy programových produktů, firem apod. mohou být ochrannými známkami nebo registrovanými ochrannými známkami příslušných vlastníků. Kniha vyšla za přispění Československého sdružení uživatelů TEXu. KATALOGIZACE V KNIZE NÁRODNÍ KNIHOVNA ČR Olšák, Petr TEXbook naruby / Petr Olšák. 2. vyd. Brno : Konvoj s. ISBN TEX TEX počítačová typografie příručky Copyright c RNDr. Petr Olšák, 1996, 1997, 2000 ISBN (2. vyd.) ISBN (1. vyd.)

5 Úvod TEX je volně dostupný počítačový program na pořizování vysoce kvalitní elektronické sazby. Tento program se od svých stejně zaměřených komerčních kolegů liší v mnoha ohledech. Mezi nejpodstatnější odlišnost zřejmě patří otevřenost systému. Šikovnému uživateli se v takovém systému dostává do rukou nástroj na vytvoření nadstavby podle vlastní představy a potřeby. K tomu je ale potřeba o vlastnostech systému poměrně hodně vědět. Chcete-li nahlédnout pod pokličku TEXovského hrnce a postupně se podívat až na jeho samotné dno, abyste se dozvěděli, co se v něm vaří, je tato kniha určena pro vás. Na každém pracovišti, kde se používá TEX, by měl být aspoň jeden odborník, který TEXu na této úrovni rozumí. Ostatní spolupracovníci pak mohou postupovat podle jednoduchých příruček typu napíšete-li \alpha, dostanete na výstupu α. Pokud si tito spolupracovníci nebudou vědět s něčím rady, mají ve svých řadách odborníka, který jim poradí. Idea, že se všechno zvládne pomocí L A TEXových příruček, se při náročnějších požadavcích na sazbu většinou rozplyne před očima jako jarní sníh. Referenční manuál k TEXu se jmenuje The TEXbook [4]. Tato základní kniha o TEXu není mezi našinci příliš rozšířena zvláště pro její vysokou cenu. Pro mnohé je navíc tato kniha dosti obtížná ke čtení, protože TEX není nic jednoduchého. Pokusil jsem se tedy napsat k tomuto základnímu manuálu alternativní text. Text ale není jen odvarem TEXbooku. Užitečné asi budou zcela původní příklady řešené přímo v textu. Nikdy jsem se nesnažil o doslovný překlad žádné pasáže z TEXbooku, ba dokonce jsem do tohoto manuálu při psaní nahlížel jen výjimečně a snažil se celou problematiku podat svými slovy podle svých vlastních zkušeností. Měl jsem potom radost, pokud se mi něco podařilo říci přehledněji nebo stručněji než v TEXbooku. Představil jsem si, že text píši pro čtenáře, který již má základní zkušenosti s pořizováním jednoduchých textů a který tuto knihu otevírá třeba proto, že chce v TEXu programovat složitější makra. Rozhodl jsem se tedy výklad obrátit. V TEXbooku se začíná popisem použití již hotových maker plainu a teprve potom, podstatně později, se čtenář dozví, na jakém principu jsou tato makra postavena. Naproti tomu, v této knize je výklad veden naruby. Nejprve je vždy popsán vnitřní algoritmus TEXu a vlastnosti souvisejících primitivů a potom jsou tyto vlastnosti ilustrovány na příkladech maker. Z této koncepce pramení název knihy TEXbook naruby. Tato kniha není příručkou uživatele, který si chce pouze osvojit základní metody při pořizování textů pro TEX. K tomu účelu slouží mnoho jiných učebnic. Je tedy patrné, že kniha není určena začátečníkovi. Ke zvládnutí tohoto textu by ale měly stačit znalosti získané četbou Jemného úvodu do TEXu [3]. Užitečné informace lze též čerpat z knížky Typografický systém TEX [7], která na rozdíl od této knihy není úzce specializovaná na TEX samotný, ale rozebírá softwarové souvislosti programu. Tam čtenář najde rozbor práce TEXu s virtuálními fonty, s PostScriptem, s obrázky a například se dozví, jak vypadá jazyk WEB zdrojového textu TEXu.

6 Text knihy, kterou právě otvíráte, je rozdělen na dvě části. Část A (Algoritmy) popisuje v jednotlivých kapitolách a sekcích systematicky všechny algoritmy TEXu. Část B (Reference) obsahuje slovník všech primitivů a maker plainu, přičemž u každého hesla je poměrně rozsáhlý vysvětlující text. Představte si rejstřík z TEXbooku v dodatku I a nechť každé heslo z tohoto rejstříku expanduje na zhruba půlstránkový výklad o heslu. Pak dostáváte část B této knihy. Obě části knihy jsou bohatě ilustrovány příklady. Jedná se především o ukázky z formátu plain a dále o úlohy, které jsem v době své praxe s TEXem někdy řešil a které mohou být pro čtenáře zajímavé. Aby čtenář nemusel ručně opisovat do svého počítače texty ukázek, které ho zaujmou, vystavuji na síti Internet soubor tbn.mac. V něm jsou veškeré ukázky z této knihy obsaženy. Každý zájemce si tento soubor může zkopírovat z adresy ftp://math.feld.cvut.cz/pub/olsak/tbn/. Nikdo není neomylný. I při sebevětší péči se neubráním možnému zavlečení chyb do textu. Budu proto na stejné adrese v Internetu průběžně obnovovat soubor errata.txt, ve kterém budou zaneseny všechny chyby, o kterých vím a které nemusí být ještě opraveny v tomto textu. K odhalení a zveřejnění chyb může přispět kterýkoli čtenář, pokud mi o chybě napíše na adresu olsak@math.feld.cvut.cz. Při psaní této knížky se též objevilo plno jazykových problémů. Jazykoví puristé mi doufám odpustí, že používám termíny jako token, expand procesor, box apod. Mohl bych sice mluvit o amuletu, proceduře na rozklad balíčků povelů a krabičce. Myslím si ale, že by takový text vzhledem k návaznosti na anglickou literaturu nebyl příliš čitelný. My také klikáme myší a díváme se na video, místo abychom poklepávali po tlačítku polohovacího zařízení a pouštěli magnetoskop. S jazykem to je těžké. Chtěl bych ze srdce poděkovat především své ženě Ludmile, která mi byla velkou oporou v dobách, kdy jsem nevnímal svět kolem sebe a myšlenkami jsem byl u svých příkladů \output rutin. Má žena pomáhala též organizaci CSTUGu v době, kdy měla tato organizace poměrně velké problémy. Dále děkuji všem dobrovolným korektorům, kteří se přihlásili v hojném počtu, za podnětné připomínky při závěrečných úpravách textu. Přeji všem čtenářům této knihy mnoho hezkých zážitků se skvělým programem, který vznikl v dílně profesora Donalda Knutha jako labour of love (práce z radosti) a byl poskytnut veřejnosti zdarma Petr Olšák Ve druhém vydání jsou jen opraveny chyby podle errata.txt. Děkuji touto cestou všem čtenářům, kteří přispěli k odhalení chyb a tím k vylepšení kvality knihy. Snažil jsem se důsledně zachovat stránkování i číslování, aby případné odkazy na knihu, které jste již dříve použili ve svých makrech, zůstaly v platnosti.

7 Obsah Část A: Algoritmy Vstupní části TEXu Koncept vstupní brány TEXu Input procesor Token procesor Expand procesor Definování maker Triky s \expandafter Podmínky typu \if Registry pro uchování posloupností tokenů (\toks) Základy hlavního procesoru Povely a parametry hlavního procesoru Kdy TEX neprovádí expanzi Registry, datové typy a aritmetika TEXu Šest módů hlavního procesoru Boxy Mezery v horizontálním seznamu Mezery ve vertikálním seznamu Tvorba tabulek Opakovací výplňky typu \leaders Tabulky s pevnou šířkou sloupců Tabulky pomocí \halign Matematická sazba Matematický seznam Konverze z matematického do horizontálního seznamu Fonty v matematické sazbě Symboly matematické sazby definované v plainu Tipy, triky a zvyky v matematické sazbě Display mód Zalamování Místa zlomu všeobecně Zlom v místě \discretionary Vyhledání míst pro dělení slov Řádkový zlom

8 6.5 Tvar odstavce Stránkový zlom Plovoucí objekty typu \insert Výstupní rutina Ukázky různých výstupních rutin Různé Jak TEX pracuje se soubory Struktura paměti TEXu Formát metriky fontu tfm Formát výstupního souboru dvi Část B: Reference Slovník syntaktických pravidel Zkratky plainu Slovník primitivů a maker plainu Seznam příkladů použitých v knize Literatura Rejstřík

9 Část A Algoritmy

10 1. Vstupní části TEXu 1.1. Koncept vstupní brány TEXu Vstupní soubor TEXu je textový a obsahuje jednotlivé znaky, které se mají vysázet. Mimoto vstupní soubor obsahuje tzv. řídicí sekvence (anglicky control sequences). Řídicí sekvence určují způsob, jakým se má sazba provést. Například řídicí sekvence \TeX způsobí vysázení loga TEX. Při startu (kdy není načten formát) je v TEXu implementováno zhruba 300 primitivních řídicích sekvencí (zkráceně primitivy). Kromě toho se dají deklarovat nové řídicí sekvence (například prostřednictvím primitivu \def), které nahrazují většinou skupiny jiných řídicích sekvencí. Nově deklarovaným řídicím sekvencím říkáme makra. Například řídicí sekvence \TeX je makro, které se opírá o primitivy \hbox, \kern a \lower (viz část B). Formáty TEXu (například plain, L A TEX atd.) deklarují nové řídicí sekvence, které jsou většinou uživatelsky mnohem přijatelnější než přímé použití primitivů. Autor textu se pak nemusí vyjadřovat jen pomocí primitivů (to by bylo asi příšerně komplikované) a není nucen si všechna potřebná makra v úvodu svého textu deklarovat sám. Vesměs všechny formáty vycházejí ze základního formátu plain, který je popsán v TEXbooku. I v této knize se zaměříme na tento formát. Všechna makra plainu jsou popsána v části B. Pokud chceme začít psát vlastní makra, bude pro nás formát plain dobrým startovním bodem, o který se jednak můžeme opřít a jednak v něm můžeme hledat inspiraci. TEX na svém vstupu čte textový soubor a na výstupu vzniká (mimo jiné) binární soubor dvi. Pro dobré pochopení jednotlivých funkcí TEXu je užitečné rozdělit cestu datových struktur od vstupního textového souboru do výstupního dvi na úseky. TEX jako program tím pomyslně rozdělíme na samostatné procesory, které si předávají mezi sebou konkrétním způsobem definované datové struktury. Knuth přirovnal tento proces zpracování vstupní informace k trávení TEXu a mluví o očích, ústech, hltanu, žaludku atd. My budeme mluvit o input procesoru, token procesoru, expand procesoru a hlavním procesoru. Input procesor čte jednotlivé řádky vstupního souboru a zpracovává je do podoby řádků, které jsou nezávislé na použitém operačním systému. Token procesor čte zpracované řádky z input procesoru a vytváří posloupnost tokenů, což jsou buď řídicí sekvence nebo jednotlivé znaky nesoucí svou kategorii (pojem zavedeme v sekci 1.3). Výstupní posloupnost tokenů už není členěna na řádky. 10

11 1.1. Koncept vstupní brány TEXu Expand procesor čte jednotlivé tokeny a rozlišuje mezi tokeny, které bude expandovat a které ponechá beze změny. Beze změny ponechá napříkad jednotlivé znaky. Také primitivní řídicí sekvence zůstávají (až na výjimky) beze změny. Naopak procesor expanduje všechny řídicí sekvence, které byly deklarovány jako makra. Expandování tokenu znamená (zhruba řečeno) záměnu tokenu za posloupnost jiných tokenů. V nové sekvenci tokenů mohou některé podléhat expanzi znova, tj. proces expanze se opakuje tak dlouho, až jsou všechny tokeny primitivními řídicími sekvencemi nebo jednotlivými znaky, které nepodléhají expanzi. Hlavní procesor rozlišuje na svém vstupu přesně definovanou množinu tzv. povelů. Například samostatný znak znamená povel na vysázení tohoto znaku. Nebo primitivní řídicí sekvence se stává v hlavním procesoru povelem k vykonání konkrétního úkonu souvisejícího se sazbou. Takové povely mohou mít své parametry, které přicházejí za povelem. Například v zápise \vskip2mm považujeme \vskip za povel a 2mm za jeho parametr. Hlavní procesor vytváří vlastní sazbu, provádí výstup do dvi a rovněž nastavuje prostřednictvím povelů hodnoty registrů, jež ovlivňují algoritmy na všech úrovních zpracování TEXu. Jednotlivé procesory spolu úzce spolupracují a jejich činnost je provázána. Nelze tedy považovat za správnou představu, při které nejprve celý vstupní soubor projde input procesorem, pak token procesorem atd. Změny parametrů provedené v hlavním procesoru (například \endlinechar, \catcode, nová makra deklarovaná pomocí \def) okamžitě mohou ovlivnit následující činnost ostatních vstupních procesorů. Proto je v každém okamžiku jednotlivým procesorem zpracováno jen tolik informace, kolik bylo pro uspokojení požadavku následujícího procesoru nezbytně potřeba. Lze si představit, že hlavní procesor řídí celou činnost. Vyžádá si od expand procesoru povel. Expand procesor si vyžádá od token procesoru jeden token, který případně expanduje. Token procesor při vytváření tokenu musí mít ve vstupním bufferu řádek vstupního textu, který byl připraven input procesorem. Nový řádek načte input procesor až v okamžiku, kdy je to nezbytně nutné. Vstupní bránu hlavního procesoru budeme též označovat jako čtecí fronta. Jedná se o místo v paměti, kam přichází výstup z expand procesoru a odkud si bere hlavní procesor povely a parametry. Později ukážeme, že hlavní procesor za určitých okolností vrací načtený povel do čtecí fronty (jakoby proti proudu dat), pak udělá nějakou konkrétní činnost a potom znovu čte ze čtecí fronty odložený povel. Přesněji si o jednotlivých procesorech povíme v následujících sekcích. 11

12 Kapitola 1. Vstupní části TEXu 1.2. Input procesor Input procesor čte ze vstupního souboru postupně řádky textu, upravuje je a na jeho výstupu jsou znovu řádky textu připravené pro token procesor. Pojmem řádek textu na vstupu rozumíme konkrétní část textového souboru, která je (bohužel) v různých operačních systémech odlišně definována. Řádek textu na výstupu z input procesoru je již vnitřní datová struktura TEXu, která je stejná ve všech implementacích TEXu. Algoritmy input procesoru jsou tedy závislé na systému a starají se o odstínění zvláštností jednotlivých operačních systémů tak, aby všechny ostatní algoritmy TEXu již mohly být implementovány nezávisle na operačním systému. Input procesor postupně provádí se vstupními řádky textu dvě aktivity: Případně překóduje obsah řádku z kódování operačního systému do ASCII. Upraví znak konce řádku smluveným způsobem. 1. Překódování. Představme si dvě implementace TEXu; jednu na operačním systému s kódováním ASCII a druhou na systému s kódováním Pišvejcovým. Pokud si uživatelé předávají mezi těmito systémy textové soubory, provádějí konverze mezi těmito dvěma kódováními. Proto uživatel A pracující se systémem s ASCII vidí v textovém editoru totéž, co uživatel B, pracující se systémem podle Pišvejce. Uvažujme, že se oba dívají na tento text: 1 \catcode64=13 % Znak "@" má ASCII 64 a bude mít kategorii 13 2 Zde je Kdyby input procesor neprovedl konverzi z Pišvejce do ASCII, pak by se tento zdrojový text mohl chovat ve zmíněných implementacích TEXu různě, ačkoli oba uživatelé vidí ve svém editoru totéž. Knuth tedy rozhodl, že vnitřní kódování TEXu bude podle ASCII a vše se do tohoto kódování bude konvertovat na úrovni input procesoru. Když v TEXu řekneme \catcode64, pak je jednoznačně jasné, co se tím myslí. Poznamenejme, že místo zápisu \catcode64 asi použijeme \catcode \@, takže pak by zmíněný problém nenastal. Nastal by ovšem na úrovni textových fontů TEXu, které se obvykle ve větší části kryjí s ASCII kódem. Například při výskytu písmene A v obyčejném textu TEX vysází znak aktuálního fontu z pozice, která odpovídá kódu tohoto písmene. Musíme tedy přesně vědět, jaký to je kód. TEX má přitom ve svých instalacích své vlastní fonty společné všem instalacím TEXu a nezávislé na operačním systému. 2. Úprava konce řádku. Textový soubor se člení na řádky. Oddělovače mezi jednotlivými řádky jsou definovány v různých operačních systémech různě. V systémech dnes už historických měly například všechny řádky stejnou délku (třeba 12

13 1.2. Input procesor 80 znaků) a byly zprava doplňovány mezerami. Dnešní systémy mají vesměs definován jeden znak nebo skupinu znaků jako oddělovač mezi řádky. Například v systémech typu UNIX je tímto oddělovačem znak s kódem ASCII 10 (LF, Ctrl-J), v DOSu se používá dvojice CR LF (Ctrl-M Ctrl-J) a na systémech počítačů Macintosh je oddělovačem pro změnu jen CR. Pokud si uživatelé mezi těmito systémy vyměňují textové soubory, musí provádět konverze. Input procesor postupně načítá řádky textu ze vstupního souboru tak, jak je tento pojem definován v použitém operačním systému. Pak provede případné překódování do ASCII a odstraní případnou značku konce řádku definovanou systémem. Dále odstraní z konce řádku (tedy zprava) všechny případné mezery (ASCII 32, nikoli token mezera) až po první znak, který není mezerou. Konečně připojí na konec řádku znak, definovaný v registru \endlinechar. Teprve takto upravený řádek vstupuje do token procesoru. IniTEX nastavuje \endlinechar na hodnotu ^^M, která ve formátech obvykle nebývá měněna. Symbolem ^^M označujeme kód Ctrl-M, což je ASCII 13 neboli CR. K pochopení funkce \endlinechar si vyzkoušíme: 3 { \endlinechar= \* Tady je první řádek, 4 tady druhý, 5 tu třetí} 6 a konečně poslední. Na výstupu dostaneme: Tady je první řádek, tady druhý,*tu třetí*a konečně poslední. Vidíme, že za první řádek byla připojena ještě původní hodnota \endlinechar, která je rovna ^^M a která na úrovni token procesoru vyprodukuje (obvykle) mezeru. Je to z toho důvodu, že v okamžiku, kdy hlavní procesor provede nové přiřazení do registru \endlinechar, byl již input procesorem celý první řádek načten a kompletován. Input procesor se tedy začne chovat jinak až od druhého řádku. Jakmile hlavní procesor na třetím řádku uzavře skupinu (}), registr \endlinechar se vrátí k původní hodnotě, ovšem input procesor už na konec třetího řádku hvězdičku připojil. Teprve na čtvrtém řádku bude vše v původním stavu. Uvedeme příklad na využití \endlinechar. Nechť máme soubor (například data.txt), ve kterém jsou data systematicky členěna do řádků. Třeba údaje pro vyplnění formuláře vysvědčení: 7 Ferdinand Mravenec 8 Údolní

14 Kapitola 1. Vstupní části TEXu 11 Karel Mařík 12 bratří Maříků atd. Vidíme, že data jsou členěna do trojic řádků. První řádek obsahuje jméno, druhý ulici a třetí známky. Vidíme též, že zde není jediná TEXovská značka (řídicí sekvence) a nám se nechce žádné značky do souboru dopisovat. K načtení takového souboru TEXem tak, aby zůstala zachována členěná struktura, můžeme použít třeba toto makro: 15 \def\jmeno#1{{\it Jméno\/}: #1\par} 16 \def\ulice#1{{\it Ulice\/}: #1\par} 17 \def\znamky#1{{\it Známky\/}: #1\par} 18 \catcode \*=13 \let*=\space 19 \def\udaj#1*#2*#3*{{\everypar={}\jmeno{#1}\ulice{#2}\znamky{#3} 20 \vfil\eject}} 21 \endlinechar= \* \everypar={\udaj} 22 \input data.txt Trik s \everypar vyžaduje znalost módů hlavního procesoru, takže přesně se o něm zmíníme až v sekci 3.4. Zde jen rámcově: Jakmile TEX narazí na první písmeno, které by se mělo sázet (písmeno F v našem souboru data.txt), spustí se \everypar, tj. v tomto případě se provede makro \udaj. Všimneme si, že konec každého řádku máme ohraničen hvězdičkou, protože \endlinechar má hodnotu hvězdičky. Hvězdička je navíc aktivní (kategorie 13) a kdyby náhodou na ni přišla řada, bude pracovat jako mezera (\space). Takže nám nebude na koncích řádků překážet. Teď už vidíme, proč makro \udaj nabere do parametru #1 první řádek se jménem, do #2 druhý řádek s ulicí a do #3 třetí řádek se známkami. Makra \jmeno, \ulice, \znamky jsou zde pro jednoduchost uvedena jen v ladicí podobě. Prakticky by tato makra měla řešit přesné usazení textu do konkrétního místa na formuláři. V případě \znamky by se asi použil cyklus přes všechny známky (viz sekci 2.3) a jednotlivé číslovky by se nahradily slovy výborný, chvalitebný atd. V tuto chvíli není účelem zde takové věci předvádět. Pokud uděláme ve vstupním souboru změny, které v obvyklých textových editorech nejsou vidět, měl by se TEX chovat pokud možno stejně. K tomu účelu je potřeba udělat trochu práce na úrovni formátu. Pokud třeba uživatel použije tabelátor místo mezery (nebo skupiny mezer), většinou to v editoru explicitně nevidí. Tabelátor je znak (ASCII 9), který v některých editorech způsobí vložení smluveného množství mezer. Plain definuje kategorii tabelátoru shodně s kategorií mezery. Také primitivní sekvence \ (pro explicitní mezeru) se v plainu ztotožňuje jednak s \^^I (čti backslash tabelátor ) a také s \^^M (čti backslash CR ). Pak se tedy sekvence \ chová stejně uvnitř řádku i na konci řádku. Uvedeme si příklad, ve kterém předefinujeme chování uvedených řídicích sekvencí: 14

15 23 \def\ {SPACE} \def\^^m{cr} 24 A nyní vyzkouším mezeru\ a také mezeru na konci\ 1.2. Input procesor Na výstupu máme: A nyní vyzkouším mezeruspacea také mezeru na koncicr. Vidíme, že ačkoli jsme za posledním znakem \ výslovně napsali dokonce dvě mezery (tato skutečnost je vyznačena pomocí vaničky) a případně jsme si překontrolovali binárním prohlížečem, že tam ty mezery skutečně máme, nepomohlo to. Input procesor totiž po odebrání znaku konce řádku zlikviduje tyto mezery a teprve pak přidá \endlinechar. Kdybychom ale napsali a také mezeru na konci\ tabelátor pak skutečně dostaneme:... mezeru na koncispace. Input procesor totiž přidá \endlinechar za znak tabelátor, protože to není mezera. Skutečnost, že tabelátor má stejnou kategorii jako mezera, nemá pro input procesor žádný význam. Uvedené příklady se mohou zdát extrémně neužitečné. Na druhé straně je velmi užitečné přesně vědět, co input procesor vlastně provádí. Může se třeba stát, že jsme převzali textový soubor pořízený v DOSu (na konci řádku jsou CR LF) a bez konverze jsme jej použili v TEXu na UNIXu. Co se stane? Input procesor odebere z každého řádku LF (to je značka konce řádku v UNIXu), ponechá CR a přidá \endlinechar, což bývá obvykle ^^M, neboli jinými slovy CR. Do token procesoru tedy vstupuje na konci každého řádku CR CR (tj. ^^M^^M). Kategorie znaku ^^M je většinou nastavena na 5, což v token procesoru způsobí ukončení zpracování vstupního řádku při prvním výskytu ^^M a vložení mezery. K druhému výskytu ^^M se token procesor vůbec nedostane. UNIXový TEX se tedy chová stejně, jako kdyby byl textový soubor pořízen přímo na UNIXu. Ale pozor! Pokud změníme kategorii znaku ^^M, začne se UNIXový TEX na našem souboru chovat odlišně. Přestává být jedno, zda máme na koncích řádků CR nebo CR CR. K takové situaci dojde například ve verbatim prostředí. Tam je znak ^^M nastaven jako aktivní a je definován jako makro pro přechod na nový řádek. Druhé ^^M v každém vstupním řádku nám tedy vloží do výstupu ve verbatim prostředí prázdný řádek. Některé DOSové editory způsobují UNIXovému TEXu ještě jednu starost. Tvrdohlavě vkládají na konec souboru znak ^^Z. Uvedeme doporučený postup, kterým naučíme UNIXový TEX číst DOSem připravené soubory. Na úrovni algoritmu překódování (o něm se zmíníme později v této sekci) provedeme konverzi znaku ^^M na ^^Z a do formátu přidáme řádeček: 26 \catcode \^^Z=9 % Znak ^^Z bude ignorován Potom na konci každého řádku budeme mít ^^Z (to je konvertované CR z DOSového konce řádku), za něj input procesor přidá ^^M z \endlinechar, které už nepodléhá 15

16 Kapitola 1. Vstupní části TEXu konverzi. Na konci řádku tedy máme dvojici: ^^Z^^M. Token procesor bude znak ^^Z ignorovat a se znakem ^^M naloží obvyklým způsobem. Dodejme, že v této věci se DOSový TEX chová podstatně lépe (mluvím o emtexu). Tam je v input procesoru naprogramováno, že konec řádku v systému může končit buď CR LF nebo jen LF. Obě situace vstupní procesor interpretuje správně, tj. odstraní CR LF, případně jen LF. Po odstranění mezer na konci přidá \endlinechar. Je tedy naprosto jedno, zda DOSovým TEXem zpracováváme soubory pořízené v DOSu nebo na UNIXu. UNIXové soubory poznáme v některých DOSových editorech podle toho, že vidíme jen jeden hrozně dlouhý řádek, který v sobě obsahuje znaky LF, promítané na obrazovce většinou jako tmavý obdélníček s kolečkem. Výše zmíněné problémy nejsou bohužel nejpodstatnější. Horší je, že nové textové editory berou do svých rukou i starosti o formátování. Na základě toho si definují své vlastní značky pro konec řádků. Jistě si vzpomenete na mnoho DOSových editorů, které aspirují na textový procesor nebo dokonce DTP a rozlišují mezi tzv. tvrdým a měkkým koncem řádku. Tvrdým koncem řádku je přitom skutečně míněn ten konec řádku, který je definován v systému. Měkký konec řádku je značka dosti často závislá na konkrétním editoru. V této záležitosti šel bohužel vývoj jiným směrem, než odpovídá velmi dobré koncepci z TEXu, kde konec řádku podléhá dalšímu formátování a konec odstavce se zapíše na vstupu jako prázdný řádek. V editorech, které používají dva druhy značek pro konec řádku, jsou tvrdé konce řádku míněny jako konec odstavce a měkké konce řádku podléhají dalšímu formátování. Tedy úplně jinak než v TEXu. Pokud je měkký konec řádku například skryt pod kódem "8D (hexadecimálně), pak můžeme zkusit na začátek dokumentu uvést: 27 \catcode"8d=5 % Měkký konec řádku bude konec řádku 28 \catcode \^^M=13 \def^^m{\par} % Tvrdý konec ukončí odstavec Například program T602 vytváří v místě měkkých konců řádků dvojici "8D (hexa) následovanou znakem LF. V takovém případě náš kód umožní načítat texty pořízené programem T602, který je již dlouhou dobu v našich končinách nejužívanějším prostředkem pro pořizování textů na počítači. Samozřejmě je potřeba odkrojit hlavičku, kterou si program vytváří na začátku souboru. Hlavička má na začátku každého řádku zavináč. Takže stačí v TEXu před načtením souboru označit tento znak jako komentářový: \catcode \@=14. Uvedené řešení může narazit na problémy. Pokud je totiž vstupní znak s kódem "8D na úrovni input procesoru překódován, ve vnitřním kódování TEXu už vystupuje pod úplně jiným kódem. Například při transformaci z kódování Kamenických do vnitřního kódu TEXu je znak s kódem "8D překódován na znak ĺ, tedy slovenské l s čárkou. Nepracujeme-li se slovenskými texty, nemusí nám to vadit. Pak ovšem 16

17 1.2. Input procesor místo řádku 27 pišme \catcode \ĺ=5. Poznamenejme, že u kódu PC Latin2 ani ISO není znak "8D transformován, takže bychom neměli mít problémy. Ovšem jen do té doby, než autor v programu T602 použije nějakou funkci, která tento procesor odlišuje od obyčejného ASCII editoru; například zvolí jiný druh písma. Tím vznikají ve zpracovávaném souboru další privátní značky textového procesoru. Bývá obvyklejší při zpracování dokumentů z programu T602 a jemu podobných provést nejprve záměnu všech tvrdých konců řádků za dva tvrdé a všech měkkých za jeden tvrdý. To můžeme provést před zpracováním v TEXu například na úrovni inteligentního editoru nebo ještě lépe UNIXového filtru využívajícího například dávkový editor sed. Také můžeme ošetřit výskyty přepínačů druhu písma apod. Dá se totiž očekávat, že když pracujeme s TEXem, pak nepracujeme s programem T602. Proto nám bude stačit provést konverzi jen jednou v okamžiku, kdy obdržíme rukopis od autora textu. Nyní si povíme o problematice překódování vstupu na úrovni input procesoru TEXu, což je pro nás v případě češtiny a rozličných operačních systémů záležitost bytostně důležitá. Knuth rozhodl, že vnitřní kódování TEXu je ASCII a všechny ostatní kódy se do tohoto kódu budou transformovat na úrovni input procesoru. V souladu s tímto rozhodnutím též připravil fonty Computer Modern, které na toto ASCII kódování navazují. Svým rozhodnutím ovšem definoval jen prvních 128 pozic v kódu a významy znaků s kódem nad 128 nechal nedefinovány. Původní verze TEXu (do r. 1988) dokonce ani tyto znaky na vstupu nedovolovala. Dnes je volba vnitřního kódování znaků v TEXu nad hranicí 128 v rukou implementátorů národních instalací TEXu. Rozhoduje většinou kód základních národních fontů, použitých v TEXovské instalaci. Pokud mají další fonty odlišné kódování, implementují se do instalace prostřednictvím tzv. virtuálních fontů (viz [7]). V DOSu v emtexu je překódování na úrovni input procesoru implementováno pomocí tzv. tcp tabulek, které se načítají do TEXu při inicializaci formátu. Jakmile je formát vytvořen, je v něm už konverzní tabulka zahrnuta. V CSTEXu se používají formáty s tcp tabulkami, které konvertují například z kódování Kamenických, nebo z kódování PC Latin2 nebo jiného Pišvejcova kódování do kódu CS-fontů. Prvních 128 pozic (základní ASCII) je ponecháno beze změny. V UNIXu je potřeba překódovací algoritmus začlenit do zdrojového textu TEXu před kompilací programu. Většinou se to dělá pomocí změnového souboru k tex.web. Problematika se týká sekcí 20 až 24 ve zdrojovém kódu TEXu a jedná se o vektory xord a xchr. V případě, že se ponechá vnitřní kódování TEXu podle CS-fontů, pak není obvykle potřeba dělat žádné zásahy do zdrojového kódu TEXu, protože čeština v UNIXu je kódována výhradně podle ISO a CS-fonty na toto kódování navazují. Je to analogie Knuthova postupu, kdy byl pro 17

18 Kapitola 1. Vstupní části TEXu angličtinu zvolen vnitřní kód ASCII a kódování Computer Modern fontů na tento (sedmibitový) kód navazovalo. V UNIXu lze též použít patch pana Škarvady. Jeho algoritmy doplňují jinak standardní UNIXový změnový soubor pro tex.web. Po kompilaci TEXu je pak možné volit mezi různými kódovacími postupy prostřednictvím nastavení systémové proměnné. Není-li příslušná systémová proměnná nastavena, TEX neprovádí žádnou konverzi, což (jak již jsme uvedli) vyhovuje vnitřnímu kódu TEXu podle CS-fontů a vstupnímu kódu podle ISO Algoritmy input procesoru jsou v TEXu implementovány i v inverzní podobě. Pokud TEX potřebuje něco zapsat na terminál, do souboru log nebo do jiného souboru prostřednictvím \write nebo \message, jsou v činnosti tyto inverzní algoritmy. Jednotlivé řádky jsou na výstupu členěny způsobem, kterému rozumí příslušný operační systém. Provádí se samozřejmě též případné zpětné překódování. Ačkoli tedy v TEXu probíhá vše podle ASCII, na terminálu a v souborech log, aux apod. čteme při použití systému s Pišvejcovým kódováním veškeré texty podle Pišvejce. Pokud se v textu pro \write použije znak s kódem shodným s obsahem registru \newlinechar, pak se na výstupu místo tohoto znaku ukončí řádek a výstup dále pokračuje na novém řádku. Například: 29 \newlinechar \^^J \immediate\write16{druhý^^jřádek} Jedná se tedy o jakýsi protějšek k registru \endlinechar. Doporučuje se, aby všechny netisknutelné znaky, které vystupují na terminál nebo do souborů log, aux apod. byly nahrazeny sekvencí ^^ něco, například ^^Z nebo ^^e1. (Podrobněji o tomto formátu, viz následující sekci o token procesoru.) Tím máme zaručeno, že se terminály nezačnou chovat po obdržení nějakého řídicího znaku nedefinovaným způsobem. Mezi lidem počítačovým se takovému jevu říká rozsypaný čaj. Proto je rozumné, že například veškeré řídicí znaky z tabulky ASCII vystupují na terminál tímto způsobem. Třeba při tisku znaku ASCII 7 (BELL, česky zvonek) nám nebude terminál pískat, ale objeví se text ^^G. Při opětovném načtení (například ze souboru aux) si TEX na úrovni token procesoru zpětně konvertuje sekvenci ^^G na ASCII 7. Takže žádný problém. Problém ovšem nastává, pokud si chceme přečíst na terminálu nebo v souborech log, aux český text. Například místo slova řádek si přečteme ^^f8^^e1dek, což není příliš čitelné. Samozřejmě, TEXu to nevadí. Ten si takový text při zpětném načtení překonvertuje. Ale jak k tomu přijde člověk? Zde je tedy třeba před kompilací TEXu ze zdrojového textu tex.web rozhodnout, zda operační systém snese na terminálu znaky s kódy nad 128 a nedojde k efektu rozsypaný čaj. Pokud ano, pak je možné (zásahem do změnového souboru k tex.web, sekce 49) potlačit 18

19 1.3. Token procesor výstup znaků nad 128 ve formátu ^^ něco a místo toho podporovat formát přímý. To je výhodné i pro TEX samotný. Stačí totiž předefinovat kategorii znaku ^ a TEX po sobě texty v pomocných souborech obsahující ^^ něco nepřečte. V případě emtexu v DOSu je přímý výstup znaků nad 128 do souborů typu log podporován. Stejně je tomu v UNIXu po použití zmíněného patch pana Škarvady. Řídicí znaky ASCII (typu BELL) samozřejmě zůstávají ve formátu pomocí ^^ Token procesor Každý znak má v TEXu svoji kategorii, což je celé číslo v intervalu 0, 15. Token procesor bere ze vstupu řádky upravené input procesorem a na jeho výstupu je posloupnost tzv. tokenů. Token (čti toukn, přeložili bychom jako symbol, známka, znak, žeton, ale překládat nebudeme) je buď uspořádaná dvojice (ASCII kód, kategorie), nebo řídicí sekvence. Ve všech algoritmech, které následují za token procesorem se už nikdy nemluví o znacích vstupního textu, ale pouze o tokenech. Kdybychom chtěli vyložit chování token procesoru uživatelům, kteří se nechtějí stát programátory maker, mohli bychom pojem token zatajit a uvést jednoduše následující vlastnosti: Konec řádku je brán jako mezera a přechází se na další řádek. Od znaku % až do konce řádku je vše ignorováno (tzv. komentář). Mezeru z konce řádku lze zamaskovat komentářem (%). Více mezer vedle sebe se rovná jedné mezeře. Mezery zleva na řádku jsou zcela ignorovány. Prázdný řádek ukončuje odstavec. Řídicí sekvence jsou tvaru \ identifikátor. identifikátor obsahuje buď písmena, nebo jen jediný jiný znak. Za sekvencí typu \slovo jsou všechny následující mezery nevýznamné. Za sekvencí typu \$ je mezera významná. Čtenář této knížky ovšem nebude s tímto výkladem spokojen. Při programování maker TEXu se totiž bez pojmu token neobejde. Než se pustíme do přesného popisu činnosti token procesoru (jedná se o stavový automat), nastíníme hrubou ideu. Token procesor plní tyto úkoly: Jednotlivé řídicí sekvence interpretuje jako jeden token (např. slovo ). Skupiny mezer interpretuje jako jeden token mezera ( 10 ). Prázdný řádek převádí do tokenu par. Ostatní znaky se stanou tokenem typu uspořádaná dvojice (např. A 11 ). Některé kategorie interpretuje token procesor ve své režii (např. % 14 ). 19

20 Kapitola 1. Vstupní části TEXu Rozlišujeme dva různé typy tokenů. Prvním typem tokenu je uspořádaná dvojice (ASCII hodnota, kategorie). Kategorie udává další chování tohoto tokenu buď přímo v algoritmech token procesoru, nebo později. Kategorii přiděluje token procesor vstupním znakům podle tabulky kategorií, která se v průběhu zpracování může měnit (viz níže). Jakmile je token vytvořen, v dalším zpracování se už jeho kategorie nemění, ani v případě, že je změněna tabulka kategorií. Token typu uspořádaná dvojice budeme značit pomocí škatulky, např. A 11 znamená ASCII hodnotu znaku A a kategorii 11. Druhým typem tokenu je typ řídicí sekvence. Například sekvenci \slovo zpracuje token procesor jako token slovo. Tím jsme také uvedli způsob značení těchto tokenů; do rámečku budeme psát identifikátor řídicí sekvence. Upozorňujeme, že je třeba rozlišovat mezi tokenem $ a $ 3. První uvedený je token typu řídicí sekvence, který vzniká zápisem \$, zatímco druhý je typu uspořádaná dvojice a vznikl prostým zápisem znaku $ za předpokladu, že tento znak měl v tabulce kategorií hodnotu 3. V textu v této knize budeme pro tokeny typu řídicí sekvence používat jak značení \slovo, tak značení slovo. Druhou alternativu použijeme v případě, kdy chceme zdůraznit, že se jedná o token. Tabulka kategorií přiřazuje každému ASCII znaku právě jednu číselnou hodnotu v rozsahu 0 až 15, tj. kategorii. Následuje seznam všech kategorií TEXu. U každé je stručně uveden význam a dále seznam znaků, které mají obvykle tuto kategorii přiřazenu. Je-li u čísla kategorie hvězdička, pak to znamená, že tato kategorie má význam jen v algoritmech token procesoru a neobjeví se nikdy na jeho výstupu. Je-li za znakem uvedeno slovo (plain), pak příslušná kategorie není tomuto znaku nastavena implicitně (v initexu), ale je nastavena až ve formátu plain. kategorie význam výchozí přiřazení 0* uvození řídicí sekvence \ 1 otevření skupiny { (plain) 2 zavření skupiny } (plain) 3 přepínač matematického módu $ (plain) 4 separátor v tabulkách & (plain) 5* konec řádku ^^M (ASCII 13) 6 označení parametrů maker # (plain) 7 konstruktor mocniny ^ (plain) 8 konstruktor indexu _ (plain) 9* znak, který se ignoruje ^^@ (ASCII 0) (plain) 10 mezera 11 písmeno A až Z, a až z 12 ostatní znaky zbylé znaky 13 aktivní znaky ~, ^^L (plain) 14* uvození komentáře na řádku % 15* nedovolený znak ^^? (ASCII 127) 20