Intro
A mobipocket a legtöbb eszközön egy nagyon kényelmesen olvasható dokumentum-forma, de van egy csomó apró részlet, amitől igazán komfortossá válik az olvasása. Évek óta konvertálok állományokat ebbe a formátumba, és mindig lehet találni valamit, amitől az eredmény még "olvashatóbbá" válik.
Az alant leírt munkafolyamat és eszköztár csak egy a lehetséges nagyszámú módszerből. Ahogy egy tanult ismerősöm mondaná, lehet 5 perc és 5 óra alatt is publikációt gyártani. Ez nem az 5 perces változat. Próbáld ki, hogy neked mi áll a kezedere.
Hozzávalók:
- Egy nyersanyag, saját írás, vagy ingyenesen letöltött anyag valamelyik publikus oldalról, pl. a MEK-ről.
- Egy jó kényelmes szövegszerkeztő. A flamewartól most tekintsünk el, itt most a MS word fog ebben a szerepben megjelenni. A lényeg, hogy legyen a szerkesztőnek html kimenete.
- A "kipucolószkript". Jvoq és Elminster munkája, ami a Word (és momentán csakis a MS Word) html exportállományából kitakarítja azt a sok sallangot, amire semmi szükség a publikációgyártáshoz, ellenben békén hagyja a szükséges formázásokat.
- Egy kényelmes html szerkesztő. Ebben fogjuk a bemenő szöveg publikálás előtti finomhangolását elvégezni. Én a FrontPage nevű alkalmazás egy régi változatát szeretem, mert kellően egyszerű, de támogat bizonyos automatizmusokat, gyorsbillentyűket, van együttes WYSIWYG és kód nézet, és működnek a regular expression-ök.
- A MobiPocket Creator. Egy ingyenes alkalmazás Mobiéktól, ami a jól előkészített html-ből, metaadatokból és fedlapból full extrás publikációt készít. (FIGYELMEZTETÉS: ebből egy install kit van, de kétféleképpen lehet telepíteni. A PUBLISHER változatot tessék választani, ne a HOME verziót. Ugyanannyiba kerül (ingyen van), de több az opció.)
- Idő.
- Türelem.
- Gyakorlás
- Kísérletezés.
I. Stáció - a szövegszerkesztés.
Itt kezdjük el az anyag finomítását. Abból indulok ki, hogy tartalmilag már minden rendben van, és nincs helyesírási hiba. Formailag az alábbiakra célszerű ügyelni:
- Ne maradjon bent a szövegben feltételes elválasztójel.
- A gondolatjel legyen gondolatjel és ne kötőjel! Nagyon nem ugyanaz.
- Egy bekezdésben egy bekezdésjel legyen, ne soronként. A bekezdésket, ha nincs tematikus törés, ne válassza el üres bekezdés.
- A formázások, dőlt betűk és egyéb kiemelések legynek rendben. Dőlt betűk szoktak lenni pl. a versidézetek, a hajónevek, néha az egyes szám első személyű gondolatok, ez utóbbiak nem mindig.
- Ha vannak (voltak) a szövegben lábjegyzetek, ez egy kényelmes stáció, hogy egységesen endnote-ra cseréld őket.
A szakasz végén az anyagot mentsd el szűrt html-be.
Ha véletlenül egy szkennelt/OCR-ezett anyagot dolgoznál föl, a kidolgozottabb ajánláscsomag itt és itt olvasható.
Természetesen mindig tartsd be a hatályos szerzői jogi törvényeket, aminek a forrása, a félreértések elkerülése végett, a Magyar Közlöny.
II. Stáció - sallangtalanítás
A word által generált html-t a mellékelt kis script (a txt kitejesztés levágása után) szépen lepucolja. Ha véletlenül beszakadna, akkor a temp file végét megnézve ki lehet deríteni, a hogy a forrás melyik sora okozta, általában valami fifikásabb formázás (pl. kézi lapdobás). Ha a vad trükköktől eltekintünk, akkor egy nagyon letisztult html lesz az eredmény.
A script használata végtelenül egyszerű, egy explorer ablakban csak húzzuk rá a html állományt.
Érdemes egy szövegszerkesztővel belekukucskálni, pár opciót lehet állítani a REM ki- és bekapcsolásával.
Köszönet Jvoqnak és Elminsternek érte.
III. Stáció - a html "finomhangolása"
Hogy a prc megjelenítés összes finomságát kihasználjuk, nem árt, ha az alábbi módosításokat elvégezzük a forrásállományunkon.
A legfontosabb, hogy a bekezdések ne <p> taggel legyenek elválasztva, hanem </br>-rel.Search&replace a barátod. A <p> taggel ábrázolt bekezdések ugyanis alapértelmezve behúzott első sorral, és (A Kindle 3 kivételével) másfeles sorugrással kezdődnek. Viszont nekünk minden pixelre szükségünk van. A bekezdés eleji behúzás ellen, ha szükséges (lásd tompasor) az alábbi attribútum is véd:<p width="0">
UPDATE 2009 november
A <br/> tages bekezdés-elválasztás még a QVGA időkből származik, amikor is tényleg minden pixelre szükség volt. VGA vagy jobb felbontás esetén az első sor behúzása már korántsem olyan fájdalmas, viszont javítja az olvashatóságot.
A másfeles sortáv ellen pedig jól véd a
<p height="0">tag használata. Ezt lehet search&replace-szel, vagy a "kipucolóscript" megfelelő sorának bekapcsolásával intézni.
Kellemes mellékhatás, hogy a korábban a <br/> tag használata miatt elkódorgó szöveg-igazítások nem okoznak problémát. (Bekezdésen belül ugyanis csak egyféle igazítás lehet, és a <br/> csere jól megkavarhatta a szövegképet, ha belefutott egy középre- vagy egy jobbraigazításba.
- Használjuk a címsor stílusokat, mégpedig így: h2: szerző, h1: cím, h3: könyv, vagy kötet, h4: fejezet. Ha nincsen elvileg szükség a h3 szintre, mert csak fejezetek vannak, akkor is célszerű a h4 tag használata, mert a h3 túlságosan nagy a normál szöveghez képest.
UPDATE 2010 szeptember
Mint kiderült, a szerző és a cím megjelölésére nem a h1 és h2 a legszerencsésebb. Bizonyos parserek ugyanis szolgaian átveszik a heading hierarchiát és azt erőltetik a tartalomjegyzékben, illetve ha ilyet látnak, a magasabb szinteket odateszik az alacsonyabbak elé, ha kell ha nem.
Ilyen parsert használ pl. a stanza, és ha prc-t konvertálunk epubra, akkor is vannak kellemetlen mellékhatások.
Ezért a tudomány jelenlegi állása szerint kötetek/fejezetek tagolására kiváló a h3/h4, szerzőre címre meg ajánlott egy sima középre igazítás, félkövér/nagyobb font használatával.
UPDATE 2010 december
Maradhat a h2: szerző, h1: cím hagyomány, mert gyakorlatilag az összes platformra, (BlackBerry, iPhone, Android, MacOS, PC) elérhető a Kindle alkalmazás, mint natív prc megjelenítő program. A hagyománnyal viszont jól használható az alább bemutatott css kódrészlet
- FIGYELEM: a nulla magas (height="0") ÉS üres sorok nem fognak látszani, nem működnek elválasztásként. Ha szövegközi üres sorra van szükség, ezt a kódot használjuk:
<p> </p>
- Az állomány "fejébe" beszúrt alábbi css bejegyzés sokat dob az olvashatóságon. Html-ben ez amúgy majdnem teljesen értelmetlen, de így a fejezeteink mindig új lapon fognak kezdődni, és szabályozható a távolság a lapszéltől és a kenyérszövegtől.
UPDATE 2010 december
<html>
<head>
<title>A könyvem címe</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-16"/>
<style type="text/css">
h1 {
text-align: center;
margin-top: 35;
}
h2 {
margin-top: 25;
text-align: center;
}
h3 {
page-break-before: always;
text-align: center;
margin-top: 30;
margin-bottom: 1em;
}
h4 {
page-break-before: always;
text-align: center;
margin-top: 30;
margin-bottom: 1em;
}
p.noind {
text-indent: 0;
}
</style>
- Ez a css lekezeli az előre beadott headingekkel a teljes publikációt. A noind class-t használhatjuk a tompasorok vezérlésére, címek és üres sorok után, ahogy az a nyomdásztankönyvekben írva vagyon. FIGYELEM: Az egyes attribútumok sorrendje kötött. Ilyen a mobi parser, ha megvariálod a sorrendet, nem mindet fogja értelmezni.
<p class="noind">
- Optikai tuning. Néha nem árt bizonyos szövegrészeket (pl. levelek, újságcikk-részletek, emailek stb.) más betűvel szedni. A Kindle a default fonton kívül tud még monospacedet kezelni. Ezt a <tt> vagy a <kbd> taggel lehet jelezni. Hogy a méretek passzoljanak én ezt még megfejelem egy <small> taggel valahogy így:
<p class="noind"><tt><small>Email a hitveshez</small></tt></p>Célszerű a sok search and replace után még gyorsan átfutni a szövegen. (Ez itt egy minta-html, ez eredetije a MEKről való).
IV. Stáció - a publikáció összerakása.
Ehhez kell a Mobipocket Creator (Publisher install).
- Nyissunk egy üres publikációt. Ha jót akarsz, itt ne használj ékezetes karaktereket, mert ronda filenevet fog generálni. Húzzuk be a publikációs állományok közé az imént letisztított és kipolírozott html állományt.
- Másold be a publikációs alkönyvtárba a fedlap-képet, és a creatorban jelöld meg, hogy ez lesz a fedlap.
- Töltsd ki a metaadatokat, úgymint cím, szerző, műfaj stb. Beszúrhatsz egy rövid fülszöveget. És újfent meg kell erősíteni a fedlap képét.
- Csinálj tartalomjegyzéket. Egyszerűen írd be az tartalom-form első sorába, hogy Tartalom, és add meg a használt tageket. Pl h3 és h4, vagy csak h4. Ellenőrizd le a Preview in browser funkcióval, hogy minden fejezetcím jól látszik, és csakis a fejezetcímek látszanak. (Ha hibát látsz, pl üres sorok, vagy hiányzó fejezetcímek, a forrás html-ben javítsd).
- KINDLE EXTRA. A Kindle kezeli a fizikai tartalomjegyzéket (a.k.a. toc.ncx). Az alábbi poszt szerinti eljárással csináld ezt meg és fűzd bele az elmentett opf-be. A Kindle innentől kijelzi a fejezethatárokat a progress baron, és lehet fejezetenként lapozni.
- BUILD. Válaszd ki a kívánt tömörítést és titkosítást. Az egyszerűség kedvéért én standard tömörítést és zéró titkosítást szoktam választani. Nem is kérek pénzt az anyagokért.
Lehet olvasni.
V. Stáció - Post processing
Olvasgatjuk a jó kis anyagunkat, elvégre azért csináltuk. És beleszaladunk egy hibába. Vagy valamit átírnánk. Már nem úgy gondoljuk. Digitalizált és legálisan letöltött könyveinkben sajtó- vagy OCR-hibát lelünk. Vagy valami értelemzavaró félrefordítást. Ilyenkor célszerű a Highlight funkciót alkalmazni. A TFT platformok ezt tudják, az e-Inkes eszközök (a Cybook és a Kindle kivételével) sajnos még nem. Ha elég korrigálni valót találtunk, mehetünk vissza a Creatorba (duplaklikk az illetékes opf állományra), ott pedig a szöveg-htmlre kattintva elérhetővé válik az Edit with html editor funkció. Ez utóbbihoz célszerű a kedvenc editorunkat beállítani, hogy ne word vagy notepad nyissa meg az állományt. A szöveget a forrás html-ben javítsuk, utána újra build. És kész. Vagy legalábbis kezdhetjük újra az V. Stációt.
Jó munkát és jó olvasást!
Költözés: az eszmecsere és kérdezz-felelek elköltözött ide:
http://forum.ekonyvolvaso.info/topic/9-mobipocket-creator/
Az utolsó 100 komment: