Állandó rovatok

A RADAR az e-könyv olvasó blog "kis-színes" híreinek társasági gyűjtőposztja. Ha találtál valami témánkba vágót, firkáld ide. Ha izgalmas új könyvmegjelenésbe futottál, oszd meg velünk a KÖNYVRADARon. Köszönjük, a műfaj nevében.

Ha eladó készüléked van, vagy használt kütyüt keresel, a KERES-KÍNÁL rovatunkat ajánljuk figyelmedbe.

Ha valami nyomja a lelked, ha összemérnéd az érveidet másokéval, gyere a DÜHÖNGŐbe. Belépés csak gumicsontokkal.

A fölösleges konfliktusokat elkerülendő megköszönjük, hogy tiszteleben tartod az E-tikettünket.

Ha adakozni akarsz, itt megteheted:

Jelenleg 45.700 HUF-nál járunk. Amire használni fogjuk: blogtalálkozó, wiki, saját domain. Nagyjából ebben a sorrendben :-) Jelképes díjazások: a legjobban pörgő e-könyveknek (Nobel Pizza, 2012-ben három darab), a legszebb ekönyveket készítő műhelyeknek (Szépség Pizza,  2013-ban, három darab).

GYIK - Szerszámosláda

Aki még csak most kezd barátkozni a villanykönyvekkel, kezdje a tájékozódást a GYIK rovatban.

Vannak még:

Válassz és rendelj Kindle-t innen

Mobipocket (prc) gyártási okosságok (Kindle, Kindle for appok)

Epub (Koobe, Nook, iOS, Android) gyártási okosságok kezdőknek és haladóknak 

Kiváló szótárak mindenre, ami bírja.

Sok Kindle trükk.

Kiváló magyar metadata-kollektorok a Calibréhez

Eszközismertetők

Boltismertetők

 

Utolsó kommentek

Címkék

1150 (1) 214 (1) 3g (4) 4700 (1) 600 (1) a9 (1) adamobooks (2) adásvétel (1) ADE (1) adobe (8) ad astra (18) áfa (12) agave (30) ajándék (5) akció (12) aldiko (1) alex (1) alexandra (4) állás (1) amazon (67) android (11) angol-magyar (1) animus (1) antikvárium.hu (1) antireklám (1) apad (1) app (5) apple (17) archiválás (1) asus (1) athena (1) athenaeum (1) atlantis (2) aura (7) avana (1) azw (1) banks (1) Baráth Kati (2) barnes&noble (14) beagle (2) bebook (2) bebook2 (1) bejelentés (3) bemutató (8) biblieteka (2) bigyó (1) blog (1) blogbuli (2) blogtalálkozó (2) bme (1) bookandwalk (4) bookdesigner (2) bookeen (3) bookgem (4) bookline (9) bookmarklet (1) boox (4) budapest noir (1) büntetés (7) calibre (4) Canvas (1) céghírek (1) ces (1) cikkajánló (4) clara (3) cloud (3) co2co (1) coelho (1) cool er (2) crowdfunding (1) crunchpad (1) csőd (1) cybook (8) dedikálás (2) deltavision (1) dibook (16) digitalbooks (12) diploma (1) disney (1) diszlexia (1) doctorow (1) dr1000 (1) dr800 (2) dragomán (1) drm (36) e-könyv (1) e-könyvészet (8) e800 (1) ebooks in Hungary (1) eclassic (5) eclicto (2) édesvíz (3) edge (1) edition 2 (1) eebook platform (1) egyesülés (2) ekm (43) ekönyv-terjesztés (3) ekulturaTV (2) elméleti kérdések (89) ELTE (1) enciklopédia kiadó (1) entourage (1) epub (68) epubcheck (2) események (9) eslick (1) etikett (1) EU (4) e gyetem (4) e könyv (19) e könyvesbolt (40) e könyvtár (3) e könyv formázás (8) e papír (12) fapados (1) fapadoskönyv (9) felmérések (21) firmware (4) fizetés (1) flepia (1) flightcrew (1) fontok (8) forgatókönyv (1) forma (3) formátum (5) fórum (3) frankfurt (2) frissítés (3) fujitsu (1) fumax (2) GABO (3) galaktika (7) galaxytab (1) garancia (1) Gitden (1) gloHD (1) goldenblog (1) goodreader (2) google (5) Grecsó (1) gyakorlati kérdések (68) gyártástechnológia (32) H2O (4) hachette (1) hack (2) hanlin (3) hanvon (4) harlequin (3) hármas könyvelés (4) harry potter (2) hvg (1) ibooks (3) icarus (1) idaságok (1) idpf (2) indesign (1) infografika (2) ingyen (1) introverziók (24) ipad (18) ipad mini (1) ipaq (1) iphone (3) ipubs (7) irex (5) iriver (4) irodalom (2) ismeretterjesztés (4) ismertetők (1) itunes (1) japán (1) játék (2) java (1) javascript (1) javítás (2) jegyzetelés (3) jelenkor (1) jókívánság (2) jótékonyság (3) jumbo (1) karácsony (7) képek (1) képregény (2) keres (1) kickstarter (1) kiegészítő (9) kínál (1) kindle (67) kindlegen (2) kindle dx (6) kindle fire (3) kindle wifi (5) kisepika (2) kleinheincz (5) kloos (1) kobo (21) kölcsönzés (1) kondor (3) konteo (1) könyvajánló (6) könyvesbolt (1) könyvhét (19) könyvkiadás (119) könyvmolyképző (9) könyvtár (6) könyvterjesztés (3) koobe (36) kötelező olvasmányok (1) közlemény (2) közösség (27) kritika (1) lámpa (3) laputa (1) lendink (1) libri (8) líra (2) Lithium (1) lrf (1) lrx (1) ludas matyi (1) magvető (3) makró (2) marketing (2) marvin (2) média (4) mediamarkt (1) megvilágítás (1) mek (4) mese (3) mesemasina (2) metaadat (1) micropayment (1) microsoft (2) middleware (1) mintakönyv (1) mkke (3) mobi (3) mobipocket (20) moly.hu (2) móra (1) msi (1) mu (1) műfaj (1) multimédia (1) multimediaplaza (31) n516 (1) ncore (1) nds (1) neal stephenson (1) nekrológ (1) német-magyar (1) networkshop (3) nook (7) nook2 (3) novella (2) oasis (2) oaxis (1) office (2) oktatás (2) olvasási nehézségek (2) omikk (1) one (1) onyx (9) openinkpot (1) Oravecz Nóra (1) orosz-magyar (1) összeesküvés (1) oszk (3) palm (1) pályázat (10) paperwhite (12) paradigmaváltás (1) paypal (2) pda (3) pdf (11) PearlHD (1) pendrive (1) pizza (2) plastic logic (4) plugin (1) pocketbook (16) podcast (2) popper (1) portal press (2) pottermore (1) prc (15) pre (1) premier (2) publio (5) rádió (4) Rajaniemi (1) rakuten (1) reb (1) rejtő (1) reklám (58) reMarkable (3) reMarkable2 (3) rendelés (2) re poszt (12) riport (1) rss (2) rtf (1) samsung (2) scalzi (7) scida (1) scribd (1) scribe (1) Semmelweis (1) SendToKindle (2) sf (12) sfmag (4) sfportal (18) sigil (2) sipix (1) slideware (1) sony (22) spanyol-magyar (1) specifikáció (2) spiritualitás (1) spotify (1) stanza (8) stardict (2) story (1) streaming (1) syllabux (1) szakdolgozat (1) szellemhadtest (1) szerkesztés (2) szerviz (1) szerzői ellentételezés (3) szerzői jogok (1) szerzői kiadás (6) színes (4) szótár (3) tab (1) táblázatok (1) tablet (10) tankönyv (1) tarandus (4) tarda (1) teaser (1) telefon (1) telekom (1) teszt (66) textr (17) tft (7) tilos (5) tok (2) tor (2) történelem (2) touch (2) txtr (6) typotex (4) t com (14) ulpius (10) üzleti modell (1) vásárlás (11) vegyesfelvágott (14) vendégposzt (4) verseny (5) vízpart (2) vizplex (3) vodafone (3) voyage (4) w3c (1) warez (14) wayteq (1) webáruház (1) web tablet (3) wifi (3) wiki (1) wisereader (1) word (2) xhtml (2) xml (2) yotaphone (1) zinio (1) zsoldos-díj (1) Címkefelhő

Linkek - források

A barátaim, innen onnan

Így neveld az epubodat - másképpen

2012.10.31. 22:53 Dworkyll

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: &hellip;) 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: &ndash;&nbsp;) 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.

Miért is lesz egy tisztességes polgár könyvkalóz?

84 komment

Címkék: gyakorlati kérdések epub gyártástechnológia

A bejegyzés trackback címe:

https://ekonyvolvaso.blog.hu/api/trackback/id/tr834882766

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

JoeP · http://mivanvelem.hu 2012.10.31. 23:22:46

A vége azért maradt le, mert közben rátört a szerzőre az e-book rendőrség?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.10.31. 23:24:07

@JoeP: Nem. Szerintem a blog.hu nem bírta a gyűrődést. Javítottam egy folytatásposztban. Bocs.

upperclass 2012.10.31. 23:55:58

Érdemes lenne egy rövid kalauzt összeállítani a kalóz tartalomfogyasztók nézőpontjából is. E-book kuncsorgás a Molyon, guglizás cím+pdf-re vagy epub-ra és a 2.-3. találati oldalon néhány halott link után végre egy működő fellelése, borító- és fülszöveg-keresgélés és passzintás a Calibre-vel, konkrét könyv hiábavaló keresése esetén az azt tartalmazó megfelelő gyűjtemény letöltése torrentről, 2-3 évvel később a leszedett könyvek árának hozzávetőleges összeadása és elsápadás, meg ilyenek.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.11.01. 00:05:49

@upperclass: lesz szó a warezről, önálló posztban. Már persze csak arról, ami publikus, ugye. Hidd el, tolom a kiadók arcába az ügyet ezerrel, mert a wareznek nem a tiltás a megoldása, hanem az ésszerű legális alternatíva.

teljesnev 2012.11.01. 07:36:26

Én az kérdezném Max-tól, hogy mit tanácsol annak, aki nem érez magában elég erőt a fentiek elsajátítására és gyakorlására, de szkennelni tud. Milyen minőség és formátum az, amiből más, vagy én később el tud kezdeni dolgozni? Ha az output a jpg, amiből az Abbyy OCR-je után vagy kétrétegű pdf, vagy rtf készül, az jó alapanyag?

(Az én célom a papírtól való megszabadulás, akár olyan áron is, hogy egy ideig csak jpg-ben van meg a cucc, de egyszer talán nekiesem a fenti folyamatnak, mondjuk akkor, ha eldől, hogy melyik formátum a befutó...)

kokendy 2012.11.01. 07:37:46

Képzelj el egy akkora hálát, amitől nem bírod becsukni a bejárati ajtódat! Na ez jár neked ezért a leírásért!

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.11.01. 07:40:04

@teljesnev: Nem, nem ez a célod, hiszen az illegális lenne. A célod az, hogy valamilyen kiadónak vagy szerkesztőségnek segíts a csak nyomtatásban elérhető anyagaik digitalizálásában. AMire manapság kifejezetten nagy az igény.

Ugye érthetően fogalmaztam ;-)

Gukker 2012.11.01. 09:03:44

Libre Office alatt a reguláris karakterekkel való vacakolás helyett érdemes telepíteni az AltSearch kiegészítőt. Nagyon profi kereső mudul:
extensions.libreoffice.org/extension-center/alternative-dialog-find-replace-for-writer

teljesnev 2012.11.01. 09:05:34

Neeem, neeem, kiiiizárólag olyan szerzők műveiről van szó, akik már réééégen (több mint 70 éve) meghaltak!

(Egyébként tényleg: nagyapámtól örököltem egy könyvtárat, nagyrészt háború előtti kiadásokat, és vagy teljesen szét vannak rongyolódva és ezért olvashatatlanok, vagy az olvasás alatt hullanak darabokra, de pont jók ahhoz, hogy szkennelhessem: nincs már gerincük... Csak akkor dobom ki őket, ha a tartalmukat már megmentettem. Igen, és van amit újra kiadtak, de hogy papírkönyvben újra megvegyem őket, az ki van zárva.)

Atyaman 2012.11.01. 09:30:50

Csatlakozom @kokendyhez. Hatalmas köszönet!

Ha lesz még blogtali akkor a fogyasztásod én állom :)

auer · http://koronus.blogspot.com/ 2012.11.01. 09:41:23

Ez a bejegyzés már sztem kicsit túlragozott legalábbis nekem sosem volt szükségem ennyi mókolásra. (szkennelt/pdf anyagból nem alakítok)
Wordbe megnyitom, sorkizárttá teszem, átpörgetem megnézem milyen nagy hibák vannak - ez leginkább txt-nél van a sor végi enterekkel. Ezt pár jól elhelyezett keresés csere megoldja, dupla szóközt kiveszem. Elmentem rtf-be, behúzom calibre-be konvertálás beírom a címet, írót rendesen keresek neten borítóképet, kicsit mókolok a sortávolsággal lekonvertálom. Kész olvasható. Ha nem txt akkor kb 3-4 perc az egész folyamat. Kindle-n megnézem milyen lett, ha nagyon zűrös akkor javítok rajta.
Én pl nagyon ritkán használok tartalomjegyzéket, fülszöveget feleslegesnek érzek energiát ilyenre fordítani.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.11.01. 09:45:10

