TeX – 4 (kódování znaků)

6. 11. 2013 | Petr Olšák | Různé | 6200×

U tak složitého systému, jakým je TeX, se občas bohužel stane, že ne vše funguje jak má. V takovém případě uživatelům asi nepostačí jen znalost autorského značkování a musejí se zanořit poněkud do hloubky mezi nánosy všeho možného, co přinesla dlouholetá historie TeXu. V tomto díle seriálu si ukážeme, jak TeX přistupoval a přistupuje ke kódování znaků textových fontů. Aspoň rámcový přehled v této problematice se jistě vyplatí.

Obsah

• Kódování znaků v diluviálním TeXu a nyní
• UTF-8 kódování na vstupu a Unicode uvnitř
• Osmibitové období
• UTF-8 na vstupu, osm bitů uvnitř
• Historický přehled

Kódování znaků v diluviálním TeXu a nyní

Původně Knuth rozhodl, že TeX bude interně pracovat v ASCII kódování. Na 94 viditelných ASCII znaků navázaly pro TeX připravené a zhruba stejně kódované fonty Computer Modern. Co Knuth neměl na své klávesnici a chtěl tisknout, na to si připravil řídicí sekvenci. Například \ae vytisklo æ. Takovéto znaky Knuth vpravil do zbývajících míst 128znakové tabulky fontů Computer Modern. Například znaku æ přidělil pozici 26 a řídicí sekvenci \ae pak deklaroval v makru plainTeX primitivním příkazem \chardef\ae=26. Na některé znaky nezbylo ve fontech místo, takže třeba znak paragrafu (§) byl tištěn makrem \S, které jej dosti nekoncepčně lovilo z doplňkové sady matematických fontů. Můžeme k tomu mít dnes výhrady, ale uvědomme si, že se psal rok 1982.

Další vychytávku Knuth vymyslel pro snadné dosažení střední a dlouhé pomlčky: dvojice -- nebo trojice --- se proměnila na odpovídající pomlčku díky tomu, že byla zanesena v tabulce ligatur fontu Computer Modern. Analogicky se f a i promění automaticky ve fontu na ligaturu fi. Implementace pomlček jako ligatur taky není příliš ideální. Na druhé straně je to ergonomické, účelné a přehledné při psaní zdrojových textů: tyto pomlčky ani nyní na klávesnici přímo přístupné nejsou.

Pro znaky s akcenty měl Knuth připravena další makra, která sestavovala akcentovaný znak z komponent (například z háčku a písmene). Takže „české slovo“ se dalo (a dosud dá) napsat jako \v{c}esk\’e slovo. S takovýmto TeXem jsem se poprvé setkal asi v roce 1990 a prohlásil jsem, že pokud se to má začít používat v češtině, pak takto rozhodně ne. A chopili jsme se společně s ostatními zájemci o TeX z tehdejšího Československa práce...

Dnes existují 16bitové modifikace TeXu (XeTeX a LuaTeX), které pracují interně v Unicode a se stejně kódovanými fonty. Ovšem cesta k tomuto stavu byla dlouhá a vedla různými oklikami. Netradičně začnu od konce a popíšu nejprve možnosti, které nabízejí současné 16bitové TeXy.

UTF-8 kódování na vstupu a Unicode uvnitř

Je třeba rozlišovat mezi kódováním vstupního souboru (což musí být UTF-8) a interním kódováním 16bitového TeXu (Unicode). Konverzi mezi prvním a druhým světem zajišťuje v TeXu vestavěný input procesor podle jednoduchého pravidla. V TeXu probíhá i opačná konverze zpět do UTF-8 při ukládání informací do textových souborů (například pro opakované načtení při sestavení obsahu). Dlužno podotknout, že input procesor včetně zpětné konverze měl v daleko jednodušší podobě už Knuth ve svém prvním TeXu: řešil tehdy otázku existence dvou kódování anglické abecedy EBCDIC a ASCII s tím, že interně v TeXu předpokládal vždy ASCII i na mašinách, které pracovaly v EBCDIC.

Input procesor konvertující UTF-8 do Unicode (a zpět) je v XeTeXu implementován „natvrdo“, zatímco v LuaTeXu je řešen pomocí Lua skriptu a je tedy modifikovatelný. Na interní kódování TeXu musejí navázat stejně kódované vzory dělení slov jednotlivých jazyků a fonty. V tomto případě tedy vzory dělení slov a fonty musejí být v Unicode.

Při psaní česky nebo slovensky v 16bitovém TeXu jsme nuceni skutečně užít unicodový font, protože znaky české a slovenské abecedy mají v Unicode přidělena čísla často větší než 255. Na druhé straně naši evropští kolegové na západ od nás používající kódovou sadu ISO-8859-1 (francouzi, němci, španělé, atd.) mohou pro svůj jazyk načíst i starší 8bitový font, protože Unicode se ve znacích jejich jazyka shoduje s ISO-8859-1. Nejsou tedy odkázáni na fonty jen ve formátu OpenType. Mají-li nějaký starší oblíbený font v kódování ISO-8859-1, nemají s tím v XeTeXu ani LuaTeXu (na rozdíl od nás) problém.

Zdrojové dokumenty je potřeba pořizovat za použití vhodného ovladače klávesnice nebo input metody textového editoru. Tím se dá zcela vyhnout původnímu způsobu pořizování textů, při kterém platilo pravidlo, že co není na klávesnici, na to se použije řídicí sekvence. Takže při zapnuté české klávesnici píšeme jednoduše česky. V editoru Emacs je také speciální input metoda, při které uživatel napíše \ae a ono se to okamžitě v textovém editoru promění na UTF-8 kód znaku æ. Nebo zápis --- Emacs promění v UTF-8 kód dlouhé pomlčky. Osobně se domnívám, že nic se nemá přehánět. Tento způsob zápisu totiž svádí používat UTF-8 kódy třeba i v matematických vzorcích. Porovnejte:

$$ \sum_{n=1}^\infty {1\over n^2} = {\pi^2 \over 6} $$
$$ ∑_{n=1}^∞ {1\over n^2} = {π^2 \over 6} $$

Aby druhý řádek fungoval, je potřeba mít použité kódy deklarovány jako odpovídající matematické znaky příkazem \mathcode. V klasickém TeXu jsou deklarovány jen použité řídicí sekvence \sum, \pi, \infty pomocí \mathchardef, jak je možné se přesvědčit například v Knuthově souboru plain.tex.

I formát CSplain je možné vygenerovat s XeTeXem nebo LuaTeXem. CSplain ale z historických důvodů má implicitně vnitřní kódování il2 (viz níže). Ovšem je snadné přepnout na jiné kódování (T1 nebo Unicode). Začátek dokumentu v CSplainu pod 16bitovým TeXem může tedy vypadat třeba takto:

\input ucode   % redefinice maker (závislých na kódování) podle Unicode
\chyph         % vzory dělení češtiny (nyní budou v Unicode)
\input lmfonts % načtení Latin Modern fontů v Unicode
Ahoj světe! Jak se mají žlutí koňové?
\end

Osmibitové období

Možnost použít unicodové fonty je poměrně nová. Ještě nedávno TeX uměl pracovat pouze s metrickými údaji fontů s maximálně 256 znaky. Vrátíme se tedy na počátek 90. let a popíšeme, jak vznikala podpora češtiny a slovenštiny. Kvůli častému konzervativnímu přístupu TeXistů se některé tyto věci používají dodnes.

Zhruba v roce 1991 jsme navrhli mírnou modifikaci Computer Modern fontů, tzv. CSfonty. Ty přidávají kompletní akcentované znaky české a slovenské abecedy do druhé poloviny tabulky podle ISO-8859-2. Toto kódování se nazývá il2. Vzory dělení češtiny i slovenštiny jsou do CSplainu načteny v il2 a CSfonty na to navazují. V té době se pro češtinu používalo několik jednobytových kódování vstupních souborů: ISO-8859-2, CP1250, CP852, KOI8-CS, Kamenických atd. Mezi různými prostředími dle použitého kódování a interním kódováním il2 bylo potřeba správně konfigurovat input procesor TeXu, který pro případ překódování tam i zpět na úrovni „byte to byte“ byl připraven již Knuthem. Docela podrobně jsem tuto problematiku popsal v článku Putování písmene ř z klávesy na papír (1997).

Na začátku 90. let na konferenci v Corku se TeXisté dohodli a vymezili evropské kódování fontů. Využili všech tehdy dostupných 256 pozic. První polovina tabulky respektovala viditelné ASCII znaky, druhá ISO-8859-1 a do volných míst byly nacpány ostatní znaky latinkou píšících evropanů, tedy i naše abeceda. Kódování nazvali T1 alias Cork. Jádro LaTeXu bylo Jiřím Zlatuškou upraveno tak, aby dokázalo načíst vzory dělení v obou kódováních (il2 i T1) a tím vznikl CSLaTeX schopný pracovat jak s CSfonty tak s T1 kódovanými fonty. Kresby znaků české abecedy byly v CSfontech vydařenější než v analogickém fontu kódovaném podle T1 a tím se asi vysvětluje, proč CSLaTeX přežíval dvě desetiletí. Já jsem navíc v il2 kódování připravil počeštění základních PostSriptových fontů.

Fonty kódované podle T1 byly většinou z různých zdrojů (třeba i bez akcentovaných znaků) generovány za použití nástroje fontinst, který vytváří virtuální kompozitní znaky, jež může pak přímo používat TeX. Bohužel v tomto nástroji byla a je chyba v konfiguraci znaku ď a ť, takže desítky, možná stovky, takto vytvořených fontů přítomných v TeXové distribuci jsou pro češtinu nepoužitelné. Když jsem to teprve loni objevil (protože vesměs používám il2 kódované fonty), docela jsem se podivil, že toto žádný uživatel za těch 20 let nereportoval. Že by všichni čeští TeXisté užívali výhradně il2?

Kuriózní na T1 kódování je například to, že sice bylo navrženo pro Evropu, ale stalo se tak v roce 1990, kdy ještě nikdo netušil, že bude existovat znak Euro. V T1 tabulce najdeme libru, dolar, ale Euro nikoli. Nicméně TeX umožňuje na úrovni maker snadno připojit ke každému 256znakovému fontu libovolné množství expertních sad tak, že uživatel ani nepozná, že TeX uvnitř přepíná mezi základním řezem a k němu připojenou expertní sadou. Viz například soubor maker exchars.tex. V expertní sadě samozřejmě Euro přítomno je.

Nové fonty například z projektu TeXGyre jsou primárně připraveny v OpenType, ale jsou k nim rovněž vygenerovány klasické metriky pro TeX podle rozličných kódování, která se během osmibitového období narodila a začala v TeXových distribucích přežívat.

UTF-8 na vstupu, osm bitů uvnitř

V roce 2000 narůstal požadavek používat UTF-8 kódování vstupních souborů. V té době byla ještě možnost číst unicodové fonty v nedohlednu, formát OpenType (2005) neexistoval. Konverze UTF-8 na 8 bitů uvnitř TeXu byla v LaTeXu řešena na úrovni maker: \usepackage[utf8]{inputenc}. Ovšem takto řešená konverze přináší na nízké úrovni programování maker docela problémy. Proto jsem počátkem milénia rozšířil input procesor TeXu tak, aby dokázal kromě „byte to byte“ konverze provádět i konverzi více bytů na jeden byte nebo na řídicí sekvenci. Počet UTF-8 znaků je sice značný, ale počet řídicích sekvencí, na které se to automaticky může uvnitř TeXu konvertovat, je víceméně neomezený. Každá řídicí sekvence může navazovat na své makro, které vyšťourá znak buď z aktuální základní sady nebo z některé z expertních sad přidružených aktuálnímu fontu. Toto řešení jsem nazval encTeX.

Současný CSplain nad pdfTeXem s UTF-8 kódovaným vstupem využívá encTeX. Implicitně rozumí znakům české a slovenské abecedy a textovým znakům, na které měl Knuth řídicí sekvenci (typu \ae). Po načtení dalších maker rozumí znakům z dalších částí Unicode tabulky. Například po \input utf8math je CSplain schopen interpretovat matematické vzorečky s UTF-8 znaky, jak bylo ukázáno v příkladu v úvodu tohoto článku.

Historický přehled

verze	rok	poznámka
TeX v.<3	< 1990	ASCII a řídicí sekvence, interně 7 bitů
TeX v. 3.*	≥ 1990	interně 8 bitů a řídicí sekvence, kódování il2, T1, konverze byte to byte
encTeX	∼ 2002	UTF-8 → 8 bitů+řídicí sekvence, kódování il2, T1
XeTeX	∼ 2006	umí číst OpenType fonty, UTF-8 na vstupu, interně Unicode
LuaTeX	∼ 2010	umí číst OpenType fonty, UTF-8 na vstupu, interně Unicode

       

Komentáře

[tomo_tn]

J\'a e\v{s}te st\'ale pou\v{z}\'ivam ten zostavovan\'y syst\'em znakov. Hlavne v\v{s}ak k\^oli zotrvacosti.

Priatelka si preto zo mna vzdy robi srandu ked pisem nejaky text :)

[olsak]

Zrovna minulý týden jsem požádal jednoho kolegu v práci o zdrojáky k písemkám, které aktuálně používá. Co si myslíte, že jsem tam našel?

Najd\v{e}te Taylor\accent23uv polynom stupn\v{e} 2 pro funkci ...

A tak to bylo napsáno celé. To jsem tedy opravdu těžko rozdejchával. Ukazuje se, že konzervatismus některých TeXistů je bezbřehý.

[Stanislav Brabec]

Nejenom TeXistů.

Ve světě profesionálních systémů lze narazit i na takové kuriozity, jako je XML soubor kódovaný v EBCDIC.

[Miloslav Ponkrác]

Přiznejme si, že je velký rozdíl v pravděpodobnosti, že člověk narazí na XML v EBCDICu, která je limitně nulová, a pravděpodobnosti, že narazíte na encypted češtinu v TeXu, pokud se o TeX zajímáte, která je limitně 100 %.

[K>]

a to vsechno je jen kvuli tomu, ze Knuth neumoznil menit svuj program?

[Qaxi]

bože to je bordel ...

Sorry, ale pokud človíček není odborník na TeX nebo (blablaTeX) tak je to opruz jen rozběhat ... natož používat ...

[egg]

"Umí číst OpenType fonty, UTF-8 na vstupu, interně Unicode" - myslím, že jedině takhle to dává smysl pro používání v tomto století.

[olsak]

Sorry, ale pokud človíček není odborník na TeX nebo (blablaTeX) tak je to opruz jen rozběhat

Promiňte, ale opravdu je obtížné nainstalovat v linuxové distribuci TeXlive a spustit pdfcsplain dokument?

bože to je bordel ...

Máte pravdu. Ovšem v uzavřených systémech je ten nános historie taky, jenom je to schované. A v pseudootevřených systémech (LibreOffice) je zmatek ještě větší, jen se Vám nechce v těch statisících až miliónech řádků kódu to hledat. A uživatelům se zdá, jak to krásně funguje, neboť směrem k uživatelům se dbá na to, aby byla vytvořena líbivá slupka.

My TeXisté hrajeme s otevřenými kartami. Vnímáte ten rozdíl?

"Umí číst OpenType fonty, UTF-8 na vstupu, interně Unicode" - myslím, že jedině takhle to dává smysl pro používání v tomto století.

Naprosto souhlasím. Bohužel ale není možné zahodit z distribuce TeXu vše, co s tímto pravidlem nemá co dělat s tím, že to novým uživatelům akorát znepříjemňuje život. Kromě nových uživatelů tu jsou totiž konzervativní TeXisté se svými obskurními makry závislými na interním kódování TeXu, které v té době použili, se svými fonty, které si třeba kdysi koupili, se znalostmi, které si kdysi přečetli a ta dokumantace tam je pořád. U 8bitových fontů jsem v článku jasně napsal, že čeština v Unicode TeXu nepojede. Kvůli těmto lidem se budeme muset smířit s tím, že v TeXové distribuci ten nános historie pořád bude.

Já jsem CSplain přizpůsobil Unicode TeXům a je možné jej tedy používat i v tomto století. Vytáhnul jsem jej tedy z popela jako bájného Fénixe a přidal k němu OPmac.

a to vsechno je jen kvuli tomu, ze Knuth neumoznil menit svuj program?

Nemáte pravdu. Knuth umožní měnit ten program, jen tu změnu nesmíte nazvat TeX. A skutečně, když se podíváte do tabulky na konci článku: v roce 2005 přišel formát OpenType a v roce 2006 jej umí číst XeTeX. Nebo Unicode Math: s tím přišel Microsoft v roce 2007, první implementaci měli v tom svém programu tuším v roce 2009 a Jonathan Kew to implementoval do XeTeXu v roce 2010. Dnes, pokud se nemýlím, Unicode math umí jen Microsoftí produkt (nebudu uvádět jeho jméno) a dále XeTeX a Luatex. Nic víc. Tím chci naznačit, že TeXisté jdou s dobou a Knuth neklade překážky.

[Miloslav Ponkrác]

„Máte pravdu. Ovšem v uzavřených systémech je ten nános historie taky, jenom je to schované. A v pseudootevřených systémech (LibreOffice) je zmatek ještě větší, jen se Vám nechce v těch statisících až miliónech řádků kódu to hledat. A uživatelům se zdá, jak to krásně funguje, neboť směrem k uživatelům se dbá na to, aby byla vytvořena líbivá slupka.“

Ale o tu líbivou slupku jde. To je princip celého programování. Ba co víc, jde o princip celého vesmíru.

Když koupím router, který perfektně funguje, jen mi v podstatě jedno, co za bordel je uvnitř.

Stejně tak, když sním jídlo, nezajímají mě detaily trávicího systému, ani celá biochemie trávení a metabolismu, jde zase jen o tu líbivou slupku – najím se a je mi fajn a funguji jako člověk.

Když budu mít sázecí nástroj, který na vstupu přijme Unicode, Open type fonty, zdroják s mocným programovacím jazykem či vizuálním rozhraním, kde nepotřebuji znát ani ovlivňovat parsovací algoritmy zdrojáku, ani dokonale zdroják celého sázecíého systému (což je jediná, naprosto jediná možnost, jak znát dobře TeX), pak je to, co 99,9999 % lidí potřebuje a požaduje.

Jestli mám něco TeXu a Knuthovi opravdu za zlé, tak to je špatný interface celého TeXu.

Knuth navrhl TeX tak, že člověk musí znát všechny vrstvy a ještě emulovat kde co, aby v tom napsal něco realtivně základního. TeX je typický příklad špatné architektury programu z hledidka API a komunikace s uživatelem. Jeden z nejhorších, co se ujal.

Osobně si myslím, že by se mělo naplno říci, že TeX není složitý systém, a kdyby ho Knuth nezamotal tak strašlivým způsobem, dal by se snadno a rychle naučit. On toho TeX zase tak moc neumí, v podstatě si hraje se skládáním obdélníčků vedle sebe a prská do toho pružné mezery. Toť naprosto celý TeX. Kolem toho je pár detailů.

Jakmile je u nějakého programu nutné dokonale znát střeva, aby se v něm rozumně dalo dělat, je to špatně navrhnuté uživatelské rozhraní. Mělo by se u TeXu říci, že to je jeho případ.

Miloslav Ponkrác

[Miloslav Ponkrác]

„Nemáte pravdu. Knuth umožní měnit ten program, jen tu změnu nesmíte nazvat TeX. … Tím chci naznačit, že TeXisté jdou s dobou a Knuth neklade překážky.“

TeXisté nejdou s dobou. Vznikají jenom další a další forky TeXu, které si za sebou táhnou tu základní překážku od Knutha. Špatné uživatelké API, které se bojí radikálně porušit.

Je jasné, že v dobách Knutha nebylo Unicode ani TTF/OTF fonty, ale i to ostatní Knuth nenapsal nejlépe. Mluvím o uživatelském rozhraní směrem k sazeči, ne o funkci.

Dokonce se přistihuji, že mám dojem, že Knuth moc zkušeností s programováním, přesněji se softwarovým inženýrstvím, neměl a na TeXu se to teprve učil.

[Fluttershy, yay!]

bože to je bordel ...

Máte pravdu. Ovšem v uzavřených systémech je ten nános historie taky, jenom je to schované. A v pseudootevřených systémech (LibreOffice) je zmatek ještě větší, jen se Vám nechce v těch statisících až miliónech řádků kódu to hledat. A uživatelům se zdá, jak to krásně funguje, neboť směrem k uživatelům se dbá na to, aby byla vytvořena líbivá slupka.

My TeXisté hrajeme s otevřenými kartami. Vnímáte ten rozdíl?

Ono to ovšem není tak černobílé. Velké naděje jsem vkládal v Lout, který ale Unicode také neumí a IMHO balancuje na hraně existence.

[pozortucnak]

Je tu také dědeček heirloom troff

[Fluttershy, yay!]

Ani za trest...

[Tibor]

V slovenčine sa používa (používala) ligatúra "fľ" (napr. slovo fľaša). Existuje riešenie na poskladanie takéhoto znaku (ligatúra fl a ') v plain-/la-texu?

[olsak]

Přiznám se, že tento zajímavý problém vidím poprvé. V Unicode tabulce ligatura flcaron, pokud se nepletu, neexistuje. Připlácnutí čárečky k ligatuře fl pomocí makrer TeXu je samozřejmě možné a je to ta nejjednodušší věc, ale vždy to bude jen kompromis. Souvisí to s těmito problémy:

• Slovo fľaša by se muselo psát jako \fl'aša, přičemž makro \fl' by řešilo to sestavení znaku. Přímo fľaša byste mohl psát při použití encTeXu, ve kterém byste mohl namapovat dvojici znaků fľ na řídicí sekvenci, která by se o to připlácnutí čárečky postarala.
• Ona čárečka dle odborníků na fonty (např. Štorm) není žádný apostrof nebo jiný znak, který by šel jako samostatný dohledat ve fontu. U písmen ť, ď, ľ to Štorm kreslí samostatně a s velkou citlivostí. Takže přidat tam jakýkoli samostatný znak z fontu nebude nikdy perfektní.
• Ve výsledném PDF souboru nebude slovo fľaša dohledatelné ani nebude zpětně vykopírovatelné do textového souboru, protože je poskládáno z komponent.

[asdfasfasfasf]

jak se nekde objevi jmeno storm a stresovicka pismolijna, hned musim dopsat Master's Hammer

http://www.deafsparrow.com/masters-hammer-interview.htm

[Atrament]

To já si teda rovnou pustím Ritual. :)

[s0]

...sám Atrament od Spiritusu vyhodit mě dal...

[Atrament]

OK, tak i toho Okultistu si dám ;)

[Miloslav Ponkrác]

Pokud se zvolí XeTeX, pak pokud font obsahuje ligaturu fl, není třeba dělat vůbec nic, provede se automaticky. A i v PDF to bude správně a dohledatelné.

To je právě to, že moderní standardy už na míle utíkají starému TeXu.

Open Font Type obsahuje řadu dodatečných informací, které starý TeXovský model neumí využít, nemá jak, ve svých algoritmech s nimi vůbec nepočítá.

XeTeX využívá přímo informací z Open Type Fontů, které toho v sobě mají zapsáno opravdu hodně.

Bude-li mít použitý font ligaturu jakoukoli, tak jí XeTeX použije, aniž by se pro to muselo hnout prstem. Tedy můžete si nastavit, které verze Open Type fontu se použijí (onum = old number = skákací číslice, clig, clat, dlig = různé další ligatury, atd.) Dále viz:

en.wikipedia.org/wiki/OpenType_feature_tag_list#OpenType_typographic_features

Proto jsem psal, že IMHO jen Unicode TeX je dnes rozumně použitelný.

Miloslav Ponkrác

[olsak]

Pokud se zvolí XeTeX, pak pokud font obsahuje ligaturu fl, není třeba dělat vůbec nic, provede se automaticky. A i v PDF to bude správně a dohledatelné.

Přečtěte si, prosím, pozorně, čeho se týká toto diskusní vlánkno a pak sem teprve něco pište. Problém je v tom, že v Unicode neexistuje ligatura flcaron. O ligatuře fl zde není řeč, tu umí automaticky vkládat i klasický TeX z roku 1982.

Pomocí TeXových bastlících metod ala Knuth neexistenci flcaron sice snadno vyřešíme, ale s vědomím problémů, které jsem popsal.

[Miloslav Ponkrác]

Ach jo.

Je jedno, co je a není za ligatury v Unicode, pokud v daném OpenType fontu tato ligatura je, XeTeX a jiné sázecí nástroje, které umějí pracovat s OpenType jí použijí.

Přiznejme si, že návrháři fontů vyřeší přesné umístění uvnitř ligatury miliónkrát lépe, než jakýkoli autmatizovaný algoritmus.

[Miloslav Ponkrác]

A abych to podpořil konkrétně:

http://www.myfonts.com/fonts/dizajndesign/deva-ideal/italic/glyphs/424651/671

http://www.myfonts.com/fonts/type-together/sirba/regular/glyphs/480630/353

TeX je zkrátka zastaralý a přestává umět to, co dnes už umějí standardy fontů.

Tedy znovu, sázecí nástroje založené na OpenType fontech umějí i ligatury, které nejsou součástí Unicode.

Starý model fontů TeXu je velmi zastaralý a neumí mnoho věcí. Ostatně pokrok v sazbě i fontech nedělali amatéři, a věděli co dělají.

[olsak]

Ostatně pokrok v sazbě i fontech nedělali amatéři, a věděli co dělají.

V tomto kontextu je dobré si položit otázku, proč tito profíci přišli na to, že je potřeba figatury automaticky nahrazovat v sázecím systému, až nyní, zatímco v TeXu je tato vlastnost implementována už třicet let.

[olsak]

Přiznejme si, že není jedno, zda je či není flcaron v Unicode. Kdyby byla flcaron v Unicode, byla by zřejmě i ve fontech. Pointa je, že flcaron ve fontech není. A nespojujte ten problém s OpenType. Kdyby flcaron ve fontu byla, tak ji TeX použije, to umí nezávisle na tom, zda to je OpenType nebo jiný formát fontu.

Shrnu to: Vy tedy navrhujete řešení počkat, až návrháři fontů flcaron do všech fontů doplní. A mlžíte přitom vlastnostmi ligatur v OpenType, což TeX zvládal už dávno od svého narození.

