Scribo, scribere, Scribus - III

21. 4. 2004 | Vlastimil Ott | Recenze | 9615×

PDF formát jako univerzální nosič. Vyšší dívčí aneb Podpora skriptování.

Vítám vás u posledního dílu našeho miniseriálu. Dnes se budeme věnovat zejména podpoře skriptování ve Scribusu a opět to bude téma úzce vázané na výstupní formát PDF. Program podporuje dva typy skriptování, z nichž se každý hodí k jinému účelu. Podpora JavaScriptu je svázána s PDF formátem a je závislá na koncovém prohlížeči, konkrétně řečeno na verzi Adobe Acrobat Readeru. (Jiné prohlížeče podporu JavaScriptu obvykle nemají, ale vývoj jde kupředu.) Python je na druhou stranu dvorní skripter aplikace - využívá se při samotném procesu navrhování a tvorby dokumentu.

PDF hraje do budoucnosti

PDF formát se stává milou skutečností a autoři programů s ním počítají. Je také nemožné vytvářet DTP program bez podpory PDF. Jak kvalitní je tedy tato podpora ve Scribusu? Využívá aplikace možnosti formátu ze 100 %?

Začněme jednoduše, ukážeme si možnosti výstupu do formátu PDF. Export se provádí volbou z hlavní nabídky (File/Export/Uložit jako PDF...) nebo kliknutím na ikonu na hlavním panelu. Zobrazí se exportní okno, ve kterém lze definovat, jaké vlastnosti bude mít nový dokument, případně, které se nevyužijí (z důvodu šetření místem apod.).

Na kartě Všeobecné lze uvést základní parametry souboru, platí pravidlo, že pokud vám vyhovuje standardní nastavení, nemá cenu něco měnit. Pokud nevyžadujete speciální vlastnosti formátu verze 5.0, ponechte 4.0, která je koncovými prohlížeči podporována snad už kompletně. (U verze 5.0 to ještě neplatí, alespoň pokud je mi známo.) Velmi vhodné je nechat vygenerovat náhledy (Vytvořit náhledy) a záložky (Včetně záložek), neboť zásadním způsobem zrychlují orientaci v textu. Pokud používáte textové řetězce (neboli logicky spojené textové rámce, mezi nimiž se přelévá vložený text), je možné vložit odkaz na ně do osnovy. Osnova, v hantýrce Bookmarks (záložky) se (obvykle) zobrazuje v levém sloupci prohlížeče.

Dále lze určit míru komprese obrázků, případně způsob, jakým je komprimován celý soubor. V neposlední řadě lze zadat rozlišení, ve kterém se má dokument a obrázky generovat. Slušným standardem pro obrazovku a domácí tisk je 300 dpi (bodů na palec). (Profesionál v tiskárně se vám pochopitelně vysměje, ale pokud poběžíte do tiskárny, víte už jistě dávno, co a jak zařídit.)

Karta Písma je důležitější, než vypadá. V levém seznamu se zobrazují písma použitá v dokumentu, v pravém ta, která budou uložena do souboru. Napadá vás, proč ukládat písma do souboru? Použijete-li své originální písmo nebo mnohdy stačí lokalizované, nemusí být pochopitelně čitelné na jiném místě zeměkoule nebo v jiné době než právě teď a tady. Proto je z tohoto pohledu praktičtější písmo do dokumentu vložit.

Na druhou stranu, použijete-li konvenční rodinu times nebo helvetica, koncové zařízení - prohlížeč si s ním poradit musí nebo by aspoň měl(o). To jistě není případ profesionální sazby, tam se žádný byť sebemenší hazard netoleruje. Pro naše účely ale obvykle stačí vnitřní písma prohlížeče. Důležitým detailem je, že vložená písma řádově zvyšují velikost souboru - není problém dostat se s pěti vloženými písmy na několik megabajtů, ačkoliv text samotný zabírá např. dvacet kilobajtů.

Karta Extra je pro hračičky a trošku nás v té šedivé teorii pobaví. PDF disponuje nejen možností vložit externí (multimediální) data, ale také interními efekty, které nejsou nijak uchvacující, ale do technicky zaměřené prezentace vnesou trochu oživení. Lze si vybrat mezi šesti typy efektu, nebo bez efektu. Každý efekt lez aplikovat na konkrétní stranu, nebo na všechny. Je možné také u každého určit dobu trvání a zobrazení.

