Každého, kdo zvažuje, zda pro nějakou sazbu je vhodný TEX, či jiný nástroj, zajímá, zda má cenu investovat úsilí do TEXu a jeho maker, nebo je vhodné sáhnout po grafickém nástroji.
Tento ostrý výběr není dán až tak TEXem samotným, jako spíš skutečností, že k TEXu neexistuje plnohodnotná grafická nadstavba. Citelně chybí grafický program, který by používal základní logiku TEXu (tj. boxy a výplňky) a dokázal by vytvořit layout stránky.
Textové procesory
Dobrou alternativou pro pořízení dat zejména pro začátečníky mohou být speciální (TEXtové :-) ) procesory, jejichž funkce je pevně provázána s TEXem. Mezi takové editory patří LyX a TEXmacs. Nezobrazují sice přesně to, co ve výsledku vygeneruje TEX, ale vytvořený text má stejnou logiku. Umožňují tedy snadnější pořízení vstupního textu (zvlášť pro LaTEX).
Import textu z běžných textových procesorů je jednou z cest, jak do TEXu dostat podklad pro sazbu. Některé editory (jako například Abiword a KWord) mají přímou podporu exportu do LaTEXu, pro jiné existují konvertory (např. wvLatex pro MS-Word – viz tento článek a wp2latex pro Word Perfect). Je to však spíš východisko z nouze – převedený text bývá plný zbytečných formátovacích příkazů a značek.
Grafika a rentabilita její sazby
Protože TEX není grafický editor, je příprava graficky orientovaných podkladů (obrázková sazba a jednostránkové kompozice jakéhokoliv druhu – letáčky, plakáty, vizitky) poměrně pracná. Zejména v případě obrázků s popisky na určitých místech nebo s obtékanými obrysy je sazba v TEXu značně nepraktická. Metodou pokus a omyl (nebo s pravítkem v ruce) opakovaně měníme numerické hodnoty jednotlivých výplňků, kompilujeme, a pak pozorujeme, zda je již dokument dostatečně úhledný. Grafická sazba je tedy v TEXu realizovatelná, ale je dost pracná, takže se na ni většinou nevyplatí TEX nasazovat.
Je třeba se rozmyslet, kdy nám stojí za to překonat tyto problémy, a kdy je vhodné použít jinou technologii (vektorový editor nebo DTP program). V moderní mluvě se tomu říká celkové náklady na použití.
Uvedu několik příkladů:
Chceme-li připravit jednu vizitku, příprava maker (seskupení na stránce a nastavení ořezových značek) a následné odladění polohy písma na vizitce nám může zabrat 20 minut, zatímco ve specializovaném programu pro návrh vizitek lze téhož výsledku dosáhnout během čtvrtinového času.
Zcela jiná situace nastane, dostaneme-li za úkol připravit 200 jednotných firemních vizitek, přičemž jména a funkce jednotlivých osob obdržíme v databázi. Při nasazení TEXu k nákladům připočteme pouhých deset minut k převedení dat z databáze do formátu vhodného pro TEX:
\def\jmeno {Jan}
\def\prijmeni{Novák}
\def\oddeleni{oddělení odbytu}
\def\funkce {vedoucí}
\generujvizitku
\def\jmeno {Hana}
\def\prijmeni{Novotná}
\def\oddeleni{}
\def\funkce {účetní}
\generujvizitku
Naproti tomu u GUI programu se stěží dostaneme pod dvě hodiny otrockého opakování příkazů „Kopírovat“, „Vložit“, nemluvě o riziku chyby, a tedy i nutnosti korektury. Pro 200 vizitek tedy TEX jednoznačně poráží GUI nástroje.
Dalším přikladem může být pořádání pravidelných akcí. Většinou potřebujete informační leták, informaci na webu, pozvánku, vstupenku a plakát, často v několika velikostech. Leták obsahuje totéž co web a jedná se o nadmnožinu informací z plakátu, vstupenka též zčásti jiné informace; navíc bude zřejmě orientovaná naležato, na rozdíl od letáku. Pokud takové materiály připravujete pouze jednou, nemá smysl o TEXu uvažovat – každý z materiálů zabere v TEXu minimálně dvojnásobně času než v grafickém programu.
Jiná situace nastane, pokud se taková akce opakuje často. Údaje uložené v databázi mohou zpracovávat dva skripty (např. v PHP) – jeden pro webovou prezentaci, druhý pro TEX. V případě XML data zpracuje třeba XSLT procesor a ConTEXt. Pak už záleží pouze na tom, jak jsme v TEXu zruční a jaké šablony pro prezentace vyrobíme.
Základní princip takové automatizece je stejný. Do souboru akce.tex zapíšeme:
\def\akce{Přednáška o zvířátkách}
\def\kde{kulturní dům}
\def\kdy{24. 11. 2002}
\def\cas{15:00}
\def\vstupne{30 Kč}
\def\foto{pejsci.jpg}
\generuj
Příkaz tex ‚&mujformat \input pozvanka \input akce‘ nám vygeneruje pozvánku, zatímco tex ‚&mujformat \input letak \input akce‘ vygeneruje leták.
Sazbu šablon v obou případech připravujeme v podstatě stejně jako obyčejnou sazbu, pouze namísto pevně určených textů použijeme makra. Musíme si však ohlídat různé poměry stran u obrázků a délky u textů. Je pouze na naší fantazii, jak to vyřešíme. Sazbu můžeme větvit podle toho, zda je fotografie na výšku, nebo na šířku, můžeme počítat optimální velikost písma pro jednotlivé nápisy. Pomocí výplňků (glue) vyplníme zbylý prostor.
TEX a barvy pro tisk
Připravovat s TEXem barevnou sazbu je možné a výsledky se prakticky v ničem neliší od výsledků profesionálních DTP programů.
Pokud se jedná o barevnou sazbu pro prezentaci na obrazovce nebo pro vytištění na stolní tiskárně, je barevná sazba prakticky stejně jednoduchá jako černobílá. Pouze je třeba dodržet pravidlo, že pro obrazovkovou prezentaci používáme RGB barvy a pro tištěnou prezentaci CMYK barvy. Jak PostScript, tak PDF sice umožňují kolorimetrickou specifikaci barev, ovšem běžná TEXová makra to zatím neumí.
Situace je komplikovanější, pokud chceme připravovat sazbu pro tisk. Již v makrech musíme pamatovat na přípravu souborů na osvit. Na filmu pro barevný tisk musí být mimo formát umístěny soutiskové značky, vhodné jsou i barevné značky a ořezové značky. Největší komplikace však pramení z barevné separace.
Nejjednodušší metodou je vytvoření kompozitního PostScriptu. Při ní se z jedné stránky sazby vytvoří jedna stránka postscriptového souboru. Pokud je osvitová jednotka vybavena moderním RIPem (nutno ověřit), dokáže takový soubor separovat na osvitu. U kompozitního PostScriptu nám odpadají starosti se separací, nastavením úhlů a frekvencí rastrů. Pokud vkládáme obrázky, vkládáme je jako EPS soubory v prostoru CMYK, v TEXu barvy definujeme též v prostoru CMYK (např. pomocí pstricks). Separací na osvitu se zbavujeme některých možností vylepšení barevného tisku – kompozitní PostScript neumožňuje přesah (aby se na hraně dvou sousedících barev tiskové plochy mírně překrývaly a při nepřesnosti soutisku nevznikla rušivá bílá mezera) apřetisk umožňuje jen u 100% černé (tedy aby se v místě, kde byla použita např. sytá šedá barva, neprovedlo vybrání v ostatních plátech), a to jen tehdy, pokud se to v RIPu nastaví. Tyto funkce budou zřejmě až součástí PostScriptu Level 4.
Pokud bude osvit prováděn na starší osvitové jednotce nebo potřebujeme využít speciální funkce, musíme vytvořit separovaný PostScript, kdy z každé stránky vytváříme několik barevných plátů. V TEXu je to skutečný oříšek. Znamená to vytvořit speciální konstrukce nebo modifikovat výstupní rutinu tak, aby vytvářela pro každou stránku sazby více výstupních plátů s různými separacemi. U každé barvy musí být správně nastaven úhel rastru. Celou situaci komplikují vložené obrázky. Zatímco černobílé obrázky se použijí pouze v černém plátu (a v ostatních se vytvoří bílý obdélník), barevné musí být separované již při vkládání do TEXu (tzv. formát DCS, skládající se z pěti souborů – čtyři barevné pláty plus kompozitní náhled). Naše nadstavba pak musí zajistit, aby do každého z těchto plátů byla vložena správná komponenta obrazu. Zároveň nám musí umožnit i přiměřený kompozitní náhled pro sazbu.
Celá situace hraničí s masochismem, pokud taková sazba navíc obsahuje i přímé barvy. Tehdy totiž nelze použít ani těch pár existujících maker, která pro barevnou separaci existují. Je třeba napsat vlastní (tmavá písmena v jedné barvě mohou být v jiné barvě světlá nebo neviditelná v závislosti na požadovaném přetisku). Přitom stačí drobná nepřesnost a filmy se mohou zahodit–
Kapitolu o barvách uzavřeme tím, že barevná sazba je v TEXu možná. Existuje dokonce i hotová podpora pro takovou sazbu (například podpora prostoru CMYK v balíčku pstricks, podpora separací v balíčcích aurora nebo cmyk-hax). Pokročilé funkce pro ofsetový tisk jsou však již poměrně tvrdým oříškem a k provedení takové sazby budeme potřebovat již poměrně dobré znalosti PostScriptu a výborné znalosti TEXu.
