TeX – 6 (fonty)

27. 11. 2013 | Petr Olšák | Různé | 5718×

Stejně jako potřebujeme cihly pro stavbu baráku, neobejdeme se bez fontů při přípravě sazby. Můžeme použít cihly kvalitní i méně kvalitní a podle toho dopadne stavba. Můžeme taky použít cihly různých technologií, což ovlivní naše pohodlí při stavbě, ale nakonec to ve výsledku nemusí být vidět. O tom, jak přistupuje TeX ke svým „cihlám sazby“, si povíme v tomto a příštím díle seriálu.

Obsah

• Metriky a kresby znaků
• Metrika TFM a možnosti její změny
• Virtuální fonty
• Metafont
• PostScriptové fonty

Metriky a kresby znaků

Font obsahuje dva druhy informace:

• Metrické informace obsahují šířky a výšky jednotlivých znaků a jejich případných přetahů pod účaří (tzv. hloubky). Dále obsahují informace o kerningových párech, což je seznam výjimek v řazení jednotlivých dvojic znaků za sebou (typicky třeba AV je třeba přisunout blíž k sobě, aby to opticky vypadalo, že jsou stejně daleko od sebe jako třeba IL). Konečně metrické informace obsahují informace o ligaturách: že se má třeba f a i proměnit ve fi.
• Kresby znaků (glyphs) jsou procedury ve fontu, které vykreslí jednotlivé znaky.

Sázecí program má za úkol na základě metrických informací fontů rozvrhnout optimální rozmístění znaků na stránce. Algoritmus, který řeší tento úkol, nepotřebuje vůbec použít kresby znaků. Teprve, až je o umístění znaků rozhodnuto a uživatel chce vidět, jak to dopadlo, je potřeba jinými algoritmy sazbu vykreslit. Tyto dvě fáze přípravy sazby důsledně rozlišil Knuth a navrhnul TeX jako algoritmus pracující jen s metrickými informacemi. Takže klasický TeXový výstup (DVI) obsahuje pouze informaci o definitivním rozmístění znaků a odkazy na názvy použitých fontů. Problém vykreslení znaků pak řeší až programy, které následně čtou DVI. V případě konvertoru dvips ani ten znaky nevykresluje, jen vkládá do PostScriptového výstupu procedury k vykreslení (provádí tzv. download fontů). Kresbu realizuje až PostScriptový RIP (raster image procesor), kterým je GhostScript pro zobrazení na obrazovce a tisk na tupých tiskárnách nebo třeba speciální RIP uvnitř tiskáren a jiných tiskových zařízení.

PdfTeX při výstupu do PDF v prvé fázi taky pracuje jen s metrikami fontů a teprve při závěrečné sumarizaci stránek PDF výstupu k nim připojuje použité fonty, jejichž znaky vykreslí PDF rasterizér.

Klasický TeX nespolupracuje s fonty instalovanými v operačním systému, ale má je uloženy ve svém datovém adresáři a musejí tam být připraveny ve dvou formách: metriky TFM (TeX fonts metrics) a další zdroje pro kresbu znaků. TeX samotný pro sazbu využije jen TFM. Existují konvertory z obvyklých formátů do TFM (například afm2tfm). Toto dělení fontů do dvou částí bylo opuštěno až nedávno v souvislosti s OTF (OpenType formát). XeTeX nebo LuaTeX si z OpenType fontu přečtou nejprve metrické informace pro sazbu a později při výstupu sazby do PDF si z něj přečtou kresby použitých znaků pro download. Pochopitelně XeTeX i LuaTeX umějí číst i TFM stejně jako klasický TeX nebo pdfTeX.

Metrika TFM a možnosti její změny

Chce-li se odborník podívat do binární metriky TFM, může použít Knuthem připravený program tftopl, který metriku převede do čitelné podoby. Může pak v editoru učinit třeba korekce a vytvořit modifikovanou TFM metriku pomocí zpětného konvertoru pltotf. V diskusi pod čtvrtým dílem seriálu byl postesk, že ve fontech obvykle neexistuje ligatura fľ například pro slovenské slovo fľaša. Autorovi dotazu jsem mohl taky poradit toto: programem Fontforge či podobným si do použitého fontu ligaturu flcaron dokreslete. Na to nepotřebujete být ani moc velký výtvarník, stačí se podívat do fontu, jak je udělaná ligatura fl a dále lcaron a tyto dvě věci dát nějak dohromady. Dále pomocí tftopl a pltotf přidejte informaci o ligatuře do metriky. Tím vzniká řešení bez kompromisů, po kterém volal jeden diskutující. Dvojici f a ľ bude od této chvíle TeX automaticky nahrazovat ligaturou fľ. Přitom je jedno, v jakém formátu ten font je, není nutné použít OpenType (ale je to taky možné).

Virtuální fonty

Pro TeX je možné vytvořit virtuální font, obsahující znaky jiných fontů třeba jinak kódované a taky doplněné o kompozity (např. háček a písmeno). V TFM pro TeX se tyto znaky tváří jako jeden celek, takže TeX s nimi pracuje jako s kompaktními znaky. Teprve algoritmy, které řeší vykreslení nebo download skutečného fontu, se podívají do popisu virtuálního fontu a dodatečně podle toho vytvoří kompozitní znaky. Popisy virtuálních fontů jsou binární a mají příponu vf. Je možno je rozkrýt pomocí Knuthova programu vftovp a případně zpětně sestavit pomocí vptovf. Tato metoda je v TeXu bohužel poměrně rozšířená při použití starších PostScriptových fontů, které neměly úplné sady například naší abecedy, ale byly tam samostatně písmena a akcenty. Píši bohužel, protože toto řešení přináší problémy: text je ve výstupním PDF nevyhledatelný. Někteří plagiátoři to naopak mohou považovat za výhodu. Nicméně jsem loni opravil implementaci základní sady 35 PostScriptových fontů v il2 kódování tak, že se virtuálním fontům vyhýbá, protože v současných PostScriptových fontech distribuovaných s TeXem je naše abeceda úplná.

Metafont

V době vzniku TeXu neexistoval PostScript, natož OpenType. Výkony počítačů nebyly na takové úrovni, aby dokázaly z matematických popisů (Bézierovy křivky) vytvářet rastry v okamžiku náhledu dokumentu nebo tisku (on the fly). Bylo tedy potřeba rastry pro každé potřebné zařízení připravit dopředu. Pro tyto účely vytvořil Knuth program Metafont, který je druhou součástí jeho softwarového odkazu k digitální typografii. Třetí součást tohoto odkazu jsou Computer Modern fonty vytvořené jako zdrojové soubory pro Metafont.

Knuth vytvořil Metafont s podobnou důkladností, jako TeX: má expand-like jazyk, umí řešit geometrické úlohy (například nalezení průsečíku dvou křivek) podobně jako např. Geogebra, ovšem bez grafického rozhraní. Čáry podél křivek je možné vykreslovat zvoleným perem libovolného konvexního tvaru (od kulaté redisky po seříznutou špičku). Každý znak fontu je napsán jako procedura, která může pracovat s globálními parametry. Pro Computer Modern fonty použil Knuth 64 takových parametrů, kterými řídil jednotlivé vlastnosti písma: šířku dříku, průměr zrna, šířku vlasového tahu, poloměr u náběhu na serify atd. Za zcela ojedinělé lze pokládat, že všechny řezy Computer Modern fontů (roman, bold, strojopis, sans-serif) jsou vytvořeny ze stejných procedur, jen s jinak nastavenými globálními parametry. Jemným strkáním do těchto parametrů můžete vytvořit další analogické řezy. Tato vlastnost dala název tomu programu: META. Tedy možnost generovat více řezů ze stejných zdrojů.

Metafont z popisů znaků generuje jednak rastr pro potřebné zařízení (např. s nastaveným konkrétním dpi, s nastavenými korekcemi slévání inkoustu atd.) a také generuje TFM pro TeX. Pokud TeX nenajde potřebný font, většinou se v distribuci spustí skript na dogenerování TFM Metafontem. To pochopitelně dnes moc nebude fungovat, protože dnes fonty v Metafontu obvykle kódované nejsou.

