Kindle DX (DeluXe): PRC készítés házilag 9.rész - .prc7

2011. február 3., csütörtök

PRC készítés házilag 9.rész - .prc7 - Karakterek és kódlapok

2/03/2011 05:10:00 du. | Bejegyezte: S. Hercegfi | Bejegyzés szerkesztése

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:

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: