Portál AbcLinuxu, 6. května 2025 02:12
% 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 >>}}
\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.
--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.
\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.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.