Knuth zřejmě neodhadl požadavky tvůrců písma: ti nepotřebují programovat Metafontí procedury. Spíš potřebují software, který jim ze skenů předloh starých tisků generuje obtahy a tyto obtahy konvertuje do formátu písma. Dále potřebují interaktivní grafické rozhraní na korektury písma. Takže pro popis jednotlivého znaku jim stačí Bézierovými křivkami deklarovat obrysy znaku, nepotřebují používat složitosti Metafontu. To je zřejmě důvod, proč byl Metafont odsouzen na propadliště dějin. Pozůstatek Metafontu najdeme v dnes používaném programu Metapost, který má stejné schopnosti, jako Metafont, ale doplněné o další možnosti a o výstup do PostScriptu. Nadšenci, kteří si zvykli na jazyk Metafontu, generují dnes obrázky geometrického charakteru Metapostem. Tento software prostřednictvím knihovny MPlib je též propojen s LuaTeXem.

Já jsem v Metafontu vytvořil písmo slabikář, které je zajímavé tím, že naplno využívá ligaturního mechanismu TeXu, tzv. „zobecněných ligatur“. Mezi jednotlivé znaky písma a na okraje slov se automaticky vkládají rozličné čárečky, aby psané písmo mělo dokonalé navazování.

Vlastnosti písma slabikář jsem podrobně popsal ve svém článku (1997) a písmo jsem též převedl do PostScriptu. Jednou za čas se objeví prosba nějakého uživatele, že by to chtěl použít např. ve Wordu. Odpovídám: toto je ukázka speciálních vlastností TeXu, bez TeXu to tedy použít nelze. V současné době svítá naděje pro tyto uživatele převést font do OpenType. Pokus už tu byl, ale nebyl završen zcela úspěchem, protože některé věci formát OpenType řeší jinak a na tuto obecnost ligaturního algoritmu (který TeX umí od roku 1982) dosud nemá.

PostScriptové fonty

Obvyklý formát fontů v PostScriptu je Type1. Formát zahrnuje soubor s příponou afm s metrickými informacemi a soubor pfb s obrysovými křivkami znaků. Formát afm je převoditelný do TeXového TFM pomocí afm2tfm. PdfTeX dokáže vybrat použité znaky z pfb pro download do výstupního souboru PDF. Klasický TeX vytvoří DVI a o download se postará konvertor dvips. Pochopitelně LuaTeX i XeTeX umějí s Type1 fonty pracovat také, ale navíc umějí přistupovat i k OpenType fontům.

Chtěl bych zde vymýtit jedno nesprávné povědomí o fontech Type1: že záleží na jejich kódování a jsou omezeny 256 znaky. Ani jedno není pravda. Nechápu, proč v době rozmachu fontů Type1 (na přelomu století) u nás vznikaly CE mutace těchto fontů ve speciálním kódování. Hlavu jsem si mohl z toho ukroutit. Vždyť font Type1 obsahuje libovolné množství znaků a k těmto znakům se přistupuje podle jejich názvu (např. Aacute, ccaron). Pořadí znaků ve fontu Type1 je pro rozumně navržený sázecí systém (například TeX) zcela irelevantní. K celkové množině všech znaků fontu Type1 je ovšem obvyklé přistupovat pomocí „Encoding vektorů“, což jsou nějaké 256znakové výběry názvů znaků z fontu. U Encoding vektoru už záleží na pořadí znaků. Sázecí program nastaví nějaký Encoding vektor jako aktuální a pak zapisuje text v 8bitovém kódování tohoto vektoru. Kdykoli může přepnout na jiný Encoding vektor a zapisovat text v novém kódování. Pomocí více Encoding vektorů může postupně přistoupit ke všem znakům fontu Type1, kterých může být neomezeně mnoho.

V TeXové distribuci jsou Encoding vektory uloženy v souborech s příponou enc a jsou propojeny s odpovídajícími 8bitovými metrikami TFM v mapovacích souborech s příponou map. Přepnutí na jinou metriku tedy znamená, že se třeba použije jiný Encoding vektor stejného Type1 fontu. Instalace a konfigurace fontu Type1 v TeXové distribuci je bohužel pro laika poněkud komplikovaná. To je důvod, proč je pro mnohé přechod na OpenType fonty jistým vysvobozením.

Snažím se střídat díly teoretičtější s praktičtějšími. Příště tedy přistoupím k praktickým ukázkám a doplním informace o fontech OpenType.

       

Komentáře

[TyPo]

Pěkný díl, díky.

Computer Modern byl také převeden do podoby Type1 a OpenType. Na tuto konverzi existuje nějaký automatický nástroj? Pro některé účely je způsob definice MetaPostu (programem) velmi vhodný. Navíc odpadá nutnost pořizovat nějaký komerční nástroj pro tvorbu fontů.

[Tomáš Pecina]

Předělat si celou metriku je bohužel zřejmě jediný způsob, jak opravit chyby v kerningových párech. Narazil jsem na to u páru "fZ" ve fontu Bookman, který potřebuji a používám; nikoho asi nenapadlo, že by někdo tak bizarní kombinaci používal, a tak je kerning špatně. Optimální by bylo, kdyby se dal kerning doplnit přímo do TeXu, tak jako se dají doplnit dělení slov pomocí \hyphenation, ale nenašel jsem, jak toho dosáhnout.

[Honza Jaroš]

Pokud používáte XeTeX, funguje tam tohle:

   \XeTeXinterchartokenstate=1
   \newXeTeXintercharclass\JrTClass
   \newXeTeXintercharclass\JrVClass
   \newXeTeXintercharclass\JrEaccClass
   \newXeTeXintercharclass\JrAaccClass
   \XeTeXcharclass`T = \JrTClass
   \XeTeXcharclass`V = \JrVClass
   \XeTeXcharclass`ě = \JrEaccClass
   \XeTeXcharclass`ä = \JrAaccClass
   \XeTeXinterchartoks\JrVClass\JrEaccClass={\kern-0.08em }
   \XeTeXinterchartoks\JrTClass\JrEaccClass={\kern-0.08em }
   \XeTeXinterchartoks\JrVClass\JrAaccClass={\kern-0.08em }

Konkrétně takhle si upravuji kerning mezi "Tě", "Vě" a "Vä" v Adobe Garamond Pro...

[Tomáš Pecina]

To je zajímavé, neměl jsem tušení, že XeTeX takové věci umí... Bohužel, není pro něj zatím udělaný pdfTeX, takže mi to nepomůže.

[Honza Jaroš]

Moment, z XeTeXu přece leze ve výchozím stavu PDF automaticky. Nebo jde ještě o něco jiného?

[Honza Jaroš]

PS: pokud by šlo o hyperlinky, eplain by měl podporovat i XeTeX, mám pocit, že jsem to před časem někde používal a fungovalo to. A rejstříky jsem si vyřešil vlastním kratičkým makrem:

\def\bookmark#1#2{\special{pdf: out #1 << /Title (#2) /Dest [ @thispage /XYZ null @ypos null ] >>}}
\def\topbookmark#1#2{\special{pdf: out #1 << /Title (#2) /Dest [ @thispage /XYZ null null null ] >>}}

\bookmark odkazuje na aktuální pozici, \topbookmark na vršek stránky.

[xkucf03]

Postupem času jsem si vytvořil vzorový soubor pro LaTeX a výsledkem je dobré PDF, které má odkazy, PDF obsah, nějaká ta metadata a hlavně český text, ve kterém se dá vyhledávat a taky se dá to PDF převést na prostý text, aniž by se zmršil (háčky někde bokem nebo úplné nesmysly). Tak kvůli tomu se mi moc nechce přecházet jinam...

[Honza Jaroš]

No já psal o plainu, mám pocit, že Tomáš Pecina (je-li to tento Tomáš Pecina) píše v něm. XeLaTeX má, pokud vím, odlišnosti minimální, dané hlavně jinou prací s fonty a tím, že jede standardně v UTF-8.

Já osobně používám TeX jen na sázení eBooků, protože mě irituje zlom ve čtečkách (nemluvě o problematických poznámkách pod čarou apod.), takže si to vysázím v TeXu na formát 8x10cm a čtu si to na PocketBooku v PDF. Narozdíl od Kindla umí PocketBook používat i rejstříky v PDF, takže funguje i rychlé přeskočení na konkrétní kapitolu apod. Původně jsem používal XeLaTeX, ale poté, co se mi po upgradu TeXLive totálně rozpadl formát (asi jsem LaTeXu moc hrabal do vnitřností) jsem pokorně přešel na plain...

[Tomáš Pecina]

Ano, jsem to já. Mně plain víceméně stačí (nic složitějšího než toto nebo toto generovat nepotřebuji), ale nedaří se mi najít způsob, jak spojit vlastnosti pdfTeXu (hyperlinky, barvy, vlastnosti dokumentu atp.) a možnost používat běžné fonty, nejen speciální TeXové. Jedna možnost by byla přejít na XeLaTeX, což se mi ale výrazně nechce.

[Honza Jaroš]

Příloha:

• test.pdf (12602 bytů)

Nojo, ale já furt nevím, co je za problém s tím XeTeXem.

Podívejte se do přílohy, máte tam odkazy, máte tam barvy a celé jsem to udělal jen s jedním linknutím souboru eplain.tex (a to jen kvůli jednoduché práci s odkazy, jejichž definice by z toho šla taky vyzobat):

\input eplain.tex
\enablehyperlinks

\font\foofont="DejaVu Serif" at 12pt
\foofont

Tohle je text

Tohle je \special{color push rgb 1 0 0}červený text\special{color pop}

Tohle je \special{color push rgb 0 1 0}zelená adresa \href{mailto:pokus@test.cz}{pokus@test.cz}\special{color pop}

Tohle je \special{color push rgb .5 .5 .5}\href{http://www.abclinuxu.cz}{šedý odkaz}\special{color pop}

\medskip

A ještě modrá čára:

\medskip

\special{color push rgb 0 0 1}\hrule height 0.5mm\special{color pop}

\bye

Pak už stačilo jen xetex test.tex a vypadlo z toho PDFko.

Jako ne že bych vám chtěl XeTeX nějak nutit, jen že sám píšete, že chcete pracovat s obecnými fonty, což právě XeTeX umí a můžete klidně zůstat u plainu...

[Honza Jaroš]

Jo - ještě vlastnosti dokumentu:

\special{pdf: docinfo << /Author (Honza Jaroš) >>}
\special{pdf: docinfo << /Title (Testovací dokument) >>}

Popis těhle speciálních příkazů pro PDF najdete v manuálech pro Dvipdfm. Třeba tady. Nejsou to jen metadata, i další možnosti ohledně hyperlinků, barev atd...

[Tomáš Pecina]

To zřejmě bude to pravé. Teď jsem trochu testoval docinfo, jestli není potřeba konverse na UTF-16BE jako v pdfTeXu, ale zdá se, že ne, takže mi už nechybí ke spokojenosti nic. Díky za tip!

[Honza Jaroš]

Rádo se stalo. Zvlášť když je to pro tenhle účel...

[xkucf03]

Přílohy:

• latex-pokus.pdf (88403 bytů)
• latex-pokus.txt (1898 bytů)
• latex-pokus.tex (2764 bytů)

Jenže když ten test.pdf převedu na text pomocí pdftotext tak z toho vznikne tohle:

Tohle
Tohle
Tohle
Tohle

je
je
je
je

text
červený text
zelená adresa pokus@test.cz
šedý odkaz

A ještě modrá čára:

1

Ale když převedu svoje PDF z LaTeXu do TXT, tak je ten výstup mnohem lepší.

[xkucf03]

mj. to má vliv na vyhledávání v dokumentu – např. Okular není schopný najít „Tohle je“ nebo „je text“, i když „červený text“ najde. V mém dokumentu najde i „červená, zelená, modrá“ nebo „a další odkaz“.

Ono to vypadá, že řeším prkotiny, ale když pak máš nějakou dokumentaci a máš v ní něco najít, tak tohle je dost znát. Další věc je indexování v různých CMS nebo i na webu a fulltextové vyhledávání (nějaké sofistikovanější, než jen že dokument obsahuje určitá slova) nebo třeba zobrazování náhledů a úryvků.

Neříkám, že LaTeX je dokonalý nebo že to v jiném *TeXu nejde, ale zatím jsem se k uspokojivým výsledkům dopracoval v LaTeXu, tak u něj zůstávám.

[xkucf03]

Špatné je, že nenajde „sit amet“ tam, kde došlo k řádkovému zlomu.

Dá se s tím něco dělat při sazbě do PDF? Nebo je potřeba to nějak vyřešit na úrovni prohlížeče?

Tohle je např. problém, když v dokumentaci hledáš nějaký_ukrutně_dlouhý_parametr a on je v tabulce a zalomil se na víc řádků – nenajdeš ho ani v tom PDF z LaTeXu.

[Honza Jaroš]

Příloha:

• test.pdf (12949 bytů)

Tohohle jsem si všiml v Evince a myslel jsem, že je to problém prohlížeče. Stačilo přepsat první řádek na něco, co nezačíná slovy "Tohle je" a najednou to bylo OK (viz příloha). Tak nevím, jestli to dělá TeX nebo Evince/Okular. Jiný prohlížeč tu momentálně nemám a instalovat si kvůli tomu Adobe Reader se mi nechce...

Každopádně totéž mi dělal s (téměř) tím samým zdrojem i pdfTeX.

[Honza Jaroš]

Tak jsem si do VirtualBoxu nacpal jedenáctkový Adobe Reader a tam normálně funguje kopírování textu i vyhledávání. Takže to vypadá spíš na to, že se Evince (či spíš nějaká knihovna na práci s PDF, když to dělá i Okular) snaží být příliš chytré a detekuje to jako tabulku. TeX samotný v tom bude nevinně.

[Petr Olsak]

Přílohy:

• testik.tex (2099 bytů)
• testik.pdf (29513 bytů)
• testik.txt (1890 bytů)

Jenže když ten test.pdf převedu na text pomocí pdftotext tak z toho vznikne tohle: ...

Ale když převedu svoje PDF z LaTeXu do TXT, tak je ten výstup mnohem lepší.

Nezáleží na tom, zda je použit pdfTeX/XeTeX, LaTeX nebo plain. Záleží na tom, jak se sejde ta sazba. Program pdftotext se snaží domýšlet některé věci. Například, když vidí mezery pod sebou, dochází k domněnce, že to je vícesloupcová sazba, a čte to po sloupcích. Když má řádky dost blízko u sebe, naopak to napere na jediný řádek. Přesněji řečeno to není vlastnost pdftotext, ale knihovny poppler, která je vybavena touto inteligencí.

Váš příklad jsem přeznačkoval do plainu a uvádím to zde taky jako přílohu. (Povšimněte si, že hlavička je výrazně kratší než ta LaTeXová.) Protože byly řádky dost blízko u sebe, poppler to nyní nacpal do jediného řádku a dokonce zrušil rozdělené slovo. V tuto chvíli se správně domníval, že to je rozdělené slovo, ale jindy se může domnívat nesprávně. Je to alchymie, jejíž důvod je ten, že v době realizované sazby už jsou informace o logickém členění dokumentu (odstavce, sloupce ve vícelsoupcové sazbě, nerozdělená slova) ztraceny a ten sowtware se může akorát pokusit si něco domyslet.

[Honza Jaroš]

Přílohy:

• test-lowriter-dejavu.pdf (11694 bytů)
• test-lowriter-times.pdf (20237 bytů)

Přesně tak. Viz ukázky v příloze, které jsem pro změnu exportoval z LibreOffice Writeru. Kupodivu stačí i jen použít jiné písmo a export do textu se začne chovat jinak - s Times New Roman to poppler čte po řádcích, s DejaVu Serif po sloupcích. Alespoň tedy v Evince 2.32.0 pod aktuálním Gentoo...

[xkucf03]

Pěkné, jsem rád, že to funguje Kdysi jsem viděl nějaké odstrašující příklady (už nevím, jaký *TeX to byl), kde nešlo v PDF ani vyhledávat česká slova, protože háčky a čárky byly někde bokem. Tak jsem se radši držel té své šablony v LaTeXu, kde to funguje.

[olsak]

... Tomáš Pecina (je-li to tento Tomáš Pecina) ...

Právnické texty jsou typická ukázka, ve které lze plně využít výhody TeXu. Měl jsem několik zakázek od takových těch nakladatelství, která pro právníky neustále znovu a znovu tisknou novelizované verze zákonů. Zdroje dostávají z jakéhosi úřadu, kde je sbírka zákonů, ve wordu. Dokázali z toho vlastním softwarem extrahovat text a základní značkování. Na mě pak bylo vytvořit makra, aby to tím prohnali a měli ty knihy hotové. Když projdete regály v knihkupectví s touto právničinou, těžko poznáte, které knížky byly dělané v TeXu...

Já jsem v souvislosti s tím ty právnické texty začal trochu více číst a nyní třeba dělám předsedu legislativní komise senátu ČVUT. Ale to je už jiný příběh...

[Tomáš Pecina]

Právnické texty jsou typická ukázka, ve které lze plně využít výhody TeXu.

Ano, podání typu trestní odvolání mi teď trvá zlomek času: předpokládá to samozřejmě vytvořit si knihovny maker s osobními údaji klientů, adresami soudů a dalších institucí atd., ale ty se pak už jen recyklují a aktualisují.

[Nicky726]

Mám to podobně, akorát v XeLaTeXu. Důvod přechodu bylo tuším zejména snazší řešení vyhledávatelné/kopírovatelné češtiny v PDFku.

[michal.h21]

A v luaTeXu jde využít feature file. ale funguje to jenom pro OpenType fonty, třeba TeX Gyre Bonum je založený na Bookmanu.

[olsak]

To je zajímavé, neměl jsem tušení, že XeTeX takové věci umí... Bohužel, není pro něj zatím udělaný pdfTeX, takže mi to nepomůže.

pokud by šlo o hyperlinky, eplain by měl podporovat i XeTeX

... LaTeX, ... výsledkem je dobré PDF, které má odkazy, PDF obsah, nějaká ta metadata a hlavně český text, ve kterém se dá vyhledávat...

Jak jsem již v jedné diskusi psal, XeTeX má jiný backend, takže pro barvy, odkazy atd. je potřeba použít jiná low-level makra. Například OPmac v takovém případě natáhne automaticky opmac-xetex.tex, kde jsou tato low-level makra zkonvertována tak, aby to prošlo XeTeXem. Můžete se inspirovat pohledem do toho souboru. Jsou tam zmíněny i problémy, kdy není výstup stoprocentně stejný z principu.

Když v ukázce z třetího dílu seriálu priklad-opmac.tex přidáte na začátek \input ucode a nezměníte nic jiného, zpracujete to csplainem v XeTeXu, vyleze vám stejný dokument, jak zjistíte, kliknete-li na odkaz. Není tedy třeba se XeTeXu bát a není vůbec nutné hovořit o LaTeXu.

Na druhou stranu není nutné na XeTeX přecházet: původní dokument má taky vyhledatelné texty a byl vytvořen prostým pdfTeXem. Vyhledatelnost českých textů je implicitní vlastností csplainu už dávno i v pdfTeXu. Jestliže tedy LaTeXisté kvůli tomu musejí přecházet na XeLaTeX, je to jejich problém, ne náš.

Jediný argument pro přejití na XeTeX je využití OpenType fontů a všech dalších fontů instalovaných systému. Já osobně tuto závislost TeXu na operačním systému moc nevítám a raději využívám fonty v TeXové distribuci. I fonty, které mám odjinud, především dávám do TeXové distribuce. Do systému je nikdy neinstaluji.

[Tomáš Pecina]

To je spíš filosofická otázka, jestli chci mít v počítači různé systémy fontů pro různé použití, nebo raději jeden.

České fonty dodávané k plainTeXu jsou hodně chudé: nejsou tam vůbec moderní bezpatková písma, která mám např. pro sazbu hlavičkových papírů za nezbytnost. Proto se spíš kloním k tomu, přejít na XeTeX.