Použití XML v profesionálních publikačních aplikacích. Bakalářská práce

Transkript

1 Použití XML v profesionálních publikačních aplikacích Bakalářská práce

2 Použití XML v profesionálních publikačních aplikacích Vypracoval: Adam Perutka Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačního a znalostního inženýrství Vedoucí práce: Ing. Jiří Kosek Praha, Srpen 2006

3 Prohlášení Prohlašuji, že jsem bakalářskou práci vypracoval samostatně a použil pouze literaturu uvedenou v přiloženém seznamu. Nemám námitek proti půjčení práce se souhlasem katedry ani proti zveřejnění práce nebo její části. V Praze dne 23. srpna 2006 Adam Perutka Anotace Bakalářská práce se zabývá možnostmi využití značkovacího jazyka XML v současné DTP praxi. Přestože má XML potenciál přinést značné zjednodušení a úsporu času, jsou v praxi tyto možnosti využívány pouze okrajově. V úvodu se práce pokouší identifikovat příčiny tak malé penetrace této užitečné technologie do oblasti předtiskové přípravy dokumentů. Další důležitou součástí je srovnání možností automatické a manuální sazby tištěných dokumentů. Po přehledu možností spolupráce současných aplikací s XML následuje nejdůležitější část celé práce: praktický návod použití XML v nejrozšířenějším programu pro sazbu tištěných knih a dokumentů Adobe InDesignu CS2. Završením celé práce je podrobný popis postupu, kterým byl v tomto programu k tisku připraven samotný tento text, původně psaný dle formátu DocBook XML. Věnování Text bych chtěl věnovat všem pracovníkům grafických studií, kteří ani přes používání moderních technologií, nezapomínají na staleté dědictví svého řemesla. Nechť se jejich klienti naučí elementárním základům zpracování textu v počítači, aby se činnost grafiků mohla sestávalt z jiných činností, než neustálého mačkání klávesové zkratek jako Alt+Tab. Speciální obdiv bych chtěl tímto vyjádřit vedoucímu bakalářské práce, p. Koskovi, za jeho nesmírný přínos světové XML a DB komunitě. Po celou dobu práce nad textem jsem nevycházel z údivu, kde všude člověk narazí na podnětné příspěvky tohoto autora. Annotation In the thesis I attempt to explore the potential of XML format in present DTP environment. Though XML s possible efficiencies and time savings are generally known they are seldom used. At the beginning of the text I identify the reasons of such a tiny penetration of this useful technology onto the pre-press planet. Next significant part is comparison of manual and automated layout of printed documents. Overview of XML integration in current DTP applications is followed by the most important section: Step-by-step tutorial of XML features of the most popular publishing application today Adobe InDesign CS2. Climax of the work is represented by a how-to description of printing this text itself, which has originally been written in DocBook XML data format.

4 Obsah Úvod Komu je text určen, cíl práce Co je to XML a DocBook (v kontextu DTP) Výhody nasazení XML v DTP Automatizovaná sazba (stručný přehled)...22 Sazba pomocí XSLT a XSL-FO DTP produkty na trhu a XML...32 QuarkXPress...34 Adobe FrameMaker Adobe InDesign XML obsah v Adobe InDesign 4.0 CS Export XML...43 Sazba DocBooku...61 Závěr...70 Literatura...72 Terminologický slovník...74

5 Úvod potřeba uchovávat veškeré texty v univerzálním nadčasovém formátu a touha připravit je k tisku ve WYSIWYG softwaru s maximálními možnostmi nastavení vzhledu stránky a písma.. As for the future of publishing, XML is really important. I can t tell you how or why, but i know it s the future. Co se týče budoucnosti publikování, XML je opravdu důležité. Nemohu říci jak nebo proč, zkrátka jen vím, že to je budoucnost. Pam Pfiffner, Editor Tato práce pojednává o dvou odlišných světech. O oborech, které jsou si v jistém smyslu blízké a zároveň velmi vzdálené. Jejich společným průsečíkem je práce s textem. Každý z těchto dvou oborů ovšem k písmenkům přistupuje zcela rozdílným způsobem a za jiným účelem. Dopustíme-li se značného zjednodušení, dalo by se říci, že jeden patří umělcům a druhý programátorům. V prvním případě je cílem estetické a srozumitelné rozmístění liter v rámci stránky. Tato disciplína se nazývá sazba, moderněji také DTP. V podstatě jde pouze o shodu okolností, že dnes probíhá naprostá většina této práce za pomoci počítače. I přes použití moderních prostředků se výsledek nijak zásadně neliší od výstupů, které tato disciplína produkovala před desítkami, či dokonce stovkami let. Druhý z oborů je naopak ryze technický. Jedná se o komplexní technologii, jež může být použita mimo jiné ke zefektivnění práce s textovými informacemi při použití výpočetní techniky. Touto technologií je značkovací jazyk XML. Pro účely této práce mě budou zvláště zajímat formáty na XML založené, zaměřující se na uchovaní a zpracování textu především DocBook. Věřím, že nyní je téma jasné. Tato práce se pokusí vyrovnat s tímto rozporem mezi dvěma rozdílnými disciplínami a bude se snažit prozkoumat možnosti použití technologie XML v profesionální předtiskové přípravě dokumentů. Ke zkoumání této problematiky mě vyprovokovaly dva požadavky, které se v současnosti bez těchto znalostí v podstatě vylučují: Důležitou skutečností, ovlivňující téma této práce je především fakt, že DTP je velmi precizní a konzervativní obor. Lidé pracující v této oblasti grafici jsou pod permanentním tlakem klientů. Ti potřebují zakázky kvalitně, přesně a včas. Zpoždění mívá pro osobu grafika drastické důsledky, proto mu nezbývá než takříkajíc jet na jistotu. DTP není technická disciplína. Grafik by měl být především umělec, ne počítačový odborník. Umělec, který dokáže rozlišit jemné detaily obrazu i nuance písma a pracovat s nimi. To jsou zřejmě hlavní příčiny toho, proč se v této branži do experimentování s technologií nikdo příliš nepouští. Grafici používají sice nejnovější hardware s gigabyty operační paměti a s obrazovkami měřícími přes dvacet palců, stále však mnoho z nich jako hlavní pracovní nástroj provozuje programy staré deset i více let. Zavedení novinky trvá v takovém prostředí neúměrně dlouhou dobu. Neochotu ke změnám pracovních postupů lze uvést na konkrétním příkladě: Naprostá většina profesionálů připravujících formát PDF pro tisk, byť za použití nejmodernějšího software, používá místo přímého exportu z programu zažitý, ale zdlouhavější postup. Software, o kterém nyní hovořím, přitom vyvinula stejná společnost, která stojí za standardem PDF. Je vyzkoušeno, že nejnovější verze programů PDF formát bezproblémově podporují. Přesto PDF dnes v praxi vzniká typicky tak, že se ze sázecího programu generuje nejprve PostScriptový (PS) soubor. Teprve ten je dále za použití specializovaného software převeden do PDF. Vše trvá o několik clicků myší, ale především o značné množství minut déle. Zkuste se někoho zeptat, proč to tedy dělá takto zbytečně složitě. Pravděpodobná odpověď, kterou uslyšíte, bude ve smyslu, že dotyčný si je sice vědom, že přímý export by asi fungoval, ale stávající postup je jistější a je na něj zkrátka zvyklý. V minulosti, v některé z dřívějších verzí programu, mohl totiž skutečně nastat v případě přímého exportu problém s výsledným PDF a jeho kompatibilitou. Na to se bohužel často příjde až v tiskárně. Hrozba toho, že zrovna jeho tiskárna si s tím PDF neporadí správně, bývá dostatečná k ospravedlnění oněch minut navíc při tvorbě tiskového souboru přes PS. Co když tiskárna vytiskne místo žščř samé otazníky a zakázku v hodnotě sta tisíce korun odmítne klient uhradit? To se v minulosti opravdu stávalo, ovšem zdůrazňuji, že se jednalo o staré verze programů. Nic naplat, že to je historie stará několik let. Nepomůže ani, že současné verze s tím problém nemají. Lidé z praxe si na stávající postup natolik navykli, že bude trvat možná dalších několik let, než se praxe vytváření tiskových PDF postupně změní.

6 Máte-li trochu lepší představu o okolnostech, které brání rozšíření XML na jednadvaceti palcové monitory, je možná snáze pochopitelný důvod vzniku tohoto textu v roce 2006, kdy XML již dávno není novinkou a je široce uplatňováno ve všech možných oblastech computingu. Paradoxem je, že i samotní grafici si jistě uvědomují široký potenciál tohoto jazyka v pre-pressu. Dokládá to dlouholetá podpora tohoto jazyka v DTP nástrojích a značné množství článků v odborných médiích se zkratkou XML v titulku. Např. FrameMaker se zaměřuje na práci s SGML již od dob, kdy XML ještě ani neexistovalo. Skutečnost je ovšem stále taková, že málokdo jej v praxi používá. Po přečtení zmiňovaných článků zjistíte, že mají něco společného: přílišný optimismus a hlavně obecnost a nekonkrétnost. Téměř v každém odborném článku se můžete dočíst o tom, jak skvělou budoucnost XML v počítačově sazbě má. Najít ale konkrétní zkušenosti či návod je velmi vzácné. O XML v pre-pressu se toho již zkrátka spoustu namluvilo, když však přijde na věc, uchýlí se většina grafiků ke staré dobré manuální práci. Ta zahrnuje spoustu označování, kopírování, přesunování a hodiny na telefonu s klientem. Samo o sobě by to ještě nemusel být takový problém, kdyby ssebou manuální postupy nenesly zvýšené riziko vzniku chyb. XML je sice technologie v zásadě jednoduchá, ovšem rozhodně ne příliš uživatelsky přívětivá. Ve spojení s jistou mírou pohodlnosti typického grafika to má často za následek vyhnutí se XML i při přípravě publikace, pro kterou by bylo použití XML šité jako na míru. Typickým příkladem těchto publikací jsou různé ročenky, seznamy členů, číselníky atp Jde o data, s opakující se strukturou, tisková úprava se na jednotlivých položkách také neliší, takže layout zůstává stále stejný. V tomto případě je navíc použití XML v libovolném SW jednoduchou záležitostí. Tato data má většinou zadavatel zakázky v nějaké relační databázi. Stačilo by je vyexportovat z databáze do XML. Mám bohužel rozsáhlé zkušenosti, že v praxi tato činnost probíhá tak, že z databáze jsou data exportována v lepším případě do PlainTextu (v tom horším do Wordu ). Poté nemůže následovat nic jiného, než otrocká práce zahrnující spoustu označování textu a přiřazování správného vizuálního znakového či odstavcového stylu. Po konzultaci s lidmi přímo z oboru je ale třeba si uvědomit, že prosba o získání podkladů v XML od zákazníka by v 99.9 procentech případů byla zcela zbytečná snaha. Klienti grafických agentur se prozatím nenaučili nepoužívat několikanásobné mezery a entery k formátování textu, nemluvě o používání odstavcových stylů ve Wordu. Ze strany klientů pravděpodobně nebude existovat po sazbě z XML naprosto žádná poptávka ještě několik let. Použití XML mezi profesionálními grafiky (celkem 26 odpovědí) Graf zobrazuje odpovědi na otázku, kterou jsem položil účastníkům špičkové odborné diskuse na Českém internetu lidem z praxe. Poznámka: Tímto zvýrazněním, je odlišen text, který považuji za doplňkový a lze ho číst méně pozorně nebo i zcela přeskočit

7 1. Komu je text určen, cíl práce Nemyslím, že problém je v tom, že by tu XML nikoho nezajímalo (mě třeba ano, pište dál), jen je pro většinu kreativců zatím zbytečně obtížné jej začít používat XML má co nabídnout, ale řekněme, že toho XML pro většinu lidí prozatím na oplátku trochu moc požaduje, takže většinový přístup lze nejspíš hodnotit za vlažný. Petr Lozan v internetové diskusi o XML na serveru Budu se snažit, aby práce nebyla pouze dalším obecným chvalozpěvem o tom, jak skvělé by bylo použití XML tam a tam. Naopak se ji snažím zaměřit prakticky. Završením je zcela konkrétní návod na sazbu XML dokumentu v nejpopulárnějším lámací aplikaci Adobe InDesign CS2. Mým cílem je, v tomto SW nástroji zpracovat výslednou vizuální podobu dokumentu dodaného ve standardu Simplified DocBook XML. Důkazem, že tento postup funguje je sazba samotné této práce v InDesignu (text je původně psán ve formátu Simplified DocBook XML V1.1.) Nevynechám ani otázku exportu XML a sazby jednoduchých opakujících se strukturovaných dat, přestože jde o úkol v dnešních aplikacích téměř triviální. Cílem je demonstrovat jednoduchost a použitelnost takového řešení, což doufám pomůže rozšířit tyto postupy mezi širší okruh odborné veřejnosti. Někteří grafici se možná po přečtení této části zastydí, že tuto možnost nevyužívají již dávno Tato práce je zaměřena na dvě skupiny čtenářů: Využití textu je primárně určeno profesionálním grafikům, kterým by měla ukázat proč a v jakých případech pro ně může být zařazení XML do jejich produkčního workflow výhodné. U této skupiny předpokládám znalost některého publikačního nástroje. Jak již bylo řečeno, grafik je především umělec, ne informatik. Nedá se tedy v tomto oboru předpokládat široká znalost technologie XML. I když se v úvodní kapitole pokusím velmi stručně nastínit úvod do této problematiky, doporučuji její hlubší nastudování v některé z publikací, které se tématu přímo věnují (např. xmlprokazdeho). Dále zde mohou nalézt informace lidé, již publikující z XML za využití s ním spojených technologií. U nich naopak předpokládám znalost tohoto značkovacího jazyka, přidružených technologií a především automatizovaného procesu tvorby tiskového formátu (PDF) z XML. Rád bych demonstroval, že k převodu XML do tiskové podoby není nutné využít pouze konvenční automatizované nástroje. XML-odborníky bych chtěl stručně seznámit se současnými profesionálními publikačními DTP nástroji a ukázat, jakou výhodu představuje použití profesionálního WYSIWYG nástroje oproti automatizovanému převodu do tiskové podoby. Patříte-li do této kategorie, budou pro vás některé části práce zcela známé a nepotřebné. Směle můžete přeskočit především následující tři kapitoly

8 2. Co je to XML a DocBook (v kontextu DTP) No, jestli tomu dobře rozumím, tak výhoda XML je, že namísto stylování dokumentu nakonec (tak jak se to dělá teď a dělá to profi DTPák), se to samé má dělat předem (dělá to amatér = sekretářka, obchoďák apod.). Takzvaná výhoda je pak v tom, že se to automaticky převede se spoustou chyb. Ty pak ten DTP operátor bude muset vychytávat a opravovat navíc, současně s chybami, které udělala sekretářka při psaní textu. Martin Vlach v odborné internetové diskusi na téma použití XML (mírně upraveno) XML je tzv. značkovací jazyk, který pomocí tagů umožňuje popsat strukturu a atributy obsahu nezávisle na jeho vzhledu. Na první pohled je podobný známějšímu jazyku HTML, který je v podstatě jeho podmnožinou. Mimo textových informací lze přitom označkovat libovolný jiný obsah grafiku, dokumenty sázecích aplikací, dokumenty v PDF a mnoho dalšího. Na rozdíl od HTML mohou být tagy libovolné a aby se zabránilo přílišné volnosti, je zapotřebí vymezit množinu možných tagů a vzájemná pravidla jejich posloupnosti. To zaručí jednotnost a konzistenci dokumentu bez ohledu na to, kde a kým je editován. Vrátíme-li se k HTML mohli bychom například definovat, že za tagem H1 (nadpis) následuje vždy odstavec textu a že tag výčtu UL nesmí obsahovat tag H1. Tyto definice se zapisují pomocí speciálního jazyka, například DTD (definice typu dokumentu), XMLSchema, Relax NG nebo DSD (deskripce struktury dokumentu). Příklad jednoduchého DTD <!ELEMENT vzkaz (komu,od,nadpis,zprava)> <!ELEMENT komu (#PCDATA)> <!ELEMENT od (#PCDATA)> <!ELEMENT predmet (#PCDATA)> <!ELEMENT zprava (#PCDATA)> V tomto jednoduchém DTD je definováno pět elementů. Element vzkaz by měl pod sebou obsahovat všechny ostatní, které už dále neobsahují nic než text. Příklad jednoduchého XML <?XML version= 1.0 encoding= UTF-8?> <!DOCTYPE vzkaz SYSTEM vzkaz.dtd > <vzkaz> <komu>adam</komu> <od>jirka</od> <predmet>nezapomeň</predmet> <zprava>chci připomenout, abys nezapoměl přiložit i zdrojový kód.</zprava> </vzkaz> Tento jednoduchý XML dokument splňuje požadavky výše uvedeného DTD (říkáme, že je validní). Všimněte si, že všechny tagy nesou sémantickou, nikoli formátovací (meta-)informaci. Na zpracovávající aplikaci pak je, jak s takto vyznačeným obsahem naloží. V případě publikování se počítá zejména s nasazením při automatickém zpracování: uživatel vytvoří taggovaný obsah a zpracovávající aplikace pak na základě požadavků a tagů vygeneruje jednu nebo více podob daného obsahu. Tento způsob nasazení by měl značně šetřit čas a lidskou práci, a to zejména tam, kde je výstup z téhož zdroje realizován souběžně na různých médiích (cross-media publishing), tedy v současnosti typicky v tištěné a internetové podobě. Taggovaný obsah lze ale také extrahovat pro nejrůznější další použití ve workflow (po přečtení této práce byste měli dokázat takový text převést do sázecího programu a dále tam s ním běžným způsobem pracovat) (zdroj: gr-xmlaid). Pokud jste předchozí odstavec četli se zaujetím, většina informací v něm pro vás byla zcela nová a pokud to myslíte s využitím XML ve vaší (grafické) praxi vážně, je nutné, abyste se nejprve s formátem XML seznámili trochu podrobněji. To není smyslem tohoto textu. Než budete číst dál, je nutné nastudovat nějakou publikaci, která se XML přímo věnuje. Pro úplný úvod doporučuji začít krátkým seriálem na internetovém magazínu Grafika On-line uvodxml1, uvodxml2 a uvodxml3, případně povedenou, středně pokročilou knihou xmlprokazdeho. Použití XML v sazbě je zřejmě nejvýhodnější v případě strukturovaných, opakujících se dat. Představme si, že úkolem je vysázet brožurku se seznamem členů nějakého sdružení. Informace o každém členu mají být vytisknuty na samostatnou stránku a mají stále stejnou strukturu: Název, sídlo, kontaktní osoba, předmět činnosti atd Jak probíhá sazba takové brožurky dnes? 14 15

9 Klient má často požadovaná data uloženy v Accesu nebo jiné databázi. Export proběhne většinou do plaintextu a v této formě je dostane grafik. Do připravené šablony stránky pak pomocí copy&paste ručně kopíruje údaje o členech a dává jim požadované formátování. Časová a pracovní náročnost je značná, riziko vzniku chyby obrovské. Nutnost následných kontrol tak jen dále zpomaluje proces přípravy tiskoviny. Existují samozřejmě další možnosti. Oblíbený export přes MS Word s sebou nese spíš více komplikací než zjednodušení jak na straně exportu dat z databáze, tak jejich importu do DTP. A práce přes jednoduchý formát CSV zase komplikuje proces na importu do grafické aplikace. Angažujeme-li při řešení tohoto úkolu XML (a půjde-li vše dobře), scénář se zjednoduší. Výsledkem exportu z databáze by měl být XML soubor označující sémantiku jednotlivých údajů. V tomto souboru je tedy pomocí tagů řečeno toto je autor, toto popis činnosti a následuje poznámka. Tvorba takto jednoduchého XML z relační databáze by pro pokročilého uživatele neměla být zásadní problém. Na vstupu do DTP programu se situace dramaticky urychlí: Jednotlivým tagům se pouze přiřadí formátovací styl a určí se místo na stránce, kam mají být vloženy. Po tomto prvotním úkonu proběhne dále automaticky natažení textu na správné pozice v požadovaném formátu a na grafikovi dále zůstává jemné doladění vzhledu stránek. Což je přesně tím, co by mělo být hlavní náplní jeho práce. Práce se může stát ještě efektivnější, pokud využijeme XML i při uchovávání a tvorbě dat. Jako pracovník grafického studia se s největší pravděpodobností můžete setkat s textovým dokumentem uloženým v XML. Příkladem k tomu určené podmnožiny XML jsou například DITA, zaměřená na zpracování technických informací, nebo obecnější DocBook (dále v textu DB). Po XHTML je to dnes asi druhá nejpoužívanější aplikace XML. Nejedná se o nic jiného, než o definovanou množinu tagů, určenou pro uchování textů, jako jsou články či knihy. Velmi zjednodušeně by se dalo říci, že XML jsou obecná pravidla, jak psát značkovací jazyky a DocBook je jedním z těchto jazyků. DB byl původně určen pro psaní uživatelských příruček a technické dokumentace, ale je univerzální a hodí se stejně dobře i pro ostatní druhy textu. Výhoda použití formátu DocBook oproti použití vlastní množiny XML tagů je především v jeho rozšířenosti a standardizaci. Vzniklo pro něj řada konfigurovatelných šablon a nástrojů, které díky tomu není potřeba složitě vytvářet. Rozdíl mezi textem v DocBooku a taggovaným textem či Wordem je, že DocBook s sebou nese informaci o sémantice. Teprve na základě toho je až v další fázi zpracování dokumentu vytvořená vizualizace jednotlivých elementů. Vše probíhá většinou automaticky, ale v našem případě se tento proces pokusíme zmanualizovat v prostředí sázecí aplikace. Navíc je díky obsaženým sémantickým informacím možné mnohem účelnější a logičtější jakékoli další zpracování textu. Pro zájemce o bližší nastudování tohoto formátu odkazuji na stručnou DBUvod a podrobnou dokumentaci tdg. Příklad jednoduchého dokumentu ve formátu DocBook <!DOCTYPE chapter PUBLIC -//OASIS//DTD Docbook XML V4.1.2//EN > <chapter><title>test Chapter</title> <para> This is a paragraph in the test chapter. It is unremarkable in every regard. This is a paragraph in the test chapter. It is unremarkable in every regard. This is a paragraph in the test chapter. It is unremarkable in every regard. </para> <para> <emphasis role= bold >This</emphasis> paragraph contains <emphasis>some <emphasis>emphasized</emphasis> text</emphasis> and a <superscript>super</superscript>script and a <subscript>sub</subscript>script. </para> <para> This is a paragraph in the test chapter. It is unremarkable in every regard. This is a paragraph in the test chapter. It is unremarkable in every regard. This is a paragraph in the test chapter. It is unremarkable in every regard. </para> </chapter> Toto je příklad velmi jednoduchého dokumentu zapsaného v DocBooku převzatý z tdg (příklad 4.6). Opět si prosím všimněte, že text neobsahuje žádné formátovací informace, ale pouze informace o významu jednotlivých částí textu ( toto je odstavec, toto je důležitý text atd ) Jeho grafická prezentace je pak ponechána zcela na zpracovávající aplikaci. Příklad, jak může výsledné formátování vypadat, naleznete v tdg (např. na přímé adrese:

10 3. Výhody nasazení XML v DTP you might worry about what seems to be an inherent contradiction between the highly designed page and well structured XML content. Would you be more successful locking a designer and an engineer in a room and asking them to build something with blocks? Starost vám může dělat zdánlivě inherentní rozpor mezi vizuálně bohatou stránkou a dobře strukturovaným XML obsahem. Je to podobné, jako požádat grafika a inženýra společně postavit něco ze stavebnice. Michael Edson, practice director. Really Strategies [edson] Již od vynálezu knihtisku se tiskaři snaží nalézt efektivnější způsoby jak uspořádat text a grafiku na stránce. Od té doby prodělala sazba během své dlouhé historie nesmírné změny, ale od uvedení DTP v roce 1985 se situace ustálila. Během posledních 20 let jsme byli svědky pouze kosmetických změn. Stránky jsou stále manuálně skládány a není podstatné, že tato činnost je prováděna za pomoci stále lepších softwarových nástrojů. Velké naděje jsou již desetiletí vkládány do automatizace tvorby vzhledu stránky. Přestože již dlouhou dobu existují různé systémy, které tento úkol umožňují, nesou sebou tu nevýhodu, že starost o vzhled stránky přesunují od grafiků a sazečů k softwarovým vývojářům. Kreativní proces je potlačen a takové systémy jsou tedy omezeny jen na určitý okruh publikací ideální je použití na technické dokumenty. Právě do XML jsou vkládány naděje, že umožní díky své jednoduchosti a otevřenosti provést určitou automatizaci, ale tuto starost ponechat na pracovníkovi grafického studia místo programátora. Obecně největší výhoda použití XML při správě dokumentů jsou právě rozmanité možnosti jejich automatického zpracování. Hlavním důvodem, díky kterému se i v oblasti profesionálního publikování šíří podpora XML významným způsobem, je proklamovaná efektivita, kterou by mělo nasazení uvedeného standardu přinést do publikačního workflow. Ke specializovaným řešením, spadajícím obvykle do třídy enterprise, přitom přibývá nástrojů, umožňujících řešit zpracování XML obsahu i v běžných DTP aplikacích (Adobe InDesign či FrameMaker, QuarkXPress viz dále) či kancelářských programech (Microsoft Office, OpenOffice). I při nalití zdroje textu v XML do pre-press aplikace a následném manuálním zpracování, se dá ušetřit spousta práce. Základní výhoda spočívá v automatizaci řady kroků při sazbě XML dokumentů, postavené na šablonách. Zároveň si ovšem necháme prostor pro manuální doladění vzhledu. Jedná o silný nástroj zejména pro vydavatelství periodik, katalogů a obecně všech publikací s určitou strukturou. Dále lze uvedeným způsobem tentýž obsah publikovat v různých formách: jedna šablona může nabízet výstup ve vysokém rozlišení pro tisk, další třeba zcela vypustí obrázky XML se dobře hodí pro tisk údajů z relačních databází pro následný přenos dokumentu na kapesní počítač atp. Možnost tvorby různých verzí ale nabízí i další zajímavé aplikace. Za zmínku stojí například proces tvorby a posouzení různých návrhů vzhledu výsledného dokumentu: designer vytvoří různé šablony a pak porovná jejich vzhled po načtení daného XML dokumentu. Přestože by byl takovýto postup realizovatelný i klasickými prostředky, obvykle by se jednalo o pracnější řešení (gr-xmlaid). Podobné je to s DocBookem. Hlavním praktickým důvodem pro jeho použití, než běžného způsobu uložení textu, je univerzálnost a možnost automatického generování libovolného formátu (včetně budoucích, nyní neznámých formátů). Zcela automaticky tak lze dnes z jedné předlohy najednou vytvořit plnohodnotnou HTML stránku pro nahrání na web, RTF soubor pro sekretářku a PDF pro tisk. Na rozdíl od pouhého XML není třeba vytvářet žádné šablony, což je činnost, která je pro většinu uživatelů nepříjemná tím, že se blíží programování. Z tohoto hlediska je DB ideálním formátem k dlouhodobé archivaci. Z uvedeného ale vyplývá, že DB představuje významné výhody spíše pro autora textu, než pro grafické studio, jakožto jeho vizuálního zpracovatele. Pokud tedy mluvíme o případu, kdy studio dostane za úkol pouze jednoúčelové zpracování, což je stále nejčastější případ

11 DB samozřejmě přejímá všechny obecné výhody XML. Těch je nespočet a z těch, které mohou být zajímavé pro tvůrce papírové podoby informace stojí za zmínku třeba ještě pokročilá správa verzí nebo jednoduché a účelné připojení metadat. Mohlo by se zdát, že import DocBookového (či XML) dokumentu do aplikace za účelem jejího ručního formátování je nesmysl. Je to totiž většinou právě snaha o odstranění takovýchto manuálních činností, která vede k nasazení XML do publikačního workflow. Takže znovuzařazení WYSIWYG nevyhnutelně otevírá jednou již vyřešené problémy. Ve většině případů bych skutečně doporučil sáhnout po některé z konvenčních (=automatických) metod přípravy XML dokumentu k tisku. Přestože jsou však takto dosažené výstupy dostatečně kvalitní pro běžné použití, pro přípravu profesionální tiskoviny je bohužel WYSIWYG metoda nenahraditelná. Z mého pohledu tedy nastane snoubení těchto dvou jinak vzdálených technologií v následujících případech: Osoba/organizace zvyklá na práci s grafickou aplikací, ale XML a příbuzné technologie zvládá pouze okrajově. Přesto z nějakého důvodu chce (nebo je donucena) XML využívat. To je typický příklad, grafického studia, které jednoduchým krokem nasazení XML pouze zefektivní stávající postup práce. Dalším příkladem je situace, kdy tvůrce obsahu tvoří XML, které dále poskytne grafickému zpracovateli, pracujícímu s konvenčním programovým vybavením. V tomto vztahu je dodavatel obsahu zákazník a grafik se jeho požadavkům musí přizpůsobit převod do čistě textového formátu by byl sice značně neefektivní, nicméně v současné situaci to je pravděpodobný kompromis, který v takovém případě nastane. Uživatel není schopen/ochoten naprogramovat potřebné šablony. S tím souvisí případ, kdy se jedná o jednorázové zpracování určitého typu XML dokumentu, které se již nebude opakovat. V tom případě může být tvorba tiskového formátu rychlejší ve WYSIWYG prostředí. Požadavky na výsledný design tiskoviny jsou natolik vysoké, že jej není možné dosáhnout jinak, než manuální sazbou. Je třeba si uvědomit, že textové a grafické části dokumentu mohou být natolik rozmanité, že je zkrátka není možné zpracovat automaticky. Stačí se podívat do libovolného komerčního časopisu. Toto se týká obzvláště dokumentů v DB, jejichž autoři se i přes požadavky na výsledný vzhled tiskoviny nehodlají vzdát výhod pro uchování textu v tomto formátu. Opakuji, že právě řešení tohoto problému pro mou potřebu mě přimělo k napsání této práce. Srovnání klasického pojetí ve stylu textového editoru a strukturovaného přístupu k témuž dokumentu (ze strfm) 20 21

12 4. Automatizovaná sazba (stručný přehled) Zatímco manuální sazba stránek je běžnou metodou přípravy pro tisk, existuje paralelně s ní oblast velkoobjemové dávkové přípravy dokumentů. Dávková sazba připravuje dokumenty zcela bez zásahu lidské ruky. Používá se především tam, kde je potřeba najednou vyprodukovat stovky či tisíce stránek. Cílem je dosáhnout kompromisu mezi slušně typograficky vypadajícími stránkami při současném snížení nákladů. Úspory může být dosaženo díky ušetřenému času při tvorbě tak velkého množství stránek. Manuální sazba se dá charakterizovat tak, že je zaměřena na vzhled, je interaktivní a WYSIWYG. V podstatě uživatel ručně umisťuje textové a grafické prvky do stránky. Naproti tomu dávkové zpracování vypadá obecně následovně: otaggovaný text (nemusí jít nutně o XML) je prohnán přes šablonu v podobě skriptu či kódu (ve druhém případě ve spojení s nějakým procesním enginem procesorem) a výstupem je dokument, jehož výsledné stránky jsou většinou dále needitovatelné. Použití tohoto postupu zahrnuje nutnost naprogramování skriptu či kódu šablony, což je nesmírně náročná fáze (ve srovnání s manuálním DTP). Bez ohledu na to, zda šablona existuje v podobě skriptu či kódu (např. XSL kódu), je třeba k jejímu vytvoření proces podobající se spíše vývoji software než grafickému designu. katalogy, telefonní seznamy či finanční zprávy. Ani v těchto případech není výhodné ale použít dávkové zpracování vždy. Například dnešní systémy vykážou v naprosté většině negativní přínos (z hlediska nákladů a výnosů), pokud bude šablona použita pouze pro jeden projekt. S výjimkou případů, kdy takový projekt zahrnuje tisíce nebo až statisíce stránek. Přínosným se takový systém stane teprve tehdy, kdy je možné šablonu použít na stovky až tisíce unikátních dokumentů. Skutečnost, že se automatizovaná sazba realizuje přes kódované šablony je její největší výhoda a zároveň nejvíce limitující faktor. Aby obyčejný uživatel dokázal dávkově sázet dokumenty, to vyžaduje čas na zaškolení v řádu týdnů až měsíců. I když člověk ovládne všechny potřebné dovednosti, výstup stále trpí problémy, které zkrátka ve světě DTP neexistují: nemožnost znovupoužití a editace výsledku, používání nestandardních nástrojů, totální změna publikačního workflow oproti klasickému postupu Další problém nastane, pokud výstup nějakým způsobem vyžaduje lidský zákrok. To dnes probíhá typicky tak, že dokument je prohnán transformačním procesem do výstupního formátu, poté operátor projde výsledek, na jeho základě se upraví šablona a postup se opakuje. To je ale komplexní a časově náročná činnost. V naprosté většině publikačních workflow by bylo výhodnější vzít výsledek první transformace a ten pak drobně manuálně upravit. Ideální by bylo mít tuto možnost úpravy v jedné z běžných DTP aplikací na trhu. Automatizovaná sazba vzniká programátorskými postupy, postrádá interaktivitu a výstup nemůže být typicky dále editován. Instrukce, jak má vypadat výstup jsou obsaženy většinou v externí šabloně, nebo mohou být i v samotném zdrojovém dokumentu. Šablony se tvoří postupem podobným programování a vytvoření šablony k nějakému složitějšímu projektu vyžaduje zkušeného pracovníka a čas minimálně v řádu týdnů. Samotná podstata šablon neumožňuje jejich flexibilní změny. Stejně, jako je těžké přizpůsobit softwarový nástroj novým požadavkům, je těžké vzít existující šablonu a nějak zásadně změnit její design. Tento nedostatek flexibility je ještě zřetelnější, pokud jej srovnáme s jednoduchostí, jakou je možné reorganizovat a přizpůsobit vzhled dokumentů produkovaných DTP. V dávkovém systému nemůže existovat přizpůsobení vzhledu na poslední chvíli před odesláním do tiskárny. Tato omezení limitují oblasti použití, pro které je automatizovaná sazba vhodná. To jsou důvody, proč si automatizovaná sazba dosud nenašla cestu do specifických (ve smyslu požadavku na vzhled) a flexibilních (ve smyslu častých změn) provozů jako sazba knih, či do publikačních oddělení velkých společností. Zůstává spíše doménou velkoobjemových projektů s předvídatelnou strukturou, jako například technická dokumentace, 22 23

13 Jednoduchost Kvalita výstupu Flexibilita Uživatelská základna Manuální Srovnání manuální a dávkové sazby Jednoduchá vyžaduje znalost některého publikačního nástroje, např. InDesign Vysoká vhodné pro vizuálně zaměřené dokumenty Vysoká sazeč může přímo měnit design stránek Široká miliony uživatelů DTP nástrojů Dávková Obtížná vyžaduje znalost jazyka pro napsání šablony Střední i přes poměrně rozsáhlé možnosti zaostává v grafických a typografických nuancích Nízká možnost změny pouze přes šablonu Malá omezeno na specializovaná prostředí a znalostními nároky Ideální systém by měl kombinovat ty nejlepší vlastnosti z manuální i automatické sazby. Měl by používat standardní designové nástroje, zachovat plnou podporu XML pro cross-media publishing, měl by být jednoduchý pro použití a poskytnout editovatelný výstup s možností roundtrippingu Tyto požadavky částečně splňuje postup importu strukturovaného XML dokumentu do DTP aplikace, tedy hlavní téma této práce. V automatizované sazbě neexistuje jediné řešení, které by se dalo považovat za všeobecný standard. Mnoho produktů působí ve své malé oblasti profesionálního publikování, zatímco ostatní našli své místo v akademické sféře. Např. TeX je přes svou zjevnou zastaralost nedostižný v oblasti vědecké sazby a de facto standardem. Pro seznámení s možnostmi dávkové sazby stručně zmíním běžně používaný postup převedení DB dokumentů do tiskové podoby pomocí XSL transformací. Protože se jedná o automatickou sazbu, trpí tento postup většinou neduhů, jak byly popsány výše. Nevyžaduje však od uživatele rozsáhlé znalosti a programovací dovednosti (narozdíl např. od zmiňovaného TeXu). Integrace s XML Editovatelné stránky Roundtripping Rychlost Střední i tímto dokumentem se pokusím tento stav zlepšit Vždy ve kterékoli fázi je možno pohybovat s jakýmkoli objektem stránky Obtížný obsah musí být manuálně otaggován aby mohl být vyexportován v XML. V případě exportu v nestrukturované formě je jeho další použití téměř vyloučeno Pomalá v řádu jednotek stránek za hodinu u jednoduchých dokumentů. U složitých mnohem méně Kompletní vyžaduje znalost XML u tvůrců systému i u sazeče Vzácné Podle mých informací umožňuje editaci pouze produkt Arbortext 3B2. Tato je velmi omezená ve srovnání s DTP aplikacemi. Neobvyklý Pokud by bylo možné editovat výsledné stránky, změny by pravděpodobně zůstaly uvězněny ve výstupním dokumentu Rychlá tisíce stránek za hodinu 24 25

14 Sazba pomocí XSLT a XSL-FO Převod XML dokumentů do tiskového formátu pomocí technologie XSL je konvenčním způsobem publikování XML dokumentů. XSL je stylový jazyk, pomocí něhož jsme schopni popsat konverzi sémantického XML dokumentu do rozličných podob. Jak je vidět z obrázku, možnosti jsou velmi široké. Všimněte si ale, že toto klasické schéma nikde nepočítá s jakýmkoli kreativním procesem veškeré vizuální vlastnosti jsou definovány kódem. Obecné schéma transformace [pavlovic] Ukázka jednoduchého A4 dokumentu popsaného pomocí FO převzatá z xml.com <?xml version= 1.0 encoding= UTF-8?> <root xmlns= font-size= 16pt > <layout-master-set> <simple-page-master margin-right= 15mm margin-left= 15mm margin-bottom= 15mm margin-top= 15mm page-width= 210mm page-height= 297mm master-name= bookpage > <region-body region-name= bookpage-body margin-bottom= 5mm margin-top= 5mm /> </simple-page-master> </layout-master-set> <page-sequence master-reference= bookpage > <title>hello world example</title> <flow flow-name= bookpage-body > <block>hello XSLFO!</block> </flow> </page-sequence> </root> XSLT umožňuje popsat transformaci dokumentu do XML s jinou strukturou (např. do HTML) nebo třeba do čistého textu. Díky XSLT je možné provést automatické generování rejstříků, obsahů atp. K provedení transformace je kromě zdrojového XML dokumentu potřeba XSLT šablona, ve které je definován převod jednotlivých částí XML dokumentu, a XSLT procesor program, který provede samotnou transformaci. XSLT transformaci již dnes ale zvládá i běžný software, např. nové verze internetových prohlížečů. XSL v sobě obsahuje dvě samostatné části: transformační jazyk XSLT a tzv. formátovací objekty XSL-FO. XSL-FO je sada výrazů, které velmi dobře umožňují popsat vizuální vzhled tištěného dokumentu. Pomocí jejich kódu lze popsat stejné vlastnosti, jaké grafik definuje při práci s DTP programem. Počínaje definicí vzhledu stránky, tiskového zrcadla, přes vlastnosti odstavců, tabulek seznamů apod., až po typografické vlastnosti písma. Důležitou skutečností je to, že FO se sami zapisují jako XML dokument. Díky tomu, že XSL-FO není nic jiného než XML dokument, můžeme pro převedení XML do formátovacích objektů použít XSLT. Touto transformací tedy dojde k převedení sémantického dokumentu na XML dokument, ve kterém je podrobně definován vzhled objektů (o pravidla tohoto převodu se samozřejmě postará XSLT šablona). Typický postup transformace dokumentu do tiskové podoby Máme-li určitým kódem kompletně pospsán vzhled dokumentu, stačí předat tento soubor FO procesoru, který se postará o převedení našeho kódu na konečný výsledek typicky PDF nebo PS

15 Praktické ukázky této technologie lze nalézt na mnoha místech. K bližšímu prostudování doporučuji například oddíl hotových bakalářských a diplomových prací v [pavlovic]. Na zmiňované stránce Masarykovy univerzity si kromě zdrojového XML kódu několika absolventských prací můžete prohlédnout výsledek transformací do všech možných formátů. Obsah prací také není nezajimavý. Například v bakalářské práci Jana Pavloviče Tvorba dokumentu v XML se dozvíte spoustu dodatečných informací o XML i XSL. Text je dostupný na Ukázka stránky výsledného PDF souboru Pěknou ukázkou širokých možností formátovacích objektů je demonstrace zveřejněná na stránkách firmy RenderX tvůrce známého procesoru FOP. Vstupem ve zmíněném příkladu je malý XML soubor, popisující známou šachovou partii Garryho Kasparova proti superpočítači Deep Blue. Aplikováním XSL transformace do FO je následně získán PDF dokument s grafickým znázorněním všech tahů. Na stránkách najdete i další zajímavé příklady transformace. Zdrojový XML zápis partie má pouhých 57 řádků <?XML version= 1.0 encoding= ISO ?> <chessgame event= IBM Kasparov vs. Deep Blue Rematch site= New York, NY USA date= round= 1 white= Kasparov, Garry black= Deep Blue opening= Reti King s Indian attack, Keres variation result= 1-0 > <move> <white>n g1-f3</white> <black>p d7-d5</black></move> <move> <white>p g2-g3</white> <black>b c8-g4</black></move> <move> <white>p b2-b3</white> <black>n b8-d7</black></move> <move> <white>b c1-b2</white> <black>p e7-e6</black></move> <!-- vynecháno 39 řádků --> <move> <white>p f5-f6</white> <black>r d5-d1</black></move> <move> <white>p g6-g7</white></move> </chessgame> Aplikování transformace jejíž vstupem je kromě výše uvedeného souboru už jen XSLT šablona poskytne jako výsledek 16-ti stránkový PDF dokument. Jednu stránku z něj si můžete prohlédnout na protější straně.: 28 29

16 Výhodou aplikování tohoto postupu na text napsaný ve formátu DocBook je především to, že není potřeba vytvářet vlastní šablony. V praxi je tento postup často používanou aplikací automatizované sazby. Přestože je toto řešení technicky i finančně nepříliš náročné, je velmi mocné a univerzální. K dispozici je velké množství šablon, které jsou připraveny k okamžitému použití. V případě potřeby přizpůsobení výstupních dokumentů je možné šablony upravit, což je samozřejmě stále mnohem jednodušší než příprava šablon zcela nových. Šablony jsou psány tak, aby jejich přizpůsobení úpravami jejich parametrů bez problému zvládl zkušenější uživatel v řádu minut. Konvenční převod DocBooku do tiskové podoby pomocí XSL má oproti obecnému případu automatizované sazby výhodu především v tom, že poskytuje tak více prostoru k soustředění na samotný obsah dokumentu, místo na technické nástroje. Technická náročnost na obsluhu není velká a problémy, které mohou nastat bývají drobnějšího charakteru. Po úvodní konfiguraci, doladění postupu a použitých programových nástrojů je pak již používání poměrně bezproblémové, pohodlné a jednoduché. Nepřeberné množství šablon samozřejmě existuje i pro výstup do jiné než papírové podoby. Při minimálním úsilí je tedy možné jeden zdroj textu publikovat v mnoha různých formách. Každý má díky tomu na dosah velmi silný publikační nástroj navíc založený zcela na otevřených standardech. XSL šablony pro DB volně ke stažení je možné získat například na XSL-FO je bezpochyby velmi mocný a užitečný nástroj, přesto se domnívám, že existují důvody pro hledání alternativních možností publikování XML dokumentů. FO se hodí spíše pro dokumenty technického charakteru s jednodušším rozvržením a omezeným počtem fontů, barev a externích prvků. Je v podstatě nemožné vymanit se z nutnosti formátovat vše do obdélníkových bloků. Dalším problémem je nemožnosti úpravy výsledného vzhledu stránek jinak, než psaním kódu změnou šablony či formátovacích objektů. To značně snižuje jejich efektivitu a zcela znemožňuje provedení těchto úprav typickým pracovníkem grafického studia

17 5. DTP produkty na trhu a XML There is no question that efficient publishing of content to multiple media is a key goal for every company involved in content creation, from magazine and book publishers through to financial institutions and government departments. It is fundamental to increasing revenue through content sharing, syndication and subscriptions. There is also no question that XML is the format of choice for achieving this goal. However one aspect of implementing an XML workflow that has and continues to cause problems that stifle creativity and efficiency in this area, is how to integrate print publishing, primarily with QuarkXPress, into such an XML workflow. Nikdo nepochybuje o tom, že efektivní publikování jednoho zdroje na různá média je hlavním cílem každé firmy, zabývající se tvorbou obsahu od vydavatelů knih a časopisů přes finanční instituce po vládní úřady. Zásadní je zvýšení výnosů pomocí sdílení obsahu a publikací do několika médií. Jistě se také shodneme na tom, že pro dosažení tohoto cíle je jasnou volbou formát XML. Přesto existuje jeden aspekt, který způsobuje problémy tlumící kreativitu a efektivitu této oblasti. Je jím integrace tištěného publikování do takovýchto workflow. Gavin Drake, Easypress Technologies marketing director Qarku. Oba programy nicméně prožívají rychlý vývoj a jejich souboj je dost vyrovnaný. Těmto nejvýznamnějším programům věnuji celou kapitolu. Dále bych se podrobněji podíval na třetí program: Adobe FrameMaker. Jeho vývoj byl již sice v podstatě ukončen a nejedná se o konkurenci dvou dříve jmenovaných z hlediska rozšíření. Přesto existují důvody, proč mu věnovat trochu více prostoru: stále je v praxi používán a především již od samého počátku se zaměřuje na práci se strukturovanými dokumenty. Ostatní aplikace na trhu zmíním pouze jednou větou: Adobe PageMaker býval kdysi nesmírně populárním programem. Postupně došlo k jeho nahrazení InDesignem. Byl velmi jednoduchý na ovládání. Používal se často ve firmách pro tvorbu jednodužší firemní grafiky. Zanikl v době, kdy se teprve začalo vyvíjet XML a v současnosti je používán zcela okrajově. Funkce na spolupráci s XML do něj, vzhledem k cílové uživatelské skupině, nebyly implementovány. Corel Ventura je následovníkem programu Ventura Publisher. Také býval velmi populárním programem (tehdy ještě patřil Xeroxu). Jeho vývoj byl taktéž ukončen, nebudu se jím tedy více zabývat. Z vlastní zkušenosti musím říct, že to je veliká škoda, verze 10 měla velmi intuitivní ovládání a dnes je myslím ještě stále dobře použitelná. Jakési náznaky použití XML v tomto programu sice existují, mé experimentování s nimi ovšem ukázalo, že se pro reálné použití nehodí. MLayout je program existující pouze na platformě OS X. Jeho uživatelské rozhraní je velmi podobné QuarkXPressu, jen je o trochu jednodušší. Tento program je prakticky neznámý, ale přesto je něčím zajímavý. Jeho výrobce, korejská firma Softmagic je totiž známá úpravami Quarku pro vydavatele novin. Díky tomu je tento program údajně velmi dobře integrován s XML. Své šablony zapisuje v XML a import strukturovaného obsahu je možná ještě o kousek jednodušší než v případě dvou hlavních hráčů. V současnosti je většina profesionálních tiskovin připravována jedním ze dvou programů. Je to QuarkXPress nebo Adobe InDesign. Qark je starší program s dlouhou historií a věrnými dlouholetými uživateli. InDesign je naopak poměrně novinkou, která nahradila kdysi populární PageMaker. InDesign je první program, který má tak rozsáhlé možnosti práce s písmem, že se vyrovná starým super-složitým systémům založeným na TeXu. V posledních letech tak nabývá na popularitě a ukrajuje z pomyslného koláče 32 33

18 QuarkXPress QuarkXPress je velmi oblíbená grafická aplikace s dlouhou tradicí. První verze byla uvedena v roce 1987, obrovskou popluaritu si získal především verzí 3 vydanou o tři roky později. Quark si svou dominantní pozici na trhu držel po dlouhou dobu. Obrat ve prospěch konkurenčního Adobe InDesignu nastal v roce 2002, kdy měl Quark prodlení s uvedením verze pro OS X. Přechod uživatelů k InDesignu pokračuje nezadržitelným tempem až do dnešních dnů. Quark má sice stále větší počet prodaných kopií, to ovšem nevypovídá o skutečném počtu uživatelů. Hromadnému odchodu ke konkurenci by mohla zabránit aktuálně vydaná verze 7 (červenec 2006). Kvůli relativně vysoké ceně to bude obtížný úkol. Quark obsahuje podporu XML od verze 4.1. Ani v současná nejnovější verze neumí s XML pracovat ve standardní instalaci. Quark nabízí zdarma ke stažení tzv. XML QuarkXTensions doplněk, který práci s XML umožní. Součástí volitelného balíku jsou tři nástroje: avenue.quark, XML Import a Item Sequence. První z nich je určtena k exportu obsahu dokumentu do XML pro jeho další uchování či zpracování. Již z názvu je patrné, že komponenta XML import naopak slouží Paletka Sequences v Quarku (zdroj: dokumentace) k načtení strukturovaného obsahu do Quarku. Velmi zajímavá je poslední ze tří jmenovaných součástí. Item Sequence je nástrojová paletka, s jejíž pomocí lze prvky (textové a grafické rámečky) řadit do určitého pořadí. To je výhodné zejména pro pozdější otaggování takovéto sekvence a export do XML. Práce se velmi podobá tomu, jak se s XML zachází v InDesignu. Důležitý rozdíl je ten, že Quark vždy vyžaduje DTD. Nehodí se tedy pro drobnější jednorázové projekty, pro které je tvorba DTD zbytečná. V jednom dokumentu lze pracovat pouze s jediným DTD. Podobně jako v dále popsaném InDesignu i v Quarku nalezneme speciální panel pro zobrazení struktury, který se zde nazývá Placeholders. Tento panel je poměrně propracovaný. Dělí se na dvě části a umožňuje zvlášť zobrazit strukturu XML dat a strukturu tištěného dokumentu (čili použitých Placeholders v textu). Rozdělení těchto dvou struktur je velmi vítaná vlastnost, ze které by se mohla poučit i konkurence. Vzhledem k častému použití slova placeholder v tomto textu, považuji za vhodné tento pojem stručně vysvětlit. Nejvhodnější překlad asi zní zástupný text. V našem kontextu se jedná o nesmyslný text, umístěný na určitém místě dokumentu, na který je aplikováno veškeré potřebné formátování. Tento text slouží pro lepší návrh vzhledu výsledného dokumentu. Při následném importu dat dojde k nahrazení placeholderu skutečným textem. Analogicky lze vytvořit placeholder z grafického rámečku. Kvůli neexistenci stručného překladu tohoto termínu jsem se uchýlil k používání anglického výrazu. V některých místech textu jsem se nevyhnul jeho nehezkému skloňování. Doufám, že důvod je pochopitelný a že zvolené řešení je snesitelné. V Quarku je možné placeholdery členit do struktury podobně, jako je tomu v XML. Na spodním obrázku si můžete všimnout trochu nešikovného použití znaků větší než a menší než, které zbytečně evokují běžné XML tagy. Použití struktury přímo v dokumentu je ale výborné a usnadní velmi dobré provázání s XML dokumentem. Ukázka panelu Placeholders Placeholder: ukázka zástupného Velmi praktickou funkcí je Data Merge textu tří elementů v QuarkuXpressu zautomatizované opakování elementů, včetně přidávání potřebných stránek. Tato vlastnost se hodí zejména při sazbě opakujících se dat, např. z databáze. Typickým příkladem je dvoustránkový obchodní leták, jenž v úvodu obsahuje adresu zákazníka. Při importu XML dat se 100 adresami zákazníků vznikne dvouset stránkový dokument, jenž obsahuje sto letáků s různými adresami všech zákazníků. Podobně umožňuje Quark import obsahu mnoha XML dokumentů najednou. Obě funkce jsou nadmíru užitečné. Ještě bohatší možnosti nabízí komponenta avenue.quark pro export XML. Je to propracovaný nástroj, který je i v praxi relativně často používán. Vynikající je způsob, zadávání taggovacích pravidel. V těch se nachází specifikace pro automatické otaggování dokumentu. Pravidla lze nastavit velmi podrobně v závislosti na odstavcových a znakových stylech, na barvě textu, lokálním formátování a dalších vlastnostech. Pro případ, kdy není 34 35

19 možné definovat pravidla existuje možnost manuálního otaggování částí dokumentu. Diskutabilní je nutnost existence DTD. Díky tomu je vždy výstup z této komponenty validní, pro menší projekty to opět může znamenat zásadní překážku. Quark je proslulý svým jednoduchým a předvídatelným ovládáním, což se potvrzuje i v případě propojení s XML. Spolupráce s tímto formátem vyžaduje od uživatele značné úsilí od nutnosti hledání a instalace doplňkových komponent, po proniknutí do DTD. Na druhou stranu nabízí pokročilé možnosti práce se strukturou a je vhodný i na komplexnější projekty. Tvůrci XPressu dosáhli unikátního kompromisu mezi jednoduchostí použití a potenciálními možnostmi. Oba následně popisované programy se od tohoto kompromisu vychylují na jednu či na druhou stranu. Adobe FrameMaker 7 FrameMaker (FM) je aplikace s rozdílným konceptem než jeho konkurenti QarkXPress a InDesign. Je to program s velmi dlouhou historií, který se již od samého počátku zaměřuje na dlouhé, složité a strukturované dokumenty. Právě jeho komplexnost ovšem brání jeho širokému rozšíření. Na rozdíl od dvou zmiňovaných se příliš nehodí na typograficky náročné CMYK dokumenty. Je robustní, stabilní a obsahuje velmi dobrou podporu nástrojů jako podmíněný text, odkazy, rejstříky a složité tabulky. Již od raných verzí v něm je možné nalézt podporu SGML a později XML. Nejnovější verzi FrameMakeru je možné spustit ve dvou verzích: FrameMaker a tzv. Structured FrameMaker. Z hlediska spolupráce s XML je pro naše potřeby důležitá právě druhá jmenovaná verze. Podporován je import XML včetně validace i výstup do tohoto formátu. Ve FrameMakeru lze využívat definice typu dokumentu (DTD) a v nejnovější verzi (7.2) také XML Schema. Je podporována technologie XSLT, takže je možné provést automatickou úpravu dokumentu XSL skripty při jeho otevření nebo při ukládání. Taková konverze se na první pohled jeví nepříliš logická (chceme se přece zbavit dávkového zpracování a dokument zpracovat manuálně ), ve skutečnosti se najde dost případů, kdy lehká transformace pomocí XSLT ulehčí následující manuální zpracování. Uvedu příklad, kdy je vhodné použít XSLT ve FM: K optimalizaci dokumentu pro jeho výstupní formu při zachování konzistentního a dobře strukturovaného zdrojového XML (za účelem zpracování v dalších aplikacích). Pomocí XSL může být například vhodné odstranit z dokumentu nepotřebné elementy (jako komentáře) a narovnat (zjednodušit) jeho strukturu aby se přiblížil sekvenčnímu charakteru klasického papírového dokumentu. V případě, že dokument, se kterým hodláme pracovat se skládá z několika samostatných XML dokumentů. Na importu takového dokumentu do FM je tedy nutné jednotlivé části sloučit, a na případném exportu zpět do XML provést rozdělení zpět. To je výhodné použít například tehdy, pokud jsou data mimo FM zpracovávána CMS systémem, který pracuje s jednotlivými částmi dokumentu. Společně s FrameMakerem dostanete při koupi od Adobe také ukázkovou aplikaci s názvem XML starter applications for DocBook 4.1 and XHTML, plus an XML Cookbook (dále v textu XML DB Starter Kit). Tento balík by měl usnadnit přechod na začlenění XML do produkčního workflow. Jak uvidíte dále, přestože se FM přímo zaměřuje na XML publikování autoři jej dokonce označují jako vhodný XML editor není to ani pro něj úkol jednoduchý a bezproblémový. No, není to příliš optimistický začátek Vzhled FM včetně zobrazení struktury 36 37

20 Jak je tedy těžké vysázet ve FrameMakeru knihu v DocBooku? Na tuhle otázku se pokusil odpovědět Steve Whitlatch [FrameMaker] a já se pokusím jeho poznatky shrnout: Projekt spočívá ve zpracování stejného DocBook dokumentu do PDF dvěma metodami: konvenčně pomocí open-source prostředků, které jsou volně k dispozici ke zpracování DB a prostřednictvím Structured FrameMakeru 7.1. Steve se zaměřuje na kvalitu výstupu a na složitost postupů při zpracování. Prvním krokem Už z oficiálního schématu, znázorňujícího import XML dokumentu je vytvoření EDD do FM lze vytušit, že se nejedná o triviální úkol [FM_XSLT] z DocBook DTD. Z velké části to je pouze otázka odsouhlasování dialogů, ale ne vždy. FM přiřadí každému elementu typ, se kterým pak dále interně pracuje. U některých elementů v tomto generovaném EDD je nutno typ ručně upravit. Při validaci dokumentu proti vzniklému EDD používá FM trochu jiná kritéria, než je zvykem u klasických XML nástrojů. Je proto třeba dát si pozor při exportu XML dokumentu na jeho validitu vzhledem k původnímu DTD. Použití EDD trochu trpí tím, že FM EDD je navrženo tak, aby bylo současně kompatibilní i se starším standardem SGML Jen pro ilustraci uvedu stručně některé z problémů, se kterými se uživatel při tvorbě EDD z DocBook DTD setká: FM nepodporuje, všechny možnosti formátování tabulek, které se objevily v DocBooku od verze 4.3. Pokus o vytvoření EDD z DB DTD 4.3 a novějšího vyvolá chybu. Nevhodné interpretování a nastavení vlastností elementů xref, indexterm, footnote, graphic, inlinegraphic, imagedata a dalších. FM EDD dovoluje specifikovat inkluzi/exkluzi pravidlo, které DTD formát nemá k dispozici. I když se jedná o poměrně užitečné pravidlo je lepší se jeho použiží vyhnout a nepoužívat jej ani v EDD. (Např. inkluze dovoluje child elementu objevit se kdekoli uvnitř parent elementu včetně všech jeho ostatních child elementů.) Dalším krokem je import vytvořeného EDD do formátovací šablony. Tento úkol je bez vážnějších problémů. Následuje napsání pravidel pro import a export. V této fázi se uživatel neobejde bez znalostí programování v C nebo C++. Bez jednoduchých API klientů ovšem dochází k zásadnímu porušení validity dokumentu jak při importu tak exportu. V této fázi navíc opět nastávají problémy nejen s tabulkami ale navíc i s vloženou grafikou. Nyní již následuje samotný import dokumentu zapsaném v DocBooku do FM. Přes veškerou snahu FM nedokáže importovat XML dokument tak, aby byl validní. Steve píše: XML je validní dle utility XMLlint; EDD a pravidla pro import jsou validní dle FM; šablona je v pořádku. Přesto FM vytvoří při importu nevalidní XML dokument. Nejsou to již však žádné vážně nedostatky. Naštěstí. FM změní například názvy některých atributů, nebo zdovojí atribut u některých elementů. Přestože v XML souboru je již u daného elementu atribut specifikován, FM jej přidá ještě jednou Podobné problémy jsou nepříjemné spíše svou nevyzpytatelností Pokud se nám povedlo vložit XML dokument do programu, následuje samotné formátování vzhledu. Dá se provést mnoha různými způsoby, ale vždy nastávají problémy s automaticky generovanými částmi, např. obsahem, indexem, externími odkazy atd Je zapotřebí náročné manuální práce, která se může stát díky častému nepředvídanému chování FM frustrující Další lavina chyb spojených s validitou se valí při exportu, pokud se pokusíte o round-tripping. Je jich takové množství, že napsat na každou z nich opravného API klienta je takřka nemožné. Zapotřebí by bylo snad celého týmu vývojářů a je tedy lepší na tuto možnost raději rovnou zapomenout. Pokud člověk dokáže čelit všem problémům, které nastanou, lze skutečně dosáhnout slušného výsledku. Tím je zformátovaný soubor, připravený k tisku. K dosažení tohoto cíle je publikovaný materiál nedocenitelnou a ojedinělou pomocí. Ani jedna z porovnávaných možností (XSL+FOP vs. Structured FM) není pro zpracování knihy v DocBooku ideální, konstatuje na závěr Steve Whitlatch. Ani jeden způsob zatím podle něj není dostatečně jednoduchý a bezproblémový a nedá se běžným uživatelem zvládnout bez rozsáhlého nastudování technických detailů nebo bez pomoci expertů. Přestože je ale FrameMaker drahý, komplikovaný, nepřehledný, nedostatečný a plný chyb, dá se v něm DB dokument naformátovat zcela přesně dle představ. Vyžaduje ovšem hodně snahy. Říká se, že FM přinutíte udělat cokoli pokud umíte dobře kouzlit s Céčkem. K nápravě četných chyb, kterými Structured FM trpí, je pro větší projekty nevyhnutelné naprogramovat záplaty (XML pre- a post- processing na importu a exportu, vlastní API klienti a FDK klienti), což vyžaduje ohromné množství práce. Bez této berličky produkuje FM nevalidní dokumenty z validních v každé fázi jejich zpracování (import, editace, export) a je nepoužitelný. Na rozdíl od toho, je porovnávaná kombinace XSL+FOP spolehlivá a funguje předvídavě. Případné psaní kódu se navíc neodehrává v opravdovém programovacím jazyce. Úpravám XSL 38 39