TeX – 9 (grafika)

21. 1. 2014 | Petr Olšák | Různé | 3950×

Sazba textu společně s grafikou vytvářejí jednotný vizuální celek. Je tedy potřebné při tvorbě sazby mít pod kontrolou i tvorbu a umisťování grafických prvků. O TeXu se můžete na mnoha místech dočíst, že grafiku svými nástroji neřeší, že tento problém pouze postupuje prostřednictvím příkazu \special tiskovým ovladačům. Je to pravda jen částečně a dnes si o tom řekneme více.

Obsah

• Příkazy \special a \pdfliteral
• Příklad: přepnutí barvy
• Vložení obrázku
• Jazyky pro vytvoření obrázku
• Kombinování grafiky s textem

Příkazy \special a \pdfliteral

Po expanzi maker klade TeX písmena sazby (která vnímá jako obdélníky-boxy) vedle sebe do řádků, tyto řádky jsou zase boxy, které klade pod sebe do sloupců. To jsou také boxy, které jsou seskupeny případně do dalších boxů až vzniká kompletní sazba strany: box. Mezi boxy strká TeX podle maker a vnitřních algoritmů mezery různých pružností. Dále je TeX schopen vytvořit černý box s rozměry, které mohou souviset s rozměry okolní sazby (\hrule a \vrule). Takové obdélníky, jsou-li velmi tenké a dlouhé, se používají jako linky, například v tabulkách. Je tedy zřejmé, že s tímto přístupem je TeX schopen sestavovat pouze černobílou sazbu a svislé nebo vodorovné linky. Složitější grafiku takto nevytvoříme.

Kromě boxů, linek a mezer je TeX schopen do sazby dávat tzv. \special, což je bezrozměrná neviditelná „tečka“ v sazbě, která uvnitř DVI formátu nese textovou informaci. Tuto informaci může napsat přímo autor dokumentu, ale častěji je tato informace výsledkem expanze maker. Informaci pak přečte tiskový ovladač, a pokud ji rozumí, vykoná, co se po něm žádá. Například tam je jazykem ovladače napsáno: „přepni barvu sazby na zelenou“.

Tento koncept umožňuje dodatečně pomocí \special dosáhnout všeho, co dokáže použité tiskové zařízení, protože v argumentu \special s tímto zařízením hovoříme jeho vlastním jazykem. Zpočátku, při zrodu TeXu, bylo mnoho různých jazyků tiskových zařízení, takže argumenty příkazů \special byly závislé na následné technologii tisku. Později se téměř vše převádělo na jazyk PostScriptu, který vyvinula firma Adobe. Tento jazyk prodělal několik verzí a stal se koncem devadesátých let de facto standardem v počítačové typografii. Konverzi z DVI do PostScriptu obstará program dvips, který přečte argumenty \special, ve kterých mohou být přímo low-level příkazy PostScriptu, umožňující řešit jakýkoli grafický požadavek.

Dnes se častěji setkáme s formátem PDF, který ideově vychází z jazyka PostScriptu, ale není s ním kompatibilní. Je to také jazyk, kterým je možno popsat jakýkoli grafický element v dokumentu. K formátu PDF je možné dojít cestou přes DVI a následným použitím konvertoru dvipdfm. Argumenty příkazu \special v takovém případě mohou obsahovat jednoduché PostScriptové konstrukce nebo další speciální vzkazy, kterým tento konvertor rozumí. To je dokumentováno například zde.

Druhou možností je vygenerování PDF přímo pdfTeXem. Ten nabízí pro změnu příkaz \pdfliteral, který funguje analogicky, jako příkaz \special. Jeho argumentem může být jakýkoli kód z jazyka PDF a bude vložen na to místo sazby, kde je \pdfliteral použit.

Příklad: přepnutí barvy

V PostScriptu se na zelenou barvu přepneme pomocí 0 1 0 setrgbcolor a zpět na černou pomocí 0 setgray. Takže přechodná změna na zelenou může v TeXovém zdrojovém souboru vypadat takto:

\special{ps: 0 1 0 setrgbcolor}Sazba v zeleném.\special{ps: 0 setgray}

Po vytvoření DVI z této ukázky je možné ověřit, že PostScriptovému \special rozumí nejen konvertor dvips, ale též program xdvi, který správně zobrazí barvy. Rovněž konvertory dvipdf* rozumí PostScriptovým specialům a zkonvertují je do odpovídajícího PDF kódu.

