Sokan példát vehetnének erről a blogról. Egyfelől szent őrültek gyülekezőhelye (és ebbe magamat is beleértem) másfelől ha vannak is vérmes véleményütközések (azok pedig vannak) a legtöbbször abból is konstruktívan jövünk ki.
A minap volt egy kis vitánk az egyik poszt alatt. Ez a vita kellően inspirálóan hatott az egyik rendszeres olvasónkra, akinek az azonosságát saját kérésére nem tesszük közzé. Nevezzük csak egyszerűen Maximalista Olvtársnak, vagy röviden Maxnak. Max a csúcsokat ostromolja, és szerencsére a tapasztalatait velünk is megosztja.
Olvassátok, okuljatok.
A könyvkalózkodás tematikát továbbra sem szeretnénk bátorítani, de tény, hogy rablóból lesz a legjobb pandúr, és momentán a civileknél gyűlt össze a legtöbb tapasztalat. A tudás innentől hozzáférhető. Ha valakinek kereskedelmi ajánlata lenne Max irányába, keressen nyugodtan, továbbítom a kérést.
Dworkyll
PS: bár sok szó esik a posztban a könyvkalózkodásról, alapvetően ez egy gyártástechnológiai írás. A kalózkodást kérdéskört ne itt feszegessük, arról tervezek egy önálló posztot. Akinek mondandója van róla, az tartogassa még egy kicsit, hamarosan elsütheti. Sajnos az írás nagyobb, hogysem a blog.hu motorja egyben megenné, ezért két részletben közöljük.
A szenvedelmes könyvkalóz
Miért is lettem könyvkalóz? Hosszú, de egyszerű a történet, akit érdekel a „tanoda” után elolvashatja, itt most egy tapasztalatokon alapuló leírás/ajánlás következik az e-könyvek előállításról, bárki számára elérhető programok segítségével.
Hogyan is lehet/kell egy nyers, bescannelt, majd ocr-en átzavart szövegből e-book-ot készíteni? Esetleg egy kiadónál a rendelkezésre álló forrásszövegből ugyanezt? Az eszköztár mindkét esetben azonos, a munka az elsővel némileg több.
Szükséges programok
Itt abból indultam ki, hogy épp elég bűncselekmény gyanánt a könyvkalózkodás, ezt tegyük olyan programokkal, amelyek bárki számára elérhetőek és ingyenesen használhatóak. A kiadóknak persze némelyiket meg kellene venni, hogy tényleg jogosultak legyenek a használatra. Erről az adott program licence ad pontos információt.
LibreOffice
Ez az StarOffice-ból, több lépésben kialakult irodai programcsomag. Testvére az Apache OpenOffice (korábban OpenOffice.org). Jelenleg a LibreOffice-nak két „ága” van, a 3.5.7, illetve a 3.6.2 a legfrissebbek. Akinek még nem volt telepítve, annak érdemes először a 3.5.7-et felrakni. Okáról később. Linux és Windows verzióban egyaránt használható.
LibreOffice extension-ok
Ezek a programba betölthető kiegészítők. Alapvetően a writer2epub-ra lesz szükségünk. Ha ez a link nem jó, el lehet indulni a forrástól is. Ez olasz nyelvű, de a Download megtalálható könnyen. A telepített LibreOffice-ba betölthető a Kiterjesztéskezelővel (az Eszközök menüben található), vagy kettőt klikkleve az oxt-n.
A másik, amit javasolt használni, a LightProof Grammar checker. Ez (beállítástól függően) figyeli a többszörös szóközöket, gondolatjel-kötőjel hibákat, kicseréli a törtjeleket valódi törtjel karakterekre, kezeli a triplaponotkat, kérésre az „f” ligaturákat, és még számtalan dolgot. A hibákat/ajánlásokat kék aláhúzással jelzi.
A LightProof extension-t nem tudjuk hozzáadni a 3.6.x sorozathoz, mert egy "kivonatolt" részét már tartalmazza és telepítés közben ezzel összeakad. Ha a 3.5.x sorozathoz hozzáadtuk és ezt update-ljük 3.6.x-re, örökli a korábban telepített verziót és teljes értékűen használható lesz. Emiatt érdemes a kezdő LibreOffice-ozóknak előbb a 3.5.7-tel indulni. Ha ezt a kiegészítőt nem akarjuk használni, mehet egyből a 3.6.x legfrissebb verziója (elvileg félévente van frissítés).
A fentieken kívül számtalan extension-t lehet letölteni hozzá, ki-ki a neki megfelelő készletet rakhatja össze.
Ha valaki FB2-t is szeretne, kiválóan használható az OOOFBTools kiegészítő. Ez orosz fejlesztés (ahogy a FictionBook formátum is), így a mellékelt leírás orosz nyelvű, de maga az extension beszél" angolul, így a használata nem lehetetlen oroszul nem olvasóknak sem.
Sokszor segít az „Alternative Searching” vagy „Alt. Find and replace” kiegészítő, ez megtalálható a kiterjesztéskezelőből indított „További kiterjesztések letöltése” linken. Ebben rengeteg előre definiált „reguláris kifejezés” alapú keresés benne van, nem kell kitalálni, hogy hogyan is kell pl üres sorok keresését definiálni.
Sigil e-pub editor Van belőle windowsra, linuxra, mac-re, 32 és 64 bites, ki-ki a neki megfelelőt használja. Ez egy e-pub forrásszerkesztő, aminek van WYSIWYG üzemmódja és forrásszerkesztő módja egyaránt, menet közben lehet oda-vissza váltani. Beépített szintaxis ellenőrző figyelmeztet a be nem zárt tag-ekre, hibásan használt opciókra. A betöltött e-pub-ot automatikusan a megfelelő könyvtárszerkezetbe rendezi, ha az eredetileg nem ilyen lett volna. A „book” nézetben nagyjából azt látjuk, amit majd az olvasó program fog mutatni. A „nagyjából” azt jelenti, hogy a QT alap miatt ugyanazon az oldalon nem tud egyszerre dőlt és vastagított szövegeket megjeleníteni, de minden egyebet (beágyazott képek, táblázatok, iniciálék, beágyazott betűtípusok) úgy mutat, ahogy az majd egy ADE képességekkel bíró olvasón látszani fog.
A ma reggeli frissítéssel (0.6-os verzió) sok változást, bővítést vittek a programba, amelyek közül az egyik némileg nehezíti a magyar billentyűzetet használók életét. Az Altgr billentyűnket Ctrl+Alt-ként érzékeli, így mindaddig, míg az Edit - Preferences - Keyboard Shortcuts beállításnál ki nem cseréljük azt a 4-5 kombinációt, ami Ctrl+Alt+valamit tartalmaz, nem tudjuk beírni pl a & karaktert a megszokott módon. A lényeg, hogy egyelten olyan se legyen köztük, ami CTRL+Alt kombinációt igényel.
Kindlegen
Létezik Windows, Linux, MAC verziókban. E-pubból MOBI (KF8) formátumra konvertál. Parancssoros alkalmazás.
Valamilyen szövegszerkesztő (text editor). A Notepad minden windows-os gépen ott van, de elég fapados. Helyette inkább a PsPad (http://www.pspad.com/), vagy a Notepad++ (http://notepad-plus-plus.org/) javasolt. Mindkettőhöz létezik magyar felület, rengeteg funkcióval segítik az xml/html fájlokban turkálókat. Kiegészítőkkel tovább okosíthatók. Én mindkettőt használom, mert kis eltérések vannak a kezelésükben. Shell scripteket inkább a pspaddal, e-pub xhtml-eket inkább a notepad++-szal javítgatok. De mindenkinek megvan a maga kedvenc és megszokott editora, használja azt. Ha képes az xml/html tag-ek kiemelésére és kezelésere, már jó.
Valami, amivel szétszedjük a Kindlegen által generált mobi-t. Ez akkor kell, ha prc-t is akarunk, a mobipocket readerhez, vagy egyéb, prc-t olvasó ketyeréhez. A mobival nem mindig bírnak el, ráadásul a mobi 3-4-szer akkora, mint a prc (ami egyébként enne van a mobiban).
Erre én a Calibre Mobi-Unpack kiterjesztését használom.
A kicsomagolt prc forrást a MobiPocket Creatorral lehet prc-vé alakítani.
Műveleti sor
Legfontosabb feladat a forrásanyag rendbetétele. Ehhez el kell olvasni, ki kell javítani a tördelési és ocr hibákat (kiadók esetében sem árt, ha valaki újra elolvassa, mert mostanság elég sok, bár szerencsére csökkenő számú, sajtóhibát lehet a nyomtatott könyvekben is találni). Rengeteg módja van, sokan makrókat írnak hozzá, én jobb szeretem a „kézi” megoldásokat (keres-cserél). A makrók is ezt végzik, csak gyorsan és igazából követhetetlen módon.
A forrásunk lehet eleve formázott, szerkesztett, ocr hibáktól mentes (kiadónál/nak dolgozunk), de épp csak felismerhető szerkezetű, ocr-ezett anyag is. Gyakoribb a második, így azt boncolgatnám inkább.
Tehát: betöltjük az anyagot a LibreOffice writer-be. Ha ez nem eleve odt, a folyamat meglehetősen lassan tud elindulni. Kivált, ha rtf-fel kezdünk. Várjuk ki türelemmel, majd ahogy kész mentsük ki odt-be, zárjuk be a programot, majd újra indítsuk el és olvassuk be az imént mentett odt-t. Nem lett szebb, de egy csomó memóriát felszabadítottunk a továbbiakhoz. Érdemes 5-10 perces automatikus mentést beállítani, mert általában rengeteg módosítás következik.
Állítsuk be az Eszközök, Beállítások, Libreoffice Writer, Formázási segédletek panelén, hogy mutassa a nem törhető szóközöket, tabulátorokat is szerkesztés közben, így feltűnik, ha valahol felesleges van belőlük, vagy ha valahonnan hiányzik.
A formázás beállításával kezdjük. A tipikus ocr kimenet valamelyet hasonlít az eredeti kötetre, de az oldaltörések hiányoznak, a címsorok talán elkülönülnek, de csak „helyi” formázással, nem külön bekezdésstílussal szedve, stb…
Mielőtt nekiállna valaki a tördelésnek, egy alapszabályt meg kell tanulni. A szerkesztő program oldalakkal operál, a könyvekhez szokott szemünk is azt követné. Az e-book olvasók ellenben nem. Ott egy folyamatos „papirusztekercs” látszik, aminek a szélessége adott és a képernyőt mint egy csúsztatható ablakot tologatjuk le-föl rajta, ráadásul ezen a tekercsern a betűk mérete nem eleve meghatározott, olvasás közben változhat és változik is, kinek-kinek az ízlése szerint. Azaz ne a megszokott oldalakban, csak azok arányaiban gondolkodjunk a tördelésnél. Nem tudhatjuk, hogy az olvasón mekkorák lesznek a betűk, milyen széles és magas lesz ez az ablak. Azaz semmit ne állítsunk fixen képernyőpixelekre, vagy tipográfiai pontokra méretezve. Ez némileg ellentmond annak, hogy pl. a betűmérete meg kell határoznunk, ahogy a sormagasságokat, sorközöket, bekezdések egymástól való távolságát, de ezt ahol lehet tegyük „arányítva” és %-ban, ahol nem, ott meg inkább pt (tipográfiai pont) méretekkel, nem pedig cm, mm, vagy px mértékegységekkel. Egy idő után megszokja az ember azt a gondolkodásmódot, hogy az alapértelmezett bekezdés betűméret 12pt, minden mást ehhez arányítunk, tehát a címsor ennek duplája, másfélszerese, háromszorosa, stb. Ahogy az adott kötet igényli. A LO Writerben megadható az alap betűméret %-ában, de ha az arányokkal számolunk, megadhatjuk konkrét pt adatokkal is. Javasolt az oldalakat A5-ös, 36pt széles (minden irányban) margókkal felvenni. Így elég közel leszünk az elterjedt 600x800-as, 6"-es e-book olvasókhoz méretbe és arányokban is. Az esetleges képeket is a sorok méretéhez arányítva állítsuk be, bár végeredményként ez is fix px méreteket fog eredményezni, de hozzászokunk ehhez az arányított látásmódhoz.
Minden könyv elején van borító, ezzel itt most nem kell foglalkoznunk. Van copyright oldal, ahol felsorolják a mű megalkotásában résztvevőket, rögzítik azt a jogot, ami ellen épp vétünk, megadják az eredeti mű címét, ha fordításról van szó, stb. E-book esetében nem fontos, hogy ezek ugyanúgy 2-3 oldalra legyenek tördelve, mint nyomtatva, bár ha a szerkezet megkívánja, a megfelelő bekezdések elé beszúrhatunk egy lapdobást. Vigyázat, néha az ilyenek egy üres oldalt eredményeznek, ezért érdemesebb a beszúrás helyett a legfelülre kerülő bekezdés paramétereinél megadni, hogy ez előtt lapot kell dobni. Úgy általában is szokjuk meg, hogy a lapdobásokat, és bekezdéstávokat mindig a következő bekezdésnél állítjuk be. Ha tehát két sor között nagyobb térköz kell, mint a megszokott, akkor nem az előtte lévő sor alsó margóját (térköz bekezdés alatt), hanem a következő sor felső margóját (térköz bekezdés fölött) állítsuk 0-nál nagyobbra. Ez a prc miatt kell, abban ugyanis nincs értelmezve az alsó és a jobb margó.
Mindenképp külön oldalra kell kerüljön a főcím, ami tartalmazza a szerzőt, a kötet címét és gyakorta a kiadót.
Ha már belekezdtünk a bekezdésstílusok létrehozásába, érdemes átgondoltan dolgozni. A writer2epub megkívánja, hogy azokat az egyedi bekezdésstílusokat, amelyeket használni akarunk az e-pubban is, a „w2e_” karaktersorral (macskakörmök nélkül) kezdődő nevekkel lássuk el. A konverzió előtt erre figyelmeztet is, így érdemes eleve így kezdeni. Az alapvető bekezdéseket (címsor, lábjegyzet, alapértelmezett, jobbra igazított, stb…) nem kell, ezeket automatikusan kezeli, de az általunk létrehozottakat igen, különben ezek a bekezdések egyszerű alapértelmezettként <p> </p> kerülnek át, ami nem lesz jó. Nálam tipikusan ilyenek szerepelnek: w2e_first, w2e_bigtopmargin, w2e_stanza, stb… Fontos, hogy a címsorok a Writerben beépített Címsor 1, Címsor 2, stb… stílusúak legyenek (mármint a nevük, a beállításaikat szabadon piszkálhatjuk), ezeket h1, h2, stb… stílussal menti át. Ha nem ezeket használjuk, nem tudja elkészíteni a toc.ncx-et és a „html” tartalomjegyzéket.
A minap belefutottam a writer2epub egy korlátjába. Egy könyv rengeteg idézetet és hozzá tartozó szerzőt, megjegyzést tartalmazott, amelyek méretüktől függően más-más elhelyezési beállítást igényeltek, így több mint 60 bekezdésstílust sikerült létrehoznom. A konverzió egy index túlcsordulással elszállt. Jeleztem a kiterjesztés készítőjének, de még nem válaszolt. Az biztos, hogy amint lecsökkentettem ezt a mennyiséget a felére, az e-pub gond nélkül létrejött. A pontos határt nem tudom. Emiatt a kész e-pubban kézzel kellett visszaállítani az eredetileg elképzelt formázást úgy 40-50 ponton.
Tipikus beállítások nálam (nem kötelező, de bevált):
Oldal: A5, minden oldalon 36pt margó
Alapértelmezett bekezdés: 12pt méretű betű, 115%-os arányos sormagasság. Bekezdés alatt-fölött 0pt távolság. Sorkizárt (justified), Fejezetkezdő első sor 12pt behúzással. Jobb és bal margó 0pt. Fattyú (3) és árvasorok (2) figyelése. (ezt elvileg az e-pub olvasók kezelik, gyakorlatban még nem láttam olyat, de nem baj, ha benne van)
Fejezetkezdő bekezdés: 12pt méretű betű, 115%-os arányos sormagasság. Bekezdés alatt 0pt, fölötte 24pt vagy nagyobb távolság. Sorkizárt (justified), Első sor 0pt behúzással. Jobb és bal margó 0pt. Fattyú (3) és árvasorok (2) figyelése.
Címsor 1: 24-36pt betűméret, a betűtípus a könyvtől függ. Címsor 1 előtt lapdobás. Sormagasság betűtípusfüggő. Vannak nagyon magas betűtípusok (pl Matrix Tall), amelyek megzavarják a parsereket, és ha nem adunk 200%, vagy esetleg nagyobb sormagasságot, levágják a betűk alját vagy tetejét. Ki kell kísérletezni, de majd az e-pubban. Általában nem szoktam vastagítani, elég a nagyobb méret. Alsó-felső távolság 0. Igazítás: könyvfüggő.
Címsor 2 és továbbiak: 18-24pt betűméret, ha kell vastag, vagy dőlt, esetleg eltérő típus. Fölöttük 24-36 pont térköz, alattuk 0. Igazítás könyvfüggő.
Versszakok: Betűméret 12pt, ha prózába beszúrt versek, akkor dőlten szedve. Felső margó 12pt, egy versszak sorai „lágy sortöréssel” (Shift+Enter) elválasztva. Így egy versszak, egy bekezdés. Balra zárt (esetleg középre igazított, de ez általában nem túl szép), méretfüggő bal margóval, amit érdemes %-ban megadni. Ez a kijelző szélességében értendő, azaz 25%, a képernyő negyedéig betolt sorkezdés. Behúzás nincs, bekezdés egybentartása javasolt, bár egyelőre ezt sem kezelik az e-pub olvasók. Az utolsó versszak után következő sor vagy, 12pontos „felette” térközzel beállított bekezdés, vagy olyan, mint a fejezetkezdő, de csak 12pt felső margóval.
Így haladva szép komótosan beállítjuk a kötet formáját. Ez viszonylag gyorsan megy, mert nem foglalkozunk a figyelmes olvasással, csak pörgetni kell az oldalakat és ahol kell, beállítani. Sajnos rtf-ből kiindulva minden bekezdés Default lesz, az eltéréseknél egyedi beállításokkal, amelyeket gyakorlatilag bekezdésenként kell leszedni a bekezdésen kiadott „jobbklikk – Közvetlen formázás törlése” lépsekkel. Ez egyben törli a bekezdésben található dőlt vagy vastagított szövegek beállítását is, így ezeket vissza kell állítani.
Tapasztalati javaslat: A szövegben megtalált fejezetcímtől a következőig kijelölöm az összes bekezdést, majd duplaklikk az „Alapértelmezett” formázáson. Visszafelé pörgetve azok a bekezdések, amelyek nem vették fel az Alapértelmezett kinézetét, tartalmaznak valamilyen helyi beállítást. Dőlt betűket, lábjegyzet mutatókat, ilyesmiket. Ezeket meg kell jegyezni, majd az adott bekezdésen alkalmazni a „közvetlen formázás törlését”, aztán visszaállítani amit kell. Kicsit munkás, de megéri. Lehetne automatizálni is, de az több hibát okozhat, amelyeket később tovább tartana javítani, mint maga a művelet.
Persze a közben megtalált hibákat is érdemes javítani.
A tördelés beállítása után jöhet a nyers hibakeresés. Ez még mindig nem a figyelmes átolvasás, csak a durva hibák megkeresése.
Tipikus hibák, ocr után:
Felesleges sortörések. Ezek az eredeti kötetben az oldalak végén megtörő bekezdésekben szoktak megjelenni, ha az ocr program nem képes egyesíteni az ilyen mondatokat. Viszonylag gyorsan meg lehet őket találni egy „regular expression” (reguláris kifejezés) alapú kereséssel. Vagy rákeresünk az olyan sorokra, amelyek nem „.:!?” végűek, vagy megkeressük azokat a sorokat, amelyek kisbetűvel, vagy szóközzel kezdődnek. Legjobb mindkét keresést megcsinálni, előbb a sorvégekre, majd a kezdetekre. Néha nagybetűvel kezdődik egy ilyen feleslegesen kettétört sor második része, így azt csak a kisbetűs sorkezdetre vonatkozó keresés nem találná meg.
A reguláris kifejezés alapú keresést a Ctrl+H-ra megnyíló ablakocska „Több beállítás” gombja mögötti részen lehet beállítani. Vigyázat! Ha benne marad a pipa később, akkor egy olyan cserére, ami „.”-ot (pont) tartalmaz, a teljes szöveget képes lehet lecserélni.
A reguláris kifejezésekkel érdemes megismerkedni, de tudni kell, hogy némileg eltérőek lehetnek a mintaértelmezések a különböző szerkesztőprogramokban.
Példa:
^[:lower:]
Ez keresi meg a soreleji kisbetűket, ha a „Kis és nagybetű megkülönböztetése” be van kapcsolva a kereső ablakban.
[^\.\:\!\?]$
Ez meg a sorvégi nem „.:!?” karaktereket. (LibreOffice Writer „nyelvjárásban”)
Az ilyen sorokat egyesítsük. A triplapont (html kódban: …) karaktert jobb esetben csak 3 db pontként adta vissza a scanner és az ocr, ennek cseréje gyorsan megoldható (vigyázat, ne maradjon bekapcsolva a „reguláris kifejezésre” keresés, mert ezzel az egész szöveg triplapontokra cserélhető véletlenül), de előfordul .. . vagy .:. esetleg .., és még számtalan variáció is. Ha használjuk a LightProof kiterjesztést, ez szépen aláhúzza mindet. Figyelni kell az aposztrofra is. Ezt majdnem mindig a „sima” ' karakterként adja vissza az ocr, ami magyar szövegben hiba. Cseréljük a normális szimpla „hiányjelre”, az pont az ellenkező irányba dől, mint a billentyűzetről bevihető verzió.
A párbeszédeket tartalmazó sorok kötelezően „gondolatjel – nem törhető szóköz” (html-ül: – ) karakterpárral kezdődnek. Innen a kötőjel, szóköz irtandó. A cseréhez a „reguáris kifejezés” használata javasolt, mert azzal meg lehet adni, hogy a sorok elején lévőket akarjuk cserélni. A szövegben gondolatjel helyetti kötőjeleket a „ - ”, „ -, ”, „ -; ”, és a „ -[:alpha:]” (ez megint csak a reguláris kifejezés bekapcsolását igényli) keresésekkel találhatóak meg.
Gyakori ocr hiba, hogy a párbeszédet jelölő sor eleji gondolatjeleket felsorolásjelként értékelik, és a szöveget felsorolásként jelenítik meg. Ez nagy hiba, ki kell javítani. A LO Writerben, ha be van kapcsolva a „formázási segédjelek mutatása”, nagyon szembeszökő az ilyen probléma. Tipikusan tabulátorok (gyakran mindkét oldalon több) vagy nem törhető szóközök közötti kötőjel vagy gondolatjel után következik a szöveg. Ki kell jelölni ezt a karaktersort, és a Keres-cserél funkcióval gondolatjel-nem törhető szóköz kombinációra cserélni.
Mindenképp ki kell szedni az üres sorokat és a többszörös szóközöket. Ez utóbbi egyszerű. Rákeresünk az egymást követő két szóközre és lecseréljük egyre. Ezt addig kell ismételni, míg azt nem mondja a cserélő rutin, hogy nem talált többet.
Az üres sorokra „reguláris kifejezéssel” találhatunk rá:
^$
Ez a teljesen üres sorokat találja meg, amelyekben semmi nincs a sor eleje „^” és vége „$” között. Érdemes lehet még a „^ $”-ra is rákeresni, ha egy sorban egy szóköz van csupán, azt is megtalálja.
Az üres sorokkal való tagolásról itt-ott vita folyik. Van aki szerint jó, ha ilyen van a szövegekben, mert ha txt-re konvertál valaki, akkor megmaradnak a tagolások, míg ha az e-book-okban szabályos alsó-felső margókkal operálunk, a txt-re konvertálás után ezek elvesznek. Nos a szabályos e-book olvasók az üres sorokat nem mutatják meg, hiába vannak a könyvben, emiatt pont az elválasztó funkció vész el. Maradjunk a szabályos és bevált távolságbeállításoknál, az üres sorokat pedig takarítsuk ki. A txt-re konvertálást meg egy shellscripttel kell elvégezni, ami a megfelelően méretezett (tehát 0-nál nagyobb felső margóval bíró) sor elé beszúr egy üres sort.
A tabulátorokat is el kell távolítani. Ha „tabulált” tagolásra van szükség, azt keret nélküli táblázatcellákkal érdemes megoldani, akkor biztosan nem fognak szétcsúszni a szövegeink, míg a tabulátorok méretét nem tudjuk az olvasó programok számára meghatározni, az vagy adott, vagy a program beállításainál meghatározható, azaz mindenütt más lesz. A jól (a kijelző szélességének %-ában) méretezett táblázat ellenben mindenütt olyan lesz, amilyennek elképzeltük.
Ha ezeket a hibákat szépen kijavítottuk, jöhet az olvasás. Ez elmaradhatatlan. Legjobb az eredetivel összevetve olvasni, azaz ha valahol valami nem egészen tiszta, fellapozzuk az eredeti kötetet és megnézzük, hogy mi szerepel a nem értelmezhető szó helyén. Lehet, hogy már ott is rossz volt. Az olvasást elvégezhetjük az LibreOffice-on belül és külön egy e-book olvasón is. Ha a tördelés közben azt látjuk, hogy nincs túl sok javítani való a szövegben, akkor érdemes egy nyers e-pub-ot készíteni, azt áttölteni a mobil olvasóra, és ott olvasni. Eközben a hibás részeket megjelöljük és a könyvjelzők vagy megjegyzések alapján a hibákat javítjuk a forrás odt-ben. Ha nagyon sok a hiba, akkor ez kevéssé hatékony, a LibreOffice helyesírás ellenőrzője és azonnali javítási lehetőség sokat gyorsíthat. De ez ebben a formában nem annyira élvezetes, inkább munka, mint olvasás. De kihagyni nem lehet semmiképp. Számtalan olyan szó lesz a könyvben, ami értelmes magyar szó, helyesírásilag is jó, csak épp nem oda való. Az ocr program nem értelmesen olvasta a szöveget, hanem a szótárából kiválasztotta azt a szót, ami a legközelebb áll a betűképhez. Ez vagy jó oda, vagy nem. Ezeket is javítani kell, persze az eredeti szöveggel összevetve.
E-pub generálás:
Nem túl bonyolult dolog. A telepített writer2epub 3 gombot tett a Writer „Eszköztárai” közé. Egy sarkára állított szögletes zöld „e” betű, egy ugyanilyen kis kék i-vel és egy ilyen kis piros p-vel.
Az utolsó a beállító gomb. Túl sok dolog nem módosítható. Ami fontos: mutassa-e a metaadat ablakot a konvertálás előtt (érdemes bekapcsolni). A „Helyezi W2E hitelek végén a könyv” magyarul azt engedi meg, hogy az e-pub végére beszúrjon egy oldalt a W2E logójával.
A kék i betűs gombnál lehet a metaadatokat kitölteni. A Document Preferences-nél megadható, hogy akarunk-e tartalomjegyzéket (ez a html tartalomjegyzéket, azaz a könyvben is megjelenő, a fejezetekre mutató linkeket tartalmazó generált jegyzék és nem a toc.ncx): Add Index page… Az „Index” szó helyére beírható a Tartalom és akkor ez lesz az oldal címe is.
Beállítható, hogy h1, h2 és h3 címsoroknál szabdalja-e a könyvet fájlokra. Ez fontos kérdés, ugyanis ahol vág, ott mindenképpen lesz oldaltörés. Ha a kötet szerkezete a h2, h3 szinteken nem kezd új oldalba, akkor azoknál ne legyen darabolás. A „Split Files every xxx kb” az ADE butasága miatt kell. Az nem képes az e-pubot kezelni, ha a benne lévő xhtml-ek valamelyike nagyobb, mint (talán) 260kb.
Itt megadható a widow és orphan (özvegy és árva, magyarban inkább fattyú és árva) sorok beállítása. Ezt az alapértelmezett bekezdés stílushoz hozzá is fogja adni a styles.css-ben. Ha módosítani kell, később a Sigilb-en megtehetjük. Elvileg be lehet állítani a betű (font) beágyazást is, de nekem még sosem sikerült megfelelően, így inkább kézzel csinálom később.
A harmadik (pontosabban az első) gomb ugyanazt hozza fel, amit az „i” betűs, ha a beállításoknál megadtuk, hogy a metaadat panel nyíljon meg konvertálás előtt. Ha nem, akkor nem. Az OK-ra indul a konverzió.
Az eredmény – ha sikeres – egy e-pub, aminek a neve ugyanaz, mint az odt-é. Ha nem sikerül, hanem hibaüzenetet ad, akkor kereshetjük, mi baja. Ebben nem tudok tanácsot adni. Egy lehetséges problémát feljebb leírtam.
A kész e-pub-ot be kell dobni a Sigil-be. Szó szerint. Egérrel ráhúzzuk a Sigil ikonjára és megnyílik, beolvassa és lehet javítani.
Kezdődik a munka szebbik része, az e-pub „forráskódját” alakítgatjuk kedvünkre. A Sigil jó tulajdonsága, hogy a nézetnél kiválasztható a „split”, ami azt jelenti, hogy a szöveg a nagy ablakban felül könyv formában, alul pedig xhtml forrásként szerepel. Ha ebbe belejavítunk felül rögtön látszik a módosulat. Mint már jeleztem némi hiányosság, hogy a dőlt (italic vagy emphasized) szövegek nem minden esetben jelennek meg ténylegesen dőlten, ez a Sigil alapjául szolgáló Qt libek hibája.
Először is pakoljuk be a betűinket. Ez elkerülhetetlen akkor is, ha teljesen szokványos betűkészleteket használunk, mert az őű karaktereinket az olvasók egy része csak akkor jeleníti meg, ha az benne van a beágyazott betűkészletekben. Más része még akkor sem, de az olyanokkal nincs mit tenni. A beágyazás két lépésből áll. Először fizikailag hozzá kell adni a betűfájlokat az e-pubhoz. Jobb klikk a Fonts mappán, „Add existing files” és már kereshetjük a szükséges fájlokat.
Tudnunk kell, hogy az olvasó programok csak akkor jelenítenek meg dőlt betűket, ha azok ténylegesen ilyen formában ott vannak az e-pubban. Azaz egy normális könyvhöz kell az alap betűkészlet (regular) és annak dőlt (italic) formájú fájlja is. Magyar könyvekben vastagítással nem illő kiemelést csinálni, de ha mégis, akkor kell a betűkészlet vastag (bold) és esetleg a vastag-dőlt (bold-italic) verziója is. Ez mind egy-egy külön fájl. Ha a címeket vagy bármit az alapértelmezettől eltérő betűvel akarunk megjeleníteni, azokat is hozzá kell adni a könyvtárhoz. Az e-pub ajánlása otf formátumot ír elő, nekünk meg általában ttf-jeink vannak. Tulajdonképpen házi használatra az is jó, de ha szabályosak akarunk lenni, először be kell szerezni, vagy elő kell állítani az otf-eket.
Kis kitérő: a fontok ugyanúgy szerzői jogvédelem alá esnek, mint a szövegek, de a betűkért eladott példányonkénti licence díjat kellene fizetni. Azaz ahány darab e-pub-ot sikerül eladni, annyiszor csengetni kell a felhasznált betűk készítőinek, vagy jogtulajdonosainak. Ez szép kis összeg lehet, meg amúgy is szeretek becsülettel könyvkalózkodni, így megkeresem a kötetben használt betűkhöz kinézetben legközelebb álló szabadon használható típust. Rengeteg ilyen található csak van egy kis hibájuk. Általában nem tartalmazzák a magyar ékezetes karaktereket. A legtöbben „éáíó” még csak akad, de „őű” nem. Tehát ezt is meg kell csinálni. A betűk kereséséhez nagyon jó kiindulás a http://www.myfonts.com/WhatTheFont/ oldal. Ide fel kell tölteni a szövegről készített képernyőképet (screenshot), lehetőleg az ott megadott paraméterekkel (fekete-fehér, bmp, max. 160pixel magas, a betűk jól elkülönülnek egymástól (be lehet közéjük húzni úgy egy függőleges vonalat, hogy egyok sem ér hozzá), stb…) és megkeresi a hozzá leginkább hasonlítókat.
Betűkészítésre, javításra a legjobb program a FontForge. Windowsra a http://fontforge.softpedia.com/ oldalról lehet letölteni, linux esetén része a disztrónak, csak telepíteni kell. Nem mennék bele tipográfiai és betűmetszői kérdésekbe. Ékezetes betűket úgy lehet viszonylag gyorsan és a betű képéhez igazodóan előállítani, ha a megfelelő pozícióba (azaz az őŐűŰ helyére) bemásoljuk az oOuU betűt (amelyik kell), majd az éáí (már ha van, mert ha nincs, akkor macerásabb a dolog) valamelyikéről levágott ékezetet, eltoljuk jobbra, készítünk egy másolatot, azt eltoljuk balra, betartva a szükséges arányokat, majd a kész betűt elmentjük, Ismétlés a másik hárommal. Ha egyáltalán nincs leszedhető hosszú ékezet, akkor magunknak kell rajzolni, ami nem nehéz de fontos, hogy az adott betűkészlethez igazodjon.
Ha megvagyunk, akkor jön a File – Genrate font. Itt kiválasztjuk az otf-et és mentünk egyet. Nagyon rigorózus kollégák bekapcsolhatják a mentés előtt validálás opciót is, ezzel ellenőriztetve a betűk minőségét, de a legtöbb esetben ezzel több napos munkát sikerül magunkra venni. Kijavítani az eredeti „betűmetsző mester” trehányságait nem mindig felemelő, de mindenképp aprólékos meló még akkor is, ha a FontForge a legtöbbet egyszerű „klikk a Fix gombra” módon javítja. A ttf-jeinkből is hasonlóképp tudunk otf-et csinálni, FontForge-ba be kell olvasni a ttf-et, majd Generate Font, otf, hajrá.
A Fontforge még arra is jó lehet, hogy csökkentsük a kész e-pub méretét. Pl néhány spéci, csak a könyv címéhez, vagy pl. a főcímekhez használt betű miatt nem biztos, hogy érdemes egy komplett utf-8 készletet tartalmazó, megabájt méretű fájlt betolni az e-pubba, amikor pártíz kb-ból is megoldható. Ilyenkor a javasolt metódus: készíts másolatot az eredeti fájlról. Töltsd be a másolatot a FontForge-ba. Töröld ki az összes olyan karaktert, ami nem fordul elő a könyvben ezzel a betűtípussal szedve. Mentsd el. Add hozzá az e-pubhoz. Az is járható, hogy készítesz egy új fontot, abba bemásolgatod az eredetiből a karaktereket, de ez csak annak könnyű, aki már nagyon otthon van a betűmetsző szoftverek kifejezésrendszerében, pontosan tudja, melyik adat mit jelent, minek milyen értéket kell adni, mert egy új fájl gyakorlatilag üres, minden alapadatot be kell vinni, ami egy kész fájlban már benne van. Nem sok, úgy 40-60 változó, némelyikről nem sikerült kiderítenem, mire is szolgál. Jobb a törölgetés…
A fontokat tehát bepakoltuk a helyükre, már csak a könyvben kellene, hogy megjelenjenek. Ehhez benne kell legyenek a content.opf-ben (ezt a Sigil előzékenyen kitölti, nem kell vele foglalkozni) és a styles.css-ben. Ott viszont két helyen. Egyszer az elején, a fontdefiníciós területen. Valahogy így kezdődik egy jó styles.css (fontos: az e-pub olvasó kis- nagybetű érzékeny a fájlnevekben és a definíciókban egyaránt):
@namespace h "http://www.w3.org/1999/xhtml";
@font-face {
font-family:"Magyar Linux Libertine N";
font-style:normal;
font-weight:normal;
src:url(../Fonts/MagyarLinLibertineN.otf)
}
@font-face {
font-family:"Magyar Linux Libertine N";
font-style:italic;
font-weight:normal;
src:url(../Fonts/MagyarLinLibertineNI.otf)
}
@font-face {
font-family:"Inicialek";
font-style:normal;
font-weight:normal;
src:url(../Fonts/Inicialek.otf)
}
Majd ahol használjuk. Először megadjuk az egész könyv alapstílusát és az Alapértelmezett bekezdését.
@page
{
margin: 2%;
}
body
{
font-family: "Magyar Linux Libertine N", serif;
}
p
{
margin:0pt;
text-indent:0em;
text-align: justify;
font-size: 1.00em;
font-family: "Magyar Linux Libertine N", serif;
widows: 2;
orphans: 2;
}
Ezután azokhoz a bekezdésekhez, ahol ettől eltérnénk, szintén megadjuk a paramétereket:
span.logo {font-family:"Inicialek"}
Ez pl. egy logo, amit kénytelen voltam az InkScape és a Fontforge segítségével betűvé alakítani. Ha képként szúrom be, a szöveg méretének változtatásakor ennek mérete nem változna. Viszont olyan helyen szerepel, egy mondat közepén, ahol mint egy különleges karaktert használják. De ha karakter, akkor legyen is karakter, tehát betűvé kellett alakítani. Azért Inicialek.otf, mert már több ilyenem is van, ezeket ebben a fontfájlban tartom és amelyik kell azt használom, illetve ha újat kell létrehozni, ebbe rakom bele, de az e-pubba csak annyi kerül bele, amennyi ott kell.
Fontok a helyükön, jöhetnek a képek. Ha az odt-ben volt címkép, azt a writer2epub beillesztette az e-pubba, az első oldalra. Ajánlatos ezt gyorsan lecserélni valami jó minőségűre, mert az odt-ből újratömörítve került ki. Javasolt az elterjedt olvasók 600x800-as méretén belül maradó, de azt valamelyik irányban kitöltő képet beilleszteni. Úgy általában is a képek esetén abból induljunk ki, hogy az olvasók túlnyomó része ilyen paraméterekkel bír, tehát nagyobb képekkel ne bombázzuk, vagy ha mégis, akkor lehetőleg ezen méretek többszöröse (duplája, négyszerese) legyen. Ez ugyan a méretnek nagy pofont ad, de legalább a kép megjelenítő rutint nem terheljük le, illetve a kicsinyítés után nem lesz annyira gáz az eredmény. Azért a kisebb jobb…
A képek helye az Images mappa. Minden kép, ami az e-pubban előfordul ide kerül, ide hivatkozik rá a megfelelő oldalon és mindet érdemes kicserélni az eredetijére, mert az odt-ből átméretezve kerülnek át, gyakran elég csúnyára sikerednek. Fontos, hogy azonos névvel nem lehet bemásolni, előtte törölni kell, majd jöhet a helyettesítő darab, felülírni nem hajlandó. Amennyiben a címkép generálását is beállítottuk a w2e-nek, és az odt-ben is volt egy címkép, akkor az e-pub Images könyvtárában ugyanazt a képet megtaláljuk két méretben és minőségben. Igazából elegendő csak az, ami az első xhtml-ben is megtalálható, a másikat ki lehet törölni, csak ne felejtsük el a megmaradót megadni „Cover”-ként. Erről lejjebb lesz még szó.
Amennyiben egy új xhtml-t kell beszúrni (ritkán, de előfordulhat), a <head> </head> közötti részt másoljuk át egy már eleve létezett xhtml-ből „code” nézetben, hogy biztosan benne legyen a „style” definíció. Enélkül a styles.css-ben hiába állítgatunk bármit, erre a fájlra nem lesz hatása, az ebben lévő tartalom egy alapbeállítással fog megjelenni, ami biztosan nem megfelelő.
Ha ez is megvan, alaposabb elemzésnek vetjük alá a styles.css-t. Érdemes azokat a bekezdésstílusokat, amelyek biztosan nem fordulnak elő a könyvben, törölni. Legegyszerűbben a Sigil Keres (Ctrl+F) funkciójával deríthetjük ki, hogy egy gyanús típus használatban van-e vagy nincs. A keresés opcióiban választható az „all html files”. Ha egyikben sincs, törölhető a definíció. Vigyázat, teljesen ki kell törölni, a lezáró }-t is, mert ha bennmarad valami, akkor a mögötte lévő stílusokkal gond lesz az értelmezéskor. Ezek a felesleges stílusok a LibreOffice-ban létező, de fel nem használt beépített stílusok. Egyébként elférnek, de jobb, ha nincs semmi „hulladék” a fájlokban.
A megmaradó stílusokat is át kell nézni. Tapasztalataim szerint a kiemelt, nagy méretű betűkkel, illetve nagy térközökkel formázott stílusok esetében ezeket a méreteket és térközöket gyakorta felezni kell, illetve érdemes a 2.48em szerű méretetket átírni 2.5-re, esetleg 2-re, az adott oldal tényleges tartalmától függően. Fontos: csak em, és % legyen mértékegységként a css-ben. A px, pt és társai mellőzendők.
Táblázatok. Ezek nagy problémát okoznak minden esetben, mert az egyes parserek eltérően kezelhetik őket. Csak általános szabályként: a cellák (oszlopok) szélessége mindig legyen megadva, a kijelző szélességének %-ában. Összesen ne érjék el a 100%-ot, csak ha nincs más mód arra, hogy kiférjen a kívánt szöveg. Nem jó, ha mondjuk egy négy oszlopos táblázat esetén hármat beméretezünk, a negyedik meg lesz a maradék, mert pl. a prc olvasók ilyenkor lazán kitolják a táblázat szélét a képernyőn kívülre, ha egy túl hosszú szó szerepel ebben az oszlopban. Olyan, ami elválasztás/törés nélkül nem fér ki.
Tartalomjegyzéket generált a w2e, azzal sok gond nincs. Esetleg át lehet formázni. A css-ben az index kezdetű stílusok adják meg az egyes bejegyzések kinézetét, a Tartalom cím maga h1-es és bekerül a toc.ncx-be is.
Az egyes fájlokhoz „guide” fogalmakat lehet rendelni. Jobb klikk pl. az első xhtml-en, Add Semantics és a listából ki lehet választani pl. a Cover-t. Az egyes fájlokhoz hozzárendelhető fogalmak: Copyright, Colofon, Title Page, Table of Contents, Preface, Glossary, stb… Egy fájlhoz csak egy fogalom rendelhető hozzá így, de ha kézzel belejavítunk a content.opf Guide szekciójába (a Sigil tiltakozik ugyan ellene, de megengedi), akkor egy fájlhoz többet is hozzáadhatunk, de egy fogalom csak egyszer használható fel. Én ki szoktam javítani a megjelenő szöveget a magyar megfelelőjére. Borító, címoldal, szószedet, stb…
Ki kell tölteni a metaadatokat, majd mentés.
Tulajdonképpen az e-pub kész. Az, hogy hogyan fog kinézni, attól függ leginkább, hogy a készítő mennyire jártas az xhtml formázásban, mennyire tudja alkalmazni a css-ben használható paraméterezést, illetve mennyire tartja be az e-pub szabvány ajánlásait. Erről rengeteg dokumentáció elérhető a neten, illetve erősen ízlés és hajlandóság függő, így inkább nem foglalkoznék vele. Egy kiadó e-book gyártójának kötelező a lehetséges maximumot kihozni, így őket külön tanfolyamra sem árt beíratni, ha nincsenek eleve benne a dologban jó mélyen. Házi használatra ki-ki a maga igényének és szabadidejének megfelelően dolgozhat.
MOBI készítés
Nagyon egyszerű. Létre kell hozni az alábbi kétsoros cmd-t:
kindlegen.exe -c2 %1
pause
Ezt elmentjük, mondjuk mobigen.cmd néven a kindlegen.exe-vel közös könyvtárba, mellé másoljuk a forrás e-pubot (az epub kiterjesztésű fájlt ahogy van), majd egérrel rádobjuk a cmd-re. A megnyíló ablak elég gyorsan elpörög, emiatt van a pause a scriptben: ha elszállna valamiért a konverzió, meg tudjuk nézni, mi a baja.
Túl sok hiba nem szokott lenni, ha az e-pub egyébként rendben van. Ha mégis, elég pontosan megadja mi a baj, meg kell keresni és javítani.
A kész mobi kiterjesztésű fájl jó nagy lesz, nagyobb, mint a forrásául szolgáló epub.
PRC készítés
A kész mobi-t első lépésben betöltöm a Calibre-ba. Igazából itt nem sok tennivaló van, bár élő internet kapcsolat estén lehet pl másik borítót keríteni, vagy fülszöveget. Ezt persze vissza is kell vezetni az e-pubba, így ha itt töltünk le valamit, akkor ismét elő kell szedni a Sigil-t, elvégezni a módosítást, majd mobivá konvertálni, és ismét betölteni a calibre-be. Tipikusan az egész folyamat többszöri iterációval (jó esetben 2-3, de bonyolultabb könyvnél 10-20) megy végbe, egyenként ellenőrizni kell pl az e-pub-ot több olvasó programmal, esetleg e-book olvasó, tablet és mobiltelefon segítségével, javítani ahol kell, majd ismét ellenőrizni…
A mobi-nk tehát a calibre-ben van. A Mobi-Unpack kiegészítővel (jobbklikk a könyvön, a megnyíló menüből aktiváljuk a Mobi-Unpackot. Már ha a telepítéskor ehhez a menühöz adtuk). Gyors, bár nem optimális eredményt ad a Split KF8/MOBI parancs. Ez kibontja a fájlból az azw-t, a forrást és egy mobi kiterjesztésű fájlt, amit ha átnevezünk prc-nek, már mehet is az olvasóra, de a mérete még mindig túl nagy, amiből látható, hogy felesleges dolgok is lehetnek benne. Jobb eredményt ad az Unpack parancs. Mivel kissé háklis a célkönyvtár nevére (nem jöttem rá, hogy a szóközök, vagy az ékezetes betűk akasztják-e meg), én a D:\mobi könyvtárat szoktam megadni célnak, de szabadon választott. Létrejön egy mobi7 és és egy mobi8 könyvtár. Minket a mobi7 érdekel. Megtaláljuk benne a html fájlt, ami maga a könyv, az opf-et, az ncx-et és egy Images könyvtárat.
A html egyetlen nagyon hosszú sor, így a legtöbb editor fejre is áll tőle ahogy kell. Igazából nem kell beleturkálni, bár rengeteg felesleges dolgot (pl betűmeghatározások) is tartalmaz, amelyeket a mai prc olvasók nem kezelnek, később meg prc olvasók nem lesznek (ha a dolgok így mennek tovább), de kiszedegetni csak linuxos sed, grep, tr alapú shellscriptekkel lehet hatékonyan, így lehet, hogy jobb békén hagyni. Ha mégis bele kell túrni, fontos, hogy a kimeneti fájl utf-8 kódolású legyen, másképp lőttek az ékezetes betűinknek.
Amit mindenképp ki kell szedni, ha az e-pub-ban volt és a mobi-ba is átengedtük, az iniciálék és a szöveggel körbefolyatott, vagy pl egymás mellé elhelyezett képek, mert a prc olvasókban nagyon csúnya lesz az egész. Ezeket szépen egyenként, kézi munkával a html-ben kell kiigazítani.
Lehet, hogy ilyen esetben jobb eleve két e-pub-ot készíteni. Az egyik lesz Az E-pub és a mobi forrása, a másik meg a prc forrása. Ebből ki kell szedni a betűkészleteket és a rájuk való hivatkozásokat a css-ből (mindenhonnan), az iniciálékat „vissza kell tenni a helyükre” csak betűméret növeléssel jelezni, hogy ott valami különleges van. A körülfolyatott képeket is „normál” képpé kell alakítani. Ezt az egyszerűsített e-pub-ot kell betolni a fentiek szerint a Mobigen-be, majd kibontani belőle a prc forrást és elvégezni a Creatorral amit kell.
Ha szerkeszteni akarjuk a prc forrás html-t, először egy olyan programba kell beolvasni, ami képes a sorokra tördelést elvégezni, vagy egy megfelelő shellscripttel fel kell darabolni, mert az általános editorok ezzel a több száz kB hosszú sorral nagyon nehezen bírnak el, de számunkra is áttekinthetetlen. A darabolást érdemes a „</p>” karaktersor „</p>\n” karaktersorra cseréléssel végezni, egy reguláris kifejezéseket is kezelő editorral. Ez minden „</p>” után befűz egy sortörést. Ha kész, mehet a kedvenc editorunkba.
A feladat: a telepített MobiPocket Creatorral meg kell nyitni az opf-et. Ki kell tölteni a hiányzó metaadatokat (tipikusan: az ISBN, a műfaj meghatározása és a borítókép hiányzik, illetve a kiadás dátumát nem érti, mert más a formátuma, mint amit elvár), fontos, hogy a végén a lap alján lévő (le kell odáig görgetni) Update gombbal hagyjuk el az oldalt, másképp semmit sem csináltunk. Fontos, hogy a metaadatoknál a könyv nyelve is jól legyen beállítva, mert az olvasók abból tudják, hogy melyik szótárat kell hozzájuk társítani. Az e-pub-é automatikusan az lesz, ami az oprendszerünk nyelve, de ott is át lehet állítani másra, meg itt is.
Nagyon fontos!
A kicsomagolt mobiban az e-pubból örökölt „html” tartalomjegyzék is benne van, ami belekerült ebbe a forrásba is, így nem szabad a Creator tartalomjegyzék generátorát használni. Csak a metadata ablakában kell módosítást végezni, sehol másutt. A guide-t esetleg érdemes megnézni, ott megtaláljuk a Tartalomjegyzéket és a többi bevitt információt.
Build. Ha csak 1 warning-ot ad, az általában a borítókép mérete miatt van, de meg lehet nézni, mi a baja. Ha a borító kisebb, mint 800x600 (majdnem mindig kisebb), akkor szokott morogni.
A Creator allergiás a fájlnévben szereplő ékezetes betűkre, így ha az opf fájl nevében ilyet talál, azt ékezetteleníti és hozzáfűz egy hexa kódot. A MobiUnpack-ból ékezet nélküli névvel jönnek ki a szükséges fájlok, a visszanevezést csak a már kész prc-n végezzük el.
A prc-t érdemes egy Kindle készüléken, egy Kindle for valami olvasóprogrammal és a MobiPocket Readerrel is megnézi, hogy a nagyobb csúfságokat még időben felfedezzük és javítsuk. Szerencsére a kindlegen elég jól dolgozik, az adott formátumnak megfelelően végzi a paraméterezést, így ha valami nagyon trükkös dolgot nem felejtettünk a prc forrásban, nem kell aggódni.
Tulajdonképpen készen vagyunk, van egy prc-nk, mobi-nk (KF8), e-pub-unk, meg egy odt-nk. Esetleg ebből lehet pdf-et is készíteni, de akkor nagyon fontos, hogy a Writerben használjuk az árva- és fattyúsorokat, figyeljünk az oldalképre, „csatornákra”, túl sok elválasztásra, szétcsúszó, vagy majdnem üres oldalakra, stb. Ehhez gyakorta kell az egyes bekezdéses sormagasságával, betűméretével, sűrűségével foglalkozni, néha szavanként. Az e-book gyártáshoz ezek nem szükségtelenek és nagyon el is lehet őket rontani, de egy próbát mindenképp megér, már csak azért is, hogy megtapasztaljuk, mit kell egy szedőnek, tördelőnek, oldaltervezőnek végigcsinálni azért, hogy a könyv olyan legyen, amilyennek lennie kell(ene).
Az odt-ből pár kattintással fb2-t is lehet készíteni, a telepített OOOFBtools segítségével. Ahhoz, hogy jól nézzen ki az fb2, és a tartalomjegyzék, az egyes szekciók jól elkülönüljenek, a beállításait tanulmányozni kell, mert az abban meghatározott fejezetstílusokkal operál. Pl. akkor lesz jó a fejezetek tagolása és a címsorok, ha a Level 1, Level 2, Level n bekezdésstílusokat használjuk a Címsor 1, Címsor 2, Címsor n helyett. Ehhez először használni kell az OOOFBTools menüjében a „Load Styles Template in Text” parancsot. A versszakok stílusa a Stanza, a könyv címé a BookTitle, stb. Az, hogy a LibreOffice-ban ezek épp hogy néznek ki, majdnem mindegy, ugyanis az FB2 olvasó programban külön be lehet és be is kell állítani, hogy ezek miként jelenjenek meg olvasás közben. A lényeg, hogy meghatározott nevű stílusokkal tud kezdeni bármit is, az összes többi „alapértelmezett” lesz.
Ha borítót is akarunk az fb2-be, akkor azt a könyv elejére be kell szúrni még a konverzió előtt, a LibreOffice Writer-ben és belekerül a fájlba, ha beállítjuk, hogy így legyen. Tartalomjegyzéket generál az OOOFBTools. Ha mégsem, akkor a címsorok nem a „Level n” szerint vannak elnevezve.
Régebben saját készítésű scriptekkel oldottam meg a konverziót. Volt egy script, ami az odt fájlból kibontott content.xml-t előbb sorokra vágta (ez is egyetlen sorból áll), majd a stílusokat végignézte, a nem használtakat kiszórta, a használatosokból kigyűjtötte a fontos információkat (betűtípus, dőlt, vastag) törölte az összes felesleges formázást, átkonvertálta az xml kulcsokat xhtml tag-ekké, elkészítette a html fájlokat fejezetenként, készített egy toc.ncx-et, egy content.opf-et, és egy html tartalomjegyzéket, majd az egészed beszórta egy előre elkészített könyvtárszerkezetbe. Aztán jött a Sigil-es kézimunka, képek, fontok hozzáadása, css összerakása és mindaz, ami fentebb szerepel már. Egy másik script ebből generált prc forrást, abból meg egy harmadik fb2-t. Ha valakit érdekel, még megvannak, de már jóideje nem használom, sokat kellene/lehetne rajtuk fejleszteni, javítgatni. (gyakorlatilag minden futtatás után módosultak itt-ott, az épp aktuális fájlban tapasztaltak miatt) de az office kiegészítők ezt szükségtelenné teszik.
A folytatáshoz kattints a címre itt lent.
Utolsó kommentek