Karta Bezpečnost je samovysvětlující - jedná se o podporu šifrování dokumentu; resp. určí se heslo pro vlastníka dokumentu, který může jeho zadáním zrušit všechna omezení, a heslo pro pouhého čtenáře, proti kterému jsou omezení zaměřena. Podle toho, které heslo zadáme, máme odepřeny, případně povoleny, určité možnosti, jako je tisk, výběr textu pomocí TextTool apod. Acrobat Reader reaguje následujícím způsobem, chceme-li dokument otevřít (první obrázek) a pokud jako čtenář chceme vybrat text a zkopírovat jej do schránky (druhý obrázek).

Na kartě Barva vybereme médium, pro které je dokument určen. Karta PDF/X-3 je určena pro profesionálnější zacházení než to, kterého jsem schopen; aktivuje se po definici barevných profilů, jak jsem se dočetl v nápovědě.

To jsou tedy ve zkratce možnosti pro exportování do PDF formátu. Během psaní jsem vytvořil ukázku, která není vůbec reprezentativní, ale jsou v ní použity téměř všechny funkce a efekty; včetně hesel. Heslo vlastníka je "heslo1", heslo pro čtenáře zní "heslo2". Ukázku si můžete stáhnout jako PDF nebo jako zdroj. Nutno podotknout, že ne všechny efekty mně fungují, ale o tom níže.

JavaScript

JavaScript je tím prvkem, který přináší do statických dokumentů trochu života. Specifikace PDF formátu je dnes již dostatečně široká, zahrnuje audio- i videodata, křížové odkazy, odkazy mimo dokument, odkazy na web a v neposlední řadě i interakci uživatele. Problém je, jak už bylo uvedeno, v koncovém prohlížeči. Firma Adobe je lídrem oboru, lídrem ale poněkud vadnoucím. Přesto lze konstatovat, že vlastnosti PDF formátu lze využít především v jejích produktech; bohužel dodnes nelze využít vlastnosti všechny. Nemohu opět nezmínit známou nepříjemnost s ISO8859-2 subkódováním, které jsem zmiňoval v minulém článku. Ta totiž před námi nyní vyhřezne v plné obludnosti. Omlouvám se za expresivitu, ale všechno, čemu se dnes budu věnovat, je limitováno a negativně ovlivněno absencí diakritických znamének. Poznámka: Adobe Acrobat Reader musí mít správně nastavenou sekci Weblink (konfigurace externího www prohlížeče).

PDF Forms

Jak už jsem zmínil, do dokumentu lze vkládat tzv. PDF Forms neboli formuláře. Ty mají smysl pouze v okamžiku, kdy si dokument uživatel prohlíží na obrazovce. Lze si sice připravit i vlastní papírový formulář, ale to jistě není původní účel těchto objektů. Jsou totiž schopné interaktivity a na základě určitých událostí, které generují, je možné naprogramovat reakci. Otázkou je, do jaké míry má delší rutina v takovém PDF dokumentu význam, potažmo když je skript proveditelný pouze v Acrobat Readeru určité verze.

Libovolný PDF objekt se vloží klasickým postupem stejně jako jiný objekt. Lišty PDF objektů jsou dvě a obsahují celkem sedm prvků, šest z nich představuje vizuální element, jeden je element logický (zřetězení textu).

Vložení prvku, skript

Vložme objekt požadované velikosti, pravým tlačítkem vyvoláme kontextové menu a zadáme text elementu (Editovat text). Dále vyvoláme okno pro nastavení PDF-vlastností (Vlastnosti pole příp. Vlastnosti poznámky). V horní části okna lze měnit typ elementu, na výběr mám již oněch pět zmíněných (PDF-poznámka je samostatný objekt, zřetězení textu je záležitost jednoho příznaku u textových polí, která se interpretuje jako vlastnost PDF formátu).

Teď chceme vyvolat reakci na uživatelskou akci. Na kartě Akce vybereme JavaScript, typ akce (Stisk tlačítka myši), stiskneme tlačítko Upravit a ve vestavěném editoru zadáme příkazy JavaScriptu, v tomto případě

getURL('http://www.abclinuxu.cz');

a změny uložíme. Tato akce nebude fungovat ve Scribusu samotném, protože ten používá PDF pouze jako exportní formát, nikoliv jako interní. Provedeme tedy export dokumentu do PDF (Soubor/Export/Uložit jako PDF nebo ikona na panelu) a tento PDF dokument zobrazíme v Adobe Acrobat Readeru verze vyšší než 5.x (!). Po kliknutí na tlačítko (element) by se měl spustit prohlížeč (musí být nastaven ve Weblink části Acrobatu) a načíst stránku. Ale!

Spolehlivě mi fungovala pouze PDF Poznámka a její akce Odkaz ven na web. U ostatních prvků jsem byl sice schopen dosáhnout požadovaného vzhledu, ale již ne funkce. Ačkoliv JavaScript nijak nepoužívám, základní abecedu znám. Na webu jsem našel bohužel pouze jeden soubor na téma Scribus a JavaScript, ve kterém vše ukázkově funguje, jeho zdroják jsem ale nenašel. Takže bohužel musím skončit frází "Šedivá teorie, zelený strom života". Tomuto problému jsem věnoval celkem asi tři dny, takže si říkám, že chyba musí být ještě i někde jinde, jen ji najít...

Python

Jak už bylo zmíněno, Python je určen pro snazší navrhování stránek. Součástí aplikace je modul Scripter, který neslouží k ničemu jinému než spouštění a ladění skriptů, s jejichž pomocí lze vygenerovat standardizovaný dokument. Pěkné příklady naleznete na webu Scribusu.

Další vstupní a výstupní formáty

Do textových polí lze načíst nebo přidat text z externího souborů. Tato funkce existuje i při exportu. Importovat lze i další stránky z jiného .sla dokumentu (nativní formát Scribusu). Importovat a exportovat lze i SVG, Scalable Vector Graphic, formát souborů obsahujících vektorovou grafiku. Zde se vývojářům otevírá velký prostor pro inovaci, protože ne vždy se SVG soubor podaří otevřít a zpracovat v jiném programu (např. v Sodipodi nebo Inkscape). (Vycházím z toho, že jsou známé jisté problémy při exportu do SVG a testované vektorové editory hlásily chybu při otevírání souboru.)

Kromě toho lze dokument exportovat jako EPS, Encapsulated PostScript, zapozdřený postscript, který je řádně interpretován např. aplikací GhostView.

Pluginy

Množství pluginů není velké, ale i to málo, které je zatím k dispozici, práci ulehčí. Především se jedná o variantu programu Vlna, který TeXisté dobře znají. Program (v TeXovém zdrojáku) najde všechny jednoslabičné předložky a doplní za ně symbol pro nezlomitelnou mezeru, neboť podle typografických pravidel se tyto znaky nesmějí vyskytovat právě na koncích řádků.

Scribus Vlna dělá přesně totéž. Autorem je první a jediný (?) Čech ve vývojovém týmu Scribusu - Petr Vaněk. Kromě Scribus Vlny přispěl ještě superpraktickým vizuálním seznamem písem a je také autorem zmiňovaného Scripteru.

Pozn. Bohužel je v aktuální verzi 1.1.6 chyba, kvůli které nelze použít plugin Scribus Vlna. Oprava se však nalézá v CVS a budiž omluvou, že chyba vznikla banálním přehlédnutím. Jak jsem pochopil z Petrova mailu, nebyl do zdroje vložen jeden hlavičkový soubor, který je ovšem přiložen. Stačí tedy ručně vložit jeho použití a kompilovat.

Budoucnost

Scribus-team právě zveřejnil plán pro budoucí verze. Po dobu, po kterou sleduji konferenci vývojářů, došlo k odhalení mnoha bugů a nyní se plánuje jejich náprava. Každou chvíli také padají návrhy na další zlepšení. Na tomto místě je vhodné podotknout, že vývoj aplikace je extrémně dynamický a vývojáři spíše přibývají, než by ubývali. Přesto, nebo spíše právě proto, je např. dokumentace již zastaralá, protože prostě nestačí tempu vývoje. Proto také některé mé poznatky neodpovídají pravdě, protože než vše jsem odhalil.

Program není tak amatérský a jednoduchý, jak se mi jevil na první pohled. Naopak. Práce s ním je logická a vývoj směřuje ke zdokonalování důležitých součástí, zatímco nové prvky přibývají pomalejším tempem. Naštěstí je stále co zlepšovat, takže nehrozí, že by program skončil na nějakém e-smetišti. Cogito ergo sum!

       

Komentáře

[iWan]

IMHO 300dpi je presne tolik kolik je treba pro profi tisk. Kdyz nekdo prinese neco do tiskarny ve vyssim rozliseni, stejne to tam pravdepodobne downsampluji na 300. A celkem si za tim tvrzenim stojim, protoze jsem pul roku u osvitky honil svinskym krokem radoby grafiky co nosili zakazky v 75dpi, ale s vice jak 300dpi jsem se setkal jen sporadicky.