[Miloslav Ponkrác]

Obávám se, že Vaše informace není přesná.

Budu-li matematicky přesný: To, že ligatura je či není součástí Unicode nemá žádnou souvislost s tím, zda fonty tuto ligaturu obsahují či nikoli.

Řada fontů nemá úplnou sadu Unicodových ligatur.

Naopak většina fontů má řadu ligatur, která v Unicode není.

Ty dvě věci nemají mezi sebou žádnou souvislost.

---

Kvalitní fonty mají ve své sadě potřebné ligatury. Pokud chcete kvalitní sazbu, pak musíte použít kvalitní fonty. Jakýkoli pokus o automatiku ligatury třeba flcaron nad obecnými fonty nedává kvalitní výsledek a nemůže konkurovat tomu, když ligaturu vyladí designér fontu. A pokud vám nejde o kvalitní výsledek, pak se můžete vykašlat i na ligaturu flcaron, už je to vcelku fuk.

Jediný kvalitní výsledek je, že ligatury, které používáte jsou přímo součastí fontů. Cokoli jiného je zhoršení kvality.

[olsak]

Jsem rád, že po dlouhé debatě jste nakonec dospěl k tomuto:

Jediný kvalitní výsledek je, že ligatury, které používáte jsou přímo součastí fontů. Cokoli jiného je zhoršení kvality.

Kdybyste si přečetl, co jsem psal na počátku vlákna:

Připlácnutí čárečky k ligatuře fl pomocí makrer TeXu je samozřejmě možné a je to ta nejjednodušší věc, ale vždy to bude jen kompromis.

shledal byste, že máme na věc stejný názor, takže další debata je zbytečná.

[Miloslav Ponkrác]

„Pomocí TeXových bastlících metod ala Knuth neexistenci flcaron sice snadno vyřešíme, ale s vědomím problémů, které jsem popsal.“

Jinak řečeno nevyřešíme.

Sazeč je otravován tím, že musí myslet na to, aby označil ligatury, což bez problémů by měl udělat a ligatury rozpoznat sázecí nástroj bez zásahu uživatele.

A navíc máme v PDF špatně text pro hledání.

V XeTeXu a OpenType fontech žádný z výše uvedených problémů není. Stejně tak jako v jiných moderních sázecích systémech.

Jednoduše starý model TeXu bez jeho podstatnějších změn čím dál více a více drhne, a čím dál více a více je kompromisní. A ještě za cenu, že sazeč dělá naprosto zbytečné věci.

[Ash]

V XeTeXu a OpenType fontech žádný z výše uvedených problémů není.

Pochopil jsem dobře, že v OpenType jsou všechny myslitelné ligatury (tedy žádná nechybí) a OpenType je tedy něco jako swiss knife na ligatury?

A pokud by - čistě hypoteticky - nějaká chyběla, řešit se to v těch tzv. "moderních" sázecích systémech - na rozdíl od TeXu - bude prosím pěkně jak?

[Stanislav Brabec]

Je několik odlišných přístupů k tvorbě ligatur:

1. Ligatury definuje aplikace, a pokud se objeví příslušná dvojice znaků, sáhne na místo příslušného znaku v Unicode (nebo jiné) tabulce, a vysadí ligaturu.
2. Ligatury definuje metavrstva vložená mezi font a aplikaci.
3. Ligatury definuje font, a aplikace tuto definici respektuje.

To poslední je univerzálnější, a nezávisí to na existenci ligatury v Unicode tabulkách, na druhou stranu to ale silně komplikuje např. vytváření prohledávatelných PDF. To prostřední je takový hack z doby, kdy fonty ligatury definovat neuměly, ale aplikace již pro ně měly podporu. (Dal se také použít k definování znaků s háčky a čárkami, pokud v původním fontu chyběly.)

[Ash]

Čili pro upřesnění TeX umí 1 a 2 a když jde o jinou ligaturu je nahraný, a výše zmiňovaný "moderní" sázecí systém umí 1 a 2 a 3 a když jde o jinou ligaturu je - na rozdíl od TeXu - taky nahraný?

[Stanislav Brabec]

Původní TeX + MetaFont umí 3. Dokonce i ligatury-neligatury, jako třeba konverze „---“ na „—“, je řešena touto cestou.

Varianta 2 byla dodána později ve formě virtuálních fontů. Bez zásahu do TeXu i MetaFontu byla vložená mezivrstva, která bere fonty z MetaFontu, přesklávává je, a TeXu pak předává metriku takto vytvořeného virtuálního fontu. Veškerou práci s virtuálními fonty zajistily změny v programech pracujících s DVI soubory.

Potřeba implementace volby 1 se projevila až při generování prohledávatelných PDF (potřebujete mapovat ligatura → kód Unicode → interpretace kódu Unicode ve formě samostatných znaků).

Adobe Type 1 ani Intellifont, jediné běžné neTeXové formáty fontů v minulém století (později se k nim přidaly Adobe Type 3 a TrueType), nic takového neměly, a tak tehdejší konkurenční software téměř zásadně implementoval volbu 1 (pokud vůbec nějakou, a nepožadoval přímo po uživateli, aby místo „fi“ (dvě písmena) psal „fi“ (ligaturu)). To se změnilo až s příchodem Adobe Font Metrics, který skrze obezličku mezivrstvy implementoval ligatury specifické pro font.

Teprve s příchodem OpenType zmizela nutnost všech těchto obezliček, a volba 3 se stala jasnou volbou. Natolik jasnou, že jí implementují nejen sázecí programy, ale dokonce i některé knihovny klikacích grafických prostředí či webové prohlížeče.

Nicméně stále zde je potřeba prohledávatelných PDF, které vyžadují, aby použité ligatury byly v tabulkách Unicode. Jinak je sice lze vysadit, ale takový PDF pak nelze jednoduše (tedy bez analýzy tabulek ligatur použitého fontu) prohledávat.

[egg]

Nicméně stále zde je potřeba prohledávatelných PDF, které vyžadují, aby použité ligatury byly v tabulkách Unicode.

Je problém, aby se ligatura pro účely vyhledávání mapovala na řetězec místo jednoho Unicode kódu?

[olsak]

V PDF specifikaci je od jisté verze příkaz /ActualText, který umožní, aby se vyhledalo resp. vykopírovalo z PDF zcela něco jiného, než co uživatel přímo vidí v PDF vysázené. Takže TeX se svým makrojazykem by i toto dokázal vychytat.

Nicméně mi to připadá jako velmi akademická diskuse. Ve skutečnosti každé slovo, které je v sazbě rozděleno, není ve svém původním tvaru v PDF vyhledatelné. Aspoň tedy nevím o nějakém standardu, který by toto řešil. A takových rozdělených slov je řádově více než slov s ligaturou.

[Stanislav Brabec]

Jak mne kolega Olšák doplnil, jde o situaci, kdy mapování /ActualText není přítomno (nebo o starší formáty PDF, kde vůbec neexistuje), a PDF prohlížeč musí text zjišťovat analýzou toho, co je vysazeno. Pokud najde ligaturu „fi“, pozná ji podle jejího Unicode kódu, a najde slovo správně, i když uživatel zadá písmena „f“ a „i“. Pokud bych do fontu přidal ligaturu „fľ“, a správně ji definoval, program ji vysadí, ale PDF prohlížeč nebude mít tušení (pokud nebude analyzovat ligační tabulky použitého fontu), že jde o ligaturu písmen „f“ a „ľ“.

Tento problém není nijak nový. Pokud vygenerujeme PDF z TeXu starším způsobem TeX → DVI → dvips → ps2pdf/pstopdf → PDF, dostaneme krásné PDF, které ale vůbec nelze prohledávat, protože o kerning se v takovém případě postaral dvips, a pro PDF prohlížeč se jedná o nesouvislou změť skupin písmen rozposouvaných po stránce.

[petr_p]

Já mám pocit, že PDF nabízí reverzní převodní tabulku ToUnicode, která mapuje glyphy na unikódový text. Takže není problém při tvorbě PDF udat, že glyph G z fontu F představuje text T.

[Stanislav Brabec]

Předpokládám, že aby to fungovalo, musí to podporovat jak font, tak sázecí program.

(Jak je na tom moderní TeX, netuším; svět sazby jsem opustil v době, kdy tyto vychytávky byly ještě hudbou budoucnosti.)

[little.owl]

Ano, vysvetluje mi to, proc mi kopirovani z PDF u nekterych fontu tak casto selhava.

[little.owl]

Předpokládám, že aby to fungovalo, musí to podporovat jak font, tak sázecí program.

Tedy jestli tomu dobe rozumim, musi to podporovat predevsim sazeci program, a pokud chyby podpora ve fontu, je nutne to doplnit jinak. Na zaklade techto informaci sazeci program vygeneruje ToUnicode tabulku, ktera je soucasti PDF dokumentu. Musite mit jeste samozrejme PDF prohlizec, ktery to podporuje.

Pak staci pouzit:

\input glyphtounicode
\input glyphtounicode-cmr
\pdfgentounicode=1

a v prohlizeci zalozenem na poppleru mi pak vyhledavani pro Type1 fonty chodi.

[petr_p]

Tak nic. ToUnicode mapuje glyph na code point, nikoliv na řetězec.

[little.owl]

Nevim, nasel jsem puvodni zdroj, na ktery jsem chtel odkazat, serii blogu o pdf, konkretne ligaturachzde:

A ToUnicode table can be associated with a font that does not normally have a way to determine the relationship between glyphs and Unicode characters (some do). The table maps strings of glyph identifiers into strings of Unicode characters, often just one to one, so that the proper character strings can be made from the glyph references in the file.

[olsak]

Chtěl bych zde vyvrátit mylný názor, že vyhledávání textů v PDF bez nastavení /ToUnicode nejde. V PDF specifikaci je to zmíněno jako jedna možnost vedle další možnosti, vyhledávat podle standardizovaných názvů glyphů. Vyzkoušejte si za domácí úkol v ISO-8859-2 terminálu napsat:

pdftex -ini
**\relax
*\hsize=10cm \vsize=10cm \pdfoutput=1
*\font\f=csr10
*\f Tady je příklad vyhledatelného textu, to je finta.
*\font\fa=cmmi10 \fa \char12
*\end

Ty hvězdičky jsou prompt, budete si povídat s pdftexem. Nemáte-li po ruce ISO-2 terminál, můžete si řádek ,,\f Tady je příklad ...`` vložit do souboru, překódovat jej pomocí iconv do ISO-8859-2 a místo uvedeného řádku napsat \input soubor. Potom se podívejte do výsledného texput.pdf. Zkuste vykopírovat text včetně symbolu beta (přes clipboard nebo pomocí pdftotext). Dostanete ho v Unicode. Například symbol beta má v Knuthově fontu cmmi10 pozici 12, ale po vykopírování dostanete jeho správný UTF8 kód. Stejně tak v prohlížeči půjde vyhledat slovo ,,příklad``, přestože písmeno ř od svého vstupu do sázecího programu až po výstup do PDF nepoznalo, co to je Unicode.

Příklad se záměrně opírá o ini verzi 8bitového pdfTeXu (přepínač -ini), tj. bez jakýchkoli dopředu načtených maker, bez jakéhokoli překódování. Není použito žádné \input glyphtounicode. Proto například symbol beta není možné tisknout pomocí $\beta$, protože to není v iniTeXu definováno.

Proč to funguje: font má v PDF downloadovány nejen glyphy, ale i jejich názvy. Knihovna na čtení PDF (např. poppler) má vlastní tabulku ,,názvy to Unicode`` a s tou při vyhledávání nebo vykopírovávání textů pracuje. Ostatně jsem to popsal i v závěru nového dílu tohoto seriálu.

Můžete se za domácí cvičení ještě zamyslet nad ligaturou ve slově finta. Po vykopírování textu máte Unicode ligatury fi, třebaže v době vzniku fontu csr10 byl Unicode teprve vzdálená budoucnost. Všimněte si, co dělají vyhledávače textů: napíšete finta (bez ligatury), vyhledávač ve Vašem slově najde dvojici f a i, promění ji ve fi (podle Unicode) a takové slovo vyhledá.

[little.owl]

Nasadil jste mne brouka do hlavy a tak jsem se vcera tesne pred spanim kouknul jak to dela prave poppler.

Provadi se expanze ligatur a prevod do unicode. Kod je zde, implementovano mezi radky 1200-1324.

Pak se vytvori "textova stranka", coz vypada jako magie plna konstant, ale v zasade se jedna o skenovani dokumentu a snaha najit textove radky ci fragmenty textovych radku, list slov, vcetne detekce deleni. V tomto kodu je implementovano i vyhledavani ci vybrani textu na zaklade souradnic. Jadro kodu je zde.

Skutecne to vypada, ze spolehlive vyhledavani je predevsim zalezitost knihovny prohlizece.

[little.owl]

Jen mi vrta hlavou spolehlivost te expanze, ve fontu muze byt cokoliv, a pak je asi potrebna prave ToUnicode tabulka v pdf.

[Stanislav Brabec]

Kdysi (cca 1993) jsem koupil CD s TrueType + Type1 fonty, a ač jsou ty fonty východoevropské, názvy znaků jsou západoevropské. Tehdejší Corel, ke kterému byly ty fonty prodávány, to ignoroval, a TeX (resp. dvips) jakbysmet.

Kolik podobných zprasků se asi používá dodnes, a kolik podobných fontů je součástí existujících dokumentů na webu?

[petr_p]

Díval jsem se do specifikace PDF 1.7. strings of glyph identifiers into strings of Unicode characters je zavádějící, protože popisuje spíše implementaci než algoritmus. Pro úsporu místa je možné místo párování jednoho glyphu na jeden znak párovat rozsah glyphů na stejně dlouhý rozsah nebo seznam code pointů. Odsud asi ony strings. Navíc code pointy se zapisují v UTF-16BE, takže neBMP nebo složené znaky jsou z implementačního hlediska řetězec surrogates.

[Drekin]

Používá-li XeTeX a LuaTeX interně 16bitové kódování Unicodu, poradí si bez problémů se znaky mimo BMP přítomnými v UTF-8 vstupu? Tyto znaky se totiž v 16bitovém kódování do jedné codeunit nevejdou.

[olsak]

Omlouvám se, v článku mám chybu. Těch bitů uvnitř je poněkud více než 16. Tu šestnácku jsem si pamatoval z dob Omegy, ale ukazuje se, že situace je nyní už jiná. Dohledal jsem, že LuaTeX i XeTeX akceptují znaky v rozsahu 0 až 1114111.

[Miloslav Ponkrác]

XeTeX používá interně UTF-16, tedy pobere celé 21bitové kódování Unicode. Ostatně udělal to, co řada jiných programů, když rychle potřebuje Unicode, vzal ICU knihovnu, která je díky obsolete dědictví Javy a Microsoftu v UTF-16.

Nicméně nedělejte si iluze.

Ačkoli je IMHO XeTeX dnes jediným použitelným TeXem, protože nerozumím, proč by se dnes někdo chtěl trápit s něčím jiným, než Unicode a běžnými fonty – neumí to tak dokonale.

Na první problém narazíte, jakmile si vyzkoušíte matematiku. Zjistíte, že XeTeX je jen lehké pozlátko na starém TeXu, protože matematiku nezvládne ani Unicodem, ani běžnými fonty. To je opět vše ve starém 8bitovém hnusném Knuthovském stylu.

Tedy podpora Unicode není úplná ve všech částech TeXu.

XeTeX má ale řadu dodatečným maker a příkazů, které rozšiřují schopnosti TeXu oproti Knuthovskému vzoru o další grafické i jiné schopnosti, a je poněkud větší radost ho používat, než originální TeX.

Ba i dokonce práce s fonty je u XeTeXu o maličko radostnější nejen proto, že bere rovnou TTF a OTF fonty, ale umí s nimi i trochu více kouzlit.

Nicméně pořád je to TeX. Rok od roku čím dál víc drhne, a čím dál víc zaostává za tím, co umí jiné sázecí programy.

Miloslav Ponkrác

[little.owl]

Od konce VS, kdy jsem v LaTeX-u napsal dizertacni praci (majici pocit zbabelce po prednaskach p. Olsaka), jsem se toho dotknul jen jednou, kdyz jsem potreboval automaticky generovat pdf-ka ze SAT. Tedy vysledky SAT -> filter -> *.tex -> pdfTeX -> pdf report.

Pak uz jsem radsi toho *TeX bince nikdy nedotkl a udelal si zivot jednodussi, a vystacil si jen s markdown ci html. Cim mene to clovek pouziva, tim mene se mu v tom chce rypat.

Nicméně pořád je to TeX. Rok od roku čím dál víc drhne, a čím dál víc zaostává za tím, co umí jiné sázecí programy.

Jakou jinou alternativu ma tedy clovek k dispozici? U TeX a jeho pohrobku mi to stale prijde jako snaha hackovat neopravitelne.

[Nuphar]

Myslím, že nemá smysl používat jiný TeX, než ten založený na UTF8, že? Takže XeTeX nebo LuaTeX. Je v tom nějaký zásadní rozdíl? Také se musím přiznat, že jsem spokojený uživatel LaTeXu (přesněji XeLaTeXu) za vydatné pomoci Kile a KBibTeXu. Práce s LaTeXem mi plně vyhovuje. Také mi pořád není jasná, abych tak řekl, evoluční pozice ConTeXtu - je to něco jako LaTeX (akorát s jinou filozofií)? Tedy paralelně vyvíjená nadstavba nad plain TeXem? Podobně pdf(La)TeX. V jakém kódování pracuje? PDF mohu dostat z čehokoliv velice snadno, ne? Tak k čemu to je? Možná se v tom ztrácím, protože přede mnou Kile schovává něco, co by nemusel, ale funguje to, tak co.
Hlavně bych rád poděkoval panu Olšákovi za skvělý seriál. Možná se konečně dokopu k tomu, abych přečetl víc, než jen uživatelskou příručku.

[elenril]

Rozdíl mezi xetexem a luatexem mi přijde takový, že luatex je experimentálnější, ale umí toho víc. Např. luatex plně podporuje microtype, xetex jen částečně.

Ale hlavně luatex už je psaný jako normální moderní program s dynamickou alokací všeho podstatného, zatímco xetex (a předpokládám, že i všechny starší odrůdy texu) mají hromadu natvrdo nastavených hranic. Na to jsem narazil, když jsem chtěl do diplomky dávat contourploty vygenerované matplotlibem to pgf (tj. řádově několik MB velký textový soubor popisující něco takového). Všechny ostatní texy mi řekly že jsem se asi zbláznil, jen luatex to přeložil (i když mu to trvalo několik minut a chtěl přes GB paměti).

[Miloslav Ponkrác]

XeTeX umí bez problémů přímo vložit obrázek nebo jiné PDF. Takže řada problémů odpadá.

[michal.h21]

S pomocí balíčku luainputenc je možné používat 8 bitové fonty s utf8 vstupem i v lualatexu

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{luainputenc}
\usepackage[czech]{babel}
\usepackage{tgschola}
\begin{document}
Ahoj světe! Jak se mají žlutí koňové?

Příliš žluťoučký kůň úpěl ďábelské ódy
\end{document}

[olsak]

Děkuji za doplnění. Skutečně nejsem pochodující encyklopedie LaTeXových balíčků. Ale princip byl v článku vysloven: input procesor v LuaTeXu je udělán Lua skriptem a tudíž je modifikovatelný, zatímco v XeTeXu je input procesor neměnný. Takže není zas tak překvapivé, že někdo na to udělal LuaLaTeXový balíček.

[olsak]

S pomocí balíčku luainputenc je možné ...

Ještě jsem o tom balíčku přemýšlel a chtěl bych upozornit, že se mi to jeví jako nedotažené řešení. Především to při zápisu do textových souborů pomocí \write nekóduje zpět do sprévného UTF-8. O tom, že v TeXu je prováděná i zpětná konverze jsem v článku psal. Autor balíčku na to nějak zapomněl.

Za druhé do LuaLaTeXu jsou nataženy vzory dělení slov v Unicode, takže po použití luainputenc tyto vzory dělení fungovat přestanou a jiné tam nejsou. Pouze CSplain umí načíst vzory dělení současně v IL2, T1 i Unicode.

[Miloslav Ponkrác]

V XeTeXu je dvojice příkazů:

\XeTeXdefaultencoding … určuje defaultní znakové kódování pro všechny soubory, všetně následně vložených

\XeTeXinputencoding … určuje znakové kódování jenom aktuálního souboru

Není třeba nic měnit, žádný dodatečný balíček, funguje to transparentně. Žádné nadstavby ani makra nejsou třeba.

Miloslav Ponkrác

[Miloslav Ponkrác]

Ještě by chtělo dodat, že konverze mezi znakovými sadami XeTeX vnitřně provádí ICU knihovnou, takže to umí opravdu na co si vzpomenete a umí to dobře.

Miloslav Ponkrác

[Stanislav Brabec]

Není náhodou encTeX podstatně starší, než z roku 2002? Používal jsem ho mnohem dříve; na svém webu jsem našel zmínku o roce 1997 a můj vlastní port encTeXu na tehdy nový Web2C je z roku 2000.

[olsak]

encTeX měl dvě generace. V té první z roku cca 1997 encTeX umožnil snadnou konfiguraci input procesoru makry TeXu, ovšem konverze byla jen na úrovni byte to byte. Tuto generaci encTeXu v článku nezmiňuji.

Druhá generace encTeXu (cca z roku 2002) umožňuje konverzi na úrovni multibyte to byte-or-\csname. O této generaci se zmiňuji, neboť teprve tato umožnila konverzi z UTF-8.

[olsak]

Pan astrolog Miloslav Ponkrác přispěl včera třinácti různě roztroušenými příspěvky do této diskuse, ve kterých dává najevo, že TeX je špatně navržen a drží na sobě kouli minulosti, které se nikdy nezbaví. Částečně má pravdu, ovšem místy to poněkud přehání a pravdu nemá. A mám nepříjemný pocit, že záměrně mlží. Přestože ty jeho příspěvky projevují známky jisté trollovitosti, dovolím si reagovat. Ovšem případných následných reakcí se už zdržím.

Já a zřejmě mnoho dalších propadli TeXu zejména pro jeho otevřenost veškerých formátů (zdroj, výstup, fonty), jejich důkladné zdokumentování a neexistenci omezující překážky mezi uživatelem a softwarem v podobě líbivé slupky typu „tady jsem a klikej“. V rámci těch formátů můžeme vytvářet všelijaké modifikace a zcela nevídaná řešení sazby, která by jiným softwarem byla většinou nedosažitelná. Jestli tedy někdo považuje chybějící slupku a komplikovaný makrojazyk za chybu, budiž to jeho názor, ne můj.

I my, co máme TeX rádi a moc dobře mu rozumíme, si občas posteskneme, že by některé věci mohly být udělány jinak a lépe. Vede to k myšlenkám typu: kdybych já před pětatřiceti lety s těmi znalostmi, co mám teď, a s těmi technologiemi, které mě nyní obklopují, to měl navrhnout, šel bych na to jinak a lépe. Ovšem to jsou nereálná kdyby.

Reálné je, že v každém okamžiku má kdokoli možnost napsat něco kompletně nového a lepšího. Je zajímavé, že zatím nikdo neudělal něco, co by bylo výrazně lepší než TeX a začalo se místo něj přirozeně masově využívat. Pokusy byly (např, lout). I mě jednu dobu svrběly prsty. Ale navrhnout něco jiného a lepšího opravdu není jednoduché. Zůstal tedy jen pokrok v mezích nepatrných a nových možností soustředěný momentálně v projektech XeTeX a LuaTeX. Nějak jsem si nevšiml, že by „jiné sázecí nástroje“ dokázaly aspoň stejně dokonalou matematiku jako TeX. Že bych něco přehlédl? Že by „jiné sázecí nástroje“ dokázaly lépe než LuaTeX a XeTeX pracovat s nejnovějšími možnostmi OpenType fontů? O tom taky nic nevím.

Pokud tedy existuje „jiný sázecí nástroj“, stačí na něj jednoduše odkázat a prokázat, že je lepší než TeX. Ten odkaz jsem tady zatím neviděl.

[little.owl]

Tak asi vetsina zde uznava, ze pokud budeme posuzovat kvalitu vystupni sazby, nema [La|*]TeX v soucasne dobe stale konkurenci, a to i v okamziku kdy se nejedna o sazbu textu s velkym mnozstvi vzorcu, kdy je situace pak jasna, hezky je to videt i zde ve srovnani s MS Word ci Adobe InDesign.

Nicmene tento benefit u vetsiny nevyvazi nevyhody TeX, a tim je predevsim komplexnost jeho makrojazyka, urcita omezeni poplatna dobe jeho vzniku, dlouha ucici krivka a spousta nianci, ktere se vykouri z hlavy, kdyz to chvili nepouzivate. Dukazem budiz, ze vetsina lidi prestane TeX pouzivat v okamziku kdy opusti akademickou sferu, a skutecne to neni o tom, ze jinde by dobra sazba nebyla zadouci - jen ta cena je proste vysoka.

Problem se mi zda byt dnes i jinde. TeX byl designovan pro sazbu na papir, medium fixni velikosti a rozliseni (ok, dvi ...), v podstate staticky layout, jenze v budoucnu se bude vetsina dokumentu zobrazovat na obrazovkach ruznych velikosti a ruznych rozliseni, a pak je potrebny urcity dynamicky scaling. Skutecnost, ze kazdy znak muze byt umisten staticky precizne, mi nikdy nevykompenzuje treba fakt, ze starsi clovek s horsim zrakem zrakem si na svem zarizeni nemuze rozumne zmenit velikost pisma, aniz by se mu nerozpadl cely dokument. Energie se bude, IMHO, venovat spise nastrojum s rozumnym dynamickym vystupem do HTML5/CSS/MathML/SVG/JS, pripadne i s prevodem do PDF, typografie v teto oblasti se zlepsuje milovymi kroky, stejne jako souvisejici standardy. Bohuzel se mi zda, ze tady TeX pokulhava a veci jako latex2html ci latexml jsou spise k placi.

Kazdopadne dekuji za serii clanku, 'TeXbook naruby' mam stale ve sve knihovne, stejne jako par vzpominek travenych s ni, s TeX od CSTUG na RedHat 5.1 CZ, snazici se napsat semestralni prace.

[Fluttershy, yay!]

+1

BTW četl jsem někde, že zrovna indesign adoptoval jádro TeXu nebo aspoň některé jeho algoritmy.

[Josef Kufner]

To OpenOffice prý také.

[michal.h21]

OpenOffice adaptoval asi jenom algoritmus dělení slov, zarovnání odstavců má stejně tragické jako ostatní textové procesory.

[egg]

TeX byl designovan pro sazbu na papir, medium fixni velikosti a rozliseni (ok, dvi ...), v podstate staticky layout, jenze v budoucnu se bude vetsina dokumentu zobrazovat na obrazovkach ruznych velikosti a ruznych rozliseni, a pak je potrebny urcity dynamicky scaling.

Možná by to šlo vyřešit tím, že dokument by měl podobu TeXového zdrojáku. Při změně nastavení písma by čtečka spustila TeX, aby dokument znovu vysázel.

[little.owl]

Leda ze byste TeX prevedl pres emscripten do nejake javascriptove knihovny, jinak na to zapomente

[michal.h21]

S luaTeXem je možné makrojazyk TeXu úplně obejít a jako vstupní formáty použít třeba markdown, xml, nebo i komplexní formáty jako ODT nebo Epub (sice pro to zatím neexistují nástroje, ale technicky to možné je, viz Speedata publisher, nebo balíček pro čtení ods tabulek.)

Já osobně mám na TeXu rád hlavně makro jazyk, že si ho můžu přizpůsobit svým potřebám. Třeba pandoc a jeho varianta markdownu se mi také líbí, ale vadí mi, že pro nové vlastnosti bych si musel přizpůsobovat parser.

Souhlasím, že výstup do html5+mathml/epub3 je důležitý, nevím, jak jsou na tom latex2html (ten je dost zastaralý), nebo latexml, ale tex4ht se dá docela dobře použít k převodu do obou formátů (ale občas je třeba si ho trošku přizpůsobit a vzhledem k absenci dokumentace to není úplně triviální).

[little.owl]

S luaTeXem je možné makrojazyk TeXu úplně obejít

Nic bych neobchazel, na vstup (frontend) bych moc nesahal, prave stabilita makrojazyka je silna stranka TeX a to co podle informaci z clanku dela treba XeTeX mi prijde jako rozumny smer.

Klicem je IMHO backend, pokud bude k dispozici dobre integrovana implementace layout enginu schopneho generovat kvalitni epub3+ ci embeddable HTML5+CSS, s MathML, ma TeX opet na roky vyhrano, i kdyby se musely zatim pouzivat u prohlizecu obezlicky jako epub.js ci MathJax.

[ghibulo]

Energie se bude, IMHO, venovat spise nastrojum s rozumnym dynamickym vystupem do HTML5/CSS/MathML/SVG/JS, pripadne i s prevodem do PDF, typografie v teto oblasti se zlepsuje milovymi kroky, stejne jako souvisejici standardy. Bohuzel se mi zda, ze tady TeX pokulhava a veci jako latex2html ci latexml jsou spise k placi.

Řekl bych, že to pokulhávání není problém TeXu, ale těch konvertorů (la)tex2html/latexml... Když už je něco v něčem dobré, proč to nevylepšit i do jiných oblastí? Z TeXu jde velice snadno vytvořit značkovací nástroj na úrovni txt2tags/asciidoc/markdown... proč na takovouto jeho podmnožinu nevytvořit nějakej konvertor do dynamických formátů? Měli bychom možnost tuto podmnožinu TeXu postupně rozšiřovat a přitom stále disponovat s nestárnoucím formátem a dokonalým výstupem do pdf/ps. Vytvářet vedle TeXu zase novej nástroj s případným převodem do PDF, mi přijde jako znovu vynalézání kola.

[little.owl]

Řekl bych, že to pokulhávání není problém TeXu, ale těch konvertorů (la)tex2html/latexml...

Dobre, ale existuje dobry konvertor? Zmineny tex4ht generuje taky pekny binec, testovano na verzi svn30088.0 (Fedora 19).

[michal.h21]

Dobre, ale existuje dobry konvertor? Zmineny tex4ht generuje taky pekny binec, testovano na verzi svn30088.0 (Fedora 19).

to záleží na tom, jak vypadá konvertovaný soubor, žádný konvertor nefunguje stoprocentně. třeba tex4ht se snaží co nejvíc zachovat vizuální formátování, i za cenu divočejšího html kódu. ale dá se hodně konfigurovat, jen to není úplně trriviální

[ghibulo]

Chtěl jsem se zeptat - zkusil jsem si něco napsat pomocí xetex+opmac a všechno funguje nádherně, kromě dělení slov. Při pokusu použít příkaz \chyph se mi to zarazí...

This is XeTeX, Version 3.1415926-2.5-0.9999.3 (TeX Live 2013)
 restricted \write18 enabled.
entering extended mode
(./sbirkazakonu.tex
(/usr/local/texlive/2013/texmf-dist/tex/csplain/base/ucode.tex
Font encoding set to Unicode.
WARNING: czech+slovak hyphenation patterns are not loaded in Unicode.)
! Undefined control sequence.
l.2 \chyph

Můžete mě někdo prosím nasměrovat k řešení? Když jsem si teď zkusil u trochu delšího textu přidávat u přetečených slov dělítka, daleko více oceňuji práci pánů Ševečka a Lhotky pro csplain .

[olsak]

Příkaz xetex dokument spustí XeTeX s formátem eplain. Tento formát má nataženy vzory dělení podle souboru generic/config/language.def a k jejich přepínání používá příkaz \uselanguage, tedy v tomto případě \uselanguage{czech}. Můžete tedy zkusit použít tento příkaz a zůstat u XeTeXu s eplainem. Osobně tuto cestu nemám moc prozkoušenou, takže netuším, k jakým to může vést v souvislosti s OPmac problémy. I když, samozřejmě, OPmac je udělaný tak, aby aspoň anglicky fungoval i nad plainTeXem (není nutný csplain).

Já bych spíš vygeneroval csplain pod XeTeXem a ten použil, pokud tedy potřebujete použít Unicode. Tedy:

xetex -jobname pdfcsplain -ini -etex csplain.ini
xetex -fmt pdfcsplain dokument

Soubor pdfcsplain.fmt pak soukromě umístím mezi ostatní do web2c/xetex/pdfcsplain.fmt (následuje použití příkazu texhash) a konečně místo xetex -fmt pdfcsplain používám zkratku xeplain udělanou pomocí skriptu. Příkaz \chyph funguje jen v csplainu.

[ghibulo]

Moc díky za radu... s tím příkazem \uselanguage{czech} se akorát objevila chybička slovenských výrazů pro Tabulka/Obrázek, to druhé doporučenější řešení vypadá bezchybně.

Má nějaký smysl (kromě zpětné kompatibility starších textů) používat ještě encTeX místo XeTeXu?

[olsak]

Má nějaký smysl (kromě zpětné kompatibility starších textů) používat ještě encTeX místo XeTeXu?

Vaše otázka mě přinutila k vážnějšímu zamyšlení, děkuji za ni.

Je pravda, že začínající uživatel by se asi nemusel zabývat starobylostmi a měl by se zaměřit na XeTeX nebo LuaTeX. Ideální by též bylo, kdyby ty starobylosti (včetně staré dokumentace, která může vést jen ke zmatení) byly od začínajícího uživatele zcela odstíněny, aby se nemusel rozptylovat tím, co nepotřebuje. To bohužel jednoduše nejde.

Mírné důvody ke konzervatismu encTeX+pdfTeX nicméně zůstávají:

1. Za deset let existence encTeXu jsem udělal dvě aplikace, které využívají rozšiřující možnosti encTeXu: jednak (A) makro vlna.tex na automatické doplňování vlnek za neslabičné předložky a dále (B) DocBy.TeX na dokumentování SW projektů. Je v tom například technická dokumentace k OPmac.
   ad A) Existuje modifikace vlna.tex zvaná xevlna.tex, která funguje v XeTeXu. Analogii v LuaTeXu neznám.
   Obě zmíněné věci by se daly udělat v Lua skriptu pro LuaTeX, ale nepřinutil jsem se tím zatím zabývat. Ani nikdo jiný to neudělal.
2. V pdfTeX+encTeX mám vesměs všechny své věci. Je to engine, na kterém vše testuji a je nejvíce prověřený. Dávám mu známku nejvyšší spolehlivosti. Na druhé straně moje makra na XeTeXu či LuaTeXu považuji za experimentální beta verzi, kterou sám moc nepoužívám. Uvítám ale samozřejmě zpětnou reakci od uživatelů. To je třeba důvod, že csplain pro XeTeX a LuaTeX sice TeXlive generuje, ale není propojen s příkazem příkazového řádku. To se chystám v nejbližší době trochu posunout dál (pravděpodobně použiji názvy xeplain, luaplain a formáty budou mít nataženy vzory dělení všech jazyků). Ovšem dokud budu psát jen česky nebo anglicky, osobně se asi nepřinutím opustit pdfTeX.
3. LuaTeX i XeTeX jsou ve vývoji, nesázel bych tedy na jejich úplnou spolehlivost. Například load OTF je v LuaTeXu řešený pomocí Lua skriptů a já jsem do svých maker z toho cosi překopíroval a spoléhám se na to, že názvy a parametry funkcí, na které odkazuji, už nebudou měnit. Dokonce jsem se jich na to dotázal. Neodpověděli. I oni tuší, že změna je možná. Po změně má makra přestanou fungovat a vyřešení se dá očekávat až poté, co mi to bude nějaký uživatel reportovat a já se přinutím tím zabývat.
4. Je potřeba se rozhodnout, kudy dál, zda LuaTeX nebo XeTeX, což taky snižuje motivaci na to přejít. Důsledkem je bohužel neexistence jednoznačného doporučení pro nové uživatele, co místo pdfTeXu použít, neexistence jednoznačného horizontu, na který bychom měli soustředit své síly. Pro generování PDF mají LuaTeX a XeTeX zcela rozdílný backend, což komplikuje low-level makra pracující s fyzickými možnostmi PDF: je třeba udržovat dvě verze těchto maker. LuaTeX má stejný backend jako pdfTeX a tedy moje makra tam fungují přímo. Pro XeTeX musím přidávat obezličky (viz například opmac-xetex.tex) a stejně ne vše funguje zcela stejně jako v pdfTeXu.

[michal.h21]

ad A) Existuje modifikace vlna.tex zvaná xevlna.tex, která funguje v XeTeXu. Analogii v LuaTeXu neznám.

Obě zmíněné věci by se daly udělat v Lua skriptu pro LuaTeX, ale nepřinutil jsem se tím zatím zabývat. Ani nikdo jiný to neudělal.

Patrik Gundlach vytvořil callback pro lualatex, který toto řeší. Používá sice knihovny pro LuaLaTeX, ale ta funkce by měla fungovat i v plainu. Toto řešení je také obsaženo v balíčku impnattypo

[michal.h21]

Příloha:

• prevent_single.zip (786 bytů)

Řešení pro luacsplain+opmac

\chyph % nebo \uselanguage{czech} pro čistý luatex
\input opmac
\input luaotfload.sty
\input prevent-single 
\font\hello={Latin Modern Roman} at 12pt
\hsize=3in
\hello
Příliš žluťoučký kůň úpěl ďábelské ódy. Text s krátkými souhláskami a samohláskami i dalšími jevy z nabídky možností v textu možnými.
\bye

[olsak]

Řekl bych, že to je výchozí stav, který by bylo třeba trochu vylepšit. Zkuste v uvedeném příkladě dát poslední tři slova do závorky, tj. (v textu možnými). Pak to tu předložku nevychytá, zatímco makro vlna.tex ano.

Ještě bych chtěl uvést, že ten příklad je poněkud pomotaný. \chyph bez předchozího \input ucode nebude v csplainu fungovat správně. Chystám se vytvořit předgenerované formáty xeplain a luaplain, které už budou mít \input ucode do sebe zahrnuté, takže tato starost v budoucnu odpadne.

Dále já osobně se rád vyhýbám \input luaotfload.sty, protože to natáhne tisíce řádků roztodivných a pro mě nepřehledných maker, místo kterých použiji raději \input lmfonts. Podívejte se jen do logu, jaký je pak rozdíl v počtu natažených souborů. Mám rád jednoduchost. Takže:

\input ucode
\chyph
\input lmfonts
\font\hello={Latin Modern Roman} at 12pt
\input prevent-single
\hsize=3in
\hello
Příliš žluťoučký kůň úpěl ďábelské ódy. Text s krátkými souhláskami a
samohláskami i dalšími jevy z nabídky možností (v textu možnými).
\bye

[michal.h21]

Příloha:

• prevent_single.zip (942 bytů)

pokusil jsem se o novou verzi, která funguje i se závorkami a omezuje se jenom na předem omezenou množinu znaků, u kterých je vkládaná nezalomitelná mezera.

Pokud jde o luaotfload, je pravda, že je to velký moloch, ale to je kvůli tomu, že fontloader v luatexu jenom načte veškeré informace z fontu do tabulky a veškeré úkoly jako je aplikace ligatur a ostatní opentype featury nechává na makrech - to je třeba v xetexu řešeno opentype knihovnou, v luatexu to musí řešit makra.

Upravený příklad:

\input ucode
\chyph 
\input prevent-single
\input luaotfload.sty
\font\hello={name:Linux Libertine O:+rlig;+clig;+liga;+tlig} at 12pt 
\hsize=3in
\hello
Příliš žluťoučký kůň úpěl ďábelské ódy. 
Text s krátkými souhláskami a samohláskami i dalšími jevy z nabídky možností (v textu možnými). 

Grafika, ffinance -- pomlčka a tak.

I začátek odstavce je třeba řešit, i když výskyt zalomení není pravděpodobný.

Co třeba í znaky š diakritikou?

Různé možnosti [v závorkách <a jiných znacích
\bye

[little.owl]

Rekl bych, ze jste to omezil moc, cekal bych minimalne s-z-k-v-a-i-o, plus jejich uppercase varianty.

[olsak]

Pokusil jsem se o novou verzi, která funguje i se závorkami

Výborně, dejte to např. na CTAN, ať o tom vědí i TeXisté, kteří nečtou diskuse pod Olšákovými články.

Pokud jde o luaotfload, je pravda, že je to velký moloch, ale to je kvůli tomu, že fontloader v luatexu jenom načte veškeré informace z fontu do tabulky a veškeré úkoly jako je aplikace ligatur a ostatní opentype featury nechává na makrech

Nemáte pravdu. Veškerou inteligenci obstará font a dále Lua-kód, který modifikuje primitivní příkaz \font tak, že umí načíst OTF. Místo \input luaotfload.sty pište prosím \input luafonts. To csplainu sluší lépe. Pro srovnání: soubor luafonts.tex obsahuje jen 14 řádků maker a Lua kódu, zatímco luaotfload.sty načte 47 souborů a s tisíci řádky, aby nakonec dokázal totéž, co luafont.tex. Já mám rád jednoduchost, proto se mi vůbec nelíbí, že v ukázce pro csplain načítáte zbytečně komplikované makro.

[michal.h21]

Pokusil jsem se o novou verzi, která funguje i se závorkami

Výborně, dejte to např. na CTAN, ať o tom vědí i TeXisté, kteří nečtou diskuse pod Olšákovými články.

Zatím jsem to umístil na Github, na CTAN dodám později.

Pokud jde o luaotfload, je pravda, že je to velký moloch, ale to je kvůli tomu, že fontloader v luatexu jenom načte veškeré informace z fontu do tabulky a veškeré úkoly jako je aplikace ligatur a ostatní opentype featury nechává na makrech

Nemáte pravdu. Veškerou inteligenci obstará font a dále Lua-kód, který modifikuje primitivní příkaz \font tak, že umí načíst OTF. Místo \input luaotfload.sty pište prosím \input luafonts. To csplainu sluší lépe. Pro srovnání: soubor luafonts.tex obsahuje jen 14 řádků maker a Lua kódu, zatímco luaotfload.sty načte 47 souborů a s tisíci řádky, aby nakonec dokázal totéž, co luafont.tex. Já mám rád jednoduchost, proto se mi vůbec nelíbí, že v ukázce pro csplain načítáte zbytečně komplikované makro.

O existenci luafonts.tex jsem neměl tušení, proto jsem použil luaotfload. Ale tím molochem jsem myslel především tu lua knihovnu. Ovšem když jsem se na to teď díval, zdá se, že luaotfload.sty načítá knihovnu luatexbase.sty docela zbytečně a luafonts.tex poskytuje stejnou funkcionalitu s menším množstvím TeXového kódu.

[olsak]

Vývojáři luaTeXu bohužel od verzi k verzi dělají dost velké změny v konceptu. Například luatex z TeXlive 2013 už nepotřebuje lualibs a jeho luaoftload je generálně předělaný. Důsledkem toho je, že bohužel těch mých zmíněných 14 řádků funguje v luaTeXu 2012 (0.70) ale ne v luaTeXu 2013 (0.76). Tam je potřeba napsat jiných (podobných) 14 řádků a ještě jsem se nepřinutil to zveřejnit, ačkoli to mám už v počítači odladěné. Pak ale začne vznikat soubor luafonts.tex, který bude mít rozbočku na 14 řádků pro verzi 0.70 a na jiných 14 řádků pro verzi 0.76. A to zatím není moc dobrá vyhlídka. Takže připouštím, že je někdy lepší využít mnohasetřádkový luaotfload.sty, který je distribuován vždy v souladu s ostatními změnami ve verzích lua kódů, takže funguje.

Rád bych napsal nějakých definitivních 14 řádků a považoval to za vyřešené, ale v situaci překotného vývoje luaTeXu to není asi v tuto chvíli možné.