\hsize=30pc \vsize=45pc \emergencystretch=2em \hbadness=2000 \chyph \hyphenation{ASCII} \exhyphenpenalty=10000 \font\mflogo=logo10 \def\mf{{\mflogo META}\-{\mflogo FONT}} \def\CS{CS} \def\uv#1{\clqq#1\crqq} \def\LaTeX{L\kern-.36em\raise.5ex\hbox{\sevenrm A}\kern-.12em\TeX} \def\titul#1\par{{\bf#1}\medskip} \def\autor#1\par{{\it#1}\medskip} \def\sub#1.{\par\bigskip\noindent{\bf#1}\par\nobreak\medskip} \def\ps-{Post\-Script} \def\To{~$\longrightarrow$~} \chardef\\=`\\ {\obeyspaces \gdef\activespace{\obeyspaces\let =\ }} \def\setverb{\def\do##1{\catcode`##1=12}\dospecials} \def\begtt{\medskip\bgroup \parindent=0pt \setverb \activespace \def\par##1{\endgraf\ifx##1\par\leavevmode\fi ##1} \obeylines \startverb} {\catcode`\|=0 \catcode`\\=12 |gdef|startverb#1\endtt{|tt#1|egroup|medskip}} \titul Putování písmene ř z~klávesy na papír \autor Petr Olšák V~tomto článku podrobně rozeberu, co se odehraje v~počítači mezi zmáčknutím písmene ř na klávesnici a vytištěním písmene ř na papíře. Ono písmeno je v~jednotlivých fázích zpracování interpretováno jako číselný kód. Ukážeme, že se zdaleka nemusí jednat o~kód jediný. V~průběhu zpracování může písmeno ř (a~ostatní písmena a znaky, které používáme) absolvovat až sedm různých kódování, přičemž v~každém z~nich může (ale nemusí) být naše písmeno reprezentováno jiným kódem. Článek by měl dokumentovat velkou flexibilitu přístupu k~různým kódováním při zpracování dokumentu \TeX{}em. Uvidíme, že možností je mnoho a těžko bychom hledali u~jiného softwaru obdobu. Putování písmene ř rozdělíme do několika fází. V~každé fázi může být tento znak reprezentován jiným kódem. Jednotlivé fáze můžeme zhruba načrtnout do následujícího schématu: $$\vbox{ \def\ram#1{\vbox{\hrule\hbox{\vrule\strut\ #1 \vrule}\hrule}} \def\h#1{{\tt#1}} \let\par=\cr \obeylines \halign{\hfil#\hfil&\quad#\hfil \ram{klávesa ř} & \h K-kódování & ... hardwarové kódování klávesnice $\downarrow$ & ... ovladač klávesnice \h A-kódování & ... kódování aplikace textového editoru $\downarrow$ & ... uložení dokumentu na disk \h D-kódování & ... kódování dokumentu na disku $\downarrow$ & ... input preprocesor \TeX{}u \h I-kódování & ... kódování dokumentu na vstupní straně maker $\downarrow$ & ... expanze maker \h T-kódování & ... kódování na úrovni hlavního procesoru a v~dvi $\downarrow$ & ... expanze dvi podle virtuálních fontů \h F-kódování & ... kódování fontu, nebo jeho Encoding vektoru $\downarrow$ & ... Encoding vektor \h P-kódování & ... vnitřní kódování PostScriptového fontu \ram{tištěné ř} & }} $$ Uvedeme seznam nejběžnějších kódování, která se na úrovni jednotlivých fází zpracování obvykle v~českém a slovenském jazyce používají: $$\vbox{ \let\par=\cr \obeylines \halign{#\hfil&\quad#\hfil K-kódování &... scan kódy klávesnic A,D,I-kódování &... ISO-8859-2, Kamenických, PC-Latin2=CP852, CP1250, \dots I,T,F-kódování &... kódování \CS-fontů, T1=Cork, \dots F,P-kódování &... Adobe StandardEncoding, \dots }}$$ V~dalším textu se jednotlivými fázemi zpracování dokumentu budeme věnovat podrobněji. \sub K-kódování\To A-kódování. Stisknutí klávesy se reprezentuje číselným kódem, který je odeslán do počítače. Například na klávesnicích PC se jedná o~tzv.~\uv{scan kódy}, kde klávesy mají vesměs čísla podle svého rozmístění. Klávesa Esc má číslo jedna, klávesa A~číslo~30, S~31, D~32 atd. V~počítači pracuje ovladač klávesnice, který jednotlivou posloupnost stisků kláves interpretuje a běžící aplikaci již vrací aplikační kód. Je-li onou aplikací textový editor (což je při přípravě dokumentu pro \TeX{} obvyklé), pak aplikace zobrazí znak na obrazovce a uloží si jej do paměti. K~tomu zobrazení na monitoru potřebuje použít font, který musí mít rovněž A-kódování, jinak bychom byli zmateni. Přehled o~tom, co kdy bylo zmáčknuto a uvolněno a co to v~dané situaci znamená, musí udržovat ovladač klávesnice. Například stisk levé klávesy Shift vyvolá scan kód 42. Pokud uživatel klávesu drží, pak ovladač musí následující klávesy interpretovat odlišným způsobem. O~puštění klávesy Shift se ovladač dozví podle scan kódu 42+128. Ovladač klávesnice obvykle pracuje v~několika režimech (český/standardní). Naše klávesa ř samostatně neexistuje. Písmeno ř může být v~českém režimu vyvoláno buď použitím smluvené klávesy (obvykle klávesa~5/\%) nebo stiskem a uvolněním smluvené \uv{mrtvé klávesy} (obvykle klávesa~+/=) a následným stiskem klávesy r. Vše může vypadat i jinak. Záleží na tom, jak je ovladač klávesnice naprogramován. V~UNIXu je scan kód z~klávesnice zpracován rovněž ovladačem klávesnice (v~jádru operačního systému) na tzv. key kód. Pokud běží X~Window System, pak je key kód obvykle zpracován X~aplikací podle globální mapovací tabulky, společné všem aplikacím. Tuto tabulku je možné měnit programem {\tt xmodmap}. Aplikace může také převzít inteligenci ovladače klávesnice do svých rukou a starat se o~přepínání režimů klávesnice a transformaci znaků. Mám na mysli třeba Emacs při použití maker z~balíku {\tt emacs-czech}~[EC]. Kód znaku se tedy může měnit na třech místech: v~jádru systému, na úrovni globální mapovací tabulky a uvnitř konkrétní aplikace. Ve všech případech existují konfigurační možnosti, jak do konverzního algoritmu zasáhnout. Font, který používá aplikace k~zobrazení právě stisknutého znaku, je obvykle fontem, který je nějakým způsobem instalován v~operačním systému. A-kódování tedy volíme shodně s~kódováním fontu v~operačním systému. U~jiného druhu textového zpracování tím veškerá starost o~kódování končí (např. MS Word a jiné), protože pro tisk dokumentu používá aplikace rovněž fonty, které nabízí operační systém. My uživatelé \TeX{}u víme, že mezi fontem použitým v~operačním systému a fontem určeným pro kvalitní typografické zpracování sazby může být propastný rozdíl. Font operačního systému volíme takový, aby hezky vypadal a byl dobře čitelný na obrazovce, zatímco pro tisk volíme font, který nejlépe odpovídá typografickému záměru, kvalitě papíru, tiskové technologii apod. Proto se pusťme do dalších fází zpracování dokumentu. \sub A-kódování\To D-kódování. Jakmile požádáme aplikaci (textový editor), aby uložila dokument na disk, může aplikace při této činnosti spustit nějaký filtr, který může změnit kódování dokumentu. Například pro MS~Windows existují (prý) editory, které vytvářejí a zobrazují dokument v~CP1250, ale po uložení jej máme třeba v~PC-Latin2. Vstupní bránu \TeX{}u pak musíme připravit na to, že bude číst kódování v~PC-Latin2, ačkoliv pracujeme s~operačním systémem, který používá CP1250. Obvykle při ukládání dokumentu kódování neměníme. V~této fázi zpracování budeme měnit kódování asi jen ve zcela ojedinělých a opodstatněných případech. Na druhé straně je běžnou praxí převádět dokumenty před zpracováním \TeX{}em z~jednoho kódování do druhého. Označme to jako D$_1$-kódování\To D$_2$-kódování. Ve většině \TeX{}ovských instalací jsou konverzní utilitky k~dispozici. Konverzi provádíme například tehdy, když obdržíme dokument v~jiném kódování, než používáme v~našem systému. \sub D-kódování\To I-kódování. Tato konverze již probíhá uvnitř \TeX{}u na úrovni jeho input procesoru. Ve zdrojovém kódu \TeX{}u jsou implementovány vektory {\tt xord} a {\tt xchr}, které se starají o~odstínění kódování použitého v~hostitelském operačním systému od vnitřního kódování \TeX{}u. Toto vnitřní kódování se předpokládá jednotné a nezávislé na kódování, které je podporováno hostitelským operačním systémem. To byl původní záměr autora \TeX{}u. Knuth v~sedmibitových dobách uvažoval existenci systémů s~kódováním EBDIC, zatímco on volí v~\TeX{}u kódování ASCII. Na systémy s~ASCII jsou tedy vektory {\tt xord} a {\tt xchr} nastaveny tak, že se chovají jako identické zobrazení, zatímco na těch druhých systémech dnes už vymřelých dinosaurů byly uvedené vektory příslušným způsobem pozměněny. Je třeba poznamenat, že vektory {\tt xord} a {\tt xchr} se starají o~oboustranné konverze, tj. nejen \uv{dovnitř} \TeX{}u, ale též při výstupu na terminál a do logu (nikoli do dvi). Proto \TeX{} nabízí všechny své textové výstupy v~kódování podle hostitelského operačního systému, ačkoli si sám interně může pracovat v~jiném kódování. Bohužel, nastavení překódovacích vektorů {\tt xord} a {\tt xchr} je možné jen před kompilací \TeX{}u ze zdrojového souboru {\tt web}. Za provozu \TeX{}u lze měnit tyto vektory jen na některých implementacích. Tam, kde změna kódování za provozu není možná, je obvykle pevně nastaveno identické zobrazení. Implementace \TeX{}u zvaná em\TeX{} (DOS, OS/2) je vybavena možností uvedené vektory měnit velmi volně prostřednictvím tzv. {\tt tcp} tabulek. Tyto tabulky lze nejprve editovat, pak převést do binární podoby a předložit je \TeX{}u v~době inicializace formátu. Většinou se používají tabulky, které mají na vstupní straně kódování podle Kamenických, PC-Latin2 nebo CP1250 a na výstupní straně kódování \CS-fontů nebo T1 nebo expanze na \TeX{}ovské sekvence. Poslední možnost způsobí, že naše {\tt ř} vstupuje do \TeX{}u nakonec jako {\tt \\v r}. Tuto třetí možnost nedoporučuji, protože znemožňuje výskyt písmene~ř ve verbatim prostředí. UNIXové instalace \TeX{}u, které vycházejí z~implementace {\tt web2c} a jsou ozáplatovány kódem podle {\tt ftp://ftp.muni.cz/pub/tex/local/cstug/skarvada} mají rovněž možnost měnit uvedené vektory {\tt xord} a {\tt xchr} za provozu \TeX{}u, ovšem kódovací tabulku nemůžeme editovat, pouze si můžeme vybrat jednu z~několika málo možností. Mezi zajímavou možnost patří zřejmě konverze ISO-8859-2\To T1. Existuje i jiná úprava \TeX{}u, kterou jsem si udělal sám, a která umožňuje přímý přístup k~vektorům {\tt xord} a {\tt xchr} za běhu \TeX{}u~[ENCTEX]. \sub I-kódování\To T-kódování. Než se naše písmeno {\tt ř} propracuje z~input procesoru do hlavního procesoru \TeX{}u, může s~ním expand procesor pořádně zatočit. Této problematice se budeme nyní věnovat podrobněji. V~nejběžnějším případě, tj. když není vstupní písmeno {\tt ř} aktivní, se nestane nic. Takže I-kódování je rovno T-kódování. Tak tomu je například v~csplainu. V~\LaTeX{}u též implicitně nedochází ke konverzi těchto dvou kódování. Pokud se ale použije balík {\tt inputenc.sty}, například: \begtt \usepackage[cp852]{inputenc} \endtt \noindent pak se všechny znaky s~kódy nad 128 stávají aktivními a jejich význam je definován v~souboru {\tt *.def} (v~našem příkladě {\tt cp852.def}) prostřednictvím sekvence {\tt \\DeclareInputText}. Například pro písmeno {\tt ř}, které je v~CP852 kódováno jako {\tt \char`\"FD} (hexadecimálně), najdeme v~definičním souboru: \begtt \DeclareInputText{"0FD}{\v r} \endtt Znamená to, že náš znak {\tt ř} se bude expandovat na {\tt \\v r}. Co se dále stane s~touto sekvencí, záleží na volbě T-kódování, a tím se budu zabývat za chvíli. Ve stylu {\tt inputenc.sty} je zajímavým způsobem řešeno definování znaku, který je aktivní, a jehož kód makro {\tt \\DeclareInputText} přečte ze svého parametru. Je k~tomu použit primitiv {\tt \\uppercase} zhruba takto: \begtt \def\DeclareInputText #1{\bgroup \uccode`~=#1 \uppercase{\egroup \def~}} \endtt \noindent Zápis \begtt \DeclareInputText{"0FD}{\v r} \endtt \noindent tedy expanduje na \begtt \def ř{\v r} \endtt \noindent přičemž ono {\tt ř} je aktivní token kategorie 13 s~kódem {\tt \char`\"0FD}. Jak je to uděláno? Znaku {\tt \char`\~} je přechodně (mezi {\tt \\bgroup} a {\tt \\egroup} přiděleno {\tt \\uccode} odpovídající načtenému parametru, takže primitiv {\tt \\uppercase} změní v~prvním svém průchodu znak {\tt \char`\~} na aktivní {\tt ř}. V~druhém průchodu se uzavírá skupina ({\tt \\egroup}) a otevírá definice {\tt \\def ř}. V~případě \LaTeX{}u existuje jeden drobný zádrhel se zápisem {\tt \\'a} například pro písmeno {\tt á}. Makro {\tt \\'} má totiž v~\LaTeX{}ovém prostředí tabbing pozměněný význam. Kdyby uživatel v~tomto prostředí použil písmeno {\tt á} a ono by se expandovalo na {\tt \\'a}, pak by se uživatel asi nestačil divit. Balík {\tt inputenc.sty} proto používá pro {\tt á} expanzi na {\tt\\@tabacckludge'a} a \LaTeX{}ové jádro expanduje {\tt\\@tabacckludge'} na {\tt \\'} jen v~případě, že zrovna nejsme v~prostředí tabbing. Pokud v~něm jsme, řeší \LaTeX{} problém dlouhého á jinak. V~\LaTeX{}u a jmenovitě v~NFSS je velmi důkladně ošetřeno další chování sekvencí typu {\tt \\v r}, resp. {\tt \\'a}. To záleží na volbě T-kódování, kterému \LaTeX{} říká {\tt \\fontencoding}. Je-li zvoleno kódování CM fontů, které se v~\LaTeX{}u jmenuje OT1, pak zmíněné sekvence expandují na {\tt\\accent20r}, resp. {\tt \\accent19a}. To je řečeno v~souboru {\tt ot1enc.def} na následujících řádcích: \begtt \DeclareTextAccent{\'}{OT1}{19} \DeclareTextAccent{\v}{OT1}{20} \endtt T-kódování je vnitřní \TeX{}ovské kódování, ve kterém jsou načteny vzory dělení slov a ve kterém \TeX{} vystupuje do {\tt dvi}. Aby bylo možno použít české dělení slov, musí být T-kódování bezpodmínečně osmibitové. Předchozí příklad s~kódováním OT1 je tedy pro češtinu nepoužitelný. Uvažujme proto například kódování \CS-fontů, kterému \LaTeX{} říká IL2. V~souboru {\tt il2enc.def} je řečeno k~našemu písmenu {\tt ř} toto: \begtt \DeclareTextComposite{\v}{IL2}{r}{248} \endtt \noindent Pokud se použije font s~kódováním IL2, pak bude sekvence {\tt \\v r} expandovat na znak s~kódem 248. Podobných řádků, jako je tento, najdeme v~souboru {\tt il2enc.def} více. \LaTeX{} se do tohoto souboru podívá, pokud je nastaveno {\tt \\fontencoding} na IL2. Uživatel může toto kódování nastavit takto: \begtt \usepackage[IL2]{fontenc} \endtt Jak je makro {\tt \\DeclareTextComposite} definováno, nebudu pro nedostatek místa rozvádět. Zkuste si nastavit {\tt \\tracingmacros=2} a nechte zpracovat \LaTeX{}em sekvenci {\tt \\v r} jednou v~režimu OT1 a jednou třeba při IL2. V~obou případech se po pohledu do {\tt log} souboru zhrozíte, jak intenzivně a komplikovaně je tímto problémem zatížen expand procesor. Nicméně víme, že expanze nakonec při OT1 vede na {\tt \\accent20r} zatímco při IL2 se věc expanduje na samotný znak s~kódem~248. Aktivovat akcentované znaky použitím balíku {\tt inputenc.sty} může mít smysl třeba tehdy, pokud chceme v~průběhu jednoho dokumentu měnit I-kódování nebo T-kódování. Na oba případy jsou uvedená makra připravena. Při změně I-kódování (pro přepínání píšeme {\tt\\inputenc\char`\{KÓD\char`}}) makro jednoduše předefinuje všechny aktivní znaky podle nového kódu. Při změně T-kódování (pro přepínání píšeme {\tt\\fontencoding\char`{jinykod\char`}}) se zase změní způsob expanze sekvencí {\tt \\v}, {\tt \\'} a podobných. Chceme-li změnit T-kódování v~rámci zpracování jediného dokumentu, nesmíme zapomenout současně přehodit vzory dělení slov, které jsou závislé na použitém T-kódování. Je tedy potřeba načíst před zpracováním dokumentu tolik variant vzorů dělení, kolik budeme používat různých T-kódování. Změna tohoto kódování uvnitř odstavce je ovšem velice problematická. Je sice možno uvnitř odstavce změnit vzory dělení, ale už není možno změnit tabulku {\tt \\lccode} jednotlivých znaků, která je interpretována globálně pro celý odstavec. Bohužel tato tabulka také ovlivňuje dělení slov. Je proto lepší T-kódování v~průběhu sazby nestřídat a raději na různě kódované fonty navázat prostřednictvím virtuálních skriptů. Je-li I-kódování${}\not={}$T-kódování, pak je potřeba upravit konverzi znaků z~malých na velké a naopak, na kterou dříve stačily primitivy {\tt\\uppercase} a {\tt\\lowercase}. Tyto primitivy totiž pracují podle {\tt\\lccode} a {\tt\\uccode} znaků {\it před\/} případnou expanzí posloupnosti tokenů. Přitom {\tt\\lccode} musí být nastaveno podle T-kódování, protože tyto kódy mají přímou souvislost s~dělením slov. Hodnoty {\tt\\uccode} se z~důvodu symetrie také nastavují podle T-kódování. Máme-li tedy I-kódování rozdílné, musíme nejprve provést expanzi a pak teprve použít primitiv {\tt\\uppercase} nebo {\tt\\lowercase}. Problém může řešit makro {\tt\\Uppercase}, které definujeme třeba takto: \begtt \def\Uppercase #1{\edef\act{\uppercase{#1}}\act} \endtt Uděláme si nyní malé shrnutí konverze I-kódování\To T-kódování v~\LaTeX{}u. {\medskip\def\p#1. {\noindent\hbox to2em{#1.\hss}} \p 1a. Znak ř není aktivní: I-kódování = T-kódování.\par \p 1b. Znak ř je už v~I-kódování rozložen na {\tt \\v r}: jdi na 2.\par \p 1c. Znak ř je aktivní (použitím {\tt inputenc.sty}): jdi na 3.\par \p 2a. Jsme ve verbatim prostředí: vytiskne se {\tt \\v r}.\par \p 2b. Nejsme ve verbatim prostředí: {\tt \\v r}\To T-kódování.\par \p 3. I-kódování\To {\tt \\v r}\To T-kódování (bez závislosti na verbatim prostředí).\par \medskip} Cílem tvůrců maker na konverzi I-kódování\To T-kódování v~\LaTeX{}u je snaha po uživatelsky příjemnější přenositelnosti dokumentů na úrovni {\tt *.tex} a oddělení problematiky vstupního kódování dokumentu od kódování fontů. Pokud každý \uv{standardní} \LaTeX{}ový dokument bude obsahovat volání stylu {\tt inputenc.sty}, pak je vlastně v~hlavičce řečeno, jaké vstupní kódování použil autor dokumentu. Dokument pak není závislý na kódování, které používá příjemce dokumentu. Příjemce se totiž nemusí starat o~konverzi dokumentu do svého kódování, ale rovnou dokument \LaTeX{}uje. Tento záměr má ale k~ideálu hodně daleko. Příjemce se totiž musí starat, jak jsou v~dokumentu vyznačeny konce řádků. Pokud to nevyhovuje použitému operačnímu systému, musí provést před zpracováním konverzi dokumentu (o~problémech s~konci řádků viz [TBN] stranu 15). Může se také stát, že příjemce dostane dokument z~elektronické pošty ve \uv{svém} kódování, zatímco odesílatel jej poslal v~jiném \uv{svém} kódování~--- o~konverzi se automaticky postaraly systémy pro přenos elektronické pošty. Pak zápis v~hlavičce dokumentu o~kódování odesílatele dokonce lže a může působit potíže. Snaha o~co největší pohodlí uživatele je oprávněná právě u~nástrojů, které umožňují přenos dokumentů z~různých operačních systémů. V~tomto případě jde o~programy na práci s~elektronickou poštou. Snažit se o~totéž v~samotném \LaTeX{}u mi připadá nevhodné s~tím, že to přináší více komplikací než užitku. Laického uživatele většinou vůbec nezajímá, jaké používá kódování. Takže se mu může jevit požadavek na uvedení tohoto údaje do hlavičky v~{\tt\\usepackage[...]\char`\{inputenc\char`\}} jako zbytečnost, o~kterou by se měl správně nainstalovaný systém postarat sám bez jeho pomoci. Používání tohoto balíčku také předpokládá, že A-kódování = D-kódování = I-kódování, což neguje původní Knuthův záměr, aby se rozdílnosti použitých operačních systémů řešily na úrovni D-kódování\To I-kódování. Pokud jsme po zpracování \TeX{}em ztratili přehled o~tom, jak dopadlo naše písmeno ř (to se vzhledem ke složitosti cesty od D-kódování po T-kódování může stát), pak je vhodné se podívat přímo do dvi souboru. Uděláme jednoduchý \TeX{}ový soubor, který tiskne do dvi pouze jediné písmeno {\tt ř}. Pak použijeme program {\tt dvitype}, který vypíše obsah dvi souboru v~textové podobě. Najdeme tam například povel pro sazbu znaku písmene {\tt ř} jako {\tt set\char`\_1 248}. \sub I-kódování\To T-kódování --- další možnosti. Při popisu transformace mezi I-kódováním a T-kódováním nesmíme zapomenout na běžné situace, které vlastně dělají \TeX{} \TeX{}em. Jedná se o~tyto možnosti: (1)~transformace mezi zápisem názvu makra a výsledným kódem v~{\tt dvi}, (2)~transformace v~matematickém módu podle {\tt\\mathcode} a (3)~proměna skupin znaků na ligatury. Transformace kontrolních sekvencí na výstup do {\tt dvi} je řízena makrojazykem \TeX{}u, který má v~této oblasti velmi široké možnosti. Z~důvodu stručnosti uvedeme jen jeden z~mnoha příkladů. Sekvence {\tt\\alpha} na vstupu se při použití rodiny fontů Computer Modern převede na kód {\tt\char`"0B} (hexadecimálně) ve fontu {\tt cmmi*}. Vysvětlit přesně, jak je to zařízeno, by bylo na delší vypravování, takže bez komentáře pouze zmíním, že to souvisí s~touto deklarací: \begtt \mathchardef\alpha="010B \endtt V~matematickém módu podléhají transformaci nejen kontrolní sekvence, ale i všechny běžné znaky. Napíšeme-li například {\tt\$-\$}, pak toto \uv{mínus} se při použití rodiny Computer Modern převede na znak s~kódem 0 ve fontu {\tt cmsy*}, protože bylo v~makrojazyku řečeno: \begtt \mathcode`\-="2200 \endtt Nakonec zmíním přeměnu skupin znaků na ligaturu. Tato vlastnost je definována v~metrice fontu {\tt tfm}. Proměna v~ligaturu se odehrává na úrovni T-kódování. Máme-li například na vstupu {\tt ---} a je zrovna použit font {\tt cmr10}, pak se tyto tři znaky promění ve znak jediný s~kódem {\tt\char`"7C}, tj. znak \uv{---}. \sub T-kódování\To F-kódování. Pod F-kódováním rozumíme kódování použitých fontů ve formátu PK, \mf{}u nebo Encoding vektoru \ps-ového fontu. Je-li v~{\tt dvi} odkazováno na font, který je instalován jako {\tt *.mf}, {\tt *.pk} nebo \ps- a není přítomen skript virtuálního fontu {\tt *.vf}, je T-kódování~=~F-kódování. To je dosti častý případ. Zde ale rozebereme případ, kdy mezi kódováním {\tt dvi} souboru (T-kódováním) a F-kódováním stojí skript virtuálního fontu. Ten může obsahovat požadavek na změnu pozice znaku. Uvedeme abstraktní příklad. Nechť naše písmeno ř je v~{\tt dvi} na pozici 176 a má být vysázeno fontem {\tt vcsr10}. Tento font je virtuální a odkazuje na font {\tt csr10}, přitom pozici 176 mapuje na pozici 248. Pak bude nakonec naše písmeno ř sázeno fontem {\tt csr10} z~pozice 248. Uvedeme nyní, jak takový virtuální font {\tt vcsr10} zhruba vypadá. Především někde v~instalaci musí být přítomen soubor {\tt vcsr10.vf}. Je tam, kde ho najdou použité {\tt dvi} ovladače. Chceme-li se mu podívat na zoubek, převedeme jej do čitelné podoby pomocí programu {\tt vftovp}. Po konverzi najdeme v~souboru {\tt vcsr10.vpl} mimo jiné tyto informace: \begtt (VTITLE Pouze priklad) ... (MAPFONT D 0 (FONTNAME csr10) ) ... (CHARACTER O~260 (CHARWD R 0.391668) (CHARHT R 0.694445) (MAP (SETCHAR O~370) ) ) \endtt Vidíme tedy, že znaky jsou implicitně čerpány z~fontu {\tt csr10} (viz {\tt MAPFONT D 0}) a že pozice 260 (oktalově) je vysázena jako znak z~implicitního fontu z~pozice 370 (rovněž oktalově). Takto je možné překódovat i ostatní pozice. Podrobněji o~virtuálních fontech~--- viz například [TST] stranu 75. Na úrovni T-kódování\To F-kódování může též dojít k~\uv{rozkladu} našeho písmene ř na samostatné písmeno r a samotný háček. Prostřednictvím virtuálních skriptů lze {\tt dvi} ovladači říci, ve kterém fontu hledat toto písmeno a akcent, a popsat přesný způsob, jak tyto segmenty sesadit k~sobě. V~naší předchozí ukázce virtuálního fontu by mohlo být napsáno: \begtt (CHARACTER O~260 (CHARWD R 0.391668) (CHARHT R 0.694445) (MAP (PUSH) (PUSH) (MOVERIGHT R -0.054167) (SETCHAR O~24) (POP) (SETCHAR C r) (POP) ) ) \endtt Poznamenejme, že tato praxe \uv{rozkladu} znaku právě popsaným způsobem je hojně používána při použití standardních \ps-ových fontů v~\CS\TeX{}u. U~těchto fontů se totiž nepředpokládá, že v~nich bude kresba písmene ř samostatně obsažena, protože třeba většina fontů z~Adobe Type Library obsahuje pouze sadu znaků podle tzv.~Adobe StandardEncoding. Tato sada má písmena anglické abecedy a samostatné akcenty všeho druhu, takže všechna akcentovaná písmena naší abecedy lze prostě poskládat ze segmentů. Pokud ale \ps-ový font obsahuje kompletní znak ř, pak není třeba provádět zmíněný rozklad na segmenty a nastupuje poslední fáze našeho překódovacího martyria: \sub F-kódování\To P-kódování. Pod pojmem P-kódování rozumíme pořadí \ps-ových procedur ve fontu na vykreslení jednotlivých znaků. Toto pořadí je z~hlediska sázecího systému naprosto nezajímavé, protože font je v~\ps-ovém kódu použit vesměs prostřednictvím operátoru {\tt show} (a alternativ). Tento operátor konvertuje pozici sázeného znaku na název procedury pro vykreslení požadovaného znaku. Konverze je definována prostřednictvím tzv.~Encoding vektoru, který je součástí každého \ps-ového fontu. Obsahuje obvykle 256 jmen \ps-ových procedur. Vysvětlíme si to na příkladě. Nechť \ps-ový font obsahuje proceduru na vykreslení kompletního znaku~ř. Tato procedura má obvykle název {\tt /rcaron}. Předpokládejme, že naše písmeno ř má v~F-kódování pozici 248. Operátor {\tt show} se při požadavku na vykreslení tohoto znaku podívá do Encoding vektoru na pozici 248 a měl by tam najít název {\tt /rcaron}. To je název procedury, která je použita pro vykreslení požadovaného znaku. RIP nyní interpretuje proceduru {\tt /rcaron} a znak vykreslí. Sláva, konečně vidíme znak ř po mnoha zákrutách na papíře\kern.1em! Může se stát, že máme nějaký \ps-ový font s~úplnou sadou české abecedy a že nám nevyhovuje jeho kódování. Jak vyplynulo z~předchozího, není nic snadnějšího, než pozměnit tomuto fontu Encoding vektor. Ten najdeme v~čitelné podobě například v~souborech s~příponou {\tt pfb} nebo {\tt pfa}. Před editováním je vhodné převést font z~formátu {\tt pfb} do {\tt pfa} (například pomocí balíku {\tt t1utils}, programy {\tt t1binary} a {\tt t1ascii}) a v~tomto formátu provést požadované změny Encoding vektoru. Vlastní algoritmy procedur bývají většinou zašifrované, ovšem to nám nevadí. Nakonec převedeme font zpět do formátu {\tt pfb} a máme jej připraven v~požadovaném kódování. Pokud je font přímo implementován v~\ps-ovém RIPu a jeho sada znaků obsahuje úplnou českou abecedu, pak překódování takového fontu můžeme provést níže uvedenými povely, které zařadíme na začátek \ps-ového kódu. V~tomto případě nelze přímo přepsat Encoding vektor, protože font je speciální případ tzv.~\uv{slovníku}, který je nastaven pouze ke čtení. Je proto potřeba tento slovník zkopírovat, v~kopii pozměnit Encoding vektor a označit jej jako nový font pod jiným názvem. Například v~RIPu máme font {\tt Helvetica-E} s~Encoding vektorem podle CP1250. My bychom ale chtěli používat tento font v~kódování ISO-8859-2. Připravíme si proto Encoding vektor v~našem kódování (kráceno): \begtt /ISOLatin2Encoding [/.notdef /./notdef ... /space /exclam /quotedblright /numbersign /dollar /percent ... /at /A /B /C /D ... /rcaron /uring /uacute /uhungarumlaut /udieresis /yacute ...] def \endtt \noindent a definujeme nový font s~názvem {\tt Helvetica-ISOLatin2}: \begtt /Helvetica-E findfont dup length dict begin {1 index /FID ne {def} {pop pop} ifelse} forall /Encoding ISOLatin2Encoding def currentdict end /Helvetica-ISOLatin2 exch definefont pop \endtt \noindent Nakonec místo fontu {\tt Helvetica-E} použijeme font {\tt Helvetica-ISOLatin2}. Podrobněji o~této technologii viz [RB]. Zásahy do fontu na úrovni F-kódování\To P-kódování jsou nezávislé na použitém sázecím systému. Není-li ale k~dispozici \ps-ový font s~úplnou sadou českých znaků, pak je nutno provést \uv{rozklad} akcentovaných znaků na segmenty už na úrovni T-kódování\To F-kódování, což je ovšem výsadou \TeX{}ovských instalací a virtuálních fontů. Výsadou \TeX{}ovských instalací je rovněž ovladač {\tt dvips}, kterému můžeme sdělit požadovaný Encoding vektor použitého fontu přímo prostřednictvím konfiguračního souboru {\tt psfonts.map}. Je-li tam například napsáno: \begtt csr10 dcr10 "XL2encoding ReEncodeFont"