@teljesnev: Ez esetben kered ScanDal olvtársat, aki nem véletlenül nyomul ezen a nicken ;-) Egyike a legjobbaknak a műfajban, és sok háború előtti kiadványt digizett már be. Képben van, hogy milyen az, amikor sárguló papíron átüt a másik oldal stb.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.11.01. 09:46:05

@Atyaman: Abszolút lesz, reményeim szerint már novemberben Adós vagyok a Nobel pizzákkal, és azt még ebben a költségvetési évben szeretném letudni ;-)

hanog 2012.11.01. 09:50:05

Üdv!

Egy olyan kérdésem lenne, amire már nagyon régóta keresem a választ, de nem találtam érdemi/számomra érthető megfogalmazást.
A kérdésem az, hogy mint átlag (leendő) kindle használó melyik formátummal járok jobban illetve miért vagy van-e megjelenítésbeli/használatbeli különbség? Gondolok itt mobi, prc, azw3 fájltípusokra. Ezeket ugyebár mind használja/támogatja a kindle. A Calibre mobi és azw3 formátumba tud konvertálni. Eddig a prc-ket átkonvertáltattam vele a másik két formátumba, viszont sok helyen látom, hogy inkább mintha a prc-ket favorizálnák. Ennek pusztán olyan okai vannak, hogy jobban lelehet védeni vagy több olvasó támogatja? Vagy van más haszna is a másik két formátummal szemben, pl szebb, jobb stb. Bocsánat, hogy egy kicsit offolok de már sokat kerestem a választ ezekre a kérdésekre és nem találtam. Itt viszont látom, hogy nem kevés hozzáértés áll a háttérben, így hátha meg tudnának engem is világosítani ez ügyben.

Köszönöm szépen!
Üdv,
Gábor

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.11.01. 09:56:59

@auer: Különbözőek vagyunk. Különböző célokkal, igényekkel. Senkinek nem kötelező ezt az utat járnia, de meríthet belőle ötleteket és inspirációt, nem?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.11.01. 10:01:19

@hanog: Lényegileg és képességekben a prc-azw-mobi nem tért el egymástól, egészen a kf8 megjelenéséig. Az alap a prc, a mobi a mobipocket.com az azw az amazon..com által autentikált prc.

Később a mobi belvilágát fejlesztették, és a kf8 óta a mobi _lehet_ egy konténerfile, ami tartalmaz egy prc-t a régi vasak kedvéért, és egy v8-as file-t, ami gyakorlatilag egy amazonos epub implementáció.

Ezzel el is érkeztünk a rekurzív mobihoz ;-)

Atyaman 2012.11.01. 10:04:22

@auer: Ezért hívják az olvtársat "Maxnek" :) Én pl. ezt a szintet szeretném(!) látni egy olyan epubban, amit megvásárolok.
Az otthoni felhasználásban pedig mindenki a saját igényének megfelelően készít magának e-könyvet, persze. Ha neked csak egy gyors elolvasásra kell és nem zavarnak a hibák illetve a hiányosságok, akkor tényleg az a jó, ha nem megy el rá sok időd.
De olvashattad a kommentekben is, hogy van aki papírkönyveit szeretné felszámolni. A digitális könyvtár pedig ne legyen már ennyire összecsapott, ha egy szép jól kidolgozott alapanyagot tárolunk, abból később fájdalommentesen lehet más formátumra is átállni.

tl;dr:
Ízlések és pofonok :)

@Dworkyll: na akkor már van mit várni, csak ne 7-8-án legyen :)

És egy külön kérdés. Nem lehetne ezt a cikket kitenni a jobb oldali sávba, a másik epub készítési útmutató alá. Egyik a kezdő hobbistáknak, másik a maximalistáknak, experteken és a kiadóknak?

Gukker 2012.11.01. 10:18:29

Én speciel jobban favorizálom a függő behúzásoknál és a szükséges bekezdéstávolságoknál %-os értéket, nem pt-t megadni. Az e-könyv elvéből adódik, hogy fix értékekkel dolgozni nem kielégítő. Egy 12 pt-os behúzás teljesen másképp mutat pl 6"-on és 9"-on. Más-más betűméretnél is torzulhat.

auer · http://koronus.blogspot.com/ 2012.11.01. 10:19:29

@Atyaman: Részben én is papírról állok át. Amit magam konvertálok ott a fentiek szerint csinálom. De pl papírkönyveknél (regény) sem használók tartalomjegyzéket, vagy fülszöveget, ami könyvem papíron megvan az minimum egyszer már olvastam (de inkább többször), ezért tartom feleslgesnek az ilyen szintű maximalizmust.

Egy céges szinten persze érezhetően ez az elvárt de sztem az egyszeri userek nagy része nem feccöl ennyi energiát egy könyvbe.

Atyaman 2012.11.01. 10:40:55

@Gukker: Én az em értéket preferálom a behúzásoknál, de tulajdonképpen ugyanott vagyunk :)

Atyaman 2012.11.01. 10:50:39

@auer: Nálam nem feltétlen a papírkönyv az e-könyv mércéje. Egyetértek vele, ha valamire nincs szüksége az embernek, akkor ne vesződjön vele, ha nem akar. (Szigorúan otthoni felhasználásra gondolok)

Tartalomjegyzék: én annó még a papírkönyveknél is néha előre lapoztam, hogy mennyi van még hátra a fejezetből (letegyem-e a könyvet, vagy még érdemes 5 percet folytatnom). Most is ugyanilyen megfontolásból mindenképpen csinálok fejezeteket. A progressbar és a .kepub (Kobo epub) oldalszámozása jó dolog.
Emellett még akad más hasznossága is, pl. külön (x)html fájlokra szabdalja a szöveget; enélkül pedig idővel le tud lassulni a lapozás a nagy mérető html fájlokban (Sony+Kobo tapasztalat, Korongvilág könyvekkel, ahol nincsenek fejezetek).

auer · http://koronus.blogspot.com/ 2012.11.01. 10:54:08

@Atyaman: Ez már olvasási szokás. Én szinte bárhol le tudom tenni a könyvet aztán onnan újra felveszem sosem ragaszkodtam a fejezetekhez, inkább a lasabb részeknél hagyom abba.

Mike76 2012.11.01. 11:00:28

És még én vagyok kőkemény... Köszönöm a cikket, jópár ötletet merítettem belőle. Azért azt hiszem, hogy ez a szint már jócskán meghaladja egy mezei otthoni felhasználó igényeit - vagy ha az igényeit nem is, de a lehetőségeit biztosan. Én legalábbis - egy-egy kivételes esettől eltekintve - nem szívesen fektetnénk ennyi időt tartalomgyártásba, a kevés szabadidőmet inkább olvasással töltöm. A kiadók (tisztelet a kivételnek) számára viszont szolgálhatna ez a bejegyzés amolyan iránymutatásként - és akkor talán nem az lenne a első vásárlás után, hogy az ember nekiáll kijavítani a frissen beszerzett e-könyv triviális hibáit.

Atyaman 2012.11.01. 11:46:40

@auer: Én is ezt mondom. Mindenki feccöljön bele annyi időt, amennyit nem sajnál rá és olvasson úgy, ahogy neki kényelmes. :)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.11.01. 12:39:36

@Mike76: na ja. Ugye ha egy címből elmegy egy évben három, darabja mondjuk egy ezresért, és van még sokszáz cím, amit konvertálni kell, akkor ez a tiszteletre méltó processz, hmm nehezen elvárható. Mert egyszerűen nem gazdaságos.

Mint a Suzukiban a kézzel vart bőrülés.

Azaz ez a processz sem tökéletes, mert egyszerűen nem elég gazdaságos/hatékony.

KTamas · http://ktamas.com/ 2012.11.01. 12:41:56

RE: nagy mobi fajlok. Van egy kindlestrip nevu cucc ami kiszedi a kindlegen altal feleslegesen berakott forrasfajlt: www.mobileread.com/forums/showthread.php?t=96903

kIára 2012.11.02. 09:45:44

Mondhatni tökéletes leírás, majdhogynem ipari workflow.
Nem is akarom kiegészíteni, csupán egy dolog van amit megfontolnék, nevezetesen a Libertine használatát.
Attól függetlenül, hogy az egyik legmodernebb tipográfiai jelkészlet, és bátran ajánlható bármelyik magára valamit is adó kiadónak (különösen mióta Németh László áldozatos munkájának köszönhetően elkészült és folyamatosan fejlődik a magyarítása), a nagyon szubjektív benyomásom és szűk körben elvégzett tesztjeim alapján még nem ajánlom e-könyvbe.
Az átlag (jelenleg leggyakoribb) e-inkes olvasók kb. 150–170 ppi között mozgó felbontása nem tesz jót a finom serifeknek. A Pearl-ön még elmegy de egy Vizplex vagy SiPix már kompromisszumos, sőt „élmény”-mentes. Az egyetlen olvasó amin elfogadhatónak, sőt szépnek találtam az az Iriver Story (HD), és valószínű hogy a Paperwhite-on is hasonló benyomásaim lesznek.
Ezen túlmenően az LCD-ken sem tartom különösen szépnek és könnyen olvashatónak.

A papír, a DTP teljesen más történet, mindenkinek bátran ajánlható, hiszen harmonikusan „metszett” a hagyományokat szépen követő, ugyanakkor a font-technológiai fejlődést csúcsra járatva hozza.

         Én továbbra is a Droid Serifet ajánlom (a Gentium előnyei ellenére csupán második), ami bár nem a legszebb, de szerintem e-könyvolvasókon a legjobban olvasható.

——————————

Mindenesetre jó lenne egyszer – legalább ötven fő részvételével – elvégezni egy nagy font-tesztet a fellelhető összes e-könyvolvasó és felhasználható fontok között.

Mike76 2012.11.02. 10:00:47

@Dworkyll: Komolyan 3 darab/cím/év a fogyás egy átlagos e-könyvből? Ha tényleg ennyire elkeserítő a helyzet, akkor revideálom minden korábbi elvárásomat a kiadók felé, és örülök ha egyáltalán megjelenik valami elektronikus formában.

kIára 2012.11.02. 10:29:26

@Mike76:
Sajnos tényleg ez a helyzet. Egy e-könyvből 10–12 db-os fogyás (nem bestsellerről beszélünk) remek eredmény.

kIára 2012.11.02. 10:30:04

Még egy is egy kis font-oskodás. Kiegészítendő a posztban elhangzottakat.
       Max írja: „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.”

Saját magam idézem a DV-s bejegyzés kommentfolyamából:
Klára: „Ellenben felhívtam a figyelmet … továbbá a font és egyéb licencek meglétének hiányára, ami kereskedelmi forgalomba hozott termék kapcsán meglehetősen veszélyes. (Kifejtsem?).”

Kifejtem.

Itt van ez a Book Antiqua és a Wingdings ügy szintén a DV-s bejegyzésnél.
Idézem Dwót: „A Book Antiqua valóban fölösleges, egész pontosan 155k a tömörítetlen mérete, kihagyható, de rajtad kívül kit zavar?”
Hát például… Nem az a baj, hogy egy epub-ban felesleges fontkészlet van, hanem az, hogy benne van. Ugyanis a fontokra szigorú szoftverlicencek vonatkoznak.
A szerző külön az e-könyv céljára megvette? A BKP külön az e-könyvkészítés céljára megvette, rendelkezik felhasználási licenccel? Netán a kiadó? Ingyenesen terjesztgetjük egy nagy szoftvermulti szellemi ÉS VAGYONI jogát képző cuccát? BSA? Valaki? Elismerem, irreálisnak tűnő eset, de elég egy rosszakaró és szívás van. A legnagyobb felelőtlenség kereskedelmi fontokat használni e-könyvben. (Lásd az Adobe Digital Editions honlapján magának az Adobe-nak a könyörgését, hogy ne legyünk már hülyék kereskedelmi fontot használni.) Ez, még itt, a vadkeleti pampákon is veszélyt jelenthet.

            A civileket nem érinti, de az összes kiadót és BKP-t igen. (Megjegyzem, hogy jelenleg csak egyetlen magyar e-könyvkiadót ismerek aki ezt betartja, és (1.) szabadfelhasználású fontokat használ, ill. (2.) mellékeli az epubba az vonatkozó licenceket és felhasználási feltételeket.)

Szóval egy hivatalos e-könyvbe (már ha nem szemtelenül gazdag a kiadó) a nyugodt alvás érdekében kereskedelmi fontokat nem ágyazunk be.
De vegyük a szabad fontokat is.
Pl. Gentium. Ez egy SIL/OFL licencű betűkészlet, amire vonatkozik az úgynevezett „GPL font exception”. Itt meg az a baj, hogy ezek meg FREE!-komcsik! Adott esetben azért fognak perelni, mert a BKP vagy a kiadó nem tette a Misc mappába azt a nyavalyás senkit sem érdeklő hat kilobájtos mindent megengedő licencszöveget. A hülye copyleft miatt! :D (»„Engem” például, aki lassan már X éve a szabad szoftverek CSENDES, de annál lelkesebb híve vagyok, ez mélységesen felháborít! Mert legalább ennyi tiszteletet megérdemelne! Hogy legalább az alkotók nevét kitenné! Vagy a mindent megengedő licencet, amiben csak azt nem engedjük meg, hogy a mindent megengedő licencet ne tegye ki!!!«)

Szóval ezt csak az erre járó kiadóknak és BKP-knek írtam. Jobb félni mint megijedni – nézzétek át az e-könyveitekbe ágyazott fontokat, és szépen pakoljátok be a Misc mappába a licenceket, copyright notice-okat.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.11.02. 13:46:11

@kIára: Legyen így. Ha összeraksz egy minta-epubot, amibe belerakod az általad versenyképesnek gondolt fontokat (az adott fontokkal szedett példaszöveget, legalább két bekezdésnyit, benne a fontvariációkkal), akkor ezt a mintát szivesen kirakom ide, és csinálunk egy minifelmérést.

Hmm?

Egyébként meg újabb vasak ahogy nézem épp azon a vonalon erősítenek, hogy ne akadjanak ki a beágyazáshiányon, illeve hogy felülvágják a beágyazást a saját fontjaikkal.

Atyaman 2012.11.02. 15:34:18

@Dworkyll:
»Egyébként meg újabb vasak ahogy nézem épp azon a vonalon erősítenek, hogy ne akadjanak ki a beágyazáshiányon, illeve hogy felülvágják a beágyazást a saját fontjaikkal.«

Ezt meg tudom erősíteni a Kobo Touchom esetén. Választható ugyan a document default, de vannak saját betűtípusai is, amikénél variálható a vastagság és az élesség – ez nagyon zsiványos funkció ám :). Az utóbbiak közt ráadásul akad olyan is, ami ismeri az ékezetes karaktereinket. Szóval az ő és ű sem para.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.11.02. 15:38:54

@Atyaman: Ja, a para csak ott van, hogy a kiadó mondjuk egy új vason, vagy egy új ADE-n ellenőrzi az epubot, és nem látja, hogy kiszúr a régi vasasokkal, mert nem ágyazta be a fontot. (Én is mindjárt állok vissza a rettenet 1.7.2-re az 2.0-ról, mert szebb és jobb nem lett, cserébe elfedi a hibákat.

Pont most kérdeztél meg tőlem, hogy mi a baj a Koobeval, mert nem frankó rajta egy könyv. Pedig nem is a vassal volt a baj, hanem az epubbal.

kIára 2012.11.02. 16:23:08

@Dworkyll:
Szívesen összerakom, de jó lenne egy felhasználói lista amiből kiindulhatunk. A Gentium, Droid, Libertine már adott – a kereskedelmi vagy erősen védett készletek kiesnek –, még ajánlom a Nimbust, de jó lenne legalább egy 10–12 készletes minta, amit nem én javasolok hanem ti, az itteni olvasók.
Csak halvány fogalmaim vannak arról, hogy kinek melyik (szabad) fontkészlettel voltak/vannak kellemes e-könyves tapasztalatai.

Maga a kérdőív nem lenne bonyolult: melyik tűnik a legszebbnek, melyik a legolvashatóbbnak, milyen eszközö(kö)n nézted?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.11.02. 16:34:08

@kIára: kezdésnek ez nem rossz. Én még próbát tennék a dejavu -vel, és nagyjából ennyi. Vannak még kedvenceim, de azok szerintem pénzesek, Caecilia pl. vagy a Lucida bizonyos családjai.

Mike76 2012.11.04. 12:00:13

@kIára: További két versenyző (bár egyik sem éri el a Droid Serif olvashatóságát): Charis SIL és PT Serif.

ehran 2012.11.05. 13:49:50

Nagyon köszönöm a cikket, hasznos volt, beszállok @Atyaman: mellé a számlába. :)

@auer: Mondjuk én ezektől szoktam falat kaparni, mert így rengeteg hiba benne marad a könyvben - természetesen, ha közkinccsé tételről beszélünk, mert magának otthonra persze mindenki azt csinál, amit akar.

@Mike76: Szerintem a legnagyobb rész továbbra is az átolvasás, az meg nem skippelhető. Azt gondolom, hogy a kiegészítő műveletek az 5-10. próba után már rutinszerűen mennek, illetve nyilván van olyan is közte, ami sablonszerűen beállítható, akkor meg elég egyszer megcsinálni. Kíváncsi lennék, mennyit mond rá a szerző, de szerintem nem több 1-másfél óránál.

SaGa 2012.11.06. 16:18:30

Némileg kiegészíteném a post-ban olvasható módszertant (én is hasonlóképp alakítom a könyveimet, így nagyjából ismerem ezeket az összetevőket)...

Az új Sigil-ben (0.6) már nincs "Split" nézet, helyette egy összetettebb, inkább a hierarchikus xml editorokra hasonlító nézetet kapunk a Preview-ban.
Meg lehet tanítani a magyar szóellenőrzésre (spellcheck). Ehhez le kell tölteni a dict-hu.oxt-t a sourceforge.net/projects/aoo-extensions/files/1283/9/dict-hu.oxt/download?use_mirror=garr&r=&use_mirror=garr oldalról, kibontani belőle (7zip szétszedi) a hu_HU.aff és a hu_HU.dic fájlokat és bemásolni a sigil hunspell-dictionaries könyvtárába. A beállításoknál meg kell adni, hogy a hu_HU legyen a spellcheck szótár. Emellett saját felhasználói szótárakat is hozzáadhatunk, amelyek pont úgy kezelhetőek, mint a LibreOffice-ban. A szóellenőrzés a Code nézetben működik, és a riportban azt is megmutatja, hogy melyik xhtml-ben hány ismeretlen/hibás szót talált.
Szintén újdonság, hogy tud html toc-ot generálni, bár ezt helyi formázással (azaz magában az új toc.xhtml-ben lévő definíciókkal) csinálja, így ezeket át kell másolni a styles.css-be és a head-be be kell illeszteni egy másik xhtml-ből a styles.css-re hivatkozó sorokat.
Sorozatszerkesztőknek egy tipp: a sorozatok jó esetben azonos betűtípussal, tördelési beállításokkal készülnek, így elegendő az első kötetnél belőni a stílusokat. A LibreOffice-nak megadható a "Stílusok betöltésénél" egy odt is , ilyenkor csak a stílusdefiníciókat tölti be belőle és hozzáadja az aktuális fájlhoz. Csak össze kell kattogtatni, vagy a keres/cserél menüben lecserélni a megfelelő stílusokat. Ha ez után azt látjuk, hogy egy halom szó, vagy bekezdés megtartotta az eredeti kinézetét, kezdhetünk gyanakodni, hogy a forrásunk tele van karakterstílusokkal (ezeket a stílusdefiníciós panelen az "a"-val jelölt gombbal lehet előcsalni). Ezt egy rosszul beállított ocr is okozhatja, mikoris a kezelő az összes elérhető betűtípust megadta a programnak használhatóként. Az meg használta, és egy homályosabb betűt már más típushoz rendelt. Ezeket mindet ki kell irtani. Hosszú menetelés, ha van belőle jó sok.

SaGa 2012.11.06. 16:21:42

@kIára: Libertine mellől ne felejtsd ki a Linux Biolinum-ot, ami a hozzá passzoló sanserif font. Igaz, a magyar verzióból nem találtam dőltet, azt a "sima" verzióból kellett pótolni

kIára 2012.11.06. 17:00:58

@Dworkyll: @Mike76: @SaGa:
Alakul… de még várok néhány ötletet. Mindenesetre felveszem a FreSerif-et is (egyrészt nem ronda, másrészt talán ennek van a legnagyobb utf8 lefedése (10,537 karakter), ami nem utolsó szempont).

A Biolinumon gondolkodom, az ugyanis groteszk (sans serif) betű és abból szinte mindegy, hogy mit használunk. Egyelőre vadásszunk olvasható serifeket.

Mike76 2012.11.06. 17:43:04

@kIára: Még egy ötlet, ami egészen olvashatónak bizonyult a teszteszközömön: Liberation Serif.

SaGa 2012.11.09. 16:27:45

@Dworkyll: Jó is az... Ha belecsúszik a delikvens valami jó kis szerzői jogi problémába még a szoftverlicence sértés is bejátszhat. Ezek az ügyes programocskák hajlamosak itt-ott elhagyni a kézjegyüket a fájlokban, amit ugyan egy mozdulattal ki lehet ütni, ha valaki tudja, hol és mit keres, de aki ott tanulja az xml-t, az nem igen fogja megtalálni. Mindegy...

Még mindig a postban vázolt folyamathoz: én is belefutottam az ott leírt indextúlcsordulásos hibába, csak nekem nem a bekezdésstílusoktól sokallt be, hanem a címsorok mennyiségétől. Csak nem volt türelmem kitalálni, hogy mi is a baja pontosan. Úgy tűnik Luke barátunk kicsit szűkre vette az indexváltozóit. Na ilyenkor segít a Sigil új Generate html toc opciója. Nekem anno még "kézzel" (igazából sok regexp keres-cseréllel) kellett html toc-ot gyártani a toc-ncx-ből.

ff48bp 2012.12.03. 08:50:58

Szeretnék tippeket kérni, hogy lehetne elegánsan és minél több olvasóprogram számára érthetően megoldani, hogy egy színes hátterű keretbe tegyem a szöveget? Próbálkoztam táblázattal, de ott az a gond, hogy ha egyáltalán a színt megjeleníti az olvasó, akkor is van amikor gondja akad a képernyőnél több szöveggel. Az Aldiko ilyenkor simán levágja a táblázat alját és nem jeleníti meg. Valamilyen iframe-es megoldás felé tapogatózom, de ennek a parancssorát még nem tudtam jól beírni. Maga a keret ugyan látszik, de nem tudom színezni és a szöveg sem látszódik benne. Azért gondolok az iframe-re, mert ott talán megoldaható, hogy a képernyőnél nagyobb terjedelemnél görgessen, bár ez egy tapizós képernyőnél nem tudom hogy megy majd.

ff48bp 2012.12.04. 19:06:06

Úgy látszik olyat kérdeztem, ami nem igazán foglalkoztat mást rajtam kívül. Szomorú vagyok. Sajnos a próbálkozásaim nem vezettek jó eredményre, mert amit az xhtml megenged, azt az olvasók vagy egyáltalán nem, vagy igencsak korlátozottan jelenítik meg. Az Iframe-re például nem reagálnak, legalábbis ahogy én próbáltam megadni, sőt a divek sem hoznak eredményt.

oldman360 2013.01.13. 15:43:07

Először is köszönöm e szépen összeállított HOWTO-t!

Nekiálltam a leírtak alapján összerakni egy "ebook fejlesztői környezetet", ez látszólag sikerült is, de amikor eljutottam ez első writer2epub exportig, a Sigil-be bedobott epub igencsak különbözött a LibreOffice-ban láthatótól.

A leginkább zavaró (és az éppen készülő könyv struktúrája miatt zavaró), hogy a felsorolások nem éppen úgy jelennek meg ahogy a LO-ban.

Mivel 1-1 felsorolás elem után több bekezdésnyi szöveg van, a teljes felsorolás blokkot kijelöltem, majd Felsorolás be.

Azon bekezdések elől, amik elé nem kell felsorolásjel, onnan azokat kitöröltem. Az LO-ban látszólag sikeresen módosul minden ilyen, de az epub-ban ott maradtak a <li> tagek mindenhol.
???

Arturo 2013.01.15. 22:40:36

@oldman360: Két megoldást látok, egyik sem tökéletes...
1. A számozott sorok között csak "lágy sortöréseket" (SHIFT+ENTER) használsz. Rendes sortörés csak a következő számozott sor előtt legyen.
Ennek hátránya, hogy minden sor ugyanott kezdődik, az első sorokat nem lehet behúzni.
2. Favágó módszer. Hagyod a felsorolást és kézzel beírod a számokat. Itt szépen eljátszhatsz a behúzásokkal.

Arturo 2013.01.15. 22:50:15

Én is nagyon köszönöm a leírást - sokkal szebb könyveket tudok készíteni a segítségével, mint eddig. :)

Azt megfigyeltétek, hogy az új ADE kezeli a ligatúrákat? Persze csak akkor, ha a fontban benne vannak, de onnantól automatikusan beteszi a megfelelő helyekre. A kereső és a szótár is minden további nélkül megtalálja az ilyen szavakat. PocketBook Basic New-n jól működik. A számítógépemen még a régi ADE van, az nem ilyen okos.

L. B. Alberti 2013.01.16. 18:35:40

+1 köszönet a leírásért.
Lenne emellett egy olyan kérdésem, hogy hiába állítom a szövegszerkesztőben a fejezet első bekezdését 0 behúzásra, mégis a generálás után a prc-ben az első bekezdések is behúzással kezdődnek. (a prc gyártási okosságok szerint készül a generálás)

Atyaman 2013.01.16. 22:03:27

@L. B. Alberti: Nekem a MS Worddel van olyan tapasztalatom, hogy a 0-ás behúzást annyira alapértelmezettnek veszi, hogy a stílusleíróban fel sem tünteti. Magyarra fordítva, ha csinálsz egy "Első bekezdés" stílust, ahol nullára állítod a behúzást, ott a kimeneti html fájlodban (gondolom abban mented el), egyszerűen nem lesz benne a behúzásra utaló érték.

A konvertálásnál jön a csavar, mert ott ha nincs megadva a behúzás mértéke, azt a prc nem nullának, hanem 1em-nek értelmezi.

Megoldás: nyisd meg a html fájlt egy szerkesztővel (pl. Notepad++), keresd meg az "Első bekezdés" stílus leíró részét, és írd be neki a nullás behúzást: text-indent:0;

oldman360 2013.01.16. 22:47:43

@Arturo: Köszi, ez így valóban működik. Nem a legtökéletesebb, de majd dolgozok még rajta.

mojo68 2013.06.18. 20:59:39

Fontbeágyazás ügyileg kérném a nálam hozzáértőbbek :-) tanácsát.
A "sima" beágyazás már nem gond nekem sem. Ott akadtam el amikor nem csak a címsor vagy teljes bekezdések vannak más betűvel hanem a bekezdésen belül csak pár szó van más karakterrel írva.

Konkrétan Palatino Linotype fontokkal (nekem ez jön be) van az alap szöveg, de vannak benne, ill nincsenek mert nem jelenít meg, héber írásjelek is. Gondolom valami div vagy span trükközés lenne a megoldás de nekem még nem sikerült rájönni a mikéntjére.

[url]http://img546.imageshack.us/img546/184/ebfy.jpg[/url]

itt a problémás szöveg pl a Liberation Serif jó hozzá.

mojo68 2013.06.18. 21:00:46

[URL=http://imageshack.us/photo/my-images/546/ebfy.jpg/][IMG]http://img546.imageshack.us/img546/184/ebfy.jpg[/IMG][/URL]

mojo68 2013.06.18. 21:01:23

Na ez sem megy nekem :-(

Arturo 2013.06.18. 21:57:42

@mojo68:
1. Ágyazd be a Liberation Serif fontot, mondjuk Liberation néven.
2. Hozz létre egy stílust a héber szövegnek, valahogy így:

.heber { font-family: "Liberation"; }

3. A héber részeknél valóban spannel kell trükközni:

...a következő héber szavak: <span class="heber">héber jelek</span>. Ez pedig...

A Sigilben rögtön meg tudod nézni, hogy jó-e.

Polemius 2013.06.18. 22:04:43

Nem tudom, hogyan fog megjelenni itt, de elvileg annyi, hogy

<p class="p1">szövegszövegszöveg<span class="masikfont">szövegszövegszöveg</span>szövegszövegszövegszöveg</p>

Nyilván a p1 és masikfont classokat a CSS-ben meg kell adni, és a fontokat beágyazni az epubba.

mojo68 2013.06.19. 08:24:36

@Arturo:
@Polemius

Műűűkszik a span :-)

Pedig esküszöm hogy ezzel is próbálkoztam, csak valamit biztos el ba... izé nem jól csináltam. Na mindegy (az a 111) a lényeg a lényeg hogy műűűkszik.

Üdv: MoJó, a hálás

borazslo · http://www.eleklaszlo.hu 2014.10.25. 16:46:55

Eredeti odalszámot hogyan lehet belevarázsolni egy epub-ba? Állítólag lehetséges (van olyan .mobi szakkönyvem, amit ha Kindle-n aláhúzogatok, akkor megadja, hogy hanyadik oldalon van a könyvben).

Dworkyll · http://ekonyvolvaso.blog.hu/ 2014.10.25. 20:28:36

@borazslo: kell bele egy indexfile, amit talán úgy hívnak, hogy pagemap. Fogalmam sincs, hogy készül, de az információtartalma alapján elég trükkös kell, hogy legyen. Hátha van valaki okosabb.

jazmine 2014.10.28. 19:42:41

Sziasztok,
képleteket (pl. matek, kémiai) mivel javasoltok betenni?

A MathML nem mindig ad jó eredményt, valamint pl. az Aldikó és az alkalmanként ADE is a html math symbol-okat is képes szupi téglalapokkal helyettesíteni...

Gukker 2014.10.29. 10:18:11

@jazmine: Szerintem legegyszerűbb, ha képként illeszted be. Vagy kétszínű gifet, vagy vektorgrafikus (skálázható) svg-t.

jazmine 2014.10.29. 11:24:18

Köszi, most azt csináltam, hogy az egysorosak kódban, a többi képként, csak ez számomra nem
tűnt elegáns megoldásnak.
A gifet kiróbálom.

Törpe minoritás 2014.10.29. 13:03:48

Az epub2 nem jeleníti meg a MathML kódokat. Az ADE, Aldiko azért "téglalapoz" (Angolszász nyelvterületen tofu-nak becézik őket:))
Ahhoz olyan olvasó kell, ami epub3 kompatibilis. Biztos van még, de én eddig az Azardit ismerem Win alá, vagy Chroma+Readium plugint. Andriod alatt pedig a Gitden readert.

Addig marad a GIF kép, mint megoldás.

jazmine 2014.10.30. 14:33:25

@Törpe minoritás:
A Gitden nagyon jó, nem ismertem; így jár, aki e-könyvet e-könyvolvasón használ :)
Ezek szerint Sigil epub2-t csinál, mivel abban sem jelenik meg jól a MathML kód.

Törpe minoritás 2014.10.31. 17:30:03

@jazmine: Igen, illetve nem. :)
A Sigil egy HTML editor, úgyhogy lehet benne MathML kódokat beírni a könyvbe, csak nem fogja WYSYWYG megmutatni a preview ablakban.

@Gukker: Ez egyébként a Calibre editorra is igaz, bár az e-book viewer legalább már felismeri a kódokat. és rendereli is.

Addig is várjuk a natív EPUB3 readereket... és a normális editorokat.

jazmine 2014.10.31. 19:28:58

@Törpe minoritás:
Normális editor érdekelne, nekem csak szabadok (pl. GPL) jöhetnek szóba, kipróbáltam párat és maradtam a Sigil mellett.

Aztán amiről itt keveset olvastam: eszközökről, readerek-ből a jegyzetek, kiemelések letöltése. Sokból lehet, de nem mindig 100%-os, a Kindle PW-tal is jártam már úgy, hogy elveszett pár kiemelésem az olvasás és a leszedés között. Ilyen témájú poszt volt már? Igény lenne rá ;)

Gukker 2014.11.01. 00:51:30

@jazmine: Calibre-re van jegyzetlementő plugin:
www.mobileread.com/forums/showthread.php?t=241206

Ráadásul a Kindle-ök a jegyzetekről csinál is egy "'My Clippings.txt" file-t. Ebbe menti az összes jegyzetet.