Při přímém použití pdfTeXu vytiskneme zelený nápis pomocí PDF kódů na přepínání barev: 0 1 0 rg přepne na zelenou a 0 g na černou:

\pdfliteral{0 1 0 rg}Sazba v zeleném.\pdfliteral{0 g}

Autor textu pochopitelně nepíše tyto \special nebo \pdfliteral do textu přímo, ale použije již hotový balík maker (například v LaTeXu xcolor, v plainu třeba OPmac). Barvy lze pak přepínat poměrně přirozeně, například pomocí \color{green}.

Vložení obrázku

PdfTeX dovede vložit obrázek do výstupního PDF přímo, zatímco při cestě sazby přes DVI se interně používá \special, jehož argument obsahuje odkaz na obrázek a požadovanou velikost obrázku. O vložení obrázku se pak postará DVI ovladač. V obou případech autor textu typicky použije nějaké hotové makro. Například:

% v OPmac
\picw=\hsize \inspic obraz.png

% v LaTeXu
\usepackage{graphicx}
\includegraphics[width=\textwidth]{obraz.png}

PdfTeX umí vložit obrázky formátů png, jpg, jbig2, pdf. V sazbě pro ně vynechá odpovídající místo, jako při vložení velkého boxu.

Podle „druhu“ obrázku je třeba volit vhodný formát. Pro fotografie je možný bitmapový formát se ztrátovou kompresí jpg. Pokud nechceme ztrátu kvality bitmapového obrázku, použijeme png. Konečně pro čárovou grafiku (například Jiránkovy kresby perem) je nepochybně nejvhodnější vektorová grafika, tedy formát pdf. Jiné formáty (např. tif, eps) je třeba na některý z uvedených formátů překonvertovat.

Jazyky pro vytvoření obrázku

TeXista je zvyklý „programovat sazbu“ bez toho, aby přímo viděl výsledek. Může ho tedy napadnout a připadá mu přirozené, že by mohl také „programovat obrázky“. Pochopitelně nebude programovat obrázky typu fotografie. Na druhé straně fraktály, grafy, matematické náčrtky atd. jsou dobrými adepty na to vytvářet je pomocí zdrojových kódů. K tomu ale je potřeba programovací jazyk.

První možností je přímo využít jazyk tiskového zařízení, tedy PostScript nebo PDF. Kód v tomto jazyku stačí napsat do parametru příkazu \special a máme obrázek naprogramován. Ovšem tyto jazyky jsou příliš nízkoúrovňové a po světě se nepotuluje příliš mnoho lidí, kteří je plně ovládají. Z toho důvodu vznikly další jazyky, které kombinují možnosti TeXových maker a jazyků tiskových ovladačů, nabízejí uživateli „programátorské rozhraní“ na obrázky a na pozadí pochopitelně vytvoří sadu příkazů \special s odpovídajícími parametry, které realizují obrázek. Takovým jazykem na obrázky je například pstricks, který předpokládá, že výstup povede cestou DVI → PostScript. Dalším obdobným a velmi propracovaným jazykem je PGF/TikZ. Ten umožňuje navázat nejen na PostScript, ale podpoří i přímý výstup pdfTeXem do PDF.

Když si prohlédneme ukázky obrázků vytvořené v TikZ, tedy pomocí TeXových maker, těžko budeme nadále tvrdit, že TeX grafiku neřeší.

Pro úplnost uvedu ještě zastaralou možnost tvorby velmi jednoduchých obrázků přímo v LaTeXu v prostředí picture. Ta je nezávislá na použité tiskové technologii, protože nabízí jen omezenou sadu grafických prvků, které jsou obsaženy jako znaky ve speciálním LaTeXovém fontu. Sestavením těchto znaků TeXovými prostředky vznikají jednoduché obrázky.

Plno TeXistů si také oblíbilo pro programování obrázků použití Metapostu, což je rozšířený jazyk Knuthova Metafontu (původně navrženého na programování znaků fontů) s možností výstupu do PostScriptu. Výstup z Metapostu je možné zpětně zakomponovat do sazby.

