TeX – 9 (grafika) (diskuse)

[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.