Igazán nem tudom mi több kéne még. :)

jazmine 2014.11.01. 16:01:01

Kindle-lel a Bookcision-t szoktam használni, nem 100%-os. Lát a My clippings fileban a sorokat és nem mind jelenik meg se a mykindle-ben, pláne nem tölti le.

Ha egy jegyzetem van, kihúzogatom, margináliázom, vandál vagyok, naná, örökre látni fogja, aki olvassa azt_a_példányt.
No most van egy e-könyvem, elolvasom Kindle-n. Tételezzük fel, rendesen működik minden, mindenhol. Aztán átmásolja Géza, aki Callibre-ben olvassa. Sehol a megjegyzések, kiemelések.
Epubot meg olvasok Gitdennel, aztán olvasnám egy fatengelyes e-inkesen vagy csak iBooks-ban, aztán Aldikóval és persze én vagyok a hülye, miért akarom hordozni. Eleve nem jegyzetelek Aldikóval, csak ha fizetek.

Ilyenekre gondolok.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2014.11.01. 18:20:19

@jazmine: iOS-en az iBooksnak, Androidon a PocketBook Readernek van olyan funkciója, hogy megshareli vagy továbbküldi a jegyzeteket egy mailcímre. Egyszerű, mint a faék, viszont működik.

Ha kindle-n akarsz ilyesmit művelni, akkor meg kell keresned azt az indexfile-t, amibe az olvasó nemcsak azt menti, hogy hol tartasz, hanem hogy mit piszkáltál a publihoz. Nyilván ez csak nem DRM-es címekre működik. Ha mindkét file-t (publi+index) átadod Gézának, na akkor fogja látni a bejegyzéseket, de nem Calibrében. Az egyszerűen nem erre van kitalálva.

jazmine 2014.11.02. 02:30:47

OFF

Igen, erre jutottam, hogy fontos a hűség, meg a diszkréció: ami a könyv és köztem történik, az inkább magánügy és 1 könyvet lehetőleg ne vigyek kalandtúrára x readerbe.
Az az érem egyik oldala, hogy adott eszköz/szoftver kire képes; a másik, hogy ez mennyire tömegesen elvárható tudás, mikor a szövegértés is luxus néha.

ON
@Dworkyll: Köszi!

Dworkyll · http://ekonyvolvaso.blog.hu/ 2014.11.02. 11:31:05

@jazmine: jó dolog ez amúgy, ha már a könyvgyártási folyamatba beepül, mert a jegyzetekkel lehet támogatni az offline szerkesztői/lektori munkát. Vannak kiadók, akik már használnak ilyesmit. Mert erre elég egy kezdetleges vagy nyers epub is, ameddig a szöveg véglegesítése tart.

jazmine 2014.11.02. 12:06:53

@Dworkyll: Mire gondolsz? Többkörös a könyvkészítés és menet közben beépítik a jegyzeteket a munkába, konkrétan mintegy tesztelési ciklusokként működik?

SaGa 2014.11.03. 07:13:08

@Törpe minoritás: Ha nekem lenne hasonló problémám, akkor egy jóval munkásabb, de mindenhol (e-pubban) jól megjelenő módon oldanám meg. El kell készíteni a képleteket, csinálni róluk 1-1 képernyőfotót, a lementett png-t svg-vé alakítani, majd ezekből készíteni egy-egy betűt egy saját "betűkészletben" a fontforge segítségével, majd ezt beágyazni az e-pubba. Mivel karakterként definiált a képlet, amennyiben a kedves olvasó nem cseréli le az e-pub betűkészletét valami sajátra, jól fog kinézni, kicsinyités-nagyítás nem rontja el az arányait és a háttér sem fog bezavarni egy nem fehér alapon fekete szöveges olvasásnál, mint pl egy beillesztett kép esetén.
Persze mivel egy karakter egy teljes képlet, jó nagyra kell választani a méretet...

Dworkyll · http://ekonyvolvaso.blog.hu/ 2014.11.03. 09:34:08

@SaGa: Ez egy ideális megoldás, viszont innen nézve embertelen drágának látszik. Ki fizeti ki ezt egy tankönyvért?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2014.11.03. 09:36:48

@jazmine: Elsősorban minőségbiztosításra használják, már késznek szánt e-könyvekre, onnan kerülhet előrébb a folyamatban, ha van igény nagy tömegű szöveg csiszolásására, offline módon.
Igen, egy kollaborációt támogató rendszer jobb, de az a jellegéből fakadóan folyamatos online jelenlétet tesz szükségessé, ez meg lehet offline.

SaGa 2014.11.03. 09:46:46

@Dworkyll: Ha egy matek könyvről beszélünk többszáz képlettel, akkor valóban drága. Ha csak néhánytíz van benne, akkor nem olyan tragikus.
Egy ilyen "képletbetű" létrehozása némi gyakorlattal 5-10 perc.
Ha százasával kell beilleszteni, akkor marad a képként beszúrás, csak az meg csúnya lesz, ha nem pont akkora az oldal, mint a szerkesztőnél.
Ilyesmire még mindig a pdf a legjobb, csak le kell szokni az A4-es pdf-ekről, egy A5-ös, 12-es alap betűmérettel készített PDF még számomra (-8,5-es szemüveg) is olvasható méretben illeszkedik egy 6"-os olvasó kijelzőjére...

Olman · http://szofejto.blog.hu/ 2014.11.04. 11:23:55

e-bookra szánt matek könyveket érdemes LaTeX-ben írni, aztán azt átalakítani epubbá vagy amivé akarják:
tex2ebook.wordpress.com/

Dworkyll · http://ekonyvolvaso.blog.hu/ 2014.11.05. 14:40:23

@Olman: Tuti csomag, kár, hogy annyira linux-centrikus.

jazmine 2014.11.05. 15:53:31

@Olman: nem minden matek könyv, amiben van képlet :)
A LaTeX-et én pl. szeretem, ez a konverter csak kész könyvet alakít át vagy szimpla képletet is?
Mert pl. a WIRIS készít MathML és LaTeX kódot is, ha ez utóbbit gyorsan át tudom alakítani xhtml-be, elvileg nyert ügyem van - amennyiben a karakterek majd jól jól jelennek meg.

Törpe minoritás 2014.11.05. 16:22:42

@Dworkyll: Hát azért ez sem fenékig tejfel!
"For situations where formulas are too complex to be displayed directly using HTML characters, we added the option to convert all formulas to images."
Szóval hiába is alakítja át a képletet, ha nincs olvasó, ami megjelentse. Az meg eléggé sovánka, hogy HTML-lé konvertálja azt, amit tud, a többi meg kép.
Akkor ugyanott vagyunk.
süti beállítások módosítása