Člověk při potřebě vytvořit vektorový obrázek typicky nesedne k textovému editoru a nezačne obrázek programovat výše popsaným způsobem. Místo toho použije interaktivní editor na obrázky, například Inkscape, Geogebra nebo něco podobného. Na tomto místě se sluší upozornit na to, že takové programy často nabízejí možnost exportu do některého z výše zmíněných programovacích jazyků na obrázky. Kromě toho si ukážeme jeden způsob, který umožní do TeXových marker či dokumentu vložit přímo jednoduchou čárovou grafiku vytvořenou Inkscapem. Stačí tento obrázek uložit jako EPS, sejmout z tohoto výstupu v textovém editoru část uvozenou q a ukončenou Q a překopírovat ji do parametru příkazu \pdfliteral. Uvedený úsek je totiž napsaný přímo v jazyku PDF. Uvedu příklad. V tomto souboru je EPS výstup jednoduchého smajlíka vytvořený Inkscapem. Do TeXového zdrojového dokumentu pak můžeme například napsat:

% Definice makra \smajlik:
\def\smajlik{\hbox to1.6cm{\vbox to1cm{}\pdfliteral{
  q .1 0 0 .1 0 0 cm
  0 214.857 444 -215 re W n
  0.701961 g
  443.43 107.427 m 443.43 48.099 344.164 0.002 221.715 0.002 c 99.266
  0.002 0 48.099 0 107.427 c 0 166.759 99.266 214.857 221.715 214.857 c
  344.164 214.857 443.43 166.759 443.43 107.427 c h
  443.43 107.427 m f
  0 g
  194.285 133.713 m 194.285 128.033 176.379 123.427 154.285 123.427 c
  132.195 123.427 114.285 128.033 114.285 133.713 c 114.285 139.396
  132.195 144.002 154.285 144.002 c 176.379 144.002 194.285 139.396
  194.285 133.713 c h
  194.285 133.713 m f
  317.715 132.572 m 317.715 118.685 304.41 107.427 288 107.427 c 271.59
  107.427 258.285 118.685 258.285 132.572 c 258.285 146.459 271.59
  157.713 288 157.713 c 304.41 157.713 317.715 146.459 317.715 132.572 c
  h
  317.715 132.572 m f
  0.776471 0 0 RG
  15.68 w
  1 J
  0 j
  [] 0.0 d
  4 M q 1 0 0 -1 0 214.857132 cm
  130.285 130.285 m 130.285 130.285 214.855 201.145 306.285 134.855 c S Q
  Q
}\hfil}}

% Použití makra \smajlik:
Aha, tu je smajlík: \smajlik. To je vše.

Tento příklad ukazuje, že je možné vytvořit obrázek interaktivně. Například pro oči smajlíka jsem neprogramoval jejich souřadnice, ale prostě jsem oči umístil v Inkscape „od oka“. Přesto se obrázek stává součástí maker TeXu a není uložen ve speciálním grafickém souboru. Expanzí dodatečných maker navíc lze měnit parametry obrázku (velikost, barvu, prohnutí úsměvu atd.), stačí jen maličko umět jazyk PDF. Úvod do této problematiky je možné najít například v článku Jednoduchá grafika PDF primitivně.

Kombinování grafiky s textem

Existují obrázky, které v sobě obsahují text, jehož font by měl korespondovat s fontem okolního textu. Například popisky os, vrcholů a dalších útvarů v učebnici geometrie. Když je sazba kolem v Computer Modern, měly by být tyto popisky také v Computer Modern. V okamžiku, kdy se rozhodneme změnit okolní sazbu třeba na Times, měly by být popisky v Times. Když obrázek dodatečně zmenšíme nebo zvětšíme, neměly by se zmenšovat/zvětšovat popisky, které mají mít stále velikost základního písma. V souvislosti s tím je třeba řešit následující problémy:

• Čáry obrázku je třeba uložit do grafického souboru bez popisků.
• Popisky je třeba na správné místo do obrázku dodatečně nastrkat TeXem.

Je sice možné pomocí TeXových \hbox, \vbox atd. umístit text prakticky kamkoli, ale v makru je potřeba TeXu sdělit rozměrové údaje, kam přesně to má dát. Možnost pokus/omyl je jistým řešením, ale není to moc pohodlné. Existují tedy i jiné cesty. Například v Metapostu je možno do obrázků vkládat na poměrně logická místa kotvy, podle kterých se pak dodatečným procesem TeX – Metapost – TeX k těm kotvám umístí popisky. Nebo v Inkscape je možno kromě obrázku psát texty přímo v TeXové notaci (například matematické vzorečky) a pak zvlášť do PDF uložit obrázek bez textů a zvlášť TeXová makra, která umístí texty na požadovaná místa. Toto řešení je ukázáno například zde.