[Martin Dvorak]

DTP a pozamo osvit je uz docela dlouho tim, co me zivi, takze snad mohu rozumne reagovat: S rozlisenim nad 300 dpi se setkate pomerne casto (alespon byste se mel setkavat). Ono totiz potrebne rozliseni primo souvisi s rastrovaci frekvenci. Nyquistuv samplovaci teorem rika, ze je treba vice nez dvojnasobne samplovaci frekvence, nez je frekvence samplovana. Jelokiz nejpouzivanejsi byla drive frekvence 150 lpi (linek na palec), pouzivalo se rozliseni 305 dpi (nekteri neznalci si to "zaokrouhlili" na 300). Nyni se nejcasteji pouziva 175 lpi => rozliseni > 350 dpi. Pro kvalitni ofsetovy tisk na bazi alkoholoveho vlhceni neni vyjimkou ani frekvence 200 lpi - potom rozliseni musi byt vetsi nez 400 dpi. Snad je to napsano pochopitelne MD

[Tomas]

ja tomu teda nerozumim, ale sazim (proste tam nacpu text + foto) mistni bulvarni platek - cernobily,normalni papir (gramáž nevim, křídový ne) a graficke studio, ktere nam delalo prvni cislo a dali mi hodnoty pro export z corelu via distiller do PDF, nastavili distiller na resolution 1200dpi?? na osvitu říkám A4 1200dpi 133lpi otáčet. co si o tom mam myslet?

[Martin Dvorak]

Myslim, ze maji castecne pravdu. 1200 dpi je rozliseni osvitky potrebne (spise "bezne pouzivane") pro "zvladnuti" frekvence 133 lpi. Cili vysledny PostScript (a potazmo PDF) by mel mit nastavene rozliseni 1200 dpi a 133 lpi (110–133 lpi je rozumna hodnota pro CB tisk). Nutno rici, ze MEL, ne nutne musel. Obe tyto hodnoty nemaji zadnou souvislost s Vasimi vstupnimi daty a lze je proto nastavit explicitne az na osvitove jednotce. Doporuceni pro vas: 1. veskere bitmapy necht maji rozliseni minimalne 270 dpi (2*133+"_neco_malo") 2. u vektoru (a tez textu) je to jedno, rozrastrovani probehne az na osvitce 3. nastavite-li spravne hodnoty pro tvorbu PostScriptu (1200dpi a 133lpi), nebudete zavisly na tom, jestli to nezapomenou na osvitce prenastavit. Pozn: Potrebne rozliseni osvitky pro pozadovana lpi si snadno spotitate dle vzorce pocet_barev=(druha_mocnina(rozliseni/freq))+1. PostScript Level 2 definuje 255 stupnu sede a proto, chcete-li je kompletne vyuzit (aby prechody nebyly pruhovane), musi byt rozliseni nejmene 15,94*frekvence. Mejte se. MD

[daymoon]

Nechci byt hnidopich, ale teorem se jmenuje Shannon-Kotelnikovuv. Jinak soouhlasim.

[Martin Dvorak]

Omlouvam se za nepresnost. Asi si to ze skoly spatne pamatuji. Kratke hledani na googlu vsak vysypalo, ze teorem je Nyquistuv. Shannonem byla rozsirena jeho platnost pro zasumene kanaly... Myslim, ze tam vsak nezalezi. MD

[fritzek]

Shannon-Kotelnikov-Nyquist-Whittaker. Ale ve skole to byl take vzdycky Shannon-Kotelnikov. V americke literature zase Nyquist-Shannon.

[Quo]

Dá se ve Scribusu sestavit brožura? (Podobně jako v PageMekeru nebo InBookletu.) Tj. přeskládat stránky.

[Juraj Václavík]

Možná to tam jednou bude, ale stejně to bude jen frontend pro psutils. Takže nic nebrání vyrobit pdf a prohnat jej přes psutils (pstops & spol.) ručně. Možnosti podstatně širší, než jen brožura - český popis viz http://www.agrospolvb.cz/paja/navody_psutils.php.

[Ctirad]

Když už je řeč o DTP na linuxu, nestálo by za to oslovit autory programu Calamus, aby popřemejšleli o nativní Linux verzi ? Nebo alespoň naprgat něco, aby mohla běžet v linux ta stávající verze (ostatně na MAC i Windows to taky běží pod "emulací") ? Proti Scribusu nic nemám, ale bude ještě dlouho trvat, než se bude moci zařadit mezi první DTP ligu.

