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

Použití XML v profesionálních publikačních aplikacích

Bakalářská práce

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

Prohlášení

Anotace

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.

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

V Praze dne 23. srpna 2006

Adam Perutka

Věnování

Annotation

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.

In the thesis I attempt to explore the potential of XML format in present DTP environ­ment.

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.



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.

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.



Obsah

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

Úvod

1. potřeba uchovávat veškeré texty v univerzálním nadčasovém formátu a … 2.  … touha připravit je k tisku ve WYSIWYG softwaru s maximálními možnostmi nastavení vzhledu stránky a písma..

A s for the future of publishing, XML is really im­­­­­­­­­­-

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.

p­ort­ant. I can’t tell you how or why, but i know it’s the future.

C o se týče budoucnosti publikování, XML je opra­v­ du 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 zje­dnoduš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ža­davky, které se v současnosti bez těchto znalostí v podstatě vylučují: 



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 stan­dardem 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í.



Použití XML mezi profesionálními grafiky (celkem 26 odpovědí)

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.

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.

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.

10

11

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 www.grafika.cz

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ářů: 1. 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). 2. 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.

12

13

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.

Příklad jednoduchého XML adam jirka <predmet>Nezapomeň Chci připomenout, abys nezapoměl přiložit i zdrojový kód.

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

— 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
vzkaz (komu,od,nadpis,zprava)> komu (#PCDATA)> od (#PCDATA)> predmet (#PCDATA)> zprava (#PCDATA)>



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?

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.

14

15



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ší

16

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 <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> <emphasis role=”bold”>This paragraph contains <emphasis>some <emphasis>emphasized text and a <superscript>superscript and a <subscript>subscript. <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.

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: http://www.docbook.org/tdg/en/html/ch04.html#simple.document.formatted).

17

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 stru­k­ turovaný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.

18

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.

19

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

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

Srovnání manuální a dávkové sazby  

Manuální

Dávková

Jednoduchost

Jednoduchá – vyžaduje znalost některého publikačního nástroje, např. InDesign

Obtížná – vyžaduje znalost jazyka pro napsání šablony

Kvalita výstupu

Vysoká – vhodné pro vizuálně zaměřené dokumenty

Střední – i přes poměrně rozsáhlé možnosti zaostává v grafických a typografických nuancích

Flexibilita

Vysoká – sazeč může přímo měnit Nízká – možnost změny pouze design stránek přes šablonu

Uživatelská základna

Široká – miliony uživatelů DTP nástrojů

Malá – omezeno na specializovaná prostředí a znalostními nároky

Integrace s XML

Střední – i tímto dokumentem se pokusím tento stav zlepšit

Kompletní – vyžaduje znalost XML u tvůrců systému i u sazeče

Editovatelné stránky

Vždy – ve kterékoli fázi je možno pohybovat s jakýmkoli objektem stránky

Vzácné – Podle mých informací umožňuje editaci pouze produkt Arbortext 3B2. Tato je velmi omezená ve srovnání s DTP aplikacemi.

Roundtripping

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

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

Rychlost

Pomalá – v řádu jednotek stránek za hodinu u jednoduchých dokumentů. U složitých mnohem méně

Rychlá – tisíce stránek za hodinu

24

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

25

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 kreati­ vní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 <simple-page-master margin-right=”15mm” margin-left=”15mm” margin-bottom=”15mm” margin-top=”15mm” page-width=”210mm” page-height=”297mm” master-name=”bookpage”> <page-sequence master-reference=”bookpage”> Hello XSLFO!

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.

26

27

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 http://www.fi.muni.cz/~xpavlov/xml/examples/bc1/



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ů <move> <white>N g1-f3 P <move> <white>P g2-g3 B <move> <white>P b2-b3 N <move> <white>B c1-b2 P <move> <white>P f5-f6 R <move> <white>P g6-g7

d7-d5 c8-g4 b8-d7 e7-e6 d5-d1

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

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 http://sourceforge.net/projects/docbook. 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.

30

31

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

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



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é opako­­vání elementů, včetně přidávání potře­­­bný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í 35

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

36

 



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

37

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.

38

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 39

stylů se ovšem stejně vyhnout nelze, pokud si člověk přeje mít nad výslednou podobou dokumentu dostatečnou kontrolu. Některé úpravy „customisation layer“ jsou ale velice jednoduché. Ve srovnání s FM je na druhou stranu samozřejmě mnohonásobně těžší vyladit drobné detaily ve vzhledu stránky. Experiment Stevea Whitlatcha je vynikající materiál pro kohokoli, kdo se chce zabývat sazbou DB dokumentů ve FrameMakeru hlouběji. Je k dispozici kompletní zdrojový kód potřebný pro vygenerování výsledku do XSL stylů po skripty v FM. Jeho balíček doplňuje vše, co v originálním XML DB Starter Kitu od Adobe chybí. Je to ojedinělý konkrétní příklad toho, jak v FM vysázet k tisku knihu z importované knihy ve formátu DB. Při porovnání jeho dvou tiskových výstupů je ihned patrný více „profesionální“ vzhled PDF vytvořeného ve WYSIWYG prostředí. To je zcela dle mých předpokladů a potvrzuje to mou tezi, že grafik je stále při sazbě profesionální publikace nepostradatelný. Je to výborná motivace k prozkoumání sazby XML manuální cestou pomocí typograficky ještě dokonalejších WYSIWYG nástrojů v dalších kapitolách. FrameMaker je velmi specifický program se zajímavým vývojem. Jde o prastarý program, který za poslední roky prodělal bohužel minimální změny. Některé součásti nejnovější verze jsou starší více než 10 let. Týká se to i velké části XML DB Starter Kitu, jehož vývoj pro SGML DB začal v době, kdy DocBook XML ještě ani neexistoval. Od té doby se bohužel nijak zásadně nezměnil. Je to nástroj vysoce specializovaný, který se vyplatí použít především na sazbu komplexních dokumentů, ve kterých je často potřeba vykonat změny nebo existují v několika verzích. Tedy podobné zaměření, jako samotného DocBooku. Problém FrameMakeru je jeho nesmírná komplexnost, tedy složitost. Když se nad tím zamyslíme, tak FrameMaker nenabízí mnoho výhod ve srovnání s kombinací DB + automaticky generovaný výstup. Při jeho použití jsou třeba programovací schopnosti a způsob ovládání jej také předurčuje k vytvoření jakési šablony a následnému „lití“ textu do něj. Nehodí se tedy na jednorázovou úpravu jednoho dokumentu. Při tom všem navíc postrádá univerzálnost, přenosnost a eleganci, což jsou hlavní výhody „nativních“ zpracovatelů DB (jak jsem si soukromě nazval XSL a spřízněné technologie). Navíc se nejedná o nikterak levný nástroj. Kromě vysoce specializovaných případů je tedy dle mého názoru výhodnější použití kombinace XML + XSL, byť za cenu „programování“ vlastních schémat a stylů v případě, že se připravené open-source nástroje pro váš účel nehodí.

40

Adobe InDesign Adobe InDesign (InD)je sázecí program s relativně krátkou historií. Adobe jej původně uvedlo jako konkurence Qarku, ale postupně nahradil i zbývající dva související produkty od Adobe – PageMaker a FrameMaker. I přes značnou nevyzrálost raných verzí si rychle začal získávat popularitu a dnes je z něj s převahou nejrozšířenější sázecí aplikace. Jeho obliba je způsobena také perfektní spoluprací s ostatními aplikacemi, které Adobe prodává v jednom balíku jako Creative Suite 2. Ani InD se sice občasnou nelogičností GUI nevymyká z trendu nastoleného jeho staršími konkurenty, přesto to je program vskutku revoluční – přináší zpět do sazby téměř zapomenuté techniky, které před dávnou dobou používali sazečtí mistři. Jeho typografickým možnostem se vyrovná snad pouze TeX – ovšem s nutností použít mnohem složitější prostředky k jejich dosažení. I přes poměrně dobrou podporu formátu XML již od předminulé verze, je dle mých informací tato funkcionalita používána skutečně zřídka. Je to další z příkladů značně konzervativního chování grafických pracovníků. Použití XML není nutné omezit pouze na zdroj obsahu. Příkladů, kdy InD s tímto formátem pracuje (často bez vědomí uživatele) se dá nalézt slušné množství: Formát .XMP pro metadata – Způsob, jakým InD uchovává metadata o dokumentech a objektech napříč Creative Suite InDesign Interchange – Formát souborů .inx pro zpracování ve starších verzích programu není nic jiného než XML SVG grafika – Export a import vektorového formátu založeného na XML InDesign Snippets – Snippets jsou části dokumentu, ukládané do samostatného souboru pro využití v dalších dokumentech. Formát těchto souborů je založen na formát ID Interchange (.inx) Export do GoLive – Při ukládání textu pro další využití pro web je soubor uložen do nativního XML formátu aplikace Export do InCopy – Soubory .incd a .incx aplikace InCopy pro spoluvytváření obsahu jsou také založeny na XML Import a export XML obsahu – InD disponuje importní i exportní funkcí, umožňující načíst do dokumentu XML nebo naopak uložit obsah dokumentu ve formě XML. Vzhledem k současnému tržnímu podílu na trhu (a jeho dynamice) věnuji možnostem využití XML jako vstupního a výstupního formátu v tomto programu samostatnou kapitolu. Jak již bylo zmíněno v úvodu, důraz bude kladen na možnost praktického využití DTP pracovníky. V závěru kapitoly najdete postup, jakým byl vysázen tento text. 41

6. XML obsah v Adobe InDesign 4.0 CS2

z databáze, kdy XML slouží jako jakýsi zprostředkovatel mezi databází a DTP programem. Bohužel se ještě stále velmi často i tato činnost provádí stylem „copy&paste“.

A s a desktop publisher i use InDesign for about 80%

of my work and i  use DocBook for other personal projects. However, i  would not, at this point in time, even entertain a Docbook/InDesign solution. It’s just not there yet.

   

Používám InDesign na cca 80% práce a na ostatní

osobní projekty využívám DocBook. Přesto bych se v  tomto časovém okamžiku nepokoušel tato dvě řešení spojit. Doba k tomu zatím nedozrála. — Rene Hache, oasis-open.org Archives, 04/2005

V podstatě existují dva základní scénáře, jak s XML daty v InDesignu pracovat. První spočívá v tom, že uživatel označkuje obsah (text, obrázky) stávajícího dokumentu a ten pak exportuje do XML k dalšímu použití. Nejjednodušší cestou značkování je přitom přemapování odstavcových a znakových stylů na zvolené XML tagy. Mimo ní lze pak použít různé manuální úkony, jako je například přetažení tagu z palety na zvolený obsah apod. Uživatel přitom může použít nejen tagy, které přímo vytvoří, ale též takové, které načte z jiného XML či InD dokumentu nebo případně z taggovaného PDF. Tato možnost najde své využití například při přesunu tištěného obsahu na web – ze získaného XML lze jednoduše vytvořit standardní HTML. Osobně si nemyslím, že by export do XML byl nějak masově využívanou funkcí, ale své opodstatnění v individuálních případech jistě najde. Druhá možnost je přístup opačný – uživatel má k dispozici XML jehož obsah si přeje zpracovat v InD. Odhlédněme nyní od velkých organizací, publikujících stovky dokumentů na různá média, kde bývá XML základem publikačního workflow. V dnešní praxi většiny běžných grafických studií je zatím vysoce nepravděpodobné, aby klient dodal podklady v XML. Přesto bude přibývat situací, kdy tento scénář najde uplatnění. Postupně snad stále více tvůrců obsahu (=zákazníků) pochopí, že XML znamená výhodu především pro ně. Import XML je výhodné použít například při tisku dat 42

InDesign pro práci s XML daty disponuje zajímavými funkcemi, které dokáží práci skutečně zjednodušit. Tyto možnosti zahrnují: automatické mapování tagů (elementů) na styly a naopak automatické mapování tabulek, pro jednoduchou práci s CALS tabulkami automatizované odkazování na grafické soubory XML validace Podívejme se na praktických příkladech, na kolik je využití těchto prostředků skutečně použitelné a bezproblémové.

Export XML Co dělat v situaci, když máte hotový dokument v InDesignu (.indd ) a klient si náhle vzpomene, že by nebylo špatné zobrazit data „aj na tém intérnetu“? Jedna možnost je poslat zdrojový soubor (ve Wordu) emailem do vedlejší kanceláře, kde sedí weboví grafici, a nechat je se s podklady poprat ještě jednou, stejně jako jsme se tomu nevyhnuli my. Pokud ale ve vedlejší kanceláři sedí kamarád, je vhodné ušetřit mu trochu práci. Dokument zpracovaný v INDD má oproti zdrojovému dokumentu zpravidla tu výhodu, že na rozdíl od něj neobsahuje žádné přebytečné formátovací znaky. Přidáme-li k tomu další z věcí, které zřejmě klienti nikdy nezvládnou – totiž použití systému formátovacích stylů, nemusí být již převod do XML tak složitý. A jak známo, z XML je možné dále snadno generovat další formáty, například požadované HTML … Samotný export je v InD velmi jednoduchý úkol. Ukažme si to prakticky na jednoduchém příkladu. Předpokládejme, že máme podobný dokument jako na obrázku z následující stránky.. Na obrázku si všimněte několika detailů. Vlevo od hlavního okna je panel Structure View. Je to místo, kde se zobrazuje struktura dokumentu, čili jeho otaggované části. Zatím zde není možno vidět žádné elementy kromě elementu „Root“. To je standardní kořenový element, který InD přiřadí každému dokumentu automaticky. Všimněte si vpravo paletky s odstavcovými styly,

43

být text, grafika, nebo rámeček. Neotaggovaný obsah pro tento panel jakoby neexistuje a při případném exportu nebude zahrnut do výsledného XML. Abychom mohli tedy text exportovat ve strukturované formě, musíme ho nejprve otaggovat. Prvním krokem je vytvořit seznam tagů, které chceme mít ve výstupním dokumentu. V našem případě je vytvoříme ručně. Následné zpracování XML souboru neklade žádné speciální požadavky na elementy, které má XML obsahovat, bude tedy ideální pojmenovat tagy přesně podle názvů stylů použitých v dokumentu. Je třeba dát si pozor na to, že XML je syntakticky velmi přísný jazyk a je rozdíl mezi malým a velkým písmenem. Pokud máte vytvořeny názvy budoucích elementů XML souboru je třeba je přiřadit odpovídajícímu obsahu. Jednou z možností je manuálně označit daný text, obrázek nebo frame a v paletce kliknout na požadovaný tag. Efektivnějším způsobem, jak toto udělat, je využít nástroje Map Tags to Style, který to za nás udělá do značné míry automaticky. Tento nástroj je dostupný z rozbalovacího menu na paletce Tags i panelu Structure View. Při jeho otevření můžete každému stylu přiřadit určitý tag a dojde k otaggování

kterými je text členěn. Pod ní se nachází paletka Tags. Na této paletce jsou k dispozici barevně odlišené tagy, které můžeme v dokumentu použít. U této paletky bych se na chvíli zastavil, protože se lehce může stát zdrojem nedorozumění. Je důležité pochopit rozdíl mezi Structure View a Tags. Zatímco v prvně jmenovaném panelu je zobrazena skutečná struktura použitých elementů, v paletce jsou zcela libovolné tagy k dispozici. Kde se vezmou? Jednak je tam můžeme sami ručně vytvořit. To je případ těchto šesti tagů, které na obrázku vidíte. Další možností je import tagů z jiného XML souboru nebo INDD dokumentu. V tomto případě se na paletce zobrazí všechny tagy použité v daném dokumentu. Nedojde k importu obsahu a panel Structure View tedy zůstane beze změny. Poslední možností je načtení tagů z DTD. Zatímco do paletky Tags můžeme libovolně vkládat tagy, které ani nikdy nemusíme použít, v sousedním panelu je již zobrazená skutečná struktura elementů použitých v dokumentu. Aby se tedy v tomto panelu něco objevilo, je třeba nejprve otaggovat nějaký obsah v dokumentu. Tímto „obsahem“ může 44

45

každé instance tohoto stylu v celém dokumentu. Pokud jste pojmenovali tagy stejnými názvy, jako předtím formátovací styly, stačí kliknout na tlačítko Tag by Name. Že je obsah otaggován poznáte podle barevného rámečku okolo framů a jejich podbarvení. Otaggované části textu jsou uzavřeny v tenkých hranatých závorkách. Toto zvýraznění se zapíná a vypíná v menu View>Structure. Všimněte si na obrázku panelu Structure View. Zobrazuje nyní ve formě rozbalovacího stromu strukturu otaggovaného obsahu dokumentu a tedy i budoucího XML souboru. Je dobré připomenout, že každý XML soubor může mít pouze jediný kořenový element. V tomto případě to bude standardní element Root, jeho název lze ale změnit. Automatickým mapováním tagů došlo k otaggování veškerého textu v mém dokumentu. Obrázky jsem označkoval ručně – přetažením myší odpovídajícího tagu z paletky na obrázek. Všimněte si ukázky obsahu u elementů, které je pro usnadnění orientace velmi dobré zapnout (v rozbalovacím menu panelu Show Text Snippets). Tam také můžete přepínat například zobrazení XML atributů. Na obrázku si můžete všimnout ručně zadaného atributu „Autor“ u elementu „Root“. Je třeba upozornit, že atributy není možné standardními prostředky InD dostat do obsahu dokumentu. Je dobré to mít na paměti a umisťovat do atributů skutečně pouze meta-informace. Tím už ale zbytečně předbíhám. Úkol je téměř splněn. Vytvořili nebo načetli jsme tagy pro budoucí XML soubor, otaggovali jsme jimi odpovídající obsah. Ten nyní zbývá jen vyexportovat. Před tím je třeba označit kořenový element dokumentu. Pokud by byl označen nějaký jeho potomek, do XML by byla zapsána jen tato část obsahu. Položku pro export najdeme opět v rozbalovacím menu panelu se strukturou. Po jeho stisknutí je k dispozici několik málo nepříliš významných voleb, které jsou ale snad dostatečně zřejmé. InD umožňuje současně s exportem nahrát do specifikované složky grafické soubory. Lze provést jejich automatickou optimalizaci, trochu nešikovná je ale možnost uložení obrázků pouze ve formátu GIF nebo JPEG. Na protější stránce vidíte, jak vypadá konečný soubor, který jsme schopni z InD dostat. Konkrétně ukázka, kterou vidíte výše je tedy „pretty-printed“ v jiném editoru. Přímo z InD totiž vyjde text neodsazený, což samozřejmě nemá žádný vliv na obsah. Všimněte si na konci souboru odkazů na obrázky. Nyní jsou data připravena v nejlepší možné formě na převtělení do jiného formátu, nebo na zpracování další aplikací. V podstatě stejný postup bychom uplatnili i na složité dokumenty

46

XML Výstup z InDesignu <Story> <Title>Těšte se na lyže <Story> Zima 2007 <Story> Nové lanovky Elenit lan utem do od magna feum irit lore dolum aliquat, vullaor peraessi.  … <Emp>Doluptat. Ommy nibh …  …

Možnosti exportu jsou dostatečně intuitivní a celkem dobře použitelné. InD produkuje „well-formed“ XML dokumenty, v případě, že mu poskytneme DTD, tak umožňuje ověření validity strukturu dokumentu a výsledný soubor je pak skutečně validní (jaká změna oproti FrameMakeru!). Disponuje užitečnými funkcemi, především mapováním stylů na tagy. Měl by bez větších problému umožňovat i export tabulek. Tuto vlastnost jsem však zatím neměl příležitost otestovat. Netvrdím, že výsledné XML nebude potřebovat další transformaci, aby se stalo použitelné v nějakém dalším content management systému, ale celkově je výstup z tohoto programu skutečně prakticky dobře použitelný. Je však jistě na místě zvážit, zda by nebylo vhodnější obsah převést do XML v některé z ranějších fázi životního cyklu dat Na tomto místě bych měl také poznamenat, že existují i další možnosti získání XML z InD. Ty jednodušší zahrnují použití article souborů v InCopy (jedna ze součástí Creative Suite od Adobe) nebo využití funkcí Adobe Acrobatu Proffesional. Sofistikovanější (a mnohem nákladnější) metody zahrnují publikační systémy jako K4, nebo použití skriptovacích jazyků. Pokud by se někdo dostal do nezáviděníhodné situace a musel by převést obyčejný text z InD do DocBooku, velkou pomocí mu může být plugin XMLMarkupInjector. Popis jeho použití již přesahuje rozsah této práce. Velmi obsáhlý a užitečný materiál pro převod složitějších dokumentů do XML poskytuje i dunn 47

Sazba jednoduchých opakujících se XML dat Konečně se dostáváme k zajímavějšímu a v praxi lépe využitelnému postupu. Jaké jsou možnosti a jak postupovat při sazbě dat v InDesignu, jejichž zdroj je dodán v XML? Budeme nyní uvažovat, že předem známe strukturu vstupního dokumentu a budeme tisknout opakující se data, která mají stejnou formu. Postup se tedy hodí na tisk vizitek, číselníků, seznamů, katalogů, kulturních programů a všemožných výstupů z databáze. Základním principem je zvlášť vytvoření vizuální šablony dokumentu v InD a zvlášť obsahu v libovolném textovém editoru. InD umožňuje přiřadit jednotlivým objektům stránky odpovídající XML elementy, a sloučit obsah s vizuální šablonou dohromady. Při pozdější úpravě zdrojového XML se potom tyto změny snadno promítnou do INDD. Samozřejmě je možné využít i úplně nové XML o stejné struktuře. XML tak poskytuje dvojí službu – jednak ulehčení práce znovupoužitím vizuálního formátování a také umožňuje bezbolestnou editaci obsahu mimo InDesign. To vše jsou vlastnosti, které by bez XML byly jen těžko proveditelné. Pojďme se tedy podívat na praktický příklad.

Ukázka vstupního souboru generovaného účetním SW 0690012 7.8.2006 PalmPC 2354865 <jmeno>Tomáš Brož Masarykovo náměstí 5 39301 <mesto>Pelhřimov <polozka> <popis>Sluchátka Koss Porta Pro 1290 <polozka> <popis>Sluchátka Koss PRO/3AA 2390 <polozka> <popis>Doprava 50

Připravená šablona faktury. Všimněte si umístění dat a pozadí do rozdílných vrstev

V mém malém internetovém obchodě vystavuji řádově jednotky až desítky faktur týdně. Účetní program umožňuje export detailů objednávky ve formě velmi jednoduchého XML. Samozřejmě by bylo možné vytisknout fakturu přímo z účetního programu. Takový program ale většinou umí vytvořit jen velmi strohý dokument. Proč k tomuto účelu nevyužít InDesign a neposílat reprezentativní faktury? Prvním krokem je vytvoření vzhledu dokumentu. Při tomto kroku postupujte jako při tvorbě zcela běžného INDD dokumentu. Jen je vhodné umístit do samostatné vrstvy veškerý obsah, který bude obsahovat proměnná data. Možným řešením je i umístění statického obsahu do master pages. Je třeba dát si pouze pozor na to, že jakýkoli objekt na master page nemůže být později otaggován a na základě vstupu z XML měněn. Je užitečné vyplnit konkrétní data (jedné položky), díky který získáme lepší představu o výsledném vzhledu dokumentu. Při následném otaggování se z tohoto vzorového obsahu stane tzv placeholder – obsah, jenž má být nahrazen obsahem z vnějšího zdroje.

48

49

Merge na druhou stranu porovná strukturu stávajícího INDD s importovaným XML a tam, kde najde shodu nahradí stávající obsah daty z importovaného souboru. InD porovnává postupně element po elementu a hledá, zda tento odpovídá některému z elementů ve panelu Structure View. Když importujete XML je možné nastavit několik možností: porovnávání od vybraného elementu ve struktuře, ignorování XML obsahu, který neodpovídá struktuře v INDD nebo naopak odstranění elementů v dokumentu, které nemají odpovídající protějšek v XML. Průběh standardního importu bez doplňkových parametrů začíná u kořenového elementu a probíhá následovně: 1. Porovnání začíná kořenovými elementy  Pokud je kořenový element v XML jiný než kořenový element struktury INDD a pokud panel Structure neobsahuje žádné další elementy, nahradí InD kořenový element kořenovým elementem z XML dokumentu a importuje celý soubor.  Pokud jsou názvy kořenových elementů odlišné, a panel Structure obsahuje další elementy, InD přidá soubor na konec existující struktury – stejné chování jako režim Append.  Pokud jsou kořenové elementy shodné, posunuje se porovnávání na následující element v importovaném souboru. 2. Porovnání se postupně přesunuje na další elementy počínaje elementem hned za kořenovým v XML souboru. InD hledá shodný element v existující struktuře, přičemž nestačí pouze shodný název – elementy musí být také na stejné úrovni v hierarchii.  Pokud InD nalezne odpovídající element v existující struktuře, tak jej (respektive jeho obsah, včetně atributů) nahradí obsahem z importovaného souboru  Pokud žádný odpovídající existující element ve struktuře nenalezne, umístí element do struktury na místo, kde začalo vyhledávání. V případě prvního elementu by to bylo ihned za kořenovým elementem struktury. 3. Vyhledávání pokračuje na další elementy. InD vždy posunuje začátek hledání za naposledy vložený nebo nahrazený element a vždy vyhledává směrem dolů.

Postup pro otaggování je shodný s tím, jaký jsme provedli v předcházející kapitole. Jen je nyní třeba vytvořit strukturu paralelní s vstupním XML dokumentem. Abychom se co nejlépe přidrželi struktury vstupního dokumentu, je vhodné načíst DTD (menu panelu Structure > Load DTD) nebo alespoň tagy ze vzorového XML. Označením textu a tím, že mu přiřadíme tag, se sice automaticky přidá do struktury nový element, může být ale třeba manuálně jej v panelu posunout na jiné místo hierarchie. Úplně nejbezpečnější variantou je načtení jednoduchého ukázkového XML, o stejné struktuře jako soubory, které hodláme později importovat. V menu panelu Structure vyberte Import XML, v následném dialogovém okně vyberte parametry dle mého popisu v závěru této kapitoly, nebo ponechejte standardní hodnoty. Pokud proběhne vše v pořádku, měla by se v levém panelu objevit struktura odpovídající načtenému XML souboru. Otaggování obsahu nyní proběhne buď pomocí drag’n’drop, nebo označením textu a vybráním odpovídajícího tagu na paletce Tags – v tomto případě bude možná opět potřeba přetáhnout element na správné místo struktury. Pochopení techniky jakou jsou elementy vkládány nám usnadní vytvoření správné struktury. InD umožňuje dvě varianty načtení XML: Merge a Append. Append funguje tak, že nezmění stávající dokument, a nový obsah přidá na konec panelu Structure. To je vhodné pro přidání dalšího obsahu do dokumentu, které proběhne přetáhnutím myši na cílové místo. Přílišné množství situací, kdy by bylo výhodné tohoto módu využít mě nenapadá …



50

Vložením elementu se míní vložení jeho obsahu, včetně případných potomků – za předpokladu, že pokud potomci nepatří jinam (čili není na jiném místě definován odpovídající placeholder text).

51

těchto hranatých závorek, se stal tzv. placeholder – text, který bude při importu nahrazen odpovídajícím obsahem ze souboru. Je důležité si uvědomit, že dojde k nahrazení všech znaků umístěných uvnitř tagů. To se týká i speciálních a formátovacích znaků, přejete-li si tedy zachovat tyto znaky i po importu, je třeba je umístit mimo tyto hranaté závorky. Neotaggované části textu se nazývají statický text. Zobrazení tagů ve story editoru je přehlednější

Na tomto obrázku vidíte dokument, připravený k načtení XML. Text, který zde vidíte, je smyšlený – slouží jako tzv. placeholder a při importu XML bude nahrazen skutečným obsahem. Všimněte si nejprve struktury v levém panelu a porovnejte ji se souborem, který se chystáme importovat. Oba by v ideálním případě měli být validní podle stejného DTD. Na tomto obrázku jsou červeně zvýrazněny elementy polozka a odberatel. Validátor tím označil místo, kde je nějaký problém. Současně je ve spodní části panelu popis chyby a návrh řešení (to, že va lidátor označil kvůli těmto místům strukturu nevalidní je problém, který zmíním v závěru příkladu). Pro zobrazení zvýraznění otaggovaného obsahu musí být zapnuty volby v menu View > Structure. Dva textové rámečky vlevo nahoře jsou otaggovány elementy bez potomků. V tomto případě není nutné už taggovat text uvnitř. Zajímavější je situace ve dvou větších framech.

 





Rámeček s adresou je podbarven zeleně, což značí, že mu byl přiřazen tag odberatel. Podívejte se pozorně a všimněte si kolem textu barevných hranatých závorek. Znázorňují členění textu podle jednotlivých tagů. Je dovoleno vložit mezi tagy (čili mimo ony hranaté závorky) doplňkové speciální znaky – například znak konce řádku. Z otaggovaného textu, umístěného uvnitř 52



Spodní textový rámeček s fakturovanými položkami si také zaslouží zvláštní pozornost. Samozřejmě bychom měli předpokládat, že těchto položek může být na faktuře víc, než pouze jedna. Chceme-li využít možnosti InD, který nabízí automatické vložení opakujícího se textu, stačí splnit několik podmínek a při načtení dokumentu obsahujícího několik elementů polozka dojde k jejich správnému umístění automaticky. Na co je třeba dát si pozor: Placeholder musí být otaggován stejně jako obsah v importovaném XML Textový rámeček, obsahující opakující se elementy, musí být označen tagem nadřazeného elementu, který obsahuje všechny elementy, které se opakují. (V našem případě je nadřazeným elementem pouze faktura. Bylo by možné vytvořit speciální element, který by slučoval několik položkek – mohl by se jmenovat např. seznam_polozek.) Struktura dokumentu se musí překrývat se strukturou importovaného XML. (Stačí pouze část, ale doporučuji validitu dle stejného DTD.) Veškeré formátovací znaky a statický text musí být umístěny mimo tag, který má tento text doplňovat (jinak by byl nahrazen), ale současně uvnitř rodičovského elementu, který neobsahuje žádný další obsah. Při importu je třeba zaškrtnou volbu Do Not Import Contents Of Whitespaceonly Elements. Díky tomu bude zachován statický text mezi tagy.

53



Text bude automaticky zobrazen jen v rámci Story. Je možné, aby se rozkládal přes několik zřetězených rámečků, ale InD při importu využije jen ty existující a žádné nové nepřidá. Příprava na vložení opakujícího se obsahu se může zdát komplikovaná, ve skutečnosti tomu tak není. Jen je potřeba si s tím trochu vyhrát, protože ne všechno se bohužel na první pokus chová přesně tak, jak by člověk očekával. Otaggovaný text připravený na import opakujícího se elementu polozka

Import text elements into tables if tags match Automaticky vytvoří tabulku a umístí do ní specifikované elementy. Elementy, na které se to vztahuje, se nastavují v položce Tagging preset option v menu panelu Structure. Do not import contents of whitespace-only elements Ponechá stávající obsah beze změny, pokud odpovídající XML element obsahuje pouze bílé znaky (mezera, tabelátor). Tato možnost musí být zaškrtnuta, pokud si přejete zachovat statický text vložený mezi tagy. Delete elements, frames, and content that do not match imported XML Zrcadlová položka ke třetí volbě v tomto okně. Při importu vymaže všechny elementy z pa­ n­elu struktura, které v XML souboru nemají odpovídající protějšek. Pokud v našem příkladě nebude některý soubor Volby pro import obsahovat jméno firmy, nebo ičo, tak dojde k vymazání placeholderu z dokumentu. Při nezaškrtnutí této volby by ve výsledném dokumentu text „ičo“ zůstal. Jestliže parametry importu zaškrtnete stejně jako já (viz screenshot), měli byste dostat dobrý výsledek.

Zda vše správně zafunguje, nezbývá než otestovat importem XML (File > Import XML). Po vybrání vhodného souboru je potřeba vybrat správné volby importu. Zásadní je rozdíl mezi režimem Append a Merge, který jsme si již popsali výše. Stručně popíšu, co znamenají další volby: Create link Chová se podobně jako nalinkovaná grafika. Soubor XML nebude vložen napevno do INDD, ale dojde k jeho propojení. Soubor se objeví v paletě Links. Doporučené je nechat tuto volbu zaškrtnutou – umožní to snadno promítnout změny provedené v XML dokumentu, nebo připojit jiný soubor. Clone repeating text elements Duplikuje formátování udělené placeholder textu pro opakující se elementy. Tagy musí být shodné se strukturou XML. Tato volba se používá, pokud budete importovat opakující se elementy se stejnou strukturou. V našem příkladě to jsou opakující se položky faktury Only import elements that match existing structure Filtruje obsah importovaného XML tak, že ponechá pouze elementy, které mají své protějšky v panelu Structure. 54

55

Výsledná faktura po importu ukázkového XML z úvodu kapitoly

zobrazovat či nikoliv apod. Konkrétně na příkladě faktury postrádám možnost nějaké základní matematické operace – pokud bych chtěl ve faktuře zobrazit celkovou částku k platbě musel bych ji vypočítat buď ručně nebo použít XSLT. Uznáte sami, že ani jedna varianta není příliš elegantní. Pokud jste dočetli až sem, možná vás napadá že něco chybí. Co si počít, pokud bychom chtěli vytisknout větší množství faktur najednou? Popsaným způsobem by to sice šlo jednodušeji, než zcela bez pomoci XML. Pořád by ale bylo nutné tisknout každou fakturu zvlášť. Dokázali bychom vytisknout fakturu na základě násludujího dokumentu? Příklad XML obsahujícího několik faktur (zkráceno)

Obrázek o praktičnosti a použitelnosti této techniky si udělejte sami. Myslím, že celkově výsledek nepůsobí špatně. Těším se na další verzi InDesignu, protože když se odstraní několik drobnějších problémů, mohly by být možnosti sazby XML skutečně bezchybné. Jedna z věcí, kterou bych ocenil, by byla možnost zadání podmíněného textu. V našem konkrétním příkladě bych to využil například k zobrazení popisků. Pokud by zdrojové XML obsahovalo element ico o obsahu 123456, měl by se vytisknout následující řádek: IČ: 123456 V případě, že by ale tento element v souboru nebyl, na řádku by se nemělo vytisknout nic. To současnými prostředky není možné. Rozhodně postrádám možnost umístění obsahu atributu do dokumentu. InD sice umí atributy elementů přidávat i editovat, do obsahu dokumentu je však nedostanete. S atributy by se dalo pracovat ještě lépe. Dovedu si například představit, že pomocí atributů by se dalo ovlivnit to, zda daný element 56

0602201 3.8.2006 <jmeno>Lukáš Zima Jabloňová 2929 10600 <mesto>Praha <polozka> <popis>Sluchátka Koss Porta Pro + doprava 1350 <polozka> <popis>Doprava 25

Kořenovým elementem tohoto XML je element faktury, který dále obsahuje libovolné množství elementů faktura. Šlo by využít InD pro automatický tisk faktur podobně jako dokáže automaticky přidat libovolné množství položek faktury? Pokusil jsem se o to a odpověď zní: jde to, ale ne bez problémů. Omezení vyplývá z toho, že InD umí automaticky opakovat obsah pouze v rámci jednoho „Story“. Je tedy nutné umístit obsah všech placeholders do jednoho textového rámečku, otaggovaného elementem, který hodláme opakovat, čili v našem případě faktura. 57



Do více rámečků není možné obsah jedné faktury rozdrobit i  z toho důvodu, že jeden element struktury (např. faktura) může být přiřazen pouze jednomu prvku na stránce. A zároveň potřebujeme každý rámeček otaggovat nadřazeným elementem k elementům ostatním, jinak by nebyl jeho obsah opakován. Možným řešením by bylo rozdělit fakturu do samostatných bloků (odběratel, fakturační údaje, položky) a ty přiřadit několika textovým rámečkům. Element faktura by pak neměl přiřazen žádný prvek dokumentu. Nevím, jak by se řešil problém s tím, aby si rámečky i napříč různými stránkami zachovaly při autoflow svou velikost a pozici – nejsem v InD odborník a řešení tohoto problému neznám i když asi nebude složité. Logické řešení, které se nabízí – tedy umístit tyto rámečky na master page – nepřipadá při použití XML v úvahu, protože objekty na master pages nemohou být otaggovány. Je vhodné tento hlavní (a jediný) rámeček roztáhnout do celého tiskového zrcadla, abychom v případě mnoha záznamů mohli pohodlně využít funkci autoflow. Zásadní problém v našem příkladě faktury pramení z pořadí zobrazení prvků. Pokusím se tento jev vysvětlit na příkladu faktury. Problém mezi pořadím ve struktuře a při zobrazení opakujících se prvků

58

Na obrázku nejprve sledujte červenou čáru. Značí, v jakém pořadí jsou elementy zapsány v XML a tedy i v panelu struktura. Představte si, že rámečky je nyní nutné sloučit a text napsat do jednoho tak, aby zůstal na svém místě v rámci stránky. Není problém toho docílit pomocí odsazení odstavců a tabulátorů. Avšak protože text se čte po řádcích je třeba porušit pořadí elementů dané strukturou. Modrá čára značí, jak bychom museli prvky zapsat, pokud je budeme potřebovat všechny umístit do jednoho textového rámečku. Nestačí ovšem změnit jen pořadí elementů v levém panelu. Elementy by museli v tomto pořadí být zapsány i v souboru. Shodná struktura dokumentu a XML je totiž nutnou podmínkou pro automatické opakování obsahu v InD. Tagy by se navíc překrývaly. Například element vystavena by se musel nějakým způsobem octnout uprostřed elementů odberatel a adresa. Abych ilustroval, jak funguje automatická sazba záznamů, kdy každému připadá jedna stránka, musel jsem pro zachování struktury některé tagy zkrátka vynechat.

Šablona, připravená na import množiny faktur

59

Dobře si prohlédněme celý obrázek a popišme si rozdíly oproti předchozímu. Veškeré pozadí – obsah společný pro všechny stránky – je tentokrát umístěn ne do samostatné vrstvy, ale přímo do Master page. To z obrázku nepoznáme. Čtyři samostatné rámečky jsou nahrazeny jediným, kterému je přiřazen tag faktura. Všimněte si, že z výše uvedených důvodů nejsou slova „firma“ a „ičo“ nijak otaggovány. Tím se z nich stává statický text a při importu XML nebudou nahrazeny obsahem odpovídajícího elementu. Odkud kam sahají jednotlivé tagy lze dobře vidět ve Story editoru. Všimněte si především, že pořadí prvků skutečně odpovídá tomu, jak jsou zapsány v XML. Dále je třeba zmínit umístění tabelátorů a konců řádek mimo tagy s placeholder textem. Obsah tagu mesto má na rozdíl od ostatních odlišný odstavcový styl. Jediný rozdíl je v odsazení za odstavcem v hodnotě 180pt, které způsobí zobrazení položek faktury do správného místa. Velmi důležitý znak se nachází těsně před ukončovacím tagem faktura. Nachází se zde zlom stránky, který je ve Story editoru zobrazen malou tečkou. Ten způsobí korektní zahájení další faktury na nové stránce. Pokud do tohoto dokumentu naimportujeme XML s kořenovým tagem, který obsahuje několik elementů faktura, zobrazí se na první stránce korektně první faktura a další skončí jako tzv. „overset text“. Stačí vytvořit jednu další stránku a použít funkci autoflow. Výsledkem bude x stránkový dokument obsahující na každé stránce jednu fakturu. Máme přesně výsledek, který jsme si přáli. Tedy až na malé detaily … žádná faktura bohužel neobsahuje jméno firmy, ičo a datum vystavení. Při importu nesmíme zapomenout na označení voleb „Clone repeating text elements“ a „Do not import contents of whitespace-only elements“. Napadají mě možná řešení problému s různým pořadím elementů: velmi neelegantní, avšak funkční by bylo, předem dokument uzpůsobit zobrazovanému pořadí tagů pomocí XSLT. Mohlo by se podařit provést tak zběsilé formátování, že elementy by byly zapsány ve správném pořadí a zároveň se zobrazovali tam, kde je potřebujeme. Možná by k tomu šlo využít vícesloupcové sazby. Úplně nejlepší řešení, které by mohlo přijít s novou verzí programu, by dle mého názoru byl mechanismus, který by nějakým způsobem dovolil definovat vzájemné závislosti jednotlivých textových rámečků. Na příkladu ukážu co tím myslím: uvnitř plochy rodičovského textového rámečku, by mohl být umístěn druhý, který by byl definován jako potomek, ten by dál mohl samozřejmě obsahovat další potomky ať už ve formě otaggovaných rámečků 60

nebo textu. Tedy něco trochu podobného tomu, co nabízí Item Sequence QuarkXTension. Pokud se čtenáři povede tento oříšek nějakým zajímavým způsobem vyřešit, budu velmi rád, pokud se se mnou o řešení podělí. Přestože byl v pokus o vytištění sady stránek dokumentů o stejné struktuře v podstatě neúspěšný (bez transformace zdrojového XML), lze v mnoha případech postup dobře použít. Zejména za podmínky, že je obsah jednodušší a méně strukturovaný. Hodí se perfektně například pro tisk vizitek. Doufám, že se čtenář z tohoto problémového příkladu něco naučil a tisk mnoha vizitek jednoho vzoru by za použití tohoto návodu dokázal provést bez větších problémů.

Sazba DocBooku Jak již bylo řečeno výše, DocBook není nic jiného, než obyčejné XML. Lze tedy uplatnit veškeré postupy popsané v předchozí kapitole. Přesto má sazba DB svá specifika. DB bývá většinou poměrně dlouhý, dosti strukturovaný text. Z toho vyplývá nejdůležitější rozdíl: zřejmě si zde nevystačíme s prostým mapováním tagu na styl. Uvedu příklad: element title, může být v dokumentu použit na mnoha místech v různém kontextu. Jednak to bývá nadpis celého dokumentu. Kromě toho je tento element používán jako nadpis kapitol, příkladů, obrázků a v neposlední řadě například v bibliografických citacích. V této situaci jednoduché mapování na základě jména nedostačuje. Bylo by tedy vhodné zařídit určité přiřazení stylu v závislosti na kontextu. V této kapitole popíšu postup, jakým byla zalomena tato bakalářská práce. Přestože si nečiním nároky poskytnout zcela obecný návod na sazbu DB v InDesignu CS2, věřím, že mnou použité postupy se dají velmi dobře využít v mnoha dalších případech. Rád bych zdůraznil, že přestože se postupy mohou zdát na první pohled relativně nenáročné, cesta k řešení dílčích problémů nebyla vůbec jednoduchá. Například mi trvalo několik měsíců, než se mi podařilo úspěšně zkompilovat použité pluginy. Byl bych rád, kdyby někdo mnou naznačená řešení dále rozvinul k obecnějšímu použití. Náměty se pokusím sdělit v závěru kapitoly. V první polovině práce jste se mohli dočíst o důvodech, které mohou člověka vést k tomu, že nevyužije připravené XSL šablony pro automatický převod 61

DB do tiskového formátu. Pro pořádek znovu zopakuji, co k tomu vedlo mě. Důležitá je možnost zcela uzpůsobit vzhled individuálním požadavkům. Určitá customizace volně dostupných šablon je sice možná, ovšem neposkytuje dostatek možností ani jednoduchosti. Úprava šablon je zdlouhavá a v případě jednorázového projektu se jednoduše nevyplatí. Návrh vzhledu WYSIWYG je pohodlnější a rychlejší. Text, který právě čtete, vznikl původně ve formátu Simplified DocBook XML V1.1. Jedná se o zjednodušenou verzi „velkého“ DocBooku. Na rozdíl od něj není tato verze určena pro složité publikace (knihy), ale hodí se spíše pro články menšího rozsahu. Zdrojový text práce si můžete stáhnout z URL http://sorry.vse.cz/~xpera03/sklad/BP/DTPandXML.xml. Úvodní deklarace zdrojového textu bakalářské práce

Prvním problémem, se kterým se člověk při pokusu o import XML dokumentu potýká, je skutečnost, že InD nerozezná definici typu dokumentu tipu PUBLIC . Tento řádek říká, kde se nachází DTD aktuálního dokumentu a zápis tipu PUBLIC je alternativou k přímé specifikaci cesty k souboru DTD. Při pokusu o import takového dokumentu InD nabídne DTD zcela ignorovat, což se může zdát jako jednoduché a efektivní řešení. Ve zlomku sekundy ale narazíte na další problém – v DTD není definována pouze přípustná struktura elementů, jsou v něm obsaženy rovněž definice znakových entit a další prvky, bez nichž se neobejdeme. Jednoduchým řešením je stáhnout všechny potřebné soubory na lokální disk, a v dokumentu přepsat identifikátor na typ SYSTEM. Tento krok umožní data importovat za použití lokálního DTD (po zadání správné lokální cesty, kde je DTD uloženo). Každý musí uznat, že se jedná o krajně neelegantní variantu. Já jsem využil ukázkového kódu, který Adobe dodává s jejich InDesign CS2 SDK a připravil jsem pro vás plugin, umožňující interpretaci PUBLIC deklarací díky využití katalogových souborů. Soubor s pluginem si můžete stáhnout z http://sorry.vse.cz/~xpera03/sklad/BP/XMLCatalogHandler. pln. Pro instalaci je třeba soubor nakopírovat do složky Plug-Ins v adresáři instalace vašeho InDesignu verze CS2. Zavedení proběhne po restartu aplikace. Bohužel je třeba upozornit, že plugin bude fungovat pouze na platformě Windows.

62

Pro správnou interpretaci systémového identifikátoru zbývá vytvořit katalogový soubor a vhodně jej umístit. Aby byl soubor rozpoznán, musí se v každém případě jmenovat catalog.xcat. Jedna možnost umístění tohoto souboru je ve stejné složce, jako importovaný XML dokument. Pokud chcete mít katalogový soubor jen jeden, lze jej umístit do složky aplication data pro Adobe aplikace, podadresáře InDesign/Version 4.0. Ve druhém případě bude katalog načítán automaticky při startu aplikace bez ohledu na otevíraný XML dokument. Obsah souboru může být velmi jednoduchý. Jako příklad uvedu minimalistický katalog, který umožní načíst bakalářskou práci s výše uvedenou deklarací. Kompletní specifikaci katalogových souborů naleznete na adrese http://www.oasis-open.org/committees/entity/spec.html. Velmi jednoduchý katalogový soubor. Důležitý je atribut xml:base.

Na následujícím obrázku uvidíte, že výsledek importu není zdaleka ideální. Problémem jsou nadbytečné konce odstavců (při importu s aktivovanou volbou „Do not import contents of whitespace-only elements“ je výsledek ještě mnohem horší – zkuste si to). Další úprava dokumentu v tomto stavu by vyžadovala značné množství manuální páce. Mapování tagů na styly lze použít velmi omezeně – z důvodu složité struktury. Řešení obou naznačených problémů poskytuje další plugin. Ten umožňuje provést jednoduchou XSLT transformaci při importu dokumentu. Opět se jedná o program založený na ukázkovém kódu z SDK. Jde vlastně o sadu dvou pluginů. Ty si také můžete stáhnout z adres: http://sorry.vse.cz/~xpera03/ sklad/BP/XDocBookWorkflow.pln a http://sorry.vse.cz/~xpera03/sklad/BP/ XDocBookWorkflowUI.pln. Tento doplněk pro InDesign CS2 přidá podporu pro otevírání souborů s příponou .dcbk. Jestliže dojde k otevření souboru tohoto typu, plugin jej vloží do připravené šablony (.indt) a před samotným vložením ještě provede XSLT transformaci. Parametry těchto voleb se definují v novém menu Edit>Preferences>XDocBookWorkflowUI[locale].

63

První „úspěšný“ import do InD

V nastavení stojí za povšimnutí především dvě textová pole. První z nich specifikuje cestu k .indt šabloně, do níž bude otevíraný soubor vložen. Na tuto šablonu nejsou kladeny žádné speciální požadavky, je ale žádoucí, aby obsahovala vhodné odstavcové a znakové styly. Na mnou použitou šablonu se podíváme podrobněji dále. Druhé textové políčko specifikuje XSL šablonu, pomocí níž bude provedena vstupní transformace. Pokud není zaškrtnuta volba „Above XSL file overrides processing-instruction“, lze šablonu definovat také přímo ve vstupním souboru procesní instrukcí. Další volby doporučuji ponechávat beze změny. Začátek souboru s definovanou vlastní XSL šablonou

64

Nastavení pluginu XDocBookWorkflow

Před importem souboru je vhodné zmínit několik technických podrobností. Za prvé je důležité, přejmenovat příponu souboru na .dcbk. Jedině tak dojde k aktivaci pluginu. Dále je důležité, že plugin importuje soubory včetně bílých znaků. Tzn. s nezaškrtnutou volbou „Do not import contents of whitespaceonly elements“. Praktickým důsledkem je to, že se do InD může dostat množství nežádoucích tabulátorů, mezer a znaků konce odstavce. I když se opět nejedná o příliš elegantní řešení, je vhodné soubor na import připravit. Doporučuji vymazat veškeré mezery, tabelátory a entery mezi tagy. Soubor by samozřejmě měl zůstat validní. O vložení znaků konce řádku na potřebná místa se následně postará XSL šablona. Možná vás napadlo, k čemu je vlastně dobré soubor při načtení transformovat pomocí XSLT. Kromě funkce vložení konců řádku na správná místa, plní šablona především funkci přiřazení stylů dle kontextu. Ptáte se, jak může XSL šablona přiřazovat odstavcové styly v InDesignu? Naštěstí to jde. Umožňují to speciální XML atributy ze jmenného prostoru aid:. Pokud netušíte, co to jmenné prostory jsou, mohu vás uklidnt: bez této znalosti se obejdete. Šablona provede zápis atributů automaticky za vás, včetně správné deklarace jmenného prostoru. Pokud zvídavost přece jen zvítězí, lze nalézt 65

Jde o drobnosti, které ovšem dokážou hodně ulehčit práci. Použití takovéto šablony má však jednu velkou nevýhodu: soubor při otevírání do InDesignu není validní dle standardního DTD. V konkrétním případě za to může zejména změna pořadí elementů. Ta je ovšem nevyhnutelná, protože InDesign vkládá elementy do dokumentu přesně v tom pořadí, jak jdou v souboru za sebou.

základní informace o problematice například na adrese: http://interval. cz/clanky/kompletni-pruvodce-xslt-jmenne-prostory/ Začátek souboru s definovanou jmenným prefixem aid: <article lang=”cs” xmlns:aid=”http://ns.adobe.com/AdobeeInDesign/4.0/”>



Tato skutečnost má poměrně nepříjemné důsledky: soubor není možné po úpravách zpětně exportovat do XML. Tedy možné to je, ale výsledkem bude nevalidní dokument. To prakticky znemožňuje round-tripping. Jednoduše nebude možné provést změny obsahu v InD a ty následně vyexportovat zpět do zdrojového XML dokumentu. Do InD je tedy nutné poslat konečnou verzi dokumentu. V opačném případě se nevyhneme dvojímu opravování změn. Nepochybuji o tom, že řešení tohoto problému existuje, jeho hledání přenechám někomu jinému. Pro můj účel není zpětného exportu třeba.

Pro naše účely jsou nejdůležitější atributy aid:pstyle a aid:cstyle. Zatímco první jmenovaný určuje název odstavcového stylu v InD, druhý slouží ke specifikaci stylu znakového. Díky možnosti provedení transformace před importem dokumentu a díky existenci těchto atributů, je možné uplatnit kontextové stylování dokumentu. Ukázka přiřazení odstavcových stylů v závislosti na kontextu

<para>Toto je nejvyšší úroveň a nadpisu byl přiřazen odstavcový styl hlavni_titulek. ... <para>Toto je podřízená sekce a nadpisu byl přiřazen styl podtitulek ..



  



Jmenný prostor nabízí ještě další atributy. Slouží pro formátování tabulek. InDesign dokáže ale standardní XML tabulky rozpoznat bez problému, nemusel jsem tedy tyto atributy použít. Pro pořádek je alespoň vyjmenuji: table, trows, tcols, theader, crows, ccols, ccolwidth, tfooter. Další atributy se týkají psaného japonského textu, takže je ani nebudu zmiňovat. Pro bližší informace o užití všech těchto atributů doporučuji nastudovat [XMLref ].

1. 2. 3. 4.

66



Myslím, že nemá smysl podrobně se rozepisovat o použité XSL šabloně. Kompletní soubor je k nahlédnutí na adrese: http://sorry.vse.cz/~xpera03/ sklad/BP/DB-template.xsl. Shrnu pouze funkce, které šablona plní: Přiřazení správného odstavcového a znakového stylu v závislosti na kontextu Vložení znaku konce odstavce na vhodná místa Převod elementu quote na typografické uvozovky Upravení pořadí elementů. Např. umístění elementu attribution na konec citace.

 



Poslední potřebnou součástkou je .indt šablona dokumentu. Na ní nejsou kladeny přehnané speciální nároky. Doporučuji provést následující: při tvorbě šablony by neměly být aktivní incopyworkflow pluginy a xmedia balíček pro GoLive/UI ze souboru DTD nebo přímo z XML dokumentu načíst všechny tagy umístit na stránce „master text frame“ smazat standardní kořenový tag root, místo něj vložit skutečný kořenový element (article) a ten přiřadit hlavnímu textovému rámečku vytvořit dostatečné množství odstavcových a znakových stylů, které ve vhodných případech jménem odpovídají použitým elementům. K tomu důrazně doporučuji načíst styly z mnou poskytnuté šablony a následně provést jen jejich úpravu provést mapování tagů na styly je velmi užitečné vytvořit několik úvodních stránek a jednotlivé textové rámečky vzájemně spojit do jednoho „story“.

Ukázkovou šablonu, pomocí níž byl zalomen tento dokument naleznete ke stažení na adrese: http://sorry.vse.cz/~xpera03/sklad/BP/DB-templateA5.indt. Zrekapituluji, co vše­chno po­třebujeme mít připraveno k  importu DocBooku do aplikace. Nejdůležitější je validní XML dokument s příponou .dcbk. Dokument by neměl obsahovat znaky konce řádků a další formátovací znaky. Dále jsou třeba úspěšně zavedené tři výše jmenované pluginy. Plugin XMLCatalogHandler je nepovinný, lze nahradit lokálním umístěním DTD a deklarací typu SYSTEM. Na lokálním disku musí být dále k dispozici vhodná XSL šablona a .indt šablona. Umístění těchto dvou souborů se nastaví pomocí pluginu XDocBookWorkflowUI. Hodí se ještě poznamenat, že vše je vyzkoušené ve verzi programu Adobe InDesign CS2 4.0.3 67

Nyní by konečně nemělo stát nic v cestě importu. Jsou dvě možnosti jak to provést – buď pomocí drag&drop do prázdného okna aplikace, nebo klasicky přes menu File>Open.



 

Na URL http://sorry.vse.cz/~xpera03/sklad/BP/prvniimport.pdf si můžete prohlédnout úvodních několik stránek dokumentu, který získáme prostým vložením XML dokumentu do programu. Na to, že se jedná o výstup bez jediné manuální úpravy, je výsledek vcelku příjemně uspokojivý. Všimněte si zejména: znaky konce odstavce jsou na správných místech (některé elementy v hlavičce souboru jsou bez mezery slity k sobě – vzhledem k jedinému výskytu těchto elementů v dokumentu je jednodušší provést jejich formát ručně, než složitě upravovat XSL styl) odstavce mají přiřazeny správné odstavcové i znakové styly prázdné stránky nejsou chybou, ale jsou způsobeny nastavením začátku odstavce „title“ na nové sudé stránce. Veškeré soubory potřebné k provedení tohoto importu máte k dispozici na adrese http://sorry.vse.cz/~xpera03/sklad/BP/. V případě, že by toto umístění již nefungovalo, mělo by být možné nalézt mirror všech souborů i na adrese http://adam.sluchatka.net/BP/.







68

Přestože je získaný výsledek velice slušný, nevyhneme se spoustě manuální práce. Nebudu detailně popisovat veškeré kroky, které jsou potřeba udělat. Cílem není poskytnout návod formátování textu v InDesignu. Pouze stručně shrnu nejdůležitější úpravy, které bylo potřeba provést k dosažení finální úpravy. Nemyslím, že je třeba zabíhat do zbytečných detailů Někdy dojde k přerušení „story“ vznikajícího v rámci autoflow. To se děje spíše náhodně a způsobí to občas příliš velký obrázek. Funkčním řešením je ve „story editoru“ umazat tento element a grafiku vložit manuálně. Pro dobrou funkci autoflow není špatné mít v okamžiku importu obrázků grafiku zmenšenu – obrázky jsou pouze linkovány, takže následně je možné je nahradit verzí v plném rozlišení. „Story editor“ je vůbec velmi užitečný pohled na dokument, který doporučuji používat v případech, kdy je třeba se zorientovat v elementech. Musí být nastavena volba Show Tag Markers. Některé obrázky se přesto nenačtou korektně. Můj InDesign neumí pracovat se soubory SVG. Je třeba tuto grafiku vložit ručně. Ostatní grafika se vkládá sice automaticky, ovšem nikoli ideálně. Grafika je vkládána jako anchored object, což ve spojení s jejich velikostí často spíše na obtíž. Obrázky je možné uvolnit například tak, že je označíme a zvolíme Cut a následně Paste zpět do dokumentu.

 

Obsah a index je třeba vygenerovat za pomocí InD Plugin bohužel korektně neinterpretuje odkazy. V InD nedojde k jejich automatickému vytvoření. V případě potřeby je nutno ručně odkazy zadat pomocí paletky Hyperlinks. Vidíte, že manuální práci se zcela nevyhneme. To ovšem ani nebylo cílem. Pokud bychom chtěli text vysadit zcela automaticky, nepotřebovali bychom InDesign a zřejmě bychom si vystačili s XSLT transformací.

 

  

 





 

Nejlepším důkazem, že popsaný postup skutečně funguje je tento text. Problém sazby DocBooku a XML obecně v Adobe InDesignu ovšem přesto nepovažuji za zcela vyřešený. Komplexní vyřešení detailů by mohl být zajímavý námět na další absolventskou práci. Úpravu si zaslouží především následující detaily: korektní vkládání vnitřních i vnějších odkazů možnost zobrazení atributů v dokumentu a celkově lepší práce s nimi (například vysouvací menu s možnými hodnotami). Metoda vložení prázdných elementů zlepšení vkládání grafiky na správné místo roundtripping, možnost exportu (XSL transformace i při exportu?) vložení XML v režimu „link“ – čili umožnění automatické promítnutí pozdějších úprav zdrojového dokumentu správná interpretace bílých znaků lepší spolupráce s vestavěnými nástroji aplikace pro automatické generování obsahu, indexů, seznamů, poznámek atp... možnost vložit zlom stránky ve formě elementu nebo procesní instrukce (v současnosti to je možné pouze přiřazením odstavcového stylu se začátkem na nové stránce) export InD poznámek například ve formě XML komentáře. Stejně tak chybí export XMP metadat lepší podpora standardu XSLT zjednodušení kontextuálního mapování stylů, ideálně bez nutnosti použít XSLT Pokud by se někomu podařilo vytvořit skutečně komplexní řešení veškerých zbylých problémů, pak by se tento balíček mohl stát úspěšným komerčním produktem. Nástroje, které mají podobné možnosti na trhu existují, jejich cena se však pohybuje minimálně v řádu tisíců dolarů. Uvidíme, co přinese budoucí verze programu InDesign CS3, jejíž plánované uvedení je v první polovině roku 2007. V dosavadních zprávách o nových vlastnostech aplikace se zatím o XML bohužel mlčí. Že by poptávka po této funkcionalitě byla opravdu zcela mizivá? 69

Závěr

verzích celkem snadno a dobře použitelné, stále je třeba řešit spoustu detailů, které zpomalují práci.

„Velmi hezké,“ řekla Alenka, když dočetla, „ale tak

trochu nesrozumitelné“.

— Lewis Carrol – Za zrcadlem, a s čím se tam Alenka setkala

Největší překážku průniku XML do dnešní DTP praxe paradoxně nespatřuji v technických problémech, ale spíše v uživatelích samotných. V dnešní situaci existuje sotva promile klientů, kteří jsou schopni dodat podklady v XML. Od toho se samozřejmě odvíjí ochota grafických studií učit se tyto technologie. XML sice nabízí mnoho možností, na druhou stranu od obsluhy také hodně požaduje. Pro nezasvěceného člověka se může zdát problematika všech souvisejících technologií příliš komplexní a neproniknutelná. Důležitým aspektem je také chronický nedostatek času pracovníků v polygrafickém průmyslu. Potvrzením tohoto stavu je velmi malé množství praktických zkušeností, zveřejněných na internetu. Správně jsem předpokládal, že neexistuje velké množství materiálů v českém jazyce. Ale takový nedostatek i anglických textů mě skutečně překvapil. Například vyhledávač google nalezne pouhých 17.500 stránek obsahujících slova „docbook indesign xml“. Pro srovnání: – dotaz „indesign word“, vrátí cca 4 milióny odkazů.

70

Bakalářskou práci jsem v určitém smyslu pojal jako „osvětu“ pro grafické pracovníky. V první polovině textu se soustředím na vysvětlení základních principů a hlavních výhod formátu XML a DocBook. Často si totiž všímám, že grafikům zcela uniká smysl a výhoda uložení textu v této formě a XML nevnímají jako pomocníka. Bakalářská práce srovnává možnosti tří současných programů a detailně se věnuje zejména nejpopulárnějšímu z nich – Adobe InDesignu CS2. Na praktickém příkladě jsem demonstroval import i export XML dat v tomto programu. Přestože jsem se snažil upozronit na problémy, které se v průběhu postupu mohou vyskytnout, nekladu si za cíl poskytnout úplné řešení všech z nich. Zvláštní pozornost jsem věnoval kapitole, která popisuje sazbu dokumentu pořízeného ve formátu Simplified DocBook. Předkládám konkrétní popis kroků a problémů, se kterými jsem se potýkal během předtiskového zlomu tohoto konkrétního textu . Podobných materiálů je mizivé množství, v českém jazyce jsem nenašel žádný. Míru úspěchu můžete posoudit sami nad výtiskem, který právě držíte v ruce. Přestože stále existuje značné množství prostoru pro zlepšení dílčích částí procesu, je celkový výsledek poměrně uspokojivý.

Zdálo by se, že spolupráce těchto dvou technologií nalezne širší uplatnění alespoň v případě velkých společností. Pro ně je důležitým faktorem spolehlivost, rychlost a bezproblémovost, naopak není kladen takový důraz na finance. Ve velkých společnostech se tak k publikování XML skutečně často využívá, ovšem s použitím specializovaných nástrojů, vytvořených často přímo na míru pro potřeby podniku. Cena takoých řešení je z pohledu malého grafického studia vpravdě astronomická.

Text přináší alternativní pohled na pomezí dvou oborů, a obávám se nebezpečí, že se nesetkám s pochopením ani na jedné straně. Zatím dostávám spíše odmítavé reakce od grafických pracovníků, stejně jako od znalců XML. Typickým argumentem první skupiny je nedůvěra v jakékoli automatizované řešení a fakt, že klienti stejně nikdy nebudou schopni dodat podklady v XML. Na druhé straně, lidé věnující se XML často nedokáží pochopit, jaký má vůbec smysl text manuálně zpracovávat. Hlavní výhodou XML by přece mělo být automatizované zpracování. To poskytuje dle názoru dostatečně kvalitní výstup. Všechna tato stanoviska plně akceptuji, nicméně stále trvám na tom, že scénář „polo-automatické sazby“ může přinést v mnoha situacích výhody oproti oběma řešením.

Technická řešení v aplikacích pouze zrcadlí nedostatek poptávky. I přes dlouholetou podporu v programech jsou tyto funkce používány jen okrajově a pro vývojáře tak přestávají být prioritou. Přestože je XML v moderních

Doufám, že se najde několik grafických pracovníků, kteří jsou natolik progresivní, že se nebojí hledat neprošlapané cestičky. Nechť jim tento text slouží nejen jako praktický návod, ale i inspirace k dalším moderním postupům.

71

Literatura gr-publikovani: Krejčí, R.: Publikování z XML: výhody nebo trable? [online]. Grafika On-line, 2005. Dostupný z WWW: http://ww w.grafika.cz/art/polygrafie/xmlpol.html [23.4.2006]

FMfaq : Adobe: Framemaker 7.2 and XML Publishing [online]. Adobe Systems Incorporated, 2005. Dostupný z WWW: http://www.adobe.com/products/framemaker/pdfs/faq_xml.pdf [24.4.2006]

xmlprokazdeho: Kosek, J.: XML pro každého: podrobný průvodce . Praha: Grada, 2000, 164s, ISBN: 80-7169-860-1. Dostupný z WWW: http://www. kosek.cz/xml/xmlprokazdeho.pdf [23.4.2006]

XMLref: Adobe: Adobe InDesign CS2 and XML: A Technical Reference [online]. Adobe Systems Incorporated, 2005. Dostupný z WWW: http://www.adobe. com/products/indesign/pdfs/InDesign_and_XML_Technical_Reference.pdf

[22.8.2006] gr-XmlaID: Krejčí, R.: XML a InDesign: užitečná nebo zbytečná kombinace? [online]. Grafika On-line, 2003. Dostupný z WWW: http://www.grafika. cz/art/sazba/indcsxml.html [23.4.2006] uvodxml1: Krejčí, R.: Jemný úvod do jazyka XML (I) – Proč právě XML? [online]. Grafika On-line, 2001. Dostupný z WWW: http://www.grafika. cz/art/webdesign/uvodxml_1.html [23.4.2006] uvodxml2: Krejčí, R.: Jemný úvod do XML (II) – Základy syntaxe [online]. Grafika On-line, 2001. Dostupný z WWW: http://www.grafika.cz/art/webdesign/xml2.html [23.4.2006] uvodxml3: Krejčí, R.: Jemný úvod do XML (III) – Definice typu dokumentu [online]. Grafika On-line, 2001. Dostupný z WWW: http://www.grafika. cz/art/webdesign/xml3.html [23.4.2006] tdg: Walsh, N.: DocBook: The Definitive Guide . Sebastopol: O’Reilly, 1999. 664s. Dostupný z WWW: http://www.docbook.org/tdg/en/tdg-en-2.0.12. chm[23.4.2006], http://www.docbook.org/tdg/en/html/docbook.html [23.4.2006] DBUvod: Kosek, J.: DocBook – Stručný úvod do tvorby a zpracování dokumentů [online]. 2003. Dostupný z WWW: http://www.kosek.cz/xml/db/ [24.4.2006] FrameMaker: Whitlatch, S.: Structured FrameMaker 7.1 DocBook XML 4.4 Project [online]. 2005. Dostupný z WWW: http://www.getnet.net/~swhitlat/ DocBook/docbook_section.html [24.4.2006]

72

FMtips: Adobe: XML Tips and Techniques in Adobe FrameMaker 7.2 [online]. Adobe Systems Incorporated, 2005. Dostupný z WWW: http://www.adobe. com/products/framemaker/pdfs/FM_XML.pdf [24.4.2006] FM_XSLT: Adobe: Using XSLT in Adobe FrameMaker 7.2 [online]. Adobe Systems Incorporated, 2006. Dostupný z WWW: http://www.adobe.com/products/framemaker/pdfs/fm7ip_usingxslt.pdf [12.5.2006] strFM: Adobe: Migrating from Unstructured to Structured FrameMaker [online]. Adobe Systems Incorporated, 2005. Dostupný z WWW: http://www. adobe.com/products/framemaker/pdfs/migrationguide.pdf [13.5.2006] pavlovic: Pavlovič, J.: Návod k modulu xslt2 [online]. Brno: Masarykova univerzita, Fakulta informatiky, 2006. Dostupný z WWW: http://www.fi.muni. cz/~xpavlov/xml/ [31.7.2006] edson: Edson, M.: Having Your Layout and Your XML Too: Deriving XML Content From Adobe InDesign [online]. Really Strategies Newsletter, 2005. Dostupný z WWW: http://www.reallysi.com/newsletter18_1.htm [1.8.2006] dunn: Dunn, S.: Real-world Case Studies: Getting XML From Adobe InDesign Layouts for Repurposing: Deriving XML Content From Adobe InDesign [online]. Adobe Systems Incorporated, 2005. Dostupný z WWW: http://media. studio.adobe.com/linked_content/en/indcs2bgrealxml/indcs2bgrealxml.pdf

[8.8.2006]

73

Terminologický slovník API

GUI „Application Program Interface“ neboli aplikační programové rozhraní. Definice ovládacích prvků a způsobu komunikace programu, kterou často využívají ostatní programy

CMS

Zkratka Graphic User Interface. Způsob a popis komunikace uživatele s počítačem, spočívající v tom, že maximum ovládacích prvků je prezentováno na obrazovce počítače. JPEG

Zkratka pro „Content Management System“. Termín označuje systém, zajišťující správu obsahu dokumentů v mnoha uživatelském prostředí. Základní funkcí bývá správa verzí a synchronizace úprav

Oblíbený formát uložení obrázků komprimovaný ztrátovým algoritmem. OS X Operační systém, používaný na počítačích Mac, který je hojně využíván DTP profesionály.

CMYK Zkratka čtyř anglických barev pomocí nichž lze namíchat libovolný odstín. Používá se pro označení barevného režimu používaného pro profesionální tisk. Cross-media publishing Zveřejnění stejného obsahu na více médiích, typicky v tištěné a internetové formě. DITA Zkratka znamenající „Darwin Information Typing Architecture“ označuje architekturu založenou na XML pro tvorbu a publikování technických informací a uživatelské podpory. Technologie byla vyvinuta společností IBM. DTD Definice typu XML dokumentu. Soubor, ve kterém jsou definovány veškeré elementy atributy a entity XML souboru a možné vztahy mezi nimi. Alternativou pro vyjádření této informace jsou XML Schema či Relax NG schema. Splňuje-li XML soubor všechny požadavky definované DTD dokumentem, říkáme, že je validní. DTP Zkratka slov „Desktop Publishing“. Používá se ve významu publikační činnosti prováděné za podpory počítače EDD „Element Definition Document“, obdoba DTD pro aplikaci FrameMaker. FDK FrameMaker Developer Kit. Balík umožňující doprogramovat funkcionalitu do programu Adobe FrameMaker GIF Způsob uložení bitmapových obrázků s bezztrátovou kompresí

74

PDF Zkratka slov Portable Document Format. Formát pro přenositelnost dokumentů s potenciálním složitým layoutem (grafické elementy, písma, obrazové a textové rámce atd.), vytvořený firmou Adobe. SGML Obecný metajazyk, výchozí pro veškeré další jazyky typu markup. Součást široké rodiny těchto jazyků je i XML. Tag Nejbližší překlad tohoto termínu je „štítek“. V tomto textu je tento termín používán ve smyslu XML tag, což je značka, označující zahájení či ukončení elementu. Někdy se tohoto slova používá přímo ve významu samotného elementu. Typickým příkladem tagu je text <para>. validita viz DTD well-formed dokument XML dokument, který splňuje veškeré formální požadavky jazyka XML. Dokument musí mít např. všechny tagy korektně uzavřeny a nesmí obsahovat některé speciální znaky na nevhodných místech. WYSIWYG Zkratka znamenající „what you see is what you get“. Označují se jí programy na zpracování textu, které dokument zobrazují přesně tak, jak bude vypadat na výsledném médiu (na papíře, příp. na internetu) XHTML XML jazyk používaný na internetu pro zápis webových stránek.

75