XML az alanyi költészetben II. 2004. év 22. szám A FrameMaker ismertetése a strukturált felülettel folytatódik: mit strukturáljunk, mikor, mivel, jó lesz-e az nekünk, hogyan verseljünk XML-ben, miért írjunk vastag könyveket Múlt hónapban csak érintőlegesen említettem, hogy a FrameMaker 7.1 meg tudja nyitni a QuarkXPress 3.3 és a későbbi verziók állományait. Azóta ezt ki is próbáltam, tapasztalataim alapján pedig nem javaslom a nyájas olvasónak, hogy FrameMakerrel QuarkXPress-állományokat próbáljon megnyitni. Valamelyik világlapban ugyan azt olvastam, hogy a FrameMaker 7.1-be az InDesign input szűrőit építették, viszont aki ezt leírta, nyilván nem bizonyosodott meg arról, hogy igaz-e, amit állít. Pedig az eljárás egyszerű: fogok egy QXD-állományt, megnyitom az InDesignban is meg a FrameMaker 7.1-ben is, aztán a két eredményt összevetem. Meg fogok lepődni, mert egymásra még csak nem is hasonlítanak. Az előző részben tehát áttekintettük a "strukturálatlan" FrameMaker 7.1 jellemzőit, vagy legalább a fontosabbakat. Nem esett szó például interline text nevű érdekes szolgáltatásról, mégpedig azért nem, mert a helpben ennek a lehetőségnek egyáltalán nincs nyoma. Létezéséről egy amerikai szaklapból szereztem tudomást, ki akartam próbálni, de kiderült, hogy az online dokumentáció erről a dologról sohasem hallott. Végül aztán rájöttem, hogy a FrameMaker 7.1 saját könyvtára alatt van egy samples nevű alkönyvtár, a samples alatt egy MoreSamples alkönyvtár, a MoreSamples alatt egy Special alkönyvtár, abban pedig van egy Interlin.fm nevű állomány. Megnyitottam, és megtudtam belőle, hogyan megy ez. Úgy megy, hogy kijelölöm a fordítandó szöveg minél kisebb egységét, mondjuk egyetlen szavát, leütöm a megfelelő billentyűkombinációt, ennek eredményeképp a kijelölt szó körül képződik egy kétsoros textbox, az alsó sorban van az eredeti szó, fölé beírhatom a fordítást. Utána pedig csakugyan olvashatunk a sorok között ­ nem úgy, mint az Istenben boldogult létező szocializmus idején, hanem de facto. Nyelvkönyv írásánál (főleg valamilyen egzotikusabb nyelv esetében) ennek az opciónak nagy haszna van. Eredetileg nyilván nem az Interlin.fm után nyomoztam ­ azt se tudtam, hogy van ilyen ­, hanem valamifajta konfigurációs állományt vagy állományokat reméltem föllelni. Múlt hónapban írtam, hogy a FrameMaker 7.1 egyáltalán nem konfigurálható. Van ugyan egy Preferences menüpontja, de amit ott találunk, az alig több a semminél. A helpben konfigurálásról egy árva szó sem esik. Viszont egy idő után úgy éreztem, ez így egyszerűen nem lehetséges, kell, hogy legyen valami megoldás, rejtekajtó, mifene. És csakugyan, az FMHome könyvtárban és alkönyvtáraiban egész halom inicializáló állomány lapul, ini vagy cfg kiterjesztéssel, ezeket lehet okszerűen szerkesztgetni, és akkor mindenféle érdekes dolog történik. Leginkább az FMHome.cfg állomány tarthat számot az érdeklődésünkre, ott lehet például megváltoztatni a gyorsbillentyűket meg az efféléket ­ egyszóval a FrameMaker csakugyan Unix-alkalmazás, le se tagadhatná, hiába visel Windows-göncöket, a színfalak mögött ma is úgy viselkedik, mint a régi szép időkben Unix alatt. Csak hát Unix alatt a dolgozó tudja, hogy minden alkalmazáshoz különféle konfigurációs fájlok tartoznak, és ezek célirányosan bütykölhetők. Windows alatt ilyesmi eszébe se jut. Strukturálni vagy nem strukturálni Nyomdakész állapotba hozott művünk egyidejűleg publikálható könyvben, cédén, weben, HTML-, XML- vagy PDF-formátumban, ad abszurdum akár WML-ben, akkor is, ha előállításához a FrameMaker 7.1 gyalogos ­ nem strukturált ­ megjelenési formáját választottuk. Természetesen dolgozhatunk a strukturált változattal is, bár az kétségkívül macerásabb. Ami azt illeti, elég nehéz rájönni, mért jó az nekünk, ha a strukturált FrameMakerrel birkózunk, mint Jákob az angyallal; erre vonatkozólag leginkább azt a magyarázatot kapjuk, hogy a strukturált dokumentum egyidejűleg publikálható könyvben, cédén, weben, HTML-, XML- vagy PDF-formátumban, ad abszurdum akár WML-ben is. Tehát megvannak mindazon áldásos tulajdonságai, amelyek egyébként a strukturálatlan dokumentumnak is megvannak. Mindent egybevetve úgy gondolom, hogy a szokványos körülmények között dolgozó és szokványos könyveket tördelő tipográfusnak soha az életben nem lesz szüksége arra, hogy a FrameMaker strukturált változatát indítsa el. Ha viszont a feladat, mondjuk, a Gutenberg-projekttel esik egy súlycsoportba, akkor célszerű lehet az XML-t választani, esetleg az XML egy konkrét alkalmazását, a TEI-t. A TEI (teljes nevén a Text Encoding Initiative) kifejezetten humán tárgyú szövegek rögzítésére és publikálására való, felhasználói között van például a Cambridge University Press, a Digital Dictionary of Buddhism, az Electronic Text Archive Leiden, az English Poetry Full-Text Database, az Oral History Online, az Oxford Text Archive és a Neumann-ház. Egyébként a Text Encoding Initiative honlapján találunk egy olyat, hogy "TEI-Specific tools", vagyis szoftvereszközök TEI-dokumentumok létrehozására és szerkesztésére, közöttük a legelső helyen áll a GNU Emacs + nXML major mode, amiről februárban volt szó ugyanitt. Viszont a GNU Emacs + nXML segítségével sohase fogunk nyomtatott könyveket tördelni, úgyhogy továbbra is a FrameMaker 7.1 mellett maradunk. Anyám tyúkját kódolom Nyájas olvasóm minden bizonnyal tudja, mi az az XML, vagy ha mégsem, akkor nem tőlem szeretné megtudni. Már csak azért se, mert a világhálón e tárgyban jobbnál jobb anyagok találhatók. Az XML mibenléte egyébként három perc alatt felfogható, lényege ugyanis épp az egyszerűségében rejlik. Jelölő nyelv, mint a HTML, azzal a különbséggel, hogy a HTML címkéi valamely szövegrész megjelenítésére vonatkozó parancsot írnak le, az XML-címkék vi-szont a szövegrész tartalmára referálnak. A HTML ilyen: ­i­szövegrész­/i­, ahol a szövegrész lehet idézet, tulajdonnév, anyázás és még sok minden egyéb, nem tudjuk meg, micsoda, viszont dőlt betűvel fog megjelenni. Az XML-ben az van, hogy ­anyázás­ szövegrész ­/anyázás­, amiből egyértelműen kitetszik, miről szól a jelölt szövegrész, viszont a megjelenítéséről egyelőre nincs szó, arra vonatkozólag később intézkedünk, ha intézkedünk egyáltalán. Az XML tehát metanyelv abban az értelemben, hogy nem a nyelven kívüli realitásra, hanem magára a nyelvre referál, de metanyelv abban az értelemben is, hogy kész címkekészlete nincs. Az XML szabvány valójában azt definiálja, hogyan tudunk valamely konkrét célra alkalmas konkrét jelölő nyelvet létrehozni. XML-ben minden leírható, tetszés szerinti méretű adatbázisok, vektorgrafikák, vagy akár versek, a leírás pedig megkapóan egyszerű. Nézzük csak: ­POEM­ ­TITLE­Anyám tyúkja ­/TITLE­ ­AUTHOR­ ­FIRSTNAME ­Sándor­/FIRSTNAME­ ­LASTNAME ­Petőfi­/LASTNAME­ ­/AUTHOR­ ­STANZA­­LINE N="1"­Ej, mi a kő! tyúkanyó, kend­/LINE­ ­LINE N= "2"­A szobában lakik itt bent?­/LINE­ ­/STANZA­ ­/POEM­. Betűtípusokról és effélékről az XML nem beszél, ha ez is fontos, akkor írok külön egy stíluslapot, amire a dokumentum elején hivatkozom: ­?xml-stylesheet type="text/xsl" href= "anyamtyukja.xsl"?­. Most már van tehát egy XML-állományom, sok ilyen XML-állomány pedig verseskötetet ad. A verseskötet egy erősen strukturált dokumentum, amennyiben ciklusokra tagolódik, a ciklusok versekből, a versek versszakokból, a versszakok pedig sorokból állnak. Vagyis a verseskönyv fastruktúrát mutat, az XML pedig matematikai fastruktúrák leírására való, ennek megfelelő a nyelvtana is. Mint már tisztáztuk, én döntöm el, hogy milyen címkéket fogok alkalmazni, viszont deklarálnom kell őket, célszerűen egy külön állományban (DTD-ben), amelyre szintén a dokumentum elején hivatkozom. Mielőtt azonban ennek nekilátnék, eszembe juthat, hogy nem én vagyok az első ezen a világon, aki egy verseskönyvet XML-köntösbe öltöztet, tehát nyilván vannak kész dokumentumtípus-deklarációk, röviden DTD-k, azaz a leghelyesebb, ha fogok egy kész példányt, és használom. A föntebb már említett TEI voltaképp kész DTD-ket jelent, eltekintve most attól az apróságtól, hogy valamely XML-dokumentum nyelvtanának meghatározására három út kínálkozik, az egyik a DTD, a másik a séma (XSD), a harmadik pedig a Relax NG (RNG), és a TEI erősen preferálja a harmadikat. A további részleteket lásd a világháló megfelelő helyein, itt elég annyi, hogy a FrameMaker 7.1 a három módszerből a legelsőt, vagyis a DTD használatát támogatja. Földereng az új EDD Fentebb láttuk, hogy az XML egyszerű szövegállomány, amely szükségképpen egyszerű szövegszerkesztővel, mondjuk a Notepaddal is előállítható. Persze a sok-sok címke beírogatását nagyrészt lehet automatizálni, erre való a például a Microsoft XML NotePad (http://www .snapfiles.com/get/xmlnotepad.html, ingyenes, de a Microsoft már nem támogatja) és még vagy pár tucat különféle alkalmazás, ezekről egy más alkalommal. A FrameMaker 7.1-ben az a szép, hogy az XML-szerkesztő és az abszolút profi könyvtördelő alkalmazás képességeit egyesíti; ilyen több nincs. Persze ennek megvannak a maga vonzatai. Alapesetben ­ tehát mondjuk a Notepad használatával ­ XML-állományt úgy hozunk létre, hogy leülünk az üres képernyő elé, és írjuk szépen, hogy ­?xml version="1.0" encoding="utf-8"?­, utána pedig ami eszünkbe jut. A FrameMaker 7.1 használata mellett nem megyünk fejjel a falnak, hanem megadjuk a módját, vagyis mindenekelőtt a szükséges XML-alkalmazást fogjuk létrehozni. Lássuk, hogyan. A különféle dokumentumtípusoknak (mint például szoftverdokumentáció, szakácskönyv, verseskötet, királydráma, családregény stb.) van egy jellemző adatszerkezetük és nyilván lesz egy ehhez tartozó címkekészletük, ezt együtt XML-alkalmazásnak nevezik. Másképpen fogalmazva az XML-alkalmazás az XML-szabványnak megfelelően kialakított konkrét jelölő nyelv. Esetünkben ennél bonyolultabb a helyzet, lévén a FrameMaker 7.1 eredendően egy sablonvezérelt kiadványszerkesztő program, nem pedig XML-editor. A dokumentáció azt mondja ezzel kapcsolatban, hogy a FrameMaker az XML bonyodalmait "elrejti a felhasználó elől". (A dokumentációk általában szeretnek ilyeneket mondani, pedig ettől a sokat próbált felhasználó rögtön gyanakodni kezd, az esetek többségében joggal.) Valójában a helyzet fordított: a FrameMaker éppenséggel azt a látszatot iparkodik kelteni, mintha XML-t szerkesztenénk, noha valamenynyien tudjuk, hogy erről szó sincs. Már csak azért sincs, mert hiszen mi magunk, a két dolgos kezünk munkájával hozzuk létre azokat az állományokat, amelyek a FrameMaker számára (az adott konkrét dokumentumra vonatkozólag) az XML írás-olvasás szabályait meghatározzák. Tehát: a FrameMakerben nem XML-állományt szerkesztünk, de amikor elkészült ­ vagy amikor úgy látjuk jónak ­ perfekt XML-állományként tudjuk exportálni. Viszont ehhez létre kell hoznunk egy úgynevezett XML-alkalmazást, és ez most egy hangyányival összetettebb művelet lesz, mintha nekiállnánk XML-állományt fogalmazni a GNU Emacsben, mint az állat. Mindenekelőtt kreálunk egy speciális FrameMaker dokumentumot, ezt úgy hívják, hogy structured application definition document, állományneve legyen structapps.fm. Aztán létrehozzuk az írás-olvasás föntebb már említett szabályait definiáló ReadWriteRules nevű dokumentumot, ami lényegében a DTD-t egyes elemeit fogja megfeleltetni a FrameMaker által valóságosan használt EDD-nek (Element Definition Document). Ehhez csak annyit, hogy már maga a DTD sem szűzlányok esti olvasnivalója, de normális körülmények között (vagyis ha egyszerű szövegszerkesztőt használunk) elég, ha azt bogarásszuk. Most pedig jön hozzá az EDD, és mi fogjuk leírni a kettőt összekapcsoló szabályokat. Nem lesz nagy öröm, de egyszer mégis a végére jutunk. Utána összeállítjuk a strukturált sablont, végül a structapps.fm állományban e két utóbbi dokumentumra mutató hivatkozásokat helyezünk el, a többi idő kérdése, és főleg türelemé. A folyamat babrás, ám röpke hetek vagy hónapok kérdése csupán, és ripsz-ropsz, máris dolgozhatunk. A strukturálás szépségei Mindez nem hangzik túl biztatóan, ám ne feledjük, hogy strukturált FrameMakert abban az esetben vesszük elő, ha például az amerikai szövetségi adóhivatal összes belső és külső, online és nyomtatott dokumentációját nekünk kell előállítanunk. Ilyenkor jön egy fejlesztőgárda, amely legyártja a megfelelő XML-alkalmazásokat, utána tipográfiai szakiparosok bevonásával sablonok készülnek, a napi gyakorlatban pedig majd a sablonok alkalmazása folyik. Persze nem egészen, mert hisz épp azért használunk strukturált felületet, hogy felcímkézhessük a bevitt adattömeg minden morzsáját, és ez mégse favágás, vagy legalábbis nemcsak az. Mindamellett a föntebb leírt alapozó munkát egyszer kell végigcsinálni, az eredmény olyan lesz, mint egy római hadiút, az idők végezetéig kitart. Új dokumentumot ezután ugyanúgy hozunk létre, mintha nem strukturált FrameMakerrel dolgoznánk. A kiválasztott sablonnak része az EDD, tehát az Element Definition Document, amely tartalmazza az XML-elemeket és attribútumaikat, valamint a rájuk vonatkozó formázási utasításokat is. Továbbá mindazt, ami egy kiadvány sablonjában normális körülmények között lenni szokott, bekezdés, betű- és táblázatformátumok, papírméret, margó, hasábok, lábjegyzetek, színdefiníciók, változók és effélék. A FrameMaker ablakában megjelenő strukturált dokumentum első pillantásra szemernyivel se különbözik a nem strukturáltaktól. Második pillantásra már igen. Ha például szövegrészt szúrunk be valahová vagy másolunk át egyik elemből a másikba, a szöveg az új helyen automatikusan a megfelelő tipográfiai paraméterekkel jelenik meg. Vagyis strukturált FrameMaker használata mellett a szövegformázással egyáltalán nem kell törődnünk, ez pedig olyan sajátosság, ami a legszórakozottabb tördelőnek is feltűnik előbb-utóbb. Elővarázsolható továbbá a Structure View jelű ablak, ami épp olyan, mintha XML-editorban volnánk (vagy éppenséggel a Windows Explorerben), úgy is működik. Többkötetes regényfolyamunk szerkezete ettől hirtelenjében nagyon áttekinthető lesz, és nagyon kezelhető. Sajnos a Structure View megnyitásához a menürendszeren át nem vezet út, némi idő kell hozzá, mire rájövünk, hogy a dokumentumablak jobb felső sarkában, a görgetősáv fölött is vannak alig észrevehető, ikonszerű képződmények, abból az egyik a Structure View. Ami, persze, megnyitható gyorsbillentyűvel is, lévén a FrameMaker alapvetően billentyűzetorientált. Billentyűkombináció csaknem mindenhez van, esetleg többféle is, komfortosan lehet dolgozni anélkül, hogy az egerünket minduntalan nyomorgatnánk. Persze, ha sok billentyűkombinációt használunk, akkor ezek nagy része komplexebb lesz a megszokottnál, például a Structure View a következő: ­Esc­, ­Shift­-­E­, ­Shift­-­V­. Nem állítom, hogy könynyen memorizálható, de hát az Emacs kombinációi se feltétlenül azok. De maradjunk a strukturált eszközöknél: elővarázsolhatjuk az XML-címkéket is. Ilyenek amúgy nincsenek, hiszen ami előttünk van, az valójában nem XML, viszont írtam föntebb, hogy a Frame-Maker azt a látszatot iparkodik kelteni, mintha XML-t szerkesztenénk. Címkék tehát mégis vannak, megint csak nagyjából úgy, mint egy XML-editorban. Dokumentumunk szerkesztése eszerint akként zajlik, hogy a meglevőkhöz további elemeket csapunk. Már az első kísérlet alkalmával rá fogunk jönni, hogy fékevesztett egyénieskedésre nincs mód, ugyanis a FrameMaker rajtunk tartja a szemét. A jobb XML-editorok is folyamatosan megfeleltetik a dokumentumot a DTD-nek (sémának, RNG-nek), tehát nem hagyják, hogy túl nagy marhaságokat műveljünk; ugyanígy a FrameMaker se engedi, hogy egy elembe beszúrjunk egy olyan további elemet, amely ott nem fordulhat elő. Rontó szándékunknak tehát keresztbe tesz, pozitív törekvéseinket viszont támogatja. Próbáljunk például verses formájú Erzsébet-kori rémdrámát írni vele, meg fogjuk látni, hogy öntevékenyen pakolja be a megfelelő címkéket (már ha jó a DTD-nk, persze), éppen csak dramaturgiai tanácsokat nem ad. Végszó Helyzetünket tovább egyszerűsíti az a körülmény, hogy van egy elemkatalógusunk, ez tetszés szerint megjeleníthető vagy eltüntethető, és alapértelmezés szerint azokat az elemeket mutatja, amelyek az adott helyen ­ ahol a kurzorunk éppen áll ­ beszúrhatók. Persze ezt meg lehet változtatni, mutathatja a katalógus az összes létező elemünket, de ennek általában nem vennénk hasznát. Elemeket összevonhatunk és szétszedhetünk, például két felvonást egy felvonássá, vagy egy fejezetet kettővé, az ezzel szükségképp együtt járó papírmunkát nyugodt lélekkel a FrameMakerre bízhatjuk. Másra is jó ez a katalógus, például elemeket tudunk átminősíteni (mondjuk, alcímből bekezdéssé, vagy bekezdésekből listaelemekké), ez néha elkerülhetetlen, és persze ezen az úton haladva csak-csak össze fogjuk zagyválni a dokumentum szerkezetét, de majd később rendbe szedjük. Ebben a már említett Structure View tud segíteni, például ha egy összecsukott formában ábrázolt felsőbb szintű elem alacsonyabb szintjein gabalyodás van, akkor a plusz jel, ami itt ugyanazt a szerepet tölti be, mint az Explorer- ben, piros színűre változik. Kérhetünk teljes körű ellenőrzést is, mint bármely jobb XML-szerkesztőben, ez esetben a FrameMaker az egész dokumentum szerkezeti felépítését átnézi, és minden golyhóságra fényt derít. Idővel az ember már sajnálja, hogy a strukturált FrameMakerre emberi számítás szerint sohase lesz szüksége, és így meg lesz fosztva azoktól az örömöktől, amelyeket a strukturált nézet nyújtani tud. Persze a FrameMaker alapjában véve könyvtördelő, arra pedig nagy a kereslet manapság, amikor mindenki könyvet ír, kukkantsunk be egy komfortosabb csatornanyílásba, kapualjba, híd alá, az ott elmélkedő hajléktalanok jelentős hányadának legalább egy kötete van, néha kettő. Én pedig egyre inkább úgy hiszem, hogy könyvet tördelni FrameMakerben legcélszerűbb, még akkor is, ha magyar nyelvű helyesírás-ellenőrző-je nincs. Ez óriási hátrány ugyan, de a FrameMaker annyi egyebet tud, hogy még ezt a hátrányt is ledolgozza. Mi- nél vastagabb a könyv, minél bonyolultabb, minél több kereszthivatkozás, jegyzet, név- és tárgymutató van benne, annál inkább. Vastag könyveket írjunk, felebarátim, és akkor jó lesz minekünk. Váncsa István Kapcsolódó link http://www.adobe.com/products/framemaker/main.html http://www.tei-c.org/technet.netacademia.net/pdf/2001/mar/XM http://www.perfectxml.com/XML.asp http://www.topxml.com/ http://www.w3.org/TR/2004/REC-xml-20040204/ http://www.xmlhack.com/ http://www.xml.com/pub/a/98/10/guide0.html http://www.snapfiles.com/get/xmlnotepad.html Nyomtatható verzió   Küldje tovább e-mailben   Hozzászólások