Je také možné všelijak kombinovat grafické prvky s textem. Například dekorativní rámeček bude mít rozměry dané množstvím textu, který je tím rámečkem obklopen. Příklady takových interakcí sazba–grafika lze nalézt v již zmíněném článku Jednoduchá grafika PDF primitivně.

       

Komentáře

[Tomáš Pecina]

Jako první jsem zkoušel pdftex, ale zjistil jsem, že není příliš výkonný a když jsem po přechodu na XeTeX změnil postprocesor na xdvipdfmx, nelituji. Obsahuje některé možnosti, které pdftex nemá, např. referenci na vytvářené PDF objekty.

Takto např. vypadá vytvoření podpisového pole, což TeX normálně nepodporuje a musí se to dělat v "low-level" PDF:

% Signature fields                                                                                                                                                                                                                                            
\def\siglist{}
\def\sigfield#1#2#3{\xdef\siglist{\siglist @#1 }\setbox0=\hbox{\special{pdf: bxobj @App#1 width #3bp height #2bp}\special{pdf: content .9 .92 1 rg 0 0 #3 #2 re f}\special{pdf: exobj}}\ht0=0pt\dp0=0pt\wd0=0pt\box0\special{pdf: ann @#1 width #3bp height #\
2bp << /Type /Annot /Subtype /Widget /FT /Sig /T (#1) /F 4 /H /P /P @thispage /AP << /N @App#1 >> >>}\setbox0=\null\ht0=#2bp\wd0=#3bp\box0}
\def\acroform{\special{pdf: obj @AcroForm << /Fields [ \siglist ] /SigFlags 1 >>}\special{pdf: put @catalog << /AcroForm @AcroForm >>}}

[olsak]

Tento příklad zrovna moc neukazuje výhody xdvipdfmx konvertoru, protože to, co v příkladu vidíme, je vpodstatě low-level PDF kód občas kombinovaný lexikálními elementy, kterým rozumí jen xdvipdfmx. A celé je to schováno v ne příliš dobře napsaných TeXových konstrukcích. Napsat to přímo v PDF kódu, vypadalo by to stejně, možná trochu méně krypticky. A PDFTeX by si s tím poradil.

Osobně nejsem nadšený z toho, že zde kromě PostScriptu a PDF kódu je ještě třetí jazyk argumentů \special, sice to, co umí dvipdfmx, jak bylo zde ukázáno. Přitom to zřejmě neumí zatím všechno, co PDFTeX. Příklady drobných nedotažeností jsem popsal na konci souboru opmac-xetex.tex, který je součástí csplainu.

[Tomáš Pecina]

TeXové provedení nehájím, je naprosto utilitární ("aby to fungovalo"), ale ve zbytku pravdu nemáte (ledaže vyšla nějaká nové verse pdfTeXu, o které nevím). Už jen to poslední: dvipdfmx vezme id objektu AcroForm, který předtím vytvořil, a přidá ho do katalogu dokumentu. To pomocí pdfliteral nejde.

[olsak]

V článku jsem text záměrně zjednodušil, teď to upřesním. K různým vlastnostem PDF dokumentu se programátor při použití pdfTeXu dostane nejen pomoci \pdfliteral, ale k dispozici je rozsáhlá sada dalších primitivních příkazů. Například vámi zmiňované id objektu je po vytvoření PDF objektu příkazem \pdfobj k dispozici v registru \pdflastobj. Takže v pdfTeXu to jde.

Pravda je, že dvipdfmx nabízí přístup k vlastnostem PDF jinými prostředky, výhradně pomocí argumentů \special, ve kterých je speciální syntaxe pro různé účely. Jeden přístup tedy jde přes rozšiřování primitivních příkazů, druhý přes syntaxi argumentů \special. Je vidět, že toto je pro makroprogramátora, který by chtěl vytvořit makro fungující jednak v pdfTeXu a jednak při sazbě s použitím dvipdfmx (např. v XeTeXu) poměrně velká potíž, protože ty dva přístupy se diametrálně liší. Bohužel.

Nechcete-li dělat univerzální makra, nastudujete si manulál k jedné z těch dvou cest a tu pak vesele používáte. Uživatelé specializovaných maker, která se opírají se jen o jednu cestu, pak musejí PDF dokument také vyprodukovat specifikovanou cestou.

[Tomáš Pecina]

Tak tuto "vychytávku" jsem neznal, je možné, že by i pdfTeXu vytvořit podpisové pole šlo (jinou otázkou je, zda umí skutečně všechny důležité příkazy, např. zda má obdobu \special{pdf:put ...} jinam než do infa nebo hlavního katalogu).

Nicméně přístup pdfTeXu za správný nemám. TeX je značkovací jazyk navržený od počátku s chybou, spočívající v tom, že nerespektuje zásadu, že makra, která neznám, tiše ignoruji. Proto není vhodné implementovat speciální vlastnosti jednoho formátu jako systém maker, ale něčím, co tuto zásadu respektuje, tzn. např. \special s prefixem typu. Když někdo vytvoří Úplně Nový Formát UNF, budou se příkazy pro něj zapisovat jako \special{unf: ...}, a programátoři svá makra rozšíří o podporu tohoto nového formátu tak, že novou definici zapíší za starou, pro PDF.

U pdfTeXu lze sice vytvářet převodní makra - šlo by to ostatně pro XeTeX -, za vážnou vadu návrhu ale pokládám, že tak zůstane zachován "na věky věkův", minimálně v názvu maker, "pdf", ač tento formát může být dávno nahrazen nějakým jiným.

pdfTeX mám tedy za nevhodně koncipován.

[vencas]

Možná by stála za zmínku možnost volat externí programy s použitím --shell=escape a \write18 -- je tak možné třeba spustit gnuplot a vložit výsledek do dokumentu, umí toho využívat např. TikZ.

Obecně mi ovšem grafika přijde jako slabé místo TeXové sazby, a je to podle mě kombinace několika věcí. Jednak je neinteraktivní grafika sama o sobě složitá, zadruhé zrovna markojazyk pro ni není to nejpohodlnější (TikZ, který se to snaží obejít, má překvapivá zákoutí, kde něco nefunguje kvůli expanzi - jednou jsem narazil na mocninu záporného čísla, kde bylo třeba psát {\x}^2 protože x mohlo být záporné a unární minus mělo po expanzi menší prioritu než mocnina; už to myslím opravili), a zatřetí TeX nebyl navržen na to, aby s těmi programy dokázal interagovat -- typu protokol na komunikaci "kotev" pro text, dotazování externího programu na rozměry sazby apod. -- to se řeší obezličkami; osobně jsem to většinou řešil použitím stejného OTF fontu např. v matplotlibu a TeXu, ale ani to ještě není "ono", je třeba mít kolem dokumentu skripty na přegenerování obrázků apod.

[elenril]

Mně nakonec přišlo jako nejlepší řešení kombinace ručně psaného TikZu pro diagramy a podobné věci, a matplotlib s výstupem do PGF pro grafy. Pak člověk nemusí řešit fonty a nemá ve výstupu žádné ošklivé bitmapy. Trochu práce je ošetřit generování těch matplotlibových věci na vyžádání, to jsem nakonec ošetřil přes make + nějaké skripty. Výsledek působil celkem elegantně, až na chybějící generování závislostí pro make k danému texovému souboru (ala gcc -M).

[Gejza Jenča]

Ja používam destilačnú kolónu TeX s pstricks → ps → eps + pdf .

Tým vyrobím jednotlivé diagramy, ktoré potom zahrniem do hlavného dokumentu cez includegraphics.

To umožňuje používať pstricks aj pri produkcii PDF, nielen PS.

Toto je vzor toho postupu, ktoré som pripravil pre mojich študentov (je tam prihodený aj komplet manuál pstricks, aby to bolo all-in-one, ergo to je väčšie než je nevyhnutné).

https://bitbucket.org/gjenca/obrazky

[Josef Kufner]

Btw, povedlo se někomu dostat diagramy z Dia do LuaTeXu nebo pdfLaTeXu tak, aby popisky byly interpretovány TeXem? Tedy měly stejný font, stejnou velikost písma jako okolní text a šlo tam vkládat matematiku?

[michal.h21]

Dia má možnost exportu "LaTeX PGF macros", což je ve skutečnosti export do TIKZ. Písmo se použije textové, ale speciální znaky jsou escapované, takže vkládání maker ani matematiky nefunguje.

[Stanislav Brabec]

Ve skutečnosti je to ale mnohem, mnohem složitější.

Představte si, že použijete \special{ps: 0 1 0 setrgbcolor}Sazba v zeleném.\special{ps: 0 setgray} v sazbě, a co čert nechtěl, slovo Sazba bude na konci jedné stránky, zatímco zbytek barevného textu vyjde na další stránku. Pak se taková jednoduchá makra krásně rozbijí. Obarví nám patičku stránky, zatímco zbytek textu na nové stránce bude černý.

Bude třeba mnoho práce a mnoho přepisování základních maker, než vše začne fungovat tak, jak bychom chtěli.

A co více, takový žlutý text pomocí \special{ps: 1 1 0 setrgbcolor} po vytištění vůbec nemusí vyjít čistě žlutý. Čistou žlutou tiskovou barvu nelze v prostoru sRGB (implicitně použitého mnoha tiskovými zařízeními) nijak vyjádřit. A co hůř, každá tiskárna se s tím popere trochu jinak.

[olsak]

V článku se snažím nezacházet do detailů, aby to nebylo příliš unavující. Takže ten příklad jsem záměrně vybral jen jako zjednodušený příklad na to, jak může fungovat \special. Jinak pochopitelně o zmíněné složitosti vím. Sám se jí podrobně věnuji například na stránkách 28 až 32 technické dokumentace k OPmac. Kdo se barvami chce skutečně pořádně zabývat, může se tam inspirovat.

[Stanislav Brabec]

Nepochybuji, že to víte. Ale čtenář by snadno mohl nabýt dojmu, že TeX je k barvám a obrázkům přátelský. Jenže je to něco, čemu TeX vůbec nerozumí. Jsou to pro něj jen bezrozměrné tečky, jejichž obsah vyřídí někdo jiný. Následky na okolní sazbu musíme řádně ošetřit my.

[kjklfjslk]

Diky za upozorneni na TikZ. To je nastroj ktery jsem leta hledal...

[Miloslav Ponkrác]

Není jednodušší použít XeTeX a tyhle věci tam sázet přímo pomocí standardních příkazů XeTeXu?

[olsak]

Při diskusi o grafice v TeXu je rozumné oddělit proces vzniku obrázku od procesu jeho zařazení do sazby. Obojí také závisí na typu vkládaného obrázku. Například u fotografií můžeme hovořit o tom, kterým foťákem a objektivem fotografii pořídit, kterým softwarem ji začistit a případně upravit atd. Až je toto vše připraveno, pak zařazení do sazby je v tomto případě elementární operace: v sazbě se určí místo a velikost obrázku. Jen je potřeba vědět, jaké rozlišení bitmapy je pro fotografii vhodné (obvykle stačí cca 150dpi).

Jiným typem obrázku je vizualizace dat. K jejich pořízení se hodí zde již zmíněný gnuplot nebo mathplotlib. Tento software umí generovat výstup ve vektorovém PDF, takže zařazení do sazby je pak zase elementární operací. Pokud někdo místo toho exportuje z gnuplotu nebo mathplotlib do PFG, měl by dobře vědět, proč to dělá. Obrázek se totiž typicky skládá z tisíců malých objektů, které je pak při použití PGF potřeba znovusestavit během procesu přípravy sazby, což může narazit na paměťové limity, může to zpomalit sazbu atd. Jediný důvod takového postupu vidím v tom, že autor chce v těchto obrázcích použít font z okolní sazby resp. k tvorbě popisků chce využít silné možnosti TeXu (např. popisky obsahují komplikovanější vzorce).

Dalším příkladem jsou zmíněné Jiránkovy kresby. Je možné se bavit o tom, jak je naskenovat, jaký použít software na vektorizování obrázku, ale nakonec to končí exportem do vektorového PDF, který je snadno zařaditelný do sazby.

Pro každý typ obrázku se pochopitelně liší proces jeho přípravy, ale proces zařazení do sazby je často přímočarý: zařazení bitmapy nebo vektorového PDF. Jen výjimečně je potřeba do obrázku dodatečně TeXem dopravit popisky, a pak se nabízí mnoho dalších možností. Uvedu pro tento případ jednu netypickou možnost, kterou používá můj syn při tvorbě geometrických/matematických náčrtků. Popisky (vzorečky resp. celou abecedu) si ve správném fontu správné velikosti vygeneruje pdfTeXem do PDF. Pak v Inkscape tvoří nebo upravuje obrázek a v Inkscape si udělá z těch popisků obrysy (tj. už to není písmo). Jednotlivé obrysy chňapne myší a umístí do obrázku, kam potřebuje. Výhoda tohoto řešení: popisek umisťuje ,,od oka`` do místa, kam se vizuálně nejlépe hodí. Jakýkoli automat na generování kotev nevymyslí to, co subjektivně vnímá lidské oko jako nejlepší polohu. Zkuste například označit průsečík přímek jako P. Kam písmenko P umístit hodně závisí na tom, pod jakým úhlem se přímky protínají, jak vypadá okolí toho průsečíku v obrázku, že to je písmeno P a ne A, atd.

[kjklfjslk]

Mel bych dotaz k algoritmum, ktere prof. Knuth vybral pro TeX. Pisete, ze se obsah dokumentu rekursivne sklada z boxu (obdelniku) do usporadane struktury.

Proc vybral prave tento aloritmus? Je to proto, ze nejlepe kopiruje tiskove postupy? Nebo je to kvuli typografickym zvyklostem? Nebo je to kvuli narocnosti?

Urcite uz tehdy mu bylo jasne, ze to potencialne nemusi obsahnout vsechny moznosti a taky nepochybne znal algoritmy se zpetnym prohledavanim, ktere umoznuji umistit jakykoli objekt kamkoli.

Na druhe strane je jasne, ze vyber algoritmu byl stastny, ze i dnes (a pokud budeme psat tak jak se to bezne dela) funguje bezvadne.

[olsak]

Nějak mi není jasné, jaký jiný algoritmus byste považoval za lepší, než sestavování boxů. Těžko mohu číst dávné Knuthovy myšlenky, ale mohu se domnívat, že vyšel z technologie ruční sazby, kde jednotlivé literky byly hranolky dané šířky x stupně x výšky. A výška toho hranolku (ve všech ručních sazárnách normalizovaná na 23,56 mm +- 0,02mm) je přesně ten rozměr, který v počítači chybí. Zůstává pak jen obdélník. Ten obdélník navíc není přesně boundingbox znaku (boundingbox=obdélník minimálních rozměrů ohraničující kresbu znaku), ale šířku má upravenu tak, aby znaky šly klást za sebou do slov s užitím co nejméně výjimek (kerningových párů). Takže vlevo a vpravo kresby znaku jsou typicky mezery. Vertikální rozměr zase respektuje přesahy dané optickými klamy: ,,O`` přesahuje mírně přes vodorovné linky dané písmenem ,,K``, ale vertikální rozměr boxu mají oba znaky stejný jako K. TeXový koncept box-kern-glue se chystám popsat v nějakém z budoucích dílů seriálu, pokud vás ten seriál ještě bude bavit.

Na rozdíl od tohoto přístupu PostScriptové fonty mají o každém znaku údaj o boundingboxu, o počátku a o vektoru posunu. Počátek souřadnic znaku (typicky mírně vlevo od boundingboxu) se při kladení písmene umístí na aktuální bod sazby a tento bod se následně posune o vektor posunu. Tento vektor nemusí hypoteticky směřovat jen vodorovně, ale i třeba šikmo. Jen mi není jasné, k čemu by takový font byl.

Teoreticky může existovat požadavek na sazbu podél křivky. V TeXu to taky lze řešit, i když na to není primárně stavěný (pomocí \specialů, které postupně mění transformační matici). Ovšem algoritmy pro sazbu v takovém případě ztrácejí přehled, které místo v ploše je už sazbou zaplněno a kam se tedy co dalšího ještě vejde. A tento přehled jsou algoritmy schopny udržet při minimálním množství datových údajů jen tehdy, když si hotovou sazbu zjednoduší jako obdélníky (řádky, sloupce atd.).

[Josef Kufner]

Sazba podle křivky a podobné podivnosti se mohou vcelku snadno vyskytnout v mapách, grafech a různých diagramech či schematech. A pokud má být výstup tvořen z části hladkou sazbou a z části něčím neobvyklým, je pěkné, když obojí použije stejné fonty. Naneštěstí se většina grafických editorů sazbě textu příliš nevěnuje a na jedné stránce vedle výstupu TeXu to nevypadá vůbec pěkně.

[Miloslav Ponkrác]

Lepší algoritmus je přímo sázení křivek výsledných fontů. Je to ovšem mnohem komplikovanější algoritmus.

Považuji sázení podle boxů za druhý nejlepší postup. Je to postup naslepo, který neozhledňuje tvar výsledných znaků (ale věří metainformacím fontů) – byť metainformace ve fontech to činí velmi použitelným algoritmem.