[Tomas]

hmm.. scribus nabizi neco za nejakou cenu, calamus neco mnohem vic za cenu mnohem jinou...

[Ctirad]

Jistě je mnoho lidí, kteří by rádi dělali pod linuxem profi DTP a rádi by si zaplatili za kvalitní software. A než přemlouvat nějakého giganta, kterého zajímají statisíce prodaných kopií, je lepší oslovit autory neméně kvalitního alternativního produktu, kterým by těch prodaných kopií stačilo o pár řádů méně, že ano.

[Peter Lehotsky]

http://www.calamus.net/cz/ticker/index.html ale urcite je spamujte, nic se tim neskazi.

Peter Lehotsky

[Tomáš Pelc]

S nativní podporou Calamusu pro Linux to vidím bledě. Vždyť oni pořád jedou pod emulací TOSu. Po té, co vzdali vývoj nativně pro Windows, si to opravdu nemyslim.
V současné době lze Calamus v Linuxu úspěšně rozchodit přes WINE. Nevím, jak je to s přímým tiskem, ale ten při možnostech exportu do PS, PDF ap. není ani tak třeba, že. Jenom ta rychlost se dvojí emulací docela ztrácí.

[Ctirad Feřtr]

Oni ten windows port vzdali ? To jsem nevěděl. Z jakého důvodu ? Nebyli to schopní naprgat (vždyť už kdysi dávno jedna nativní verze Calamusu pro widle byla) nebo z důvodů nerentability ? Jestli to druhé, tak tam by právě mohli mít na linuxu dost velkou šanci prorazit, protože by defacto měli monopol.

Jinak ten nápad s WINE je dost úlet. Nativní TOS aplikace se dají přece v linuxu provozovat neporovnatelně elegantněji a rychleji než oklikou přes windozní emulátory ST/TOS (hint hint )

[Tomáš Pelc]

Jak? Aranym? To už jsme asi dost off-topic. Ale tam to taky není tak jednoduché.

[s0]

> Proti Scribusu nic nemám, ale bude ještě dlouho trvat, než se bude moci zařadit mezi první DTP ligu.

ctirade, zajimaly by mne duvody, proc tohle tvrdis - mohl bys je zesumirovat a poslat mi je na petr@yarpen.cz nebo do bugs.scribus.net?

[Martin Dvorak]

Odpovim za pana Ctirada a primo sem. 1. Scribus nepodporuje obrazky ve CMYKu 2. Nema palety s PANTONE barvami a importnete-li eps s pantone barvami, separuje je naprosto spatne 3. Obecne separuje barvy zcela spatne a pouziti LCMS nic neresi 4. Scribus + LCMS = silene barvy na obrazovce a neuveritelne zpomaleni uz tak pomaleho programu 5. PostScript generovany Scribusem ma zasadni chyby v subrutinach pisem a neznam zadny interpretr, ktery by ho byl schopen zpracovat 6. Ma prebujele GUI - zabira prilis mista na ukor zpracovavaneho dokumentu (srovnej Quark, InDesign na Win i Mac), to je ale VELIKY problem vetsiny Linuxoveho softwaru (napr. Gimp) 7. Drobnosti - chybejici klavesove zkratky... Obavam se, ze dokud nebudou vyreseny problemy 1-5, tak by se produkt mel oznacovat jako BETA. Az po jejich odstraneni muzeme zacit hodnotit jeho funkcnost. MD

[s0]

ok, dik. ad bod 5 - muzete to nejak lepe specifikovat?

[Martin Dvorak]

Nejsem odbornikem na PostScript a proto ze me mnoho informaci nedostanete Jedna se o to, ze pri pouziti jakychkoliv mych pisem TrueType i PostScript Type 1 (ktera funguji na woknech dobre a v OO.org na Linuchu take) Scribus vygeneruje PostScript, ktery neumim zadnym interpretrem zpracovat (zobrazit, vytisknout). Zkousel jsem nase PostScriptove tiskarny, GhostScript (win i lin) a Distiller. Vse padne s hlaskou napadne pripominajici chybu v subroutine prvniho pouziteho pisma a stack je plny binarniho "bordelu". Mimochodem: pouzivana pisma mela ruzna kodovani: win1250, iso-8859-2, utf8 a nektera PS Type1 pisma mela sve vlastni specialni kodovani - problem byl ale u vsech stejny... MD

[s0]

prosim, ozvete se na petr@yarpen.cz - rad bych probral problematiku "az na dren". predem dekuju.