2011. február 3., csütörtök
PRC készítés házilag 9.rész - .prc7 - Karakterek és kódlapok
PRC készítés 7.
Karakterek és kódlapok
A számítógép digitális technika, csak a számokat ismeri és még abból se sokat: egyes és nulla. Hogyan tárolja akkor a számítógép a digitális szövegeket, ha csak számokkal tud dolgozni? A megoldás már a számítástechnika hőskorában kialakult: olyan összerendezési táblázatokat készítettek, ahol a számítógépben tárolt kódszámoknak darabról-darabra megfelelt egy képernyőn megjelenő, vagy a papírra nyomtatandó karakter-rajzolat (természetesen az is digitális adatként). Ezek a táblázatok a "kódlapok", és mivel kezdetben a teljesítmény korlátos volt, a programozók úgy kerülték meg az emberiségnek azt az idegesítő szokását, hogy mindenféle kriksz-krakszot használnak betűként, hogy kicsi, csak egynéhány nyelvre használható kódlapok sokaságát készítették.
Persze a kódlapok burjánzásának is véget kellett vetni kábé az Internet kialakulása után. A Unicode rendszer lett napjainkra a széleskörűen elterjedt kódszám-karakterrajz összerendelés, ennek ellenére azért megnézve a böngészőprogramunk "Karakterkódolás" menüpontját, láthatjuk, hogy még nem értünk ki a kódlapok dzsungeléből. A Unicode, de főleg a 16 bites szabványa (UTF-16) gyakorlatilag univerzális, hiszen az utolsó kínai vagy japán írásjelig minden belefér a 65000 karakterbe. (Na jó, a távolkeleti jelkészleteket lehet, hogy meghúzták egy kicsit...)
Tehát a Unicode-szabvány már kielégíti a globalizált XXI. századi világot, akkor miért is kell még kódlapokkal foglalkozni olyan tevékenység során, mint a PRC készítés? Több okból is. Egyrészt a szabvány nem kötelezi egyik program vagy eszközgyártót sem, hogy mind a 65000 kódszámhoz karakterrajzot adjon, másrészt az, hogy a Mobipocket az utolsó Creator kiadásával áttért a 8 bites Unicode (UTF-8) használatára, semmiben nem befolyásolta a Windows programokat, amelyek továbbra is előszeretettel használnak lokális kódlapokat (esetünkben például a windows-1250-est).
A Mobipocket elsősorban mobil eszközökre készült, ahol továbbra is érvényben van a teljesítmény korlátozott volta, attól függetlenül, hogy a mai teljesítmény nagyságrendekkel nagyobb akár a néhány évvel ezelőttinél is. Meg persze ne feledkezzünk el a programozók esetében az emberi lustaságról se. Emiatt van az, hogy a mobil eszközök jó része hiába ismeri a Unicode kódlapot, gyakorlatilag csak az adott régió betűkészleteinek megfelelő jelekhez van bennük karakterrajz. Így Európa közepén megállapítható, hogy a mobil eszközök többsége (főleg, amelyekre nem lehet plusz betűkészleteket telepíteni) megfekszik például a héber vagy arab betűk esetén, nem szólva a távol-keleti illetve az indiai karakterekről. Érdekesebbek persze a latin ábécék ritka betűi, amelyek azért néha felbukkanhatnak a szövegeinkben, például a nevekben. Ezek a hiányosságok teljesen esetlegesek, ahogy a következő összehasonlító táblázatok is mutatják. (Köszönet a segítségért Nargoth-nak, Tholi-nak és Dworkyll-nak!)
Ez az alap betűkészlet a PC Reader-ben megjelenítve, amit a Word2000-es a szimbólum beszúrás menüpontnál a rendelkezésünkre bocsát (a Word2007-es ugyanilyen táblázata lényegesen zavarosabb a bekerült új karakterek miatt, így maradtunk a régi listánál):
A PC Reader természetesen ugyanazt a TTF betűkészletet használja, mint a Word, így gyakorlatilag nincs is hiányzó karakter (kivéve a ♥-et követő két sor elemeit, ami viszont úgy tűnik, hogy a Word "sara"). Más a helyzet azonban a mobil eszközökön.
A Symbian S60v1, mint az egyik legrégebbi eszköz ezeket a karaktereket képes megjeleníteni:
A Palm se mai gyerek, számára ezek a karakterek használhatóak a listánkból:
A Windows Mobile 6.1 karakterkészlete:
És az egyik legteljesebb karakterkészlettel rendelkező okostelefon, egy Symbian S60v5 rendszerű eredménye:
És ennyit képes a tesztlistából egy magyar piacra gyártott eInkes Koobe megjeleníteni (valószínűleg pont ugyanazt a Times betűkészletet használja, mint a PC):
Jól látható, hogy a Palm-hoz hasonló kivételektől eltekintve általában használható a latin-cirill-görög ábécék alap-karakterkészlete, de már az extra betűk és a grafikus jelek esetében számítanunk kell rá, hogy lesznek olyan olvasók, akik üres téglalapot fognak látni helyettük. Javasolt tehát minden PRC-készítőnek, hogy adott kérdéses esetekben tanulmányozza a fenti táblázatokat, ha minden mobil eszközön működőképes megoldásra törekszik.
Mit tehetünk tehát akkor, ha az I♥NY vagy a † esetében biztosra akarunk menni? A működőképes megoldás a necces karakter képként való beszúrása a szövegbe. Mindaddig, míg a kép nem sokkal nagyobb az átlagos karakterméretnél, a MP Readerek kényelmesen megjelenítik a sorokon belül, így a képek nyugodtan helyettesíthetik a karaktert. Ehhez természetesen a karakter raszteres képére van szükségünk, amit egy "képernyő-lopó" programmal már a szövegszerkesztőnk által megjelenített képből könnyen beszerezhetünk. Több ilyen képlopó létezik, itt most az Irfanview képernyőmentés funkcióját fogjuk használni, mivel ez ingyenes program és van megfelelő magyarítása is.
Első lépésként indítsuk el az Irfanview-t. Válasszuk ki az "Beállítások" menüből a "Felvétel/képernyőkép készítése..." pontot.
A megjelenő párbeszédablakban végezzük el a szükséges beállításokat:
A mentett terület maradhat az alapértelmezett aktív képernyő (1), hiszen úgyis később darabolunk és átméretezünk a képen. Akinek ütközik az alapértelmezett aktiváló billentyűkombináció (2) valami másik programmal, az állítsa át egy szabad párosra. Természetesen nem kérjük az egérkurzor lefényképezését sem (3). Fontos a kimeneti mappa beállítása (4), érdemes olyat választani, ahol sok kattintgatás nélkül is megtaláljuk a mentett képeket. Hasonlóan fontos a kimenet fájltípusa (5), itt a tömörítésmentes BMP a legjobb választás. A végén az "Indítás"-sal (6) állítsuk a programot felvételre.
Indítsuk el a szövegszerkesztőt és írjuk ki a szükséges karaktert egy üres lap közepére, viszonylag nagy betűméretben a részletek miatt. Természetesen kapcsoljunk ki minden olyan grafikai segédletet, amit a szövegszerkesztő a munkához nyújt, hiszen azok is rákerülnének a képernyőmentésre és csak megbonyolítják a további munkát, valamint a szövegszerkesztő kurzorát is rakjuk odébb.
Az Irfanview billentyűkombinációjával készítsünk egy képet az extra karaktert tartalmazó lapról. Ellenőrizzük az elkészült képet, és ha megfelel a további munkához, akkor a szövegszerkesztőt be is zárhatjuk, sőt az Irfanview-val is végeztünk. A további munkát egy nagyobb tudású képmanipuláló programmal folytatjuk, a Gimp-el. Ez is ingyenes és tud magyarul, ezen felül szinte minden olyat el tud végezni, mint a nagyok. (Én speciel egy profi kiadványszerkesztővel dolgozok, warez mi más?, de itt a műveleteket egy mindenki számára hozzáférhető programon mutatom be.)
Tehát nyissuk meg a képernyőmentésünket a Gimp-pel, és válasszuk az "Eszköztár"-ból a téglalap alakú kijelölést
majd némi ráhagyással jelöljük ki vele a karakterünket:
A "Szerkesztés" menüben a "Kivágás"-sal vagy "Másolás"-sal rakjuk a karakterképet a vágólapra,
majd mentés nélkül bezárhatjuk a "File" menüben a képet. Visszakapjuk az üres Gimp ablakot. Most a "File" menü "Létrehozás" pontjában válasszuk "A vágólapról" lehetőséget,
így új képként megkapjuk a karakterünk körbevágott változatát.
A "Kép" menü "Kép átméretezése" menüpontjával nyissuk meg a párbeszédablakot:
Képpont mértékegységgel adjuk meg a karakterünk függőleges magasságát:
A vízszintes méret értelemszerűen az arányok megtartásával lecsökken, úgyhogy ahhoz ne nyúljunk. A függőleges magasság tetszés szerint lehet valahol 12-25 pixel között, csak az így lekicsinyített karakter felismerhető maradjon 100%-os nagyításnál.
Következő lépésként gyártsunk GIF képet a karakterből, ugyanis ilyen kis méretben a JPG formátumnál sokkal gazdaságosabb. Először a "Kép" menü "Mód" pontjában válasszuk az "Indexelt..." módot:
A megjelenő párbeszédablakban válasszuk az optimális színpalettát, és mivel csak egy apró szürkeárnyalatos képünk van, a maximális színszámot is levehetjük mondjuk 32-re vagy 16-ra:
A színszórás beállításait ne bolygassuk, nincs rá szükség a képünk esetében. Ha kész a kép palettás változata, akkor a "Fájl" menüben használjuk a "Mentés másként" lehetőséget:
Adjuk meg a kép nevét, hogy hova kerüljön, és a "Fájltípus kiválasztása" listájának lenyitásával keressük meg a GIF típust. A "Mentés" megnyomására egy plusz GIF beállítóablakot kapunk még. Itt semmit se kell bekapcsolni, sőt ki lehet venni a pipát a "GIF-megjegyzés" elől is. Ezzel elkészült a karaktert helyettesítő kép, amit a szövegszerkesztőben képként beszúrhatsz a könyvszöveg aktuális pontjára.
Hiába vagyunk viszont maximálisan óvatosak a minden készüléken megjelenő karakterek figyelembevételével, ha a Mobipocket programozói megnehezítik az életünket. Sajnos az utolsó MP Creator kiadás (v4.2 build 41) alkalmával elég faramuci módon tértek át a Unicode kódlapú nyersanyagok használatára. Korábban lazán ment a konvertálás: magyar Word-ből készítünk egy DOC-ot, beolvastatjuk a Creatorral, készül egy HTML, és a végén összerakunk egy PRC-t. Senkinek sehol nem kellett figyelnie, hogy milyen kódlapokkal dolgozik, hiszen a végeredmény tökéletes volt így is. Viszont az átállás után szörnyű hiányosságra derült fény. Ha a köztes HTML fájl nem Unicode kódlapú, akkor a belőle készült PRC képes mindenféle zagyva karaktereket rajzolni az alapkészlet feletti kódszámokra. És hogy a köztes fájl biztosan ne Unicode legyen, arról a szövegszerkesztőnk gondoskodik, hiszen ha nem mondod meg neki egyértelműen, hogy milyen kódlappal dolgozzon, akkor a regionális változattal fog menteni.
Tehát ha a Word-ben elkészíted például a korábbi tesztekhez is használt karakter-listát így:
akkor azt a Word olyan DOC-ba menti, hogy abból mindig windows-1250 kódlapú HTML fájl készül. Eleve ha a Word-ből mented közvetlenül HTML-be a listát, már akkor ellenőrizheted, hogy közép-európai kódlapos fájlt kapsz, és mivel a Creator is a Word-öt használja a konvertálásra, így a DOC változat átalakításakor is következetesen windows-1250 lesz a köztes HTML kódlapja. Ez pedig egyáltalán nem felel meg a Creator-nak, hiszen a windows-1250 kódlapú HTML-ből ilyen PRC-t készít:
A PC Reader-ben megjelenített lista annak ellenére nem tartalmazza az extra betűkészleteket (helyettük megismétli az alap latint), hogy ugyanazzal a betűtípussal dolgozik, mint a szövegszerkesztő. Itt bizony komoly karakterkódolási hiányosság van, aminek hatására az óvatlan konvertáló anyagából eltűnhetnek a görög és a cirill betűk, valamint a magasabb kódszámú jelek, mint például az ⅓.
Persze van megoldás a dologra, a köztes HTML-t át kell konvertálni Unicode kódlapra még a PRC összeállítása előtt. Viszonylag egyszerű művelet, de akkor is egy felesleges lépés, amit egy kis odafigyeléssel a Mobipocket programozói elkerülhettek volna. Ugyanabból a DOC-ből készült HTML így néz ki PRC-be fordítva, ha előzőleg átkonvertáljuk Unicode kódlapra:
Jól láthatóan ismét előkerült a teljes betűkészlet.
Három megoldás létezik a problémára. Az elsőt a korábban ismertetett kipucolószkript jelenti, amelyhez éppen azért írtam hozzá a kódlap váltást, hogy a fenti mizéria ne akadályozza a gördülékeny konvertálást. Ekkor kimondottan előny, hogy a Word más utasítás híján windows-1250 kódlapot használ, ugyanis a szkript csak ilyen anyagot fogad el bemenetként, majd a beállításától függően a végeredményt már UTF-16 típusú Unicode HTML-be tudja menteni. A szkript használatával tehát helyreállt a korábbi konvertálási menetrend: felkészítés Word-del, nem foglalkozva a kódlapokkal simán DOC-ba menteni, beolvastatni a Creator-ral, a köztes HTML-en elvégezni a pucolást (plusz kódlap váltást), majd összerakni a PRC-t.
Aki egy kicsit alaposabban körülnézett a Word-ben, az megtalálhatta a második megoldást. A Word annak ellenére tud különböző kódlapokat használni, hogy ezt nem reklámozza, az egyszeri felhasználó az életében nem találkozik ezzel a funkcióval. Alapesetben a Word olyan fájlokat ment, legyen az DOC vagy HTML, ami a közép-európai windows-1250 kódlapot használja. Viszont a mentés párbeszédablak "Eszközök" gombja mögött érdekes dolgok lapulnak.
Meglepő módon a "Webes beállítások" párbeszédablakában találunk rá a karakterkódolás beállítására, ami ugyanúgy érvényes lesz a DOC fájlra, mint a tényleg webesnek számító HTML-re.
Tehát, ha azt szeretnénk, hogy a DOC nyersanyagból a Creator automatikusan Unicode HTML-t készítsen, akkor ezen a helyen adhatjuk meg a kész DOC nyersanyag karakterkódolását Unicode-nak. A listában szereplő szimpla Unicode felel meg az általános "little endian" 16 bites kódlapnak (a HTML szerinti megnevezéssel UTF-16) , a Unicode (UTF-8) pedig értelemszerűen a 8 bites kódlapot jelenti. A lista másik két Unicode változatával nem érdemes foglalkozni. A Mobipocket hivatalosan a 8 bites kódlapot használja, de nemhivatalosan tökéletesen működik a 16 bites Unicode-dal is, így ezt javaslom alkalmazni.
Harmadik megoldásnak marad a kézimunka. Ehhez ismernünk kell, hogy a HTML szabvány a fájl <head> részében elhelyezett <meta....> információs sorban igényli a fájl tényleges karakterkódolásának a konkrét megnevezését:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-16"/>
Tehát az, hogy a text alapú HTML fájl valójában Unicode kódolású, a használat során még nem elegendő, ha a fájlban más információ (vagy éppen semmi információ se) szerepel a kódlapról. A legfontosabb kódlap megnevezések a következőek:
windows-1252 = nyugat-európai kódlap
windows-1250 = közép-európai kódlap (ANSI)
iso-8859-1 = nyugat-európai ISO kódlap
iso-8859-2 = közép-európai ISO kódlap
UTF-16 = 16 bites Unicode kódlap
UTF-8 = 8 bites Unicode kódlap
A fentiek egyikét kell tehát magába a <meta...> sorba is beírni miután a fájl kódolását átkonvertáltuk. A tényleges kódlap-váltást pedig a legegyszerűbben a Jegyzettömb-bel végezhetjük el, ha a váltás iránya a szűkebb kódlapról a bővebb felé történik. Ehhez nyissuk meg a konvertálandó windows-1250 kódlapú HTML fájlt a Jegyzettömb-bel, majd írjuk át a kódlap megnevezését a <head> részben a végleges UTF-16-ra:
Ezt követően válasszuk a "Fájl" menüből a "Mentés másként"-et:
A párbeszédablak alján a "Kódolás" listájából válasszuk a szimpla Unicode kódlapot, ugyanis ez felel meg az UTF-16 megnevezésnek. A fájlnév és a fájltípus érintetlenül hagyásával mentsük el a változtatásokat. Eredményül ugyanazzal a HTML névvel egy szabályos Unicode kódolású anyagot kaptunk, ami már tökéletesen megfelel a PRC-készítéshez. Hogy jól dolgoztál, azt leellenőrizheted az új HTML megtekintésével egy böngészőben, ugyanis azoknak kutya kötelességük Unicode kódlap automatikus használatával helyesen megjeleníteni a szöveget.
Természetesen a Jegyzettömbös kódlap váltás csak addig működik, míg a forrásfájl nem tartalmaz olyan karaktereket, amelyeket a célformátumban lehetetlen tárolni. Tehát ha a forrásfájl eredetileg is Unicode kódolású volt, és fizikailag is tartalmaz olyan karaktereket, amelyek nem részei az ANSI kódlapnak, akkor egy visszafelé kódlap váltás a következő figyelmeztetéssel jár:
És természetesen, ha a figyelmeztetés ellenére elvégzed az átkonvertálást, akkor az ANSI készleten kívüli használt karakterek eltűnnek a fájlból.
"Elminster"
PRC gyártás házilag 1.rész - Javaslatok
PRC gyártás házilag 2.rész - Szövegjavítás
PRC gyártás házilag 3.rész - .prc1 - Bevezető
PRC gyártás házilag 4.rész - .prc2 - Konvertálás Creator-ral
PRC gyártás házilag 5.rész - .prc3 - Tartalomjegyzék alapfokon
PRC gyártás házilag 6.rész - .prc4 - Tartalomjegyzék megoldások
PRC gyártás házilag 7.rész - .prc5 - Szövegformázás
PRC gyártás házilag 8.rész - .prc6 - HTML tisztítás
PRC gyártás házilag 9.rész - .prc7 - Karakterek és kódlapok
PRC gyártás házilag 10.rész - .prc8 - Képek kezelésePRC gyártás házilag 11.rész - .prc9 - Linkek és jegyzetek
PRC készítés házilag 8.rész - .prc6 - HTML tisztítás
PRC készítés 6.
HTML-tisztítás
Korábban többször szóba került, hogy a mobi PRC alig a töredékét ismeri az évtizedek alatt CSS kódokkal elbonyolított HTML szöveg-formázásoknak. Ez nem is baj, hiszen a képes albumok kivételével az olvasnivalóban a szöveg számít, nem a csicsás kinézete.
Ha a nyersanyagot eleve HTML-ben írjuk meg, akkor biztosan egyszerű és letisztult kódot kapunk. De mindenki szövegszerkesztőt szeret a felkészítésre használni, mert a műveletek elvégzése sokkal egyszerűbb: erre készültek ezek a programok. Viszont a szövegszerkesztős anyagokból automatán generált HTML fájlok messze vannak az egyszerűtől és a letisztulttól! Mivel mi Word DOC-al foglalkozunk, elrettentésül álljon itt az a HTML-kód, amit a konvertálás DOC-ból készít:
és ebből valójában ennyi a PRC számára hasznos anyag:
Évekkel ezelőtt a Mobipocket fórumán jvoq által megosztott VisualBasic szkript adta meg a megoldást számomra a kényelmes Word felkészítés és a letisztult HTML-kód ellentmondására. Egyébként léteznek kimondottan HTML/XHTML optimalizáló programok is, viszont jvoq szkriptje nekem nagyon bevált, így ezek a programok nálam kimaradtak.
Volt az eredeti szkriptnek néhány hibája (például az üres sorok automatikus törlése), amit időközben kijavítottam, és ahogy gyűltek a szkriptre bízott feladatok, végül megírtam az ide is mellékelt utolsó változatot. Hogy nagyjából látható legyen mire képes, és előre tervezhető legyen a szövegfelkészítés, álljon itt egy korábban írt összefoglaló a szkript funkcióiról:
- a programrészek magyar kommentezése
- magyarázattal ellátott szkript-vezérlő konstansok bevezetése
- felhasználó választhat win-1250 és UTF-16 kódolású fájl között
- a <head>-be visszaírja a kódlapra vonatkozó meta-sort
- külön fájlból képes <style>...</style> stíluslistát visszaírni a <head>-be
- többsorba tördelt <h#> címsorok egyesítése
- a <p> és <h#> tag-ekben csak az align bejegyzést hagyja meg
- felhasználó által megadott width és height értékeket tud a <p> tag-ekbe írni
- az ismétlődő üres sorokat nem törli
- kitakarítja a style bejegyzéseket az <i>, <b> és <br/> tag-ekből
- a </span> cseréjénél nem szóközt használ, hanem tényleg töröl
- törli a <font> bejegyzéseket
- a képhivatkozásokból töröltethető a "./" relatív mappajelzés
- jelölőkarakter-párokat háromszintű <y#> tag-ekre képes cserélni
- felhasználó választhat, hogy felülírással vagy új HTML készítésével működjön
- felhasználó bekapcsolhatja az átmeneti állományok megőrzését
Mielőtt végigmennénk a legfontosabb szkript funkciókon és a javasolt DOC felkészítésen, tisztáznunk kell a legfontosabb korlátját is. A szkript az XHTML szabványnak megfelelően csak a kisbetűs tag-bejegyzéseket ismeri meg, például <body>. Szerencsére a Creator a DOC nyersanyagból ilyet készít, sőt a Word is ilyen HTML kimenetet készít, ha mentési formátumnak ezt választjuk (csak több szemetet rak a kódba, mint a Creator-os konvertálás). Ezzel szemben az OpenOffice - annak ellenére, hogy teljes mellszélességgel az XML mellett van - valami érthetetlen okból a HTML kimenetén nagybetűs tag-eket használ: <BODY>. Ez utóbbiakba a szkript belefagy. Tehát a szkriptes tisztítást használni mindig csak Word DOC-ból Creatorral készített HTML fájlokon lehet!
A szkript használata végtelenül egyszerű: rakjál egy példányt a Windows Asztalra, majd a tisztítandó HTML fájlokat a fájlkezelőből egyszerűen húzzad rá az ikonjára. A szkript ugyanabba a mappába fogja a tisztított változatot elkészíteni, amelyből ráhúztad a nyers fájlt. Többször ellenőriztem, hogy a hasznos szövegen semmit nem változtat, a szkript műveletei csak a HTML tag-eket befolyásolják, úgyhogy kárt nem okoz.
A szkriptbe beépítettem néhány választható funkciót, amelyek a kód elején kommentezve felsorolt konstansok átirogatásával szabályozhatóak. Ha a szkript ikonjára jobbgombbal kattintasz, akkor a menüből kiválaszthatod a "Szerkesztés" pontot, ami a szkript kódját jeleníti meg a Jegyzettömbbel:
A kód elején lévő felhasználói beállítások a következők:
1. Const html_overw = True Ez szabályozza az eredeti fájl felülírását. False érték esetén egy új eredményfájlt készít, amelynek a nevéhez egy CLEAN megjegyzést fűz. Ha a nyersanyagban - a Word szokásához híven - olyan képhivatkozások vannak, amely a *****-elemei mappára mutatnak, akkor nem szerencsés a HTML fájl nevének megváltozása, mert a fájl és a képeket tároló mappa összekapcsolása elveszik. Tehát alapértelmezésben a tisztítás felülírja az eredeti fájlt, így ha bizonytalan vagy a végeredményben, akkor vagy átírod ezt a kapcsolót, vagy készítesz a nyersanyagról egy biztonsági másolatot a tisztítás előtt.
2. Const unicode_html = True A későbbiek során szó lesz a betűkészletek és kódlapok környéki mizériáról. Most elég annyi, hogy a Creator legújabb változatai jobban szeretik az univerzális kiosztású Unicode kódolást, mint a Word DOC konvertálásából alapesetben származó windows-1250 kódlapú fájlokat. Alapértelmezett beállításban tehát a szkript a windows-1250 kódolású fájlból egy UTF-16 kódolásút készít. Ha ezt ki akarod kapcsolni, akkor a konstans értékét False-ra kell átírni és így a végeredmény windows-1250 kódolású marad.
Alapjában véve nincs szükség az UTF-16 konverziót kikapcsolni, de van egy speciális eset. A szkript csak windows-1250 kódolású HTML fájlokat fogad el bemeneti nyersanyagként. Tehát az egyszer letisztított és UTF-16-ra konvertált HTML újból nem "etethető meg" a szkripttel. Olyan esetben, amikor előre látod, hogy még későbbi futtatások is lesznek, érdemes megőrizni az anyagodat windows-1250-ben, és csak a legutolsó tisztításkor elvégeztetni rajta a kódlap váltást.
3. Const style_file = "C:/E-Books/header_styles.txt" A szkript gyakorlatilag kiüríti a nyers HTML fájl stílusokkal teleszemetelt <head> részét. A Word ugyanis nem képes megfékezni magát, ha betű- és bekezdés-sítlusokról van szó, csak nézzetek bele egy DOC-ból frissen készített HTML kódjába: percekig lapozhattok, mire a hasznos szöveg előkerül, annyi szemét van a <head> részben. Minekután a szkript kiszedi az eredeti stílusokat (és a szövegből is törli a ráhivatkozó class="..." attribútumokat), azok akik utólag a saját jól beállított stílusaikat szeretnék a HTML-ben használni, itt lehetőséget kapnak arra, hogy egy külső fájlból az összeállított stílus listájukat automatikusan bemásoltassák a végeredménybe. Gyakorlatilag a <h#> címsorok stílusának beállítására érdemes egyedül saját definíciókat használni, ugyanis hiába a definíciós lista automatikus bemásolása, ahol a szövegben használni szeretnénk a stílust, ott kézzel kellene a class="..." attribútumokat egyesével visszaírni. És ez rámutat egy fontos DOC felkészítési szabályra. Mivel a stílusoktól a szkript végleg megszabadítja a szöveget, minden olyan formázás, amit a Word-ben stílussal oldottunk meg, elveszik. Ha fontos az adott formázás, akkor mindig a Normál stílus megtartásával a szövegformázási funkciók (rendezés, dőlt stb. nyomógombok) használatával alakítsuk ki a kívánt képet, ne pedig egy "Sajátstílusom24" nevű egyéni stílusba legyen beledrótozva a beállítás!
4. Const pict_path_corr = True A régebbi Word-ök a képek hivatkozásainál a HTML kódban használnak egy "./" relatív mappajelzést. Az új Creator viszont így nem találja a képet, tehát aki hozzám hasonlóan csak Word2000-est vagy hasonlóan régi változatot használ, az hagyja itt a True értéket. Aki frissebb Word-del dolgozik az nyugodtan False-ra állíthatja, de azért tegyen egy próbát, hogy a PRC-ben megvannak-e a képei. Ha ugyanis eltűntek, akkor neki is ott van az a fránya mappajelzés a képek hivatkozásaiban, és a szkripttel ki kell szedetnie.
5. Const p_width = "0" és Const p_height = "0" Szó volt róla, hogy a width="..." és a height="..." speciális mobi attribútum szabályozza a bekezdések elsősorának behúzását és az első sor előtti szünetet. Tehát aki változtatni akar az alapértelmezett kinézeten, az itt adhatja meg a megfelelő értéket, amelyek szigorúan csak a <p> tag-ekbe kerülnek be, de kivétel nélkül mindegyikbe. (Viszont a címsorok <h#> tag-jeit nem befolyásolja.) A leggyakoribb egyéni akció természetesen a nulla értékek használata, ezért van a szkriptben ez alapértékként, de a macskakörmök közé mindenki olyan számot írhat, ami neki tetszik. Ha viszont egyáltalán nincs szükséged erre a két attribútumra, vagy a kettő közül egyikre, akkor eléírt "Rem" utasítással teljesen kikapcsolhatod. Ez azt eredményezi, hogy a kikapcsolt attribútumot egyáltalán nem írja bele a <p> tag-ekbe. Egyébként ez az alapállapota a szkriptnek.
6. Const sign1_start = "..." és Const sign1_end = "..." Magamnak kidolgoztam egy rendszert <y#> tag-ekkel a tartalomjegyzékbe kerülő szövegrészek megjelölésére. Nem részletezném a dolog működését, hiszen a korábban ismertetett címsoros eljárás egyértelműbb. Viszont mivel a Creator bármit elfogat TOC-készítésnél jelölésnek, ezért mi bármit használhatunk, akár egy szabványon kívüli új tag-et is. A saját megoldásom azon alapul, hogy a DOC felkészítés során a kijelölendő szövegrészek elejére és végére egy-egy jelölőkaraktert rakok (makróval, mi mással), majd a HTML elkészülte után a jelölőkaraktereket lecserélem az <y#> tag-ekre. Ez a beállító rész gyakorlatilag a jelölőkarakterek és az <y0> <y1> <y2> tag-ek összerendelését adja meg. Aki címsoros tartalomjegyzék generálást használ, nyugodtan "Rem"-ek beírogatásával kikapcsolhatja ezt a funkciót.
7. Const sign_brake = "˛" Ismét egy saját megoldás. A szkript nem képes megbirkózni a többsorra tördelt kódú Word szeméttel a HTML-ben, és az egyik ilyen az oldal- és szakasztörések HTML kódja. Tehát a szkript használata esetén kötelező még a DOC felkészítés során minden oldal- és szakasztörést törölni. Ha viszont mégis szeretnék egy-egy ponton laptörést a PRC-ben, akkor a szkript egy megfelelően(!) megválasztott jelölőkarakter helyére képes automatikusan az <mbp:pagebreak/> kódot írni. Mivel a csere úgy történik, hogy azt a <p> sort, amiben a jelölőkarakter megtalálható, a szkript <mbp:pagebreak/><p> </p> sorra cseréli, így a DOC felkészítése során szigorúan ügyelni kell arra, hogy a laptörés jelölőkaraktere csakis egy enterrel készített üressorban lehet! Ellenkező esetben ugyanis az adott sor teljes tartalma elveszik azzal, hogy a <p> </p> HTML üressora cserélődik. Természetesen a jelölőkarakter olyan legyen, ami a magyar szövegben (plusz görög és cirill betűk) soha nem fordul elő. A szkriptbe alapértelmezetten beállított kunkor egy ilyen karakter. Egyébként a funkció eléírt "Rem"-el kikapcsolható, ahogy az alapesetben is van.
8. Const save_temp = False A szkript futása közben két átmeneti állományt készít, majd töröl le. Ha hibakereséshez szükséged lenne az átmeneti fájlokra is, akkor ezt a konstanst írd át True értékre.
A szkript további kódjába természetesen mindenki belejavíthat, ha van egy kis Basic gyakorlata, a többiek inkább ne bolygassák. A kódot igyekeztem blokkokra bontani és kommentezni, hogy rajtam kívül más is eligazodjon benne.
A felsorolt felhasználói beállításokon kívül még maradt néhány javaslat és felkészítési követelmény.
Említettem, hogy a szkript lefagy a többsorba tördelt HTML kód esetén, így egy-egy fagyás alkalmával érdemes a szkript által érintetlenül hagyott tag-ekre gyanakodni, és a HTML kódban kézzel rendberakni. Az oldaltörések mellett még a <table> elemei hajlamosak ilyen fagyást okozni, ezért javasolt a táblázatokat tartalmazó fájlok tisztítása előtt a HTML kódban szép rendezett formára alakítani a táblázatok anyagát, és kitörölni belőlük a class, span és egyéb tölteléket. (Aki megvizsgál néhány kitakarított HTML-t, az tudni fogja mi a felesleg a táblázatok kódjában.) A biztonság kedvéért a táblázatok kódjának rendezése után a táblázatot mindig ellenőrizzük böngészőben is, nehogy egy-egy tag óvatlan törlése miatt szétessen a szerkezete!
A szkriptben használt keresés-cserék igen érzékenyek a szóközök darabszámára. A megfelelő működéshez mindenképpen el kell tüntetni a többszörös szóközöket a DOC-ból. A művelet még a szövegfelkészítés során a Word keresés-csere eszközével elvégezhető: két szóközt kell egy szóközre cserélni, és addig ismételni a "Mindet" cserét, amíg nulla találattal nem fejezi be a műveletet.
A mobi PRC-ben nem javasolt a betűszínt vagy a méretet lerögzíteni, de néha szükség lehet ilyen formázásra. Mivel a szkript automatikusan kiszedi az összes <font> tag-et, ha valóban lényeges betűformázás van az anyagban, akkor azt a tisztítás előtt kézi beavatkozással kell megvédeni a törléstől. Az adott pontokat még a tisztítás előtti HTML-ben meg kell keresned, és a nyitó <font ...> valamint a hozzá tartozó záró </font> tag-ekbe be kell írni valami "elrontó" karaktert például így: <#font ...> és <#/font>. A szkript így már nem találja meg ezeket a bejegyzéseket és a tisztítás után a <# kombináció keresésével-lecserélésével megszüntetheted a tag-ek védelmét.
Legvégül, általában is nagyon hasznos, ha a Word szövegfelkészítés során már egységes, következetes és letisztult anyagot készítünk. Tehát törekedni kell egyrészt az egyszerű megoldásokra, hogy a kipucolószkript minél kevesebb potenciális hibalehetőséggel találkozzon. Másrészt ugyanazok a formai elemek a teljes szövegben következetesen ugyanazzal a megoldással készüljenek, hogy a hasonlóság a HTML-kódban is megmaradjon, így segítve téged az eligazodásban és az utólagos HTML módosításokban.
Jelen esetben az ismertető letölthető csomagjában természetesen a kipucolószkript legutolsó változata is benne van.
"Elminster"
PRC gyártás házilag 1.rész - Javaslatok
PRC gyártás házilag 2.rész - Szövegjavítás
PRC gyártás házilag 3.rész - .prc1 - Bevezető
PRC gyártás házilag 4.rész - .prc2 - Konvertálás Creator-ral
PRC gyártás házilag 5.rész - .prc3 - Tartalomjegyzék alapfokon
PRC gyártás házilag 6.rész - .prc4 - Tartalomjegyzék megoldások
PRC gyártás házilag 7.rész - .prc5 - Szövegformázás
PRC gyártás házilag 8.rész - .prc6 - HTML tisztítás
PRC gyártás házilag 9.rész - .prc7 - Karakterek és kódlapokPRC gyártás házilag 10.rész - .prc8 - Képek kezelése
PRC gyártás házilag 11.rész - .prc9 - Linkek és jegyzetek
PRC készítés házilag 7.rész - .prc5 - Szövegformázás
PRC készítés 5.
Szövegformázás
A mobi PRC kevés látványos szövegformázási lehetőséget nyújt. Amit képes kezelni az gyakorlatilag az alap HTML kód, és egy nagyon kevés CSS formázás. Másrészt sok paramétert (betűméret, betűtípus, szín) a Reader programok az olvasó beállítására bíznak, így ezeket bűn a PRC-ben fixen lerögzíteni. Ezek alapján úgy vélem, hogy a mobi PRC számára kimondottan előnyös a minél egyszerűbb HTML kód, azaz igyekezni kell minden formázást az alapelemek (<p> <h...> </br> <b> <i> <u> <s> <sup> <sub> <small> <big> <table> <a...> <img ....>) segítségével megoldani.
A saját gyakorlatomban ezért nagy fontosságú a HTML kód tisztítása, és mindig "fapados" HTML fájlt használok a következőkben részletezett módszereknél. A mobi korlátozott képességein túl még egy érv szól a letisztult HTML fájlok használata mellett: a "<span...>", "class=..." és "style=..." tölteléktől megszabadított kód átláthatóbb, és azok a módosítások, amit kézzel végzünk rajta biztos a kívánt eredményre vezetnek.
A következő átalakítások rövidebb leírást kaptak. A bemutatott HTML kódokat a szerkesztő keresés-csere funkciójával kell logikusan és értelemszerűen használni a HTML fájl módosításakor. A műveletek alapja mindig egy Word DOC-ból Creator-ral készített HTML szövegfájl, amin a később részletesen is ismertetett szkriptes kód-tisztítást is végrehajtottuk.
1. Sortávok
A mobiban az alapsortávot az olvasó állíthatja magának, a HTML ilyen paramétert nem ismer, a CSS formázásoktól pedig a tisztítás során megszabadultunk. Marad a bekezdések elsősora előtti szünet, ami alapesetben a mobiban nagyobb az alapsortávnál:
A mobi a "height=" attribútumot vezette be az elsősori sortáv szabályozására. Ha a bekezdések előtti szünet zavar, akkor a <p> tag-eket cseréld <p height="0">-ra!
A dolog hátulütője, hogy így az üres sorok végleg észrevehetetlenek a PRC-ben, ezt kivédheted ha a <p height="0"> </p> üressort 2-3 db alapértelmezett üressorra <p> </p> cseréled:
A <p> bekezdésekkel ellentétben a <br/> sortörések nem kapnak megelőző szünetet, így megfelelő szövegkép kapható az alkalmazásukkal:
A megoldáshoz a Word-ben érdemes automatikusan minden bekezdésjelet (enter) sortörésre (shift-enter) cserélni, majd a szöveg végigpörgetésével minden nagyobb szünethez kézzel visszaírni a bekezdésjeleket.
A "height=..." paraméter jól jön, ha egy kis plusz távolságot szeretnél nyerni a PRC-ben. Például laptörések utáni sor közvetlenül a margónál kezdődik, ami csúnya lehet:
Megfelelő pontokra a <h...> és <p> tag-ekbe beírhatsz valami "height=..." értéket:
2. Elsősor behúzása
A bekezdések és a sortörések elsősora között a behúzás alapértékében is különbség van:
Ha a bekezdések esetén el szeretnéd tüntetni az első sor behúzását, akkor a mobi "width=..." paraméterét használhatod, azaz a <p> tag-eket cseréld <p width="0">-ra:
Ugyanez fordítva, ha a sortörések esetén is egy bekezdésekhez hasonló elsősori "behúzásra" van szükséged, akkor a sorok elejére rakj két nemtörhető szóközt, azaz a <br/> tag-eket cseréld "<br/> " kombinációra:
3. Teljes bekezdés behúzása
Ha azt szeretnéd, hogy egy szövegrész jobbról-balról beljebb legyen a margónál, akkor erről le kell mondanod. A mobi csak részben használja azt a CSS formázást, ami a margókat állítja: csak egy fix szélességű behúzás jelenik meg a PRC-ben és az is csak a bal oldalon. Ennek ellenére (mivel a HTML-ben mindkét oldal látszik) javasolt a jobb- és a balmargó állítását mindig egyszerre használni. Ehhez a style="margin-right:20pt;margin-left:20pt" attribútumot kell beírni a kérdéses bekezdés <p> tag-jébe:
4. Keret
Egyszerű keretezéses kiemelést csinálhatsz, ha a kérdéses szövegrészt egy <div> blokkba foglalod, amely rendelkezik megfelelően megadott keret-paraméterekkel: <div style="border:solid windowtext 0.5pt; padding: 1.0pt 4.0pt 1.0pt 4.0pt">
A keret mindig margótól margóig tart, ezen semmi CSS paraméter beírása nem segít. Táblázatok használatával esetleg lehet egy keret kinézetét tovább alakítani, de a táblázatok kezelése annyira bonyolult, hogy sokszor nem érdemes ezzel komolyan szenvedni.
5. Kiemelés betűmérettel
Nem javasolt a PRC-ben fixált betűméreteket használni, mivel az olvasó olyanra állíthatja, ami neki megfelel. Viszont van két HTML paraméter, ami pontos érték megadása nélkül megváltoztatja az alapértelmezett betűmérethez képest a szöveget. Ha egy szövegrészt kicsit kisebb mérettel írva szeretnél kiemelni (pl. újságrészlet), akkor az adott bekezdéseket foglald a <small>...</small> tag-ek közé:
Ha éppen nagyobb betűmérettel akarod kiemelni (pl. táblafelirat), akkor pedig használd a <big>...</big> tag-et:
6. Iniciálé
Valódi iniciálét természetesen a mobi nem tud, de a <big> tag-el és egy <b> vastagítással az első sorok első karakterét kiemelhetjük:
7. Kiemelés betűtípussal
A betűtípust sem illik lerögzíteni a PRC-ben. Ennek ellenére mivel majd' mindenki arányos (proporcionális) betűtípussal szeret olvasni, megtehetjük azt, hogy a kiemelendő szövegrészt egy fix karakterszélességű betűtípussal írjuk. A programok általában a betűtípus helyettesítésekkor arányost arányossal, fixet pedig fixszel helyettesítenek. Így ha egy részt mondjuk a fix szélességű Courier betűvel szedtünk, az olyan Reader-ekben, amelyek több karakterkészlettel rendelkeznek, ez a rész el fog ütni a többi szövegtől. Ehhez a megoldáshoz a kérdéses részt a <font face="Courier New"> ... </font> tag-ekkel kell jelölni:
A trükk a PC Reader esetén értelemszerűen látható eredményt ad a sok telepített betűkészlet miatt. A PDA-kon is van elég betűkészlet a különbség megjelenítésére, viszont a mobiltelefonokon nem mindig látszik ez a megoldás. Javasolt tehát mindig más kiemelésekkel együtt használni.
8. Igazítások százalékos táblázatokkal
A mobi a táblázatokat - ha point, pixel vagy hasonló fix módon vannak méretezve - elég kényelmetlenül kezeli. Ezzel szemben némi szövegformázást el lehet érni, ha a táblázatok méreteit csak a kijelző-szélesség százalékában határozzuk meg. Tehát a <table> és a <td> tag-ek minden "width=..." paramétere csakis százalék-értéket tartalmazzon, minden érték legyen beírva és ezek az értékek ellentmondás-mentesek legyenek. Ha a border="0" tulajdonságot használjuk a táblázatnál, akkor az olvasó észre sem veszi, hogy táblázatot használtunk. Egy minimális táblázat, ami egy <tr> sort és két <td> oszlopot tartalmaz, HTML-kódban így néz ki:
<table border="0" width="100%">
<tr>
<td align="left" valign="top" width="30%"> ide kerül a szöveg </td>
<td align="left" valign="top" width="70%"> meg ide kerül a szöveg </td>
</tr>
</table>
Az így kialakított táblázatokkal egy kis lehetőséget kapunk a szöveg képernyőbeli elosztásának szabályozására.
Például rendezett felsorolások esetén baloldalon egy keskeny oszlop a sorszámoknak, jobb oldalon a maradék hely a szöveg-elemeknek. Ekkor az oszlopok beállítása lehet <td width="15%">...</td> <td width="85%">...</td>:
Másik megoldás a táblázattal készített kétoldali behúzás. Ehhez három oszlop kell, mondjuk így: <td width="15%">...</td> <td width="70%">...</td> <td width="15%">...</td>:
Egy kis módosítással az előző megoldást keretes szöveggé lehet alakítani. Ellentétben a korábbi faltól-falig <div> kerettel, itt ha a border="1" tulajdonságot csak a középső oszlopnál adjuk meg, akkor a megjelenített képen mindkét oldalon a margónál beljebb kapjuk a keret szélét:
Ritka esetben olyan extrém formázás is felmerül, hogy egy sorban kellene a bal margóhoz és a jobb margóhoz igazított két szövegblokkot megjeleníteni. Ekkor is táblázatot használhatunk két oszloppal (illetve középen egy vékony harmadikkal, elválasztásként) és a két oszlopon belül a szövegigazítást külön szabályozhatjuk. Tehát egy ilyesfajta megoldás lehet: <td width="47%">...</td> <td width="6%">...</td> <td width="47%">...</td>:
Látható, hogy a táblázatokkal elég rugalmas szövegképet lehet kialakítani, azonban nagyon sok kézimunkával jár, így az esetek többségében szerintem felesleges ezzel szenvedni. Fontos még megjegyezni, hogy a kis kijelzőméretekre tekintettel, az olyan oszlopok, amelyek sok szöveget tartalmaznak, ne legyenek keskenyebbek 50-80%-nál.
9. Laptörések
Nem javasolt a DOC nyersanyagban laptörést vagy szakasztörést hagyni, mert csak gondot okoz a konvertálás során. Viszont utólag a HTML kézi szerkesztésével visszaírhatsz ilyen hatású utasítást a kódba.
Egyik laptörést adó megoldás a mobi saját kódja, a korábban is említett <mbp:pagebreak/>. Van egy paramétere a "crossable=...", ami azt szabályozza, hogy lapozással vagy folyamatos görgetéssel át lehet-e jutni ezen a ponton a következő oldalra. Alapértelmezésben a crossable="yes" így ezt nem is kell beírni a pagebreak tag-be. A crossable="no" viszont egy külön szövegrészt készít, amely csak a belsejébe mutató linkkel érhető el. Én például a lapokra bontott tartalomjegyzéknél használom, de ilyennel lehet például lezárni egy-egy index vagy lábjegyzet bejegyzést is, így az olvasó csak a szóban forgó jegyzetet látja a lapon nem pedig a jegyzetek folyamatos listáját.
Másik laptörés megoldás a CSS szabvány szerinti style="page-break-before: always". Ezt egyesével bírhatod a szükséges helyekre a <p> és <h...> tag-ekbe így:
<style>
h3 {
text-align: center;
page-break-before: always;
}
h4 {
text-align: center;
page-break-before: always;
}
</style>
"Elminster"
PRC gyártás házilag 1.rész - Javaslatok
PRC gyártás házilag 2.rész - Szövegjavítás
PRC gyártás házilag 3.rész - .prc1 - Bevezető
PRC gyártás házilag 4.rész - .prc2 - Konvertálás Creator-ral
PRC gyártás házilag 5.rész - .prc3 - Tartalomjegyzék alapfokon
PRC gyártás házilag 6.rész - .prc4 - Tartalomjegyzék megoldások
PRC gyártás házilag 7.rész - .prc5 - Szövegformázás
PRC gyártás házilag 8.rész - .prc6 - HTML tisztításPRC gyártás házilag 9.rész - .prc7 - Karakterek és kódlapok
PRC gyártás házilag 10.rész - .prc8 - Képek kezelése
PRC gyártás házilag 11.rész - .prc9 - Linkek és jegyzetek
Feliratkozás:
Bejegyzések (Atom)
Beépített PDF olvasó
Állítható a szöveg mérete
Autómatikusan forduló kijelző