Ez a számláló a poszt nézettségét mutatja. Mindenképp olvasd el ezt a posztot a részletekért.

Hirdetés

Á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 34.000 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

  • acel: www.konyvfesztival.com/2014/kiallitoknak/index_magyar.html Link pdf-re, csak nekem gáz? (2014.04.24. 17:32) Radar!
  • Komavary: @Bodzsár Tamás: A múltkor is milyen jó volt az Íróúr fellépése, csak úgy kattogtak a billentyűk, a... (2014.04.24. 07:10) Eközben a jognak asztalánál
  • tetsuo_: A szöveg és a fordítás (a fordító, Weisz Györgyi is) ugyanaz, csak újra lett szerkesztve, viszont... (2014.04.23. 09:46) Könyvradar!
  • Mike76: @tetsuo_: Arról lehet valamit tudni, hogy ez miben különbözik a 2002-es, Magyar Könyvklub által ki... (2014.04.22. 18:53) Könyvradar!
  • Bodzsár Tamás: A zeneiparban megoszlanak a vélemények a hangfelvételek másolásának következményeivel kapcsolatban... (2014.04.22. 16:25) Eközben a jognak asztalánál
  • tetsuo_: Végre érkezik e-ben a Sztrugackij testvérek zseniális életműve is, elsőként kapásból egy korábban ... (2014.04.22. 14:45) Könyvradar!
  • Dworkyll: Szemérmetlen önreklám alert :D Májusban jön az új Vének Háborúja opusz, a Lázadás hangjai. Előrend... (2014.04.22. 13:43) Könyvradar!
  • Utolsó 20

Címkék

1150 (1) 214 (1) 3g (4) 4700 (1) 600 (1) a9 (1) adamobooks (1) adásvétel (1) adobe (7) ad astra (15) áfa (7) agave (21) ajándék (4) akció (9) aldiko (1) alex (1) alexandra (2) amazon (54) android (8) animus (1) antikvárium.hu (1) antireklám (1) apad (1) app (5) apple (16) asus (1) athena (1) atlantis (1) aura (1) avana (1) barnes&noble (14) beagle (2) bebook (2) bebook2 (1) bemutató (7) biblieteka (2) bigyó (1) blog (1) blogbuli (2) blogtalálkozó (2) bme (1) bookandwalk (2) bookdesigner (2) bookeen (3) bookgem (4) bookline (7) bookmarklet (1) boox (3) budapest noir (1) büntetés (5) calibre (4) ces (1) cikkajánló (4) cloud (2) co2co (1) coelho (1) cool er (2) crowdfunding (1) crunchpad (1) cybook (7) deltavision (1) dibook (9) digitalbooks (12) diploma (1) diszlexia (1) dr1000 (1) dr800 (2) drm (31) e-könyv (1) e-könyvészet (6) e800 (1) ebooks in Hungary (1) eclassic (2) eclicto (2) édesvíz (1) edge (1) eebook platform (1) egyesülés (2) ekm (29) elméleti kérdések (70) enciklopédia kiadó (1) entourage (1) epub (57) események (7) eslick (1) etikett (1) EU (1) e gyetem (4) e könyv (19) e könyvesbolt (40) e könyvtár (3) e könyv formázás (4) e papír (9) fapados (1) fapadoskönyv (9) felmérések (15) firmware (4) fizetés (1) flepia (1) fontok (3) formátum (4) fórum (3) frankfurt (2) frissítés (3) fujitsu (1) GABO (1) galaktika (7) galaxytab (1) Gitden (1) goldenblog (1) goodreader (2) google (5) gyakorlati kérdések (55) gyártástechnológia (20) hack (2) hanlin (3) hanvon (4) hármas könyvelés (4) harry potter (1) hvg (1) ibooks (3) icarus (1) idaságok (1) idpf (1) infografika (2) introverziók (14) ipad (16) ipaq (1) iphone (3) ipubs (4) irex (5) iriver (4) irodalom (1) ismeretterjesztés (3) japán (1) játék (2) java (1) javascript (1) javítás (2) jelenkor (1) jókívánság (2) jótékonyság (2) jumbo (1) karácsony (5) képregény (1) keres (1) kickstarter (1) kiegészítő (9) kínál (1) kindle (58) kindle dx (6) kindle fire (2) kindle wifi (5) kisepika (1) kleinheincz (5) kobo (7) kölcsönzés (1) kondor (2) konteo (1) könyvajánló (5) könyvhét (11) könyvkiadás (101) könyvmolyképző (7) könyvradar (2) könyvtár (4) koobe (32) közlemény (2) közösség (26) kritika (1) lámpa (3) laputa (1) lendink (1) libri (5) líra (2) lrf (1) lrx (1) ludas matyi (1) magvető (2) makró (2) marvin (2) mediamarkt (1) megvilágítás (1) mek (3) mese (2) mesemasina (2) metaadat (1) micropayment (1) microsoft (2) middleware (1) mintakönyv (1) mkke (3) mobipocket (20) moly.hu (2) móra (1) msi (1) mu (1) műfaj (1) multimediaplaza (23) n516 (1) nds (1) networkshop (3) nook (7) nook2 (3) novella (1) oaxis (1) office (2) oktatás (2) olvasási nehézségek (1) omikk (1) onyx (7) openinkpot (1) összeesküvés (1) oszk (2) palm (1) pályázat (9) paperwhite (7) paypal (2) pda (3) pdf (8) PearlHD (1) pendrive (1) pizza (2) plastic logic (4) plugin (1) pocketbook (14) podcast (2) popper (1) portal press (2) pottermore (1) prc (15) pre (1) premier (1) publio (1) rádió (1) reb (1) rejtő (1) reklám (43) rendelés (2) re poszt (7) riport (1) rss (2) rtf (1) samsung (2) scalzi (3) scida (1) scribd (1) SendToKindle (2) sf (11) sfmag (4) sfportal (18) sipix (1) slideware (1) sony (22) specifikáció (2) spiritualitás (1) stanza (8) stardict (2) story (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 (1) színes (4) szótár (3) tab (1) tablet (6) tankönyv (1) tarandus (4) tarda (1) telefon (1) teszt (55) textr (17) tft (6) tilos (1) tok (2) tor (1) történelem (2) touch (2) txtr (4) typotex (3) t com (12) ulpius (5) vásárlás (11) vegyesfelvágott (12) vendégposzt (3) verseny (5) vízpart (2) vizplex (3) vodafone (3) warez (6) wayteq (1) web tablet (3) wifi (3) wiki (1) wisereader (1) word (2) xhtml (2) xml (2) zinio (1) zsoldos-díj (1) Címkefelhő

Linkek - források

A barátaim, innen onnan

Kindle WiFi-t pedig erre a képre kattintva lehet rendelni:

Blogajánló

Így neveld az az epubodat!

2010.06.27. 19:59 Dworkyll

Intro

Bár még mindig igaznak gondolom, hogy a prc több platformon elérhető, és több funkciót biztosít általában, de az is igaz, hogy nagyjából meg vannak számlálva napjai, és ha kihalni nem is fog feltétlenül, de elszigetelődik. Ennek legaláb két oka van. Az egyik, hogy az Amazon saját formátuma, és rajta kívül nem használja komoly tartalomgyártó, a másik, hogy a megjelenítési képességei elég korlátosak.

Ezért aztán meg kellett tanulnom az epub készítést, mégpedig úgy, hogy legalább a prc vizuális élményét visszaadják. A dolog, mint hosszas vizsgálódás után kiderült, nem is akkora varázslat, mint sokan gondolják. Az is igaz, hogy a szabvány nyíltsága, és a a készítő/olvasó platformok korlátozottsága elsősorban inkább az "ipari" jellegű előállításnak kedvez, de szerencsére találtam olyan útvonalat, amin scriptelésben és command line vuduban járatlan civilek is elég jó eredményeket tudnak elérni, kis odafigyeléssel.

Az is igaz persze, hogy - megint csak a szabvány nyíltsága okán - számos út vezet a sikerhez, az itt leírt csak az egyik, és nem is feltétlenül a legtökéletesebb. Egy dolgot azért fontosnak gondolok. A sima konverzió, a "Save as", aminek a bemenete egy amúgy optimalizált formájú publikáció, nem tud olyan jó eredményt adni, mintha a konverzió bemenetét előre optimalizáljuk. Aki pedig hasonlóan ledokumentál más útvonalakat, akár Calibrén, akár OpenOffice-on keresztül, azt is szivesen vesszük.

Hozzávalók:

  • Egy nyersanyag, saját írás, vagy ingyenesen letöltött anyag valamelyik publikus oldalról, pl. a MEK-ről.
    (Kódlap-figyelmeztetés: a MEK nem UTF-et használ alapból, hanem iso-8859-2 karakterkódolást. Trükkösebb karaktereknél lehetnek meglepetések)
  • Egy jó kényelmes szövegszerkeztő. A flamewartól most tekintsünk el, itt most a MS word fog ebben a szerepben megjelenni. A lényeg, hogy könnyen és hatékonyan lehessen benne stílusokkal dolgozni. A kulcsfunkció: select text with similar formatting
  • Az Atlantis Word Processor. Ez ugyan nem ingyenes, de az epub gyártó programok közül még mindig az egyik legolcsóbb. Nagyon használható az epub konvertere, be tudja ágyazni a fontokat, metaadatokat ad a publikációhoz, és értelmesen töri darabokra a forrásszöveget.
  • Zip/unzip, notepad. Az epubok utolsó simításait kézzel fogjuk megtenni.
  • Idő.
  • Türelem.
  • Gyakorlás
  • Kísérletezés.

 

I. Stáció - a szövegszerkesztés.

Itt kezdjük el az anyag finomítását. Abból indulok ki, hogy tartalmilag már minden rendben van, és nincs helyesírási hiba. Formailag az alábbiakra célszerű ügyelni:

  • Ne maradjon bent a szövegben feltételes elválasztójel.
  • A gondolatjel legyen gondolatjel és ne kötőjel! Nagyon nem ugyanaz.
  • Egy bekezdésben egy bekezdésjel legyen, ne soronként. A bekezdésket, ha nincs tematikus törés, ne válassza el üres bekezdés.
  • A formázások, dőlt betűk és egyéb kiemelések legynek rendben. Dőlt betűk szoktak lenni pl. a versidézetek, a hajónevek, néha az egyes szám első személyű gondolatok, ez utóbbiak nem mindig.
  • Ha vannak (voltak) a szövegben lábjegyzetek, ez egy kényelmes stáció, hogy egységesen endnote-ra cseréld őket. Itt alkalmasint egy plusz kört kell futni. Ha wordben szerkesztesz, akkor kell csinálni egy Save as html-kört, majd visszaolvasni doc-ba. Az Atlantis ugyanis nem szereti a natív word lábjegyzeteket, viszont a doc->html->doc hurok szabványosítja a azokat. Innentől már az Atlantis is látja a lábjegyzeteket, dokumentumon belüli linkként.
  • Szépíti a dokumentumképet, ha a soreleji gondolatjelek után nem sima, hanem nonbreaking space van, ezt egy közönséges search&replace művelettel el lehet érni.

Search:^p–
Replace:^p–^s

  • A szakasz végén az anyag formátuma doc, vagy rtf.

Ha véletlenül egy szkennelt/OCR-ezett anyagot dolgoznál föl, a kidolgozottabb ajánláscsomag  itt és itt olvasható.

Természetesen mindig tartsd be a hatályos szerzői jogi törvényeket, aminek a forrása, a félreértések elkerülése végett, a Magyar Közlöny.

II. Stáció - egységesítés, formai ellenőrzés

Ebben a szakaszban már az epub-készítés (meg az egységes dokumentumkép végett) nézzük át a dokumentumot. A fő elv, hogy egy célra csak egy stílust használjunk, és ha lehet, ezekből ne legyen túl sok.

FONTOK

  • A törzsfont legyen Gentium Book Basic 13-as. Ez serif, és az e-könyv olvasókon való olvasáshoz kicsit vastagabb, mint a hagyományos fontok. (A tippért örök hálám SaGának). A képernyőn nem a legszebb, de eInken parádés. Lehet még valami a DejaVu családból, vagy bármi, ami tetszik, de ne legyen kereskedelmi font, mert a beágyazás, ha arra nincs licenc, jogsértés! Itt lehet még kísérletezni, milyen ingyenes fontok vannak, és mekkorának kell lenniük, hogy az olvasón jól nézzenek ki.
  • Kiegészítő font lehet a Courier New, ez legyen 12-es, de alapból bold. A normál túl vékony az eInkhez. Méretben meg a 12-es passzol a 13-as Gentiumhoz.
  • Nem használt fontokkal ne legyenek üres sorok sem, mert a fontállományok be fognak épülni az epubba, fölöslegesen.

 

BEKEZDÉSEK

  • A törzsbekezdés legyen sorkizárt (justified), az első sor 0,7 cm-rel behúzva. Sortáv másfeles, előtte-utána 0 pont. Az előtte-utána Auto bejegyzés nagy bekezdésközi szüneteket fog eredményezni.
  • Szövegblokkok első bekezdése lehet különleges. Abban térjen el a törzsbekezdéstől, hogy legyen előtte 12-18 pont szünet. Ilyen lehetnek a fejezetcímek utáni első bekezdések.
  • Az extra fontokkal lehet különleges bekezdéseket csinálni, pl. újságcikkek, jegyzőkönyvek, emailek, táviratok, stb.. Itt érdemes a sortávokkal egyénileg foglalkozni, hogy ne mosódjon össze a törzsszöveggel. (Az Atlantis nem támogatja sem a táblázatot, sem a keretes szöveget, sajnos. Az epub igen, a kész html fejezetekbe belenyúlva lehet ilyet csinálni.) Az ilyen különleges bekezdéseknél nem biztos, hogy kell az első sor behúzása.
  • A kéziratokat, kézzel írt leveleket általában dőlt betű jelöli, a törzsfontból. Itt nem kell behúzás.

 

CÍMSOROK

  • A fejezet- és kötetcímek legyenek headingek, Heading 3 és Heading 4 pl.. A tartalomjegyzék és annak hierarchiája ebből fog épülni. A fejezetcímek előtt legyen lapdobás (page break before) és legalább 24 pont, hogy ne a felső margó alatt legyen közvetlenül. Utána legyen 12-18 pont, hogy a törzsszöveg legyen szépen pozicionálva. (Ugyanerre jó lehet még az üres sor, vagy a blokkezdő bekezdés magasságának beállítása)
  • A könyvcím és a szerző NE legyen heading. Főleg nem a fejezet és kötet fölötti heading, mert azt a konverzió beszőné a tartalomjegyzékbe. Bizonyos parserek, pl a Stanza pedig betenné minden fejezet elé. Lehet persze középre igazított, vastag, megnövelt betűméret stb., csak ne heading legyen. Lehet pl. Title és Author stílus.

 

  • A szakasz végén az anyag formátuma doc vagy rtf.

 

III. Konverzió

Ha jól dolgoztunk, akkor itt nincs más dolgunk, mint az Atlantisszal megnyitni az előkészített doc állományt. Én ilyenkor szoktam a cím elé beszúrni a borítóképet. Külön lapdobás nem kell, azt a konverter intézi. Ugyanígy nem kell a tartalomjegyzékkel sem foglalkozni. Egy utolsó ellenőrzés, hogy nem maradt benn fölösleges font, pl. egy kóbor Times New Roman, és mehet a Save special -> Save as epub. Itt van még lehetőség metaadatok megadására, és egy preview nézetre, főleg ha az ADE is föl van már installálva. Ameddig az Adobe parserek nem kezelik a magyar karaktereket, az Embed fonts opció legyen bekapcsolva.

A konverzió eredménye egy epub állomány, fedlappal, heading alapú, hierarchikus tartalomjegyzékkel és beágyazott fontokkal. Lesz még egy kis kézimunka, de ha hibát találunk a szövegben, akkor azt legjobb a forrásul szolgáló doc-ban javítani. A következő kis kézimunkát ugyan meg kell ismételni, de ha egyszer felbukkan egy új formátum-igény, azt jó eséllyel a forrás-doc-ból (vagy rtf-ből) könnyebb lesz majd előállítani, mint az epubból.

IV. Stáció - Post processing

Az Atlantis epub konverterét sem nagyon lehet paraméterezni, ezért az általa késznek gondolt állományba még érdemes egy kicsit kézzel belematatni.

  1. Nevezzük át a kész epubot zip végződésűre.
  2. Nézzünk bele az ops/fonts alkönyvtárba, hogy nem maradt egy kóbor Times New Roman, vagy más, nem használt bejegyzés a stíluslapok között. A Windows Times New Romanja amúgy is bugos, bizonyos hosszú magyar karakterekkel még beágyazás esetén is gondjai vannak. Ha szemetet találunk érdemes visszamenni a konverzió előtti állományba, takarítani.
  3. A toc.ncx állományban van a tartalomjegyzék. Egy notepad-szerű editorral írjuk át a Title Page bejegyzést mondjuk Borítóra.
  4. A style.css írja le a használt stílusokat. Ebben az alap margót az Atlantis 5%-nak definiálja, szerintem elég az 1%. body{margin-left:1%;margin-right:1%;margin-top:1%;margin-bottom:1%}
  5. Az Atlantis sajnos nem kezel táblázatokat. Ha ilyen van a szövegben, akkor ezen a ponton meg kell keresni azt a fejezetet, ami tartozik, és a megfelelő html állományba kézzel lehet beapplikálni.
  6. Ezek után nincs más hátra, mint újracsomagolni a pakkot, és visszanevezni zipről epubra. Kész vagyunk, jöhet a raktár. 

UPDATE 2010 szeptember.

Új release van Atlantisból 1.6.5.2 verzióval. Erősen ajánlott, gyakorlatilag csak az epub exporton csiszolgattak.

Új lehetőségek:

  • Új - iPad friendly - módon tördelik a lapokat
  • lehet paraméterezni a margót (!)
  • Van mód az eredeti "Title Page" szöveg automatikus fölülvágására [megfelelő heading felirat a legelső bekezdésben, a címlap ELÉ, áthúzva. Az epub törzsszövegébe nem kerül bele, a tartalomjegyzékbe viszont igen, áthúzás nélkül. További részletek itt.
  • Kicsit finomítottak a fontdefiníciók megadásán, így azok a parserek, amik nem használják a beágyazott fontokat, kicsit jobban sejtik, minek kéne ott lenni. Serif, mono ilyesmi

Ezzel gyakorlatilag el lehet felejteni a kézi post processinget. Akinek mégis kéne, szintén az Atlantisnál talál egy ingyenes utilityt, hogy ne kelljen az átnevezéssel/zippeléssel  bajlódni.

IV. Stáció - Terjesztés, raktározás

Az elkészült epubokat különösebb trükközés nélkül rakhatjuk föl az eInkes olvasókra, lehet folderezni, nevezgetni bőszen, az iRex kivételével úgyse nagyon fogjuk a metaadatokat viszontlátni.

Ezért aztán ajánlott valami keretprogram használata. Szerencsés iPad tulajoknak ott az iBooks. Annál már csak a B&N readere lenne jobb, ha a boltot kikerülve is lehetne könyveket berakni alá.

Mindenki másnak ajánlom a Calibrét, ami szép rendben tartja a dolgokat, lehet a metaadatokat menetből szerkeszteni, és a helyi wifin képes kiajánlani az anyagokat a környékbeli iPodoknak, és iPhone-oknak Stanza alá. Sőt, és ez már tényleg perverz, a Calibrével húzok egy mobi példányt is az anyagokból, mert normálisan annotálni és éjjel olvasni még mindig csak iPaqon tudok ;-).

V. Kalandorok ne kíméljenek!

Ez csak egy volt, a lehetséges nagyszámú epub-generálási folyamatból. Akinek van kedve, ossza meg a saját okosságait, kísérleti eredményeit.

 

Epub szerszámosláda:

 

282 komment

Címkék: atlantis iphone calibre ipad gyakorlati kérdések epub stanza ibooks gyártástechnológia

A bejegyzés trackback címe:

http://ekonyvolvaso.blog.hu/api/trackback/id/tr622114216

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.

eNeL 2010.06.28. 00:31:25

Hmm. Én úgy tudtam, a Gentium Book Basic a Latin és a Latin-1 karakterkészletet támogatja, egyelőre nem szívleli a Közép-európai karaktereket.

Ezért nem is foglalkoztam vele. Most akkor ez használható magyar nyelvű könyvekhez, vagy sem?

dagger 2010.06.28. 01:33:24

Helló!

Én a nyersanyagot html-be konvertálom, és editplus-al (egy frankó forráskód szerkesztőprogram) szerkesztem bele a stílusokat (fejezetcimek, beszúrás, stb..) szóval full htmlben csinálom, 100%-ban a html kódot buherálva, a végeredményt pedig IE-ben vagy firefoxban ellenőrzöm.
Ha úgylátom készen van, akkor Calibre-ben import, majd ott a beépített epub konverterrel alakítom át epubbá.
a Calibre epub konverterét elég jól lehet paraméterezni (elsősorban a html-be rejtett kódtrükkökkel) szóval nekem teljesen megfelel iPhone/Stanza olvasóra, és nem utolsósórban gyors módszer

dagger 2010.06.28. 01:35:30

@dagger: ja karakter stílusok: én nem használok betűstílusokat, hanem az olvasóprogrammal (Stanza) állítom be amilyet akarok, a szövegem magában nem tartalamz ilyet, vagyis nem adtam meg neki sosem... de majd megnézek egy epubomat kicsomagolva....

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.06.28. 07:35:15

@eNeL: Előg jól frissítgetik ezeket a fontkészleteket. És igen, a Gentium Book Basicben eddig nem találkoztam "karakterhiánnyal", magyar nyelvhez teljesen jó.

@dagger: a böngészős ellenőrzés szerintem kevés. Se a lapdobás, se a sormagasság-információ nem látszik jól benne (ez utóbbi el is veszik egy html->doc imprtkor)

És a stanza egyrészt irígylésre méltóan jól paraméterezhető (sortáv, margó, behúzás (!), fényerő, fontok...) viszont más parsert használ, mint az eInkek. Az egyetlen dolog, ami nekem a stanzából hiányzott (az AA kikapcsolásán kívül), a több font egyidejű használata. Mint kiderült, ez sem lehetetlen, de még kísérletezni kell vele.

Off: pénteken volt a kezemben egy iPhone 4. Ronda, mint a bűn, de a kijelzője tényleg döbbenetes. Az arányai nem az igaziak, de a felbontás eszelős. Lehet ezzel végre elfelejtik az élsímítást.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.06.28. 07:37:35

@dagger: Ja és a Calibre paraméterezős html trükkök jöhetnek részletesen, ha nem titok ;-)

iOros 2010.06.28. 07:59:29

Egyszerű epubokra szerintem nagyon megfelelő a sigil.

Feldin · http://teateka.hu/ 2010.06.28. 08:33:21

Egyetlen bajom a Calibre-vel hogy epubra konvertálásnál meghalnak a magyar karakterek. Na nem a gépen, az einkes gépen.
Erre biztos van valami megoldás, valaki ossza meg velem!
Tudom hogy már kérdeztem és jött rá az e-könyvtárasdi, de szeretném lokálisan megoldani... nem mindig ki be másolgatni a calibre file-jait...

SaGa 2010.06.28. 09:15:37

@Feldin: A calibre nem építi be a szükséges fontkészleteket az epub-ba, azért nem lesznek jók a magyar ékezetes betűk.
Ezt utólag, kézzel be lehet pakolni, itt a blogban is van rá megadott eljárás a http://ekonyvolvaso.blog.hu/2010/04/15/gyartunk_1 topikban...

Amikor megvan a calibre konverzió, fogod a kész epub-ot (még a pc-n) belepakolod a fontokat, kijavítod a content.opf-et és a css-t, majd visszacsomagolod az egészet és visszateszed a calibre könyvtárába.

Az epub-okat a 7zip átnevezgetés nélkül ninytja, zárja, így abban alvégezhető a dolog...

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.06.28. 10:14:13

@SaGa: Ugyanez a gyenge pontja a Sigilnek, hogy erősen kell a css-ben turkálni a fontbeágyazáshoz.

Azért szeretem az Atlantist, mert elég korrektül lekezeli a beágyazást, mindenütt megcsinálja a fonthivatkozásokat, nem kell tudnom, hogy mit hova kell írkáljak.

Azaz egy alap szövegszekesztői ismerettel, meg 2 perc primitív html turkálással teljesen vállalható minőség áll elő.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.06.28. 10:15:55

@iOros: A Sigil addig komfortos, amíg nem akarsz fontot beágyazni. Ez almás vasaknál nem kötelező, Adobe parsereknél viszont sajnos igen.

ehran 2010.06.28. 10:47:31

@Dworkyll:
Első körben nagyon köszi a cikket, kipróbálom majd a dolgot, bár Atlantisom nincs, de megpróbálom a Calibre-t vagy a Sigilt bevetni helyette.
Ezt írtad:
"Az elkészült epubokat különösebb trükközés nélkül rakhatjuk föl az eInkes olvasókra, lehet folderezni, nevezgetni bőszen, az iRex kivételével úgyse nagyon fogjuk a metaadatokat viszontlátni."
Itt nem tudom, mire gondoltál pontosan, mert a Calibre-ban van pl. egy olyan opció, hogy a metaadatokat beteszi első oldalra (pontosabban a borító mögé), így a Koobe-val, vagy bármi mással is szépen látszik - persze abban igazad van, hogy mint metaadat-funkció, úgy továbbra sem tudja használni. :)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.06.28. 11:32:41

@ehran: Pedig a helyedben körülnéznék Atlantis fronton, a trial triviális, és a kiterjesztés sem akkora probléma ;-)

Az említett eszközöknek alapvetően különböző a filozófiájuk:

Sigil: html kódolás, ha a full mezei formázásnál többet akarsz.
Calibre: paraméterezett konverzió
Atlantis: szövegszerkesztésből generálás

Nagyon nagyon más őket használni. Gonosz teszt: add a kezébe a titkárnődnek, melyiket tudja majd használni?

És akkor ne beszélünk az inDesignról, ami (legalábbis CS4 szinten) fából vaskarika.

Feldin · http://teateka.hu/ 2010.06.28. 11:40:42

@SaGa: Pont ez a bajom... hogy nekem 1 gombnyomással kéne. Bármi akár a Calibre-be miért nem lehet ezt a funkciót beleheggeszteni? Ha már convertál, konvertáljon jól...

Én mint mezei user... nem értek az ilyen turkáláshoz...

De majd megtanulom akkor ha csak ez az út van. :)
Meglesem az Atlatist is. Van Mac-re is?

Feldin · http://teateka.hu/ 2010.06.28. 11:43:02

Megedte a rendszer amit írtam...

Köszönöm.
szóval én mint mezei user egy nagy piros gombot szeretnék hogy convert epub-ba, és ha valami convertál mint a calibre akkor csinálja jól... miért nem lehet ezt beleépíteni?
Nem értek én az ilyen turkáláshoz...
De akkor majd igyekszem elsajátítani ha csak ez a megoldás van...
Atlantist nézek majd. Hátha.
Van Macre is?

eNeL 2010.06.28. 11:53:59

@Feldin: Amennyire tudom, csak Windowsra. Viszont létezik egy u3-as változat is, de nem tudom a Macek kezelik-e az ilyen USB stickes dolgokat.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.06.28. 12:28:53

@Feldin: Az egygombos dolgok szerintem olyanok, mint a borotválkozógép. Hiszen mindenkinek különböző arca van. Először...

Az optimalizálásnak igenis van helye, az a kérdés, milyen filozófiával éred ezt el. Van, akinek a kódturka jön be, van akinek scriptelés, van aki GUI-függő. De opciók minden esetben kellenek.

eNeL 2010.06.28. 12:59:03

Ha valaki netán a trial változatot használná, nem kell nagyon félni attól, hogy sok könyv esetén lejár a 30 nap :)

Elég egy csomó könyvet előkészíteni, azután egyszerre konvertálni, mert az Atlantis 1.6.5-ös változata már támogatja a csoportos konvertálást is...

SaGa 2010.06.28. 13:03:56

@Feldin: A calibre megjeleníteni sem tud még mindent redesen. Van több olyen e-bookom, aminek a végén szószedet van. A szavak bold betűvel, a kiejtés kurzívval, a calibre egyiket sem mutatja meg. Pontosabban nem formázza, csak simán, normál betűvel olvashatóak a megfelelő szavak. Az ADE, az FBReader, a Firefox epub olvasója gond nélkül formázza ugyanezt a részt.
Érdekes, hogy ugyanakkor a Calibre a főszövegben ugyanazt a span class="italic" osztályt tökéletesen kezeli, itt egy span class="bold /span-nal együtt már nem bír vele.

A Calibre igazából arra való, hogy a sokféle formátumú e-könyveidet klasszikus (nem a számítógépen megszokott dir) könyvtárrá szervezze, a könyveidről kereshető katalógust készítsen és kezeljen és ha vannak külső eszközeid, akkor azokkal szinkronizálja a könyvtáradat. A konverzió igazából egy kényszer funkció. Azért kell, mert nem tud minden eszköz minden formátumot kezelni és ha valami olyanhoz jutsz hozzá, ami a te készülékeden nem lenne olvasható, tudj egy gyors konverziót csinálni rajta. Mivel ismer vagy 20 formátumot, és úgy 12-re-ről tud konvertálni, gyaníthatóan sohasem lesz mindegyikre "1 gombos" tökéletes megoldása.

dagger 2010.06.28. 17:52:53

@Dworkyll: calibre-ben le van irva a konvertálásnál, ha megállsz egérrel akkor kiírja a paraméter listát.
van pár olyan html tag amit a böngésző nem de a konverter feldolgoz, ezekkel lehet a fejezet cím stilusokat, tördelést megadni, és ebből mindjárt generálja a tartalomjegyzéket is :)
Szóval nem is igazán trükk, csak elolvastam, és használom amit a progi ajánl.
Calibre weboldaolon van egyébként egy egész wikipédiaszerű doksi a tagokról parancsokról paraméterekről.

calibre-ebook.com/user_manual/conversion.html

Atyaman 2010.06.28. 22:35:06

@Feldin: Khmm... mikor ezt legutóbb kérdezted, akkor kaptál választ is. Beraktam egy linket, ahol leírják hogyan lehet beapplikálni egy font_embedding plugint a calibrebe. Utána ez minden konvertálásnál beágyazza a választott fontot. Ha esetleg vhol elakadtál benne, akkor kérdezz nyugodtan.
Az említett komment: ekonyvolvaso.blog.hu/2010/04/15/gyartunk_1/fullcommentlist/1#c9666848

Atyaman 2010.06.28. 22:46:41

Még annyit gyorsan hozzátennék, hogy ha még mindig ott vagy elakadva, ahol a múltkor ( ekonyvolvaso.blog.hu/2010/04/15/gyartunk_1/fullcommentlist/1#c9667926 ). Akkor ott továbbra is ezt kell csinálni: Calibre->Prefrences->Plugins Plugin file: itt kattints a megnyitás ikonjára és válaszd ki a letöltött plugint, azaz embedfont_plugin.zip-et (még egyszer hangsúlyozom ZIP, vagyis nem kell kicsomagolni). Aztán pedig: Add.

Feldin · http://teateka.hu/ 2010.06.29. 00:04:46

Köszönöm és emlékszem is rá, de a vizsgaidőszak elvitt és nem volt időm belemélyedni... aztán eszembejutott a post kapcsán megint, de az nem hogy visszakeressem. Mindig remélem hogy van egyszerűbb :)
Köszönöm mégegyszer! Ígérem mostmár megértem és ha elakadok jelentkezem.

Atyaman 2010.06.29. 01:19:58

@Feldin: Sztem simán menni fog. De azért próbáld ki Dworkyll fent leírt módszerét is. Én most ez alapján előállítottam 3 könyvet és nagyon bejött. Eddig is 90%-ban így készítettem a könyveket, csak a végén Calibre-rel konvertáltam és nem Atlantisszal. De az a helyzet, hogy az Atlantis kicsit gyorsabb, kényelmesebb és a végeredményt is jobban tudom benne befolyásolni. Szóval maradok is ennél, a Calibre pedig marad rendszerező és olvasó eszköz szinkronizáló funkcióban.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.06.30. 22:30:21

Mégy egy "fontos" érv az Atlantis mellett, isteni jó írógép-hangjai vannak :-))

orkati (könyvmoly) 2010.07.06. 13:25:15

Teljesen amatőr pc user vagyok, de konvertálni szeretnék :-) Kipróbáltam az Atlantis-t, egy word-ből epub-ot csináltam a Save As eBook gombbal, de a Koobe Junior-on ?-ek vannak az ő és ű betűk helyén. Van vaakinek tippje, mit lehetne tenni, hogy szépen ott legyen minden betű a helyén? És le tudná írni nagyon egyszerűen egy nagyon egyszerű embernek? :-))

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.07.06. 13:39:13

@orkati (könyvmoly): A problémád két forrásból akadhat.

1. Amikor a konverziót csinálod, az embed fonts checkbox legyen bekapcsolva, ez beteszi a fontokat.

2. Ne használj times new romant, mert az ha beteszik is, hibásan van kódololva. Nem véletlenül ajánlgatom a Gentium Book Basicet.

orkati (könyvmoly) 2010.07.06. 14:03:43

@Dworkyll: Zseni vagy, köszi, a checkbox segített :-D
A betűkészletet már letöltöttem, kipróbálom majd.

Ami még kissé zavaró, hogy ha nagyítok a betűkön, akkor is megmarad a sorok eredeti tördelése, így a helykihasználás nem túl jó.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.07.06. 14:36:15

@orkati (könyvmoly): ez meg abból jöhet, hogy pdf-ből importálsz, és minden sorvégen van egy sortörés. (Vagy pdf reflow-t csinálsz, az meg ilyen). A szabály, hogy bekezdésenként legyen sortörés, nem sűrűbben. Stáció I, második pont.

orkati (könyvmoly) 2010.07.06. 15:13:40

@Dworkyll: ööö, oké, azt értem, csak nem tudom, hogy a teljes szöveg kijelölése után ezt valahogy automatikusan meg tudom-e csinálni, mert eddig nem találtam megfelelő klikkelési lehetőséget...

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.07.06. 15:45:05

@orkati (könyvmoly): Nem triviális. Ha bekezdések között amúgy van egy üres sortörés, akkor van esélyed. Ez esetben ugyanis az igazi sortörést KÉT paragraph jel jelenti, a simák helyett (általában) space kéne, vagy az elválasztás törlése.

A megoldás a következő: select all, a kettős sortöréseket átcseréled mondjuk XXXX-re. A kötőjel-sortöréseket egyszerűen törlöd, a simákat szóközre cseréled. Majd az XXXX-eket visszacseréled egyszeres sortörésre.

Ha nincs kettős sortörés, akkor marad a favágás :-(

Isten hozott a könyvbarkácsolás nemes művészetében;-)

orkati (könyvmoly) 2010.07.06. 16:27:20

@Dworkyll: Sok újat tanultam ma, köszi az okítást!

SaGa 2010.07.07. 07:33:22

@orkati (könyvmoly): Legjobb eredményt adó, automatizált sorvégeltüntetés: megkeresed azokat a sorvégeket, amelyek előtt az utolsó karakter nem .:!? vagy ... és ezeket lecseréled szóközre. A legegyszerűbb talán egy olyan keresés beállítása, ami reguláris kifejezést használ (regexp) és [:alnum:]$ a keresőkifejezés. Ez ugyan ott szokta felejteni azokat a felesleges sortöréseket, amelyek ékezetes magyar karakter (illetve inkább ő és ű) után vannak, de sokkal kevesebb lesz, mint volt.

A sorközök fixálódásának másik okozója, hogy az Atlantis sem em méretezést tesz a css-be, hanem fix pt értékeket. Ezt át kell állítani em-re.

Viszonylag egyszerű (bár nem tökéletes, de használható) átszámítási képlet: 12pt=100%=1em. Innen simán átszámítható: 10pt=.85em, 6pt=.5em, stb...
Ezeket kell kijavítani a styles.css-ben az epub-on belül.

Egy 7zip-pel megnyitod az epub-ot, kikeresed benne a css-t, kijavítod majd visszamented. Legjobb, ha a 7zip-ben beállítod, hogy a kedvenc editorod (notepad++, pdspad vagy valami hasonló, unix és dos sorvégeket, utf8-at kezelni képes, makrózható editor javasolt) legyen az alapértelmezett editora, így a fájl megnyitása eleve ebbe pakolja és mentédkor visszateszi az epub-ba...

orkati (könyvmoly) 2010.07.07. 08:57:53

@SaGa: köszi, ha időm engedi, nekilátok kísérletezni vele :-)

varics · http://www.kutya-tar.hu 2010.07.07. 16:52:11

@SaGa: Azt nem lehet így kimondani, hogy az 1em az 12pt, hisz az em egy relatív mértékegység, ami a böngésző beállításaitól függ. Az adott környezet betűméretét jelöli, illetve a szülő elem betűmérete. Általánosságban az 1em 12 pt a legfelsőbb szintű elemnél, mert ez van beállítva a böngészőkben.
Példa: ha a body-t 1.5em-ra rakod, akkor az kb 18pt. Ha egy bekezdésnek ezután 1.5em betűméretet állítasz be, az nem 18pt, hanem kb. 27pt lesz, mert a szülő elemhez viszonyítva adod meg a méretet.

SaGa 2010.07.07. 18:12:54

@varics: Nem egészen értem, hogy mi a gondod, de amit leírtál abban tulajdonképpen igazad van.

Amint írtam is, ez egy "quick and dirty" megközelítése a problémának. Már ezzel az óvodás képlettel javított css is sokkal szebb eredményt ad, mint az Atlantis által kiköpött, mert az fix méretekkel dolgozik, az em meg arányos. Azaz, ha nagyítom a szöveget, akkor az arányosság miatt a sorközök, címsorok és minden egyéb arányosan nagyobb lesz és pont ez a cél.
Nem is értem, hogy egy kifejezetten elektronikus (azaz az olvasó kénye-kedve, szeme szerint átméretezhető betűkkel olvasott) kiadványra kihegyezett program miért operál pont méretekkel és nem arányokkal.

A dolog másik fele az, hogy az általam megfelelőnek tartott epub-ban (és mobiban) minden stílus (és így méret) a p-ből (szövegtörzs, vagy ahogy írod body) ered és ahhoz arányított, így az én css-eimben sehol sincs pt mint méret. Csak em és %. A body mérete 1 em vagy 100%, a sormagassága meg 120%.
A kedves olvasó meg majd jól beállítja magának, ogy mekkora betveket lát szívesen a képernyőjén/e-ink felületén.

SaGa 2010.07.07. 18:22:18

@SaGa: Kiegészítés: az eredeti írásban a 12pt=100%=1em egy bemeneti arányító paraméter csak azért, hogy legyen mivel számolni. Lehetne 14pt=100%=1em is, ha valaki a 14 pontos betűméretet jobban kedveli és ehhez akar arányítani. A végeredmény ugyanaz lesz. A betűméret felére vett sorköz akkor is 50% vagy .5 em lesz, csak az egyik esetben 6pt, a másikban meg 7, de az olvashatóság szempontjából a szöveget alkotó sorok mérete, a köztük lévő távok, és egyéb méretek nem abszolút értékben, hanem arányaiban adják ki a szemnek kellemes és kényelmes oldalképet. Egy bizonyos méretig, mert pl egy 3em mérettel szedett címsor esetében már nem kell 3x akkora sorköz a többsoros címen belül, mint az 1em méretű szövegtörzsben, mert nagyon "szellős lesz" és csúnya. Már csak emiatt sem tökéletes az az osztó/szorzó átszámítás...

Mivel a 12pt a leginkább elterjedt képernyőfont, emiatt hivatkoztam erre. Egy szóval sem állítottam, hogy az 1em mindig 12 pt...

eNeL 2010.07.07. 19:00:33

Csak jelzem: van már, és még dolgozni fogok néhány makró fájlon (Word 2003), melyekkel elég sok dolgot automatizálni lehet (persze mindennek van hátulütője is). Egyelőre egyszerűbb dolgokról van szó, a többségük össze is fűzhető egy makróba.

Ha érdekes, közzé tehetjük (ha igény van rá, esetleg egy kis tutoriallal a kevésbé járatosaknak).

@SaGa: "Legjobb eredményt adó, automatizált sorvégeltüntetés: megkeresed azokat a sorvégeket, amelyek előtt az utolsó karakter nem .:!? vagy ... és ezeket lecseréled szóközre. " Csak az a baj, meglehetősen gyakori a fejezet számozás és címek felsorolt végződés nélküli alkalmazása :) Bár igaz: el kell dönteni, mi a nagyobb meló. Egyébként jó ötletet adtál, mert az eddigi makróm nem tartalmazza a ...-t :)

SaGa 2010.07.08. 07:38:56

@eNeL: A baj ezzel a mintával nem a címsoroknál, hanem minden sornál jelentkezik, ha valaki pontosan ezt a keresést adja ki és cseréli szóközre, mert ez az utolsó betűt is eltünteti.

Kell egy kicsit trükközni vele és nem is minden szerkesztőben használható.

Először a mondatzáró jel nélküli sorvégekre be kell illeszteni egy speciális jelet, ami garantáltan nincs a szövegben:
pl.:
Keresés: [:alnum:]$
Csere: &\#\#\#

Ez a megtalált szöveg (a sor utolsó karaktere) után teszi a ### jelsorozatot (a & jel a "megtalált szöveg", amibe a sorvégjel nem illik bele, így azt nem teszi oda mégegyszer). Majd a következő lépésben már a ###$ sorozatot kell lecserélni egy szóközre.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.07.08. 15:20:53

@eNeL: Akarnál írni erről posztot? Mindig jól jön az író-erő :-) A makrókat csak sima textként tudjuk ide kirakni, de onnan egy cut&paste a VB editorba és Bob a bácsikánk :-)

eNeL 2010.07.08. 19:13:04

@Dworkyll: Inkább szeretnék:) A sima textről pontosan ezek voltak az elképzeléseim. Hogy mit, és hogyan csináljak, esetleg privátban megadhatnád (milyen formában, hogyan mellékeljem a fájlokat, stb.).

ehran 2010.07.10. 14:28:16

@eNeL: Grat a szerkesztői státuszhoz!
Naná, hogy van rá igény, és persze a tutoriallal együtt, az olyan gyengébbek kedvéért, mint én. :)
Előre is köszi!

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.07.13. 09:44:06

@Professzore: Na pont ezért gondolom, hogy az inDesign gyakorlatilag alkalmatlan az epubgyártásra. Pl. nem fejtették ki, hogy a fejezeteknek már külön fájlokban kell lenni. Vagy hogy hiába van tábla (CS4) az exportkor az simán eltűnt. Iszonyat nehézkes :-(

eNeL 2010.07.13. 13:23:15

@Professzore: Ha ez náluk az epub, akkor soha sem megyek feléjük. A megadott linken nem nyílik meg semmi (nekem legalábbis), mert ilyet kapok a böngészőben: "Sajnos a kért ePub fájlot nem lehet kinyitni. Egy vagy több fájl ami az ePub fájlhoz tartozik hibás betűket tartalmaz a fájl nevében."

Valószínűleg a Firefox magyarításával van baj, mert azért az üzenet magyarsága sem semmi...

orkati (könyvmoly) 2010.07.13. 16:39:00

Nem tudom, ismeritek-e ezt az oldalt, "egyklikkes", online ePub készítő: www.2epub.com/

Komavary · http://orokorom.freeblog.hu 2010.07.13. 17:59:36

@eNeL: "Unfortunately the ePub-file couldn't be opened. One or more files, which are included in the ePub-file, have invalid characters in the filename." - én ezt kaptam. :)

Az epub magyarsága sem semmi :)

@orkati (könyvmoly): én a helyedben meggondolnám, kinek küldöm el a fájlomat (főleg, amikor ugyanilyen egyszerű átváltást megcsinál a Calibre is.)

varics · http://www.kutya-tar.hu 2010.07.13. 18:20:54

Azért nem nyílik meg a FF-ban, mert a fejezetek fájlnevei ékezetes karaktereket is tartalmaznak az ePUB-on belül.
A validator "csak" 8 hibát írt ki, remélem ezt nem gondolták komolyan...

SaGa 2010.07.14. 07:23:19

@eNeL: Letöltöttem, elolvastam... Nem tetszik. Nem a tartalom, a kivitelezés. Pl a borítón az a felirat a spéci hatással@Komavary: kifejezetten zavaró, gyakorlatilag "elszédültem" tőle. Aki ilyet tesz egy e-bookba, az inkább ne adjon tippeket. Semmilyet...

Ciuc Ottó 2010.07.19. 10:10:00

@eNeL: Sziasztok!
Olcsó használt alapkütyü érdekelne...
Koobe szerűre gondolok. Nagyon megköszönném, ha valaki ellátna valamilyen jótanáccsal, hogy merre érdeklődjek.
Köszönöm!

Pátyer 2010.08.12. 15:49:14

Sziasztok!

Szimpla mezei júzerként vágtam bele fejszém epub-készítésbe, és persze rögtön ki is csorbult az a fejsze. Ezért kérem most a professzionális epubisták segítségét.

Word - Atlantis útvonalon haladtam, alkalmazva a javasolt Gentium Book Basic fontkészletet. Ami nagyon szépen mutat - azon a gépen, ahol létrehoztam. Megnyitva egy olyan gépen, ahol nincs telepítve ez a betű, odalett a formázás. Ebből az egyszerű agyammal azt szűrtem le, hogy nem sikerült beágyazni az epub-ba a fontot, hanem az olvasóprogram (nálam: calibre) kinyúl a gépre, és onnan szedi.

Kérdésem: meg tudom-e oldani, hogy a fontot beágyazván bármilyen olvasón (másik pc-n stb.) ugyanúgy jelenjen meg az olvasnivaló, ahogy legyártottam? Ha "igen" a válasz, kérlek Benneteket, szájbarágósan mondjátok el, mit kell tennem.

Másik kérdésem a képek szöveggel való körbefolyatásával kapcsolatos: a Word-ben előállítom az általam áhított elrendezést, aztán az Atlantis egy vállrándítással nem jeleníti meg a körbefolyatott képet. Ezt jogában áll megtenni, vagy nekem van a kelleténél több bal kezem?

Köszönöm!

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.08.12. 18:19:41

@Pátyer: Font. Amikor az Atlantissal mented az epubot, van ott egy Embed Fonts checkbox. Az be van kapcsolva? Másik ellenőrzési mód: ha belenézel az epubba file szinten, (pl. CTRL PGDWN a Total Commanderrel), az Ops/Fonts könyvtárban ott vannak a font állományok?

Ja és még egy, a calibrét (apple vasakat) nem érdekli a beágyazott font, maga találja ki, hogy mi legyen (állítható). Fontellenőrzésre inkább az ADE-t használd.

Körbefolyatás. Az atlantis az kevesebbet tud a wordnél, ez biztos (lásd táblázatok), de a körbefolyatott képekkel mélyebben van a hiba, az az epubnál nem megy, azt hiszem xml képtelenség miatt. Az xml nem támogatja hivatalosan a körülfolyatást.

(Ha tévedek, meg lehet győzni, egy minta-epubbal ;-)

clon 2010.08.12. 19:31:45

Új a Koobe Junior, így még csak tesztelem, mi hogyan van.

Nekem sem ágyazta be a Gentium font-ot az Atlantisz. Sőt semelyiket. MEK .rtf Atlantis-ba megnyitva -> minden kijelölve, font Gentiumra állítva -> mentés epub formátumra, pipa jobb sarokba a font beágyazásához, kiválasztva a Gentium a listából -> .epub 7zip-el kicsomagolva, Ops mappában nincsen Fonts könyvtár.

Simán Times New Roman font-al készítve ű, ő ékezetek helyett nyíl van (û, ô), de teszt olvasásra "elfogadtam". Ariel font pedig talán ő, ű helyett ? tett.

.rtf használható, .pdf csak OCR-es, .lit felejtős, .mp3 (angol nyelvlecke) működik.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.08.12. 20:28:18

@clon: "pipa jobb sarokba a font beágyazásához, kiválasztva a Gentium a listából"

Stop. Mi ez a kiválasztva a listából? A pipa után simán az összes használt fontot beteszi, nálam nincs fontlista. Nem az exception-öket listázod? Mert az az a lista, amit NEM tesz be.

Amúgy megnéztem az új bétát, és a margó állítható, juhéé! És van tömeges konverzió.

clon 2010.08.12. 21:54:13

Igaz. Már működik. A listából manuálisan kiválasztható a nem kívánt karakterkészlet. 7zip-ben kell dolgozni mert ha kitömörítem és visszacsomagolom, akkor nem lesz használható.

Most látam egy blogot Atlantis programról (Angol, de még nem néztem végig) nem tudom volt-e már linkelve: atlantiswordprocessor.blogspot.com/

Atyaman 2010.08.12. 22:17:55

@Dworkyll: Akkor ha lehet én meggyőznélek egy minta epubbal ;)
Persze megint más tollával ékeskedek, ezt monentán a Calibre készítője Kovid Goyal rakta össze: calibre-ebook.com/downloads/demos/demo.epub

Ez a lapon lehet olvasni a részleteket: calibre-ebook.com/user_manual/conversion.html#epub-advanced-formatting-demo

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.08.13. 13:20:44

@Atyaman: Tényleg jól néz ki.

Csak két baj van vele. Az egyik, hogy nem feltétlenül támogatja minden olvasó (megnéztem, az ADE és mondjuk a Koonbe Junior szerencsére majdnem teljesen igen). A másik, hogy milyen eszközzel lehet ezt előállítani.
Mert ha mondjuk az atlantist nevezhetjük manufakturálisnak, akkor ezek a cuccok kábé mint a kódexmásolás. De ha kell ilyen, akkor már látom, hogy hogyan kell megcsinálni.

És persze köszi a linket.

Pátyer 2010.08.13. 17:07:41

Köszi a segítséget. A fontbeágyazással az volt az igazi problémám, hogy az öregecske Atlantisomon ez az "Embed Fonts" kapcsoló még nem szerepelt. Gründoltam egy újabbat, ott már vidáman kapcsolgathatok. Cserébe viszont nem tudom rávenni az oldaltörésre, pedig az előző Atlantissal ment a dolog. (Heading stílus, bekapcsolt page-break-before funkcióval, a .css-fileban látom is a parancsot, csak éppen nem hat)

Ezzel kapcsolatban is kérek segítséget, ha lehet.

Köszi a körbefolyatást is, az azt hiszem, hosszadalmas elmélyülést kíván.

Atyaman 2010.08.13. 21:06:57

@Dworkyll: Szívesen! Amúgy teljesen egyetértünk, én is az Atlantist preferálom. De jó tudni, hogy ilyen lehetőségek is akadnak, ha netán szükség lenne rájuk. Amúgy a Sony Pocket Reader is kellőképp támogatja ezt a körülfolyatás megoldást.

Pátyer 2010.08.15. 23:00:58

@Pátyer:

Sziasztok!

A oldaltörés problémám egy frissebb Atlantis használatával megoldódott.

Köszi!

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.08.16. 00:13:32

@Pátyer: Jó is az :-) Itt van még egy kis okosság az Atlantis lapdobási szokásairól, főleg az iPad fényében: atlantiswordprocessor.blogspot.com/2010/06/ipads-and-breaking-pages-for-sure.html

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.08.16. 00:16:31

Táblakérdés.

Szaktársak, táblázatot szeretnék csempészni az epubomba, és mivel az Atlantis azt se tudja, eszik-e vagy isszák, kézimunkáznom kell.

Mármost a tábla fölbukkant az epubban, nagyjából úgy is viselkedik, ahogy kell. DE. A jobboldali cellákból kilóg a szöveg a vonalakon túlra. Cellpadding nem segít :-(

Tud erre valaki valami okosságot?

SaGa 2010.08.16. 10:28:08

@Dworkyll: Nálam ilyen egy táblázat (4 oszlop):

<table class="table4col">
<tr>
<rd>
<p>első oszlop feje</p>
</td>
<td>
<p>második oszlop feje</p>
</td>.....

A hozzá való stílus a styles.css-ben:

.table4col {
border-spacing:0;
padding: 1% 5% 1%;
border: 0px solid;
margin: 0 auto;
}

Sajnos ez volt (padding) az egyetlen megoldás arra, hogy a táblázat ne a bal oldalon kezdődjön mindenképp. A szöveg nem lóg ki a mezőkből, ha szűkebb a hely a szükségesnél, akkor sortörést csinál az ADE. Persze ha nagyon keskeny, akkor az egész tábla kilóg a lapról oldalt, egy bizonyos határon túl nem tudja "összehúzni". A szavakat már nem választja el, így az adott oszlopban a leghosszabb szó határozza meg az oszlop minimális szélességét. Ha ennél több hely kellene, akkor biz le fog maradni a jobb oldala a táblázatnak.
Nekem inkább az a bajom, hogy a cellában lévő szövegnek nem tudom megadni azt, hogy ne legyen behúzva az első sora, hanem kezdje a cella szélén. Vagy igazítsa középre a szöveget a cellán belül...

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.08.16. 11:45:14

@SaGa: A bajom az volt, hogy a jobboldali cellákból - a padding ellenére - kicsorog a szöveg. (most az jutott eszembe, hogy nyomok egy plusz oszlopot a jobb szélre, 1% széleset.

A cellán belüli formázás megy amúgy szépen. Htmlben megcsinálom a táblát, annyira csicsásra, amennyire kell, azt sigillel befordítom, és a sigil által generált anyagból kibővítem a styles.css-t, illetve bevágom a táblát a helyére. Ha ésszel vágom a sigil stílusokat, egész emberi lesz.

varics · http://www.kutya-tar.hu 2010.08.16. 15:35:17

@Dworkyll: A padding-ot a cellákhoz adtad meg vagy magához a táblázathoz? Ha bemásolod a kódot, még ma meg tudom nézni (aztán csak hétvégén). Talán azt kipróbálhatnád, hogy max-width-t is beállítasz, bár nemtom, hogy az olvasók mennyire kezelik a CSS2-t (az alap dolgokon kívül).

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.08.16. 16:09:41

<table width="100%" cellpadding="25" class="MsoNormalTable sgc-2" border="5">

Érdekes módon, ez csak az elős cellát "párnázza ki" :-(

Ami még ide vághat az ez: td.sgc-2 {width:49.8%;border:inset 1.0pt;border-left:none; padding:10pt 10pt 10pt 10pt}

varics · http://www.kutya-tar.hu 2010.08.16. 18:46:16

@Dworkyll: Ez valamilyen MS cucc kimenete? A word meg a frontpage szokott ehhez hasonló html-szerűséget kiköpni.

A table-nél megadja a 25px-t, erre a cella stílusánál fölülírja ezt 10pt-re (de azt is milyen módon...)

Én így csinálnám:

<table class="tabla1">
<tr><td>1. cella</td><td>2. cella</td></tr>
</table>

A CSS:
.tabla1 {
margin: 0 auto;
border-collapse: collapse;
border-spacing: 0;
border: 1pt inset #000;
}
.tabla1 td {
width: 50%;
padding: 10pt;
text-align: justify;
vertical-align: top;
}

Egyébként én azt mondom, hogy a kiadóknak a könyvek összerakásához nem is, de az alap és a stílus elkészítéséhez webfejlesztőt kellene alkalmazniuk. Csak így lehetne a legjobb minőséget és a legkisebb méretű végeredményt elérni. Egy könyv stílusát notepad-ben max egy óra megírni, persze most egy normál regényről beszélek nem egy magazinról.

Majd csinálhatnánk pár teszt ePUB-ot, hogy kiderüljön mit tud és mit az adott parser a CSS-ből, illetve mintának a kezdő ePUB gyártóknak.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.08.16. 20:48:51

@varics: Jól látod a kérdést, word-frontpage-sigil háromszögben keveregve pórbálkozom a tábla-epubosítással.

A méret amúgy nem szűk keresztmetszet, a szöveg maga és a font vagy fontok sokkal nagyobb tétel az epubban, mint egy akármilyen brutál css.

Másfelől viszont hogyha jól integrálható css-elemeket csinálnánk, az tényleg nagy királyság lenne.

(valami ilyesmit érdemes kibányászni, az atyaman által fölplankolt calibre példaállományból.)

Ami hiányzik, a táblák (ezt mindjárt kipróbálom), a körülfolyatás és a nagy fejezetkezdőbetűl (iniciálé vagy dropcap).

Apropó, azt hogy oldod meg, hogy a normál stílus elsősor-behúzott, a táblában viszont ez nem kell?

A cellákban lehetnek <p> taggel zárt elemek?

És hogy tudok olyat csinálni, hogy a táble ne margótól margóig tartson, hanem mondjuk margó -15%, és az oszlopok között is van 10%?

Köszi előre is.

varics · http://www.kutya-tar.hu 2010.08.17. 06:47:50

Körülfolyatás pl. képnél:

.kep {
float:left;
margin: 1em;
}

iniciálé:

.iniciale:first-letter {
font-size: 2em;
}

A cellában nem lehet <p>, de a cellát is ugyanúgy megformázhatod mint egy bekezdést.

Ahhoz hogy a margón kívülre toljad, adj a táblának negatív margin-left értéket, pl.:
table {
margin-left: -15%;
}

Az oszlopok közötti távolságot is a tábla stílusában tudod beállítani:
table {
border-collapse: separate;
border-spacing: 10%;
}

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.08.18. 01:02:19

@varics: próbálgatom. A margin auto attribútumát az ADE parser nem érti :-(

Az ötlet jó, hogy rugalmas legyen a keret, de más kell.

Ehh, próbálok variálni, pl. br tag nem jó cellán belül sort törni, de br/ igen,

és nem akarja a jót.

Próbáld ki ezt a kombót ADE-ben:

<table class="tabla1">
<tr><td>3819: Midőn a kelet szekere fejre áll, négy kereke égnek áll, sebesült ember fekszik majdan ádjadon, sajogó fejét orvosolni kék, <br/>ember, aki tűvel szúr de szíve tiszta, pediglen végzetemnek sarja lészen, <br/>vedd el tőle lángoknak keltőjét, hodj helyén ledjenek és edjütt lészendtek amíg világ a világ.</td>
<td>Japán autó? Felborul. Baleset ... könnyű sérülés ... behozzák Aszpirin (vö3757) tű = boszorkányvadász (vö102) Pulsiferre utal (vö002) keressek gyufát a '90-es években! ...hmmm... ... kevesebb, mint egy nap (vö 712, 303, 4004)
</td></tr>
</table>

és

.tabla1 {
margin: 1 auto;
border-collapse: collapse;
border-spacing: 0;
border: 1pt inset #010;
}
.tabla1, td, th {
width: 50%;
padding: 10pt;
border: 1pt inset #010;
text-align: justify;
vertical-align: top;
}

felemás cellaszélesség, és a jobb oldaliból kicsorog a szöveg :-(( Fene az ADE parserbe.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.08.18. 01:34:05

További érdekesség, a td tagen belül megeszi a p taget, így veszi át pl. a törzsformázást. A táblát meg lehet direktben formázni, minden css nélkül.

Sőt. MOst hogy kivettem a css hivatkozást a táblára, nem csorog ki a szöveg.

Megyek vissza a w3cschoolsba, táblákat formázni. Az adobe parser meg monnyon le.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.08.20. 01:14:38

Küzdök a táblaszépítéssel, mint malac a jégen.

Már középen van, keretes, nem csorog a szöveg, de a padding még nem jött össze :-(

Viszont ez egy nagyon jó kis tippraktár, ajánlom mindenkinek:

www.mobileread.com/forums/showthread.php?t=46448

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.08.20. 02:10:42

@varics: HEURÉKA!! Az ADE parser nem ismeri a paddingot, csak valami kiszámíthatatlan módon.

DE. Nemcsak lehet, de kifejezetten kell P taget rakni a cellán belül, mert ahhoz már lehet kétoldali indentet rendelni, és azzal megoldottam a csorgást, és a cellpaddingot is.

Összefoglalva. A tábla középre rakásához kell egy div, meg egy css bejegyzés, a táblát szépen definiálni kell a törzsszövegben, és a cellaszövegnek kell egy dögös margózás, plusz egy vertical alignment a css-ben.

Kész vagyok, mint a lecke. A div tippet egy automata sakkfeladvány-epubgenerálóból ollóztam, na az is szép darab.

varics · http://www.kutya-tar.hu 2010.08.21. 20:34:12

@Dworkyll: Nem ismeri a paddingot??! Ez kb. olyan, mintha nem ismerné a line-height-et. Mivel jelenleg nincs olvasóm (úgy volt, hogy lesz, de...) nem tudok az Adobe Parser-ral tesztelni, olvasni is a gépen szoktam és ott ugye működik a dolog.

Az auto-t biztos nem ismeri? Csak mert te rosszul írtad le, így helyes:
margin: 0 auto;
Ha nem nullát írsz, akkor a megadott szám lesz a margó és nem igazítja középre.

Én nem használnék pt-ot mértékegységnek, akkor már inkább em-et, sokkal jobb, hisz egy 10pt-os padding nagy egy 6pt-os szöveghez, egy 20pt-oshoz viszont kicsi, szerintem az olvasók szövegméret állíthatósága miatt ezt fontos figyelembe venni.

Ha a keret-et inset-re állítod, akkor ne 1pt legyen a mérete, mert akkor olyan mintha solid-ra lenne állítva, csak egy sima vonal.

Nekem igy jól nézett ki a PC-n (kivéve, hogy a Sigil csak solid-ként jelenítette meg a keretet):

<table class="tabla1">
<tr>
<td>3819: Midőn a kelet szekere fejre áll, négy kereke égnek áll, sebesült ember fekszik majdan ádjadon, sajogó fejét orvosolni kék, <br/>ember, aki tűvel szúr de szíve tiszta, pediglen végzetemnek sarja lészen, <br/>vedd el tőle lángoknak keltőjét, hodj helyén ledjenek és edjütt lészendtek amíg világ a világ.</td>
<td>Japán autó? Felborul. Baleset ... könnyű sérülés ... behozzák Aszpirin (vö3757) tű = boszorkányvadász (vö102) Pulsiferre utal (vö002) keressek gyufát a '90-es években! ...hmmm... ... kevesebb, mint egy nap (vö 712, 303, 4004)</td>
</tr>
</table>

.tabla1 {
border-collapse: collapse;
border-spacing: 0;
font-size: 1em;
width: 50%;
margin: 0 auto;
}

.tabla1 td {
width: 50%;
padding: .85em;
border: .2em inset #001100;
text-align: justify;
vertical-align: top;
}

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.08.22. 20:14:00

Nem ismeri a paddingot??!

Az epub lehet hogy ismeri, sőt, a nyomorult ADE parserrel bírkózom napok óta. Kicsit csak, de másként ábrázol, mint egy sima browser. Pl összeszed valahonnan egy indentet (minden margó nullán és minden alignment center) amit frankón egy negatív indenttel tudok kompenzálni :-(

Ehh, mindegy, kezdenek valhogy kinézni a tábláim, és ez a lényeg, meg a heuréka.

(Az ADE parsert tudod tesztelni a gépen, az olvasókon nem teljesen ugyanaz, de majdnem)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.08.22. 22:51:21

@varics: És ezt is érdemes elolvasni: www.pigsgourdsandwikis.com/2010/03/avoiding-ereader-wars-call-for-epub.html

hogy hogyan bírálják felül az egyes parserek a dizájner döntéseit :-(

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.08.22. 22:51:52

@Dworkyll: Ennyit arról, hogy mire elég az, ha vágod magát a html-t.

varics · http://www.kutya-tar.hu 2010.08.23. 09:34:26

@Dworkyll: Egyszerűen nem értem, hogy miért nem lehet a szabványokat betartva készíteni a parser-eket.
Kb. olyan mint amikor elkészül a weboldal, minden böngészőben tök jó kivéve IE-ben...

bajomis 2010.08.26. 08:33:40

A calibre programmal kapcsolatban valaki tudna segíteni? Frissíteni akartam, és azóta megnyitáskor ezt a hibaüzenetet kapom:

Traceback (most recent call last):
File "site-packages\calibre\gui2\library.py", line 607, in headerData

KeyError: 'ondevice'

Azóta újratelepítettem, de az sem segített.

bajomis 2010.08.26. 12:13:04

Közben megoldódott.

ehran 2010.08.26. 23:25:22

@bajomis: Halasztgatom egy ideje a Calibre frissítést, de arra az esetre, ha meglépném, leírnád, mi volt a megoldás, nehogy én is így járjak? Előre is köszi!

macuser 2010.08.28. 14:49:41

Mac társaknak:
Pages ePub publikálás - www.macmagazin.hu/pagesepub/

SaGa 2010.09.01. 11:01:14

Aki szép formázást és a hozzá használható trükköket akar látni, javallom letölteni és elemezni ezt a kötetet:
www.mobileread.com/forums/attachment.php?attachmentid=28783&d=1241990005

Kíváncsi lennék, mennyi volt a szerkesztő/konverter program és mennyi az emberi kreativitás, kézzel...

Atyaman 2010.09.26. 00:49:42

Az Atlantis update-hez (1.6.5.2) kapcsolódva: Ez a két kis újítás tényleg hasznos. Bár eddig sem volt gondom avval, hogy 7zippel belenyúljak az epubba, de így tényleg kényelmesebb.

Viszont! Eddig ha lépcsőzetes tartalomjegyzéket szerettél volna összeállítani, akkor a stílus kiemelések (heading 1, 2, 3) mindegyikéhez külön html fájlt hozott létre. De az új verzióban ez nem így van. Heading 1-et és 2-őt alkalmaztam a könyv részeihez és fejezeteihez. Az olvasókon ugyanúgy jelenik meg a tartalomjegyzék, mint eddig is, de az epubot belülről megnézve azt tapasztaljuk, hogy a fejezetek (heading 2) nem kaptak külön html fájlt. Ez speciel nálam nem szerencsés, mivel a Sony 300-asom bizonyos html fájlméret felett egyre lassabban lapoz. Ráadásul szeretem, ha a fejezetek új oldalon kezdődnek. Így, hogy egy fájlba van betéve egy könyv adott részéhez tartozó összes fejezet, azok folyó szövegként, egymás után jelennek meg.
Ezt lehet orvosolni vmi úton-módon, vagy marad az egy fajta stílus használata, esetleg downgrade az 1.5.6.1-es verzióra?

Ui.: Elnézést, ha kicsit zavaros voltam.

Atyaman 2010.09.26. 00:50:49

Természetesen 1.6.5.1-re gondoltam. Az 1.5.6.1 elírás.

SaGa 2010.09.26. 10:20:07

@Atyaman: Úgy tűnik erre az a megoldás, hogy a Heading stílusok mindegyikénél beállítasz egy page-break-before:always-t...
Akkor mindegyiknél darabol...

Atyaman 2010.09.26. 16:17:14

@SaGa: Köszi! Ezt fogom tenni ;)

mekmi 2010.09.27. 09:34:14

Szeretnénk a Magyar Elektronikus Könyvtárban epub formátumot is szolgáltatni. Elkezdtem kísérletezni a Calibra-val, olvasgatom az ajánlásokat, letöltöttem az ajánlott Gentium Basic fontokat. Rájöttem, hogy jobb, ha a kész HTML formátumainkat használom input szövegnek. E-book olvasónk nincs, csak a Calibre-vel vagy az online Bookworm-mel tesztelgetek, de nem az igazi :-( Néhány próbakönyvet feltettem ide.
www.mediafire.com/?gdh7zbs44gzdu
Megköszönném ha megnéznétek, tesztelnétek, minden véleményt, javaslatot, segítséget megköszönünk. Az info@mek.oszk.hu címre írjatok.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.09.27. 10:27:44

@mekmi: Két alapvetés kezdetnek.

1. fontbeágyazás. Anélkül gyakorlatilag nincs magyar epub. A Ferencsik anyagnál sikerült, a többinél nem.

1. Adobe Digital Edition. Ingyenes, és nagyon gagyi. Arra viszont jó, hogy lellenőrizd az epubokat, mert a legtöbb olvasón (már ami nem apple vagy android) közel ugyanez a parser fut. Addig kell gyúrni az epubot, ameddig az ADE nem mutat élvezhető eredményt, utána az eInk sem lesz rossz.

Ha gondolod, meglátogathatlak az OSZK-ban a részletekkel, mert jó lenne átpörgetni a MEK-et epubba. De nem kis meló lesz, ha jól akarjátok csinálni, még korrektúrázott szövegekkel sem.

zlaboncz (ZLC) 2010.09.28. 13:41:46

@mekmi: Szia, kipróbáltam a Sony olvasón az ePUB-okat, írtam az e-mailre.

Találtam egy érdekes problémát:
A teszt ePUB állományokban (és a Dworkyll által ajánlottakban is tapasztalható) hogy Sony olvasó egyes oldalaknál lapoz ugyan, de az oldalszám nem változik. Tehát valahogy így néz ki a lapozás 1-2-3-4-4-5-6-6-6-7-8 stb. Tehát minden egyes oldal tartalma más, de az oldalszám bizonyos esetekben nem változik. (majd csinálok képet, nem tudom, hogy így érthető-e) Olyan, mintha valahol fix hosszúságú oldal lenne definiálva.
Ezt a doksit átkonvertálva LRF-be (Calibre spec beállítások nélkül) 10 oldal helyett 13 oldal lesz a hossza, és jók az oldalszámok is.

Találkozott már valaki hasonlóval esetleg?

Z.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.09.28. 14:37:00

@ZLC: Az epub adobe által használt oldalszám beégetése a tartalomméreten alapszik, azt hiszem 1024 byte-onként léptet egyet. Azaz független a lapszám a fontmérettől, ami szerintem okés.

Viszont a byte-tartalom ugrálhat, attól függően, hogy pl. van e benne kép, tábla, üres lap, stb.

clon 2010.09.29. 12:36:14

@Dworkyll: ...meglátogathatlak az OSZK-ban...

Amennyiben lesz valami publikus fejlemény szívesen olvasnék róla valamilyen formában.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.09.29. 18:04:59

@clon: Úgy érted szivesen vennéd, ha a MEK epubosítési projektjének csapnánk egy kis publicitást?

Komavary · http://orokorom.freeblog.hu 2010.09.29. 18:44:47

(Off - hozzácsapva a hangoskönyves projektet is.)

clon 2010.09.29. 21:08:46

Valójában az érdekelne, hogy ne kelljen nekem barkácsolni és mondjuk a Rejtő x elolvasott könyve után már letölthető epub-ban folytathatnám az olvasást.
Persze, ha mondjuk az epubosítási projekt több 1000 könyv kerül a "piacra" minőségben klasszikusokból, esetleg megmozgathat valamit a versenyszvérában is. A reklám mindig jól jön, de a MEK-et az akinek szüksége volt ott megtalálható forrásra, az valahogyan mindig megtalálta.

eNeL 2010.10.12. 23:43:47

A gyakorlatban már gyártó, és esetleg eszközön a gyártmányokat kipróbáló olvtársakhoz (a hozzáértőkhöz) lenne egy láma kérdésem:

Van-e jelentősége epub, vagy prc gyártásánál annak, milyen lapméretből (pl. A4, A5) készül el az említett kimenet? Ugye, a legelterjedtebb olvasó méret (jelenleg) a 6 inches (esetleg 5). Alapvetően szöveges dokumentumnál - gondolom - ennek semmi jelentősége. De mi van az ábrákkal megtűzdelt (ne adj Isten szöveggel körbefolyatott) anyaggal?

Atyaman 2010.10.13. 00:02:55

@eNeL: Annyira még nem ástam bele magam a képek megjelenítésébe, ezért lehet, hogy tévedek, de eddig ezek a tapasztalataim.
Úgy vettem észre, hogy a lapméretnek nincs jelentősége. Atlantisszal készült epuboknál a képek megjelenítése csakis a saját méretüktől függ.
Például egy kép html kódja: <img src="images/img2.png" width="117" height="25" alt="img2.png"/>
A szélesség és magasság értékek természetesen pixelben értendők.
Egy kép kivétel ez alól, az a borító: <img src="images/img1.jpg" style="height:100%;max-width:100%;" alt="img1.jpg"/>
Így a kép az adott képernyőmérethez igazodik százalékos arányban (ez a skálázás jól megfigyelhető pl. ADE-ben, mikor az ablak méretét változtatod)
Természetesen a kódok felülírásával tudod alakítani bármelyik kép megjelenését.

kIára 2010.10.19. 08:41:43

@mekmi:

@Dworkyll:
»1. fontbeágyazás. Anélkül gyakorlatilag nincs magyar epub. A Ferencsik anyagnál sikerült, a többinél nem.«

Ezzel egyetértek, de egy dolgot nagyon át kellene gondolni. Én a MEK-en csak magyar könyvek esetében merném használni a Gentium fontot.
Három előnye van: jól mutat e-inken, és lefedi a magyar karaktereket, és ingyenes.

Hátránya: kicsi a készlet. Bár elég sok ékezetes karaktert tartalmaz, nem mindent és ez gondokat okozhat, különösen többnyelvű állományok esetén.
Csak kíváncsiságból néztem meg:
Gentium által támogatott karakterek (a teljesség igénye nélkül):
é á ű í ő ú ö ü ó ă â î ú č š ŝ ů ĭ ë ı ŕ û ũ ÿ ý ẏ ỳ ẙ ỹ ṡ
Gentium által nem támogatott karakterek (szintén a teljesség igénye nélkül):
ş ţ ƫ ḑ ŗ ģ ą ď ķ ƈ ȓ ȑ
Ez azt jelenti, hogy gyakorlatilag adott külföldi művek kapcsán meg kell vizsgálni, hogy érdemes-e ezt a fontot használni vagy sem.

Például ott van a Linux Libertine teljesen nyílt és kimondottan tipográfiához készült fontkészlet ami e-inken is nagyon jól mutat, kb. hatszor annyi karaktert tartalmaz mint a Gentium, és gyakorlatilag az egyetlen olyan szabad fontkészlet ami végre rendesen metszett írásjeleket használ, ráadásul van saját metszésű kiskapitális- és ugrálóbetű készlete.
Persze ez sem igazán jó megoldás, hiszen egy majdhogynem teljes fontkészlet epub-ba ágyazva akár meg is négyszerezheti a végső méretet.

kIára 2010.10.19. 09:16:30

@mekmi:

Még néhány dolog.
Első körben olyan állományokból dolgozzatok, ami már unicode (utf-8). Ha nem, akkor az iso-8859-2 forrásaitokat előbb tegyétek át ebbe és soha ne bízzátok ezt az epub-generáló szoftverre. {[(Csak mellékesen jegyzem meg, hogy szerintem a MEK egyik legnagyobb hibája, hogy még mindig az iso-8859-2 az alapkódkészlet)]}.

A calibre saját használatra elmegy, de mivel [még mindig] nem generál szabványos epubot, alaposan végig kellene gondolni, hogy illik-e ha egy nemzeti közgyűjtemény nem szabványos epubot szolgáltat.
Ugyanez vonatkozik az Atlantis epub exportjára is. Jó-jó, meg szépnek szép, csak éppen szemetes. Az OpenOffice alá készített writer2epub pl. szinte patyolattiszta xhtmlt generál, de az epub-struktúra már itt sem követi teljesen a szabványt.
Azt akarom ezzel jelezni, hogy ha bármelyiket választjátok a fentiek közül (vagy akármi mást), akkor óhatatlanul bele kell nyúlni minden egyes MEK-epubba ami emberfeletti feladat, különösen hogy nincs rá ember ;)

Szerintem is fontos lenne, ha világosan szerepelne a jövőbeni mek-epubokban a forrás. Mind az impresszumban, ahogy Dworkyll is írta, mind pedig a Metaadatok között és ez talán még fontosabb. Tehát azt is meg kellene vizsgálni, hogy hogyan lehet tömegesen metaadatokat importálni epub-ba.

A tudományos művek kapcsán azt is végig kell gondolni, hogy olyan epub-ok készüljenek belőle amelyeket _nemcsak olvasásra_ »hanem kutatásra« is fel lehet használni (pl. az eredeti könyv oldalszámainak megjelenítési/elrejtési lehetősége, indexelés, gyors és egyszerű tárgy és névmutatók, nem képként beillesztett képletek, stb.)

kIára 2010.10.19. 09:24:10

Amúgy egy új, ígéretes szereplő az epubgyártás-fronton:
www.jutoh.com/
Az, hogy keresztplatformos (5 oprendszer) csak hab a tortán.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.10.19. 09:26:52

@kIára: Milyen _problémát_ látsz az Atlantis epub exportjával? Szerintem nagyobb baj, hogy még ha a szabványt egységesnek is tekintjük, a megjelenítő platformok nagyon szórnak a képességek szempontjából. Kezdve azzal, hogy mit vesznek át a forrás font és css definíciójából, mit oldanak meg saját erőből, és mit lehet konfigurálni olvasás közben.

kIára 2010.10.19. 11:31:21

Nézzük pl. a Város két fül között-et
A stuktúra a következő:

/META-INF

/Ops
/Ops/fonts
/Ops/images
mimetype

Az OPS-ből Hiányzik a /Texts és a /Styles és a /Misc egyszerűen az Ops-be zuttyantja a szöveget és a stílust, ahol gyakorlatilag csak a content.opf-nek és a toc.ncx-nek lenne a helye.
Ez ugyan mellékes, hiszen a legtöbb ebookolvasó/megjelenítő lenyeli, de attól még nincs normális struktúrában az epub és exportnál gondot okozhat.

Szemetes html-t generál, (amit el akar adni xhtmlnek).
Pl. Semmi sem indokolja az ilyen megoldást: <p><span class="t3">&ndash;&nbsp;Oké. </span></p> különösen ha a .t3 csupán ennyi: .t3 {font-size:1em}

A ilyet meg végképp nem:
    » Míg a többiek legy<span class="t3">ű</span>rték kis görcsökben jelentkez<span class="t3">ő</span> félelmüket, s megtanultak megbízni egymásban és a loncsban, <span class="t3">ő</span> meredten bámulta az Artistaképz<span class="t3">ő</span> padlóját és várta az ugrást. «
Ezt úgy hívják, hogy „szemét”.

Az, hogy létrehoz egy ugyanolyan stílust: .t6{font-size:1em} meg, amit a forrásban ugyanolyan gyakran és minden logikától mentesen használ, egyenesen „mocsoknak” lehet nevezni.
Ezt meg úgy hívják, hogy kakakupac:
<p><i>Nem err</i><span class="t3"><i>ő</i></span><i>l van szó… </i></p>

Eleve azt sem értem, hogy utf-8 és beágyazott fontok mellett miért hasznája még mindig az entitást (&ndash;) a sima „–” jel helyett. Semmi sem indokolja.
Az írásjelek után zárótag-ek elé space-t tesz: … </i> és ? </i> az …</i> és ?</i> helyett. (Tudom, hogy ezzel együtt lehet élni, de akkor is gagyi.)

Az impresszumban található hivatkozásokat kinyírta.
Lásd: <p class="p1">ePub változat: <a href="http://ekonyvo"><span class="t5">Dworkyll Rodriguez Workshop</span></a></p>
<p class="p1"><span class="t5">kleinheincz.wordpress.com</span></p> Tehát a netképes kütyük és megjelenítők bekaphassák.
Azt sem értem, hogy a hivatkozások stílusát miért így oldja meg:
<p class="p6"><a href="http://www.deltavision.hu"><span class="t5">www.deltavision.hu</span></a> </p>
ahelyett hogy az <a>-nak adna stílust a css-ben.

Az talán csak az én mániám, de xhtml-ben szerintem <i> helyett illik <em>-et használni – bár a megjelenített eredményen nem látszik, hozzá tartozna a dolog rejtett eleganciájához.

kIára 2010.10.19. 12:12:47

@Dworkyll:
    »Szerintem nagyobb baj, hogy még ha a szabványt egységesnek is tekintjük, a megjelenítő platformok nagyon szórnak a képességek szempontjából.«
Szerintem ez nagyon nagy baj. De ez a gyártók és a felhasználok baja és talán kicsit segíti a versenyt.

Én azonban a szemetes fájlokat még nagyobb problémának tartom. (Igaz, ízlések és pofonok.)
Tegyél csak egy három-négyszeres oda-vissza konverziót (mondjuk epub-mobi-epub-mobi-epub egy calibre – sigil – ecub – akármi – kindlegen konverter-sorral). Mindegyik az alapszemetet továbbalakítja (azaz megpróbálja saját szemétté gyúrni és maga előtt görgetni) mindaddig amíg használhatatlan nem lesz az ebook. Tiszta xhtml esetén ennek a veszélye csökken.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.10.19. 15:16:22

@kIára: Nem vitatom a megfigyeléseidet, valóban nem elegáns a publikáció belülről.

DE. Alapvetően, ha egyszer működik ugyanúgy nem érdekel egy állomány "bel-csíne", mint mondjuk hogy milyen enkóderrel tömörítettek egy mp3-at.

Az ilyen konverziós láncokat erősen ellenzem. Sima konverzió még mindig (majdnem) tök jól működik ebből az epubból is, de a normális szerintem az lenne, ha a forrás lenne normálisan összerakva (elvileg tiszta xml, gyakorlatilag mondjuk egy rtf, vagy html), és az egyes publikációformátumokat abból gyártanánk, és nem egymásból.

Én örülnék a legjobban, ha ennél "elegánsabb" struktúrát gyártana bármilyen eszköz. De ilyenről nem tudok, írni nem akarok, ez meg elég használható, a strukturális pongyolasága ellenére is.

kIára 2010.10.20. 14:14:20

@Dworkyll:
»DE. Alapvetően, ha egyszer működik ugyanúgy nem érdekel egy állomány "bel-csíne", mint mondjuk hogy milyen enkóderrel tömörítettek egy mp3-at.«
Ne haragudj, ez nagyon súlyos hiba (legalább akkora, mint a MEK-nek az iso-8859-2 melletti elkötelezettsége :D )
És még nagyobb felelőtlenség részedről ez a kijelentés.
Jelenleg ezt a blogot, figyeli a szakma, és a e-könyvolvasó közönség. És meglehetősen mérvadó maga a blog és a szerző(ik) is.
Erre mit csinálsz? Egy fizetős szoftver, sharvare-verziójának alulteljesítő képességét (epub-export) jónak és elfogadhatónak tartod, sőt melegen ajánlod. Ez szakmai hiba (még akkor is, ha csak „egy blogger” vagy :D )
Egy evidens hibára ezt mondod: „ha egyszer működik ugyanúgy nem érdekel”. Az ilyen hozzáállásnak „köszönhető” például az, hogy sokszázmillió embert lehetetlen leszoktatni az IE6-ról :D

»Én örülnék a legjobban, ha ennél "elegánsabb" struktúrát gyártana bármilyen eszköz.« – Ez megint tévedés. Az eszköz vagy szoftver mindig másodlagos. Az, hogy magánfelhasználásra vannak szoftverek (atlantis, openoffice stb.), amik havi egy-két olvasásra Tibi vagy Klára számára használható e-könyvet készítenek ez üdvös
De egy kiadó vagy egy elektronikus könyvtár számára elsősorban odafigyelő, gondos, és hozzáértő szakember kell.
Te is tudod, hogy epubot simán lehet készíteni egy olyan primitív szoftverrel is mint a notepad.

kIára 2010.10.20. 14:26:41

@Dworkyll:
»Az ilyen konverziós láncokat erősen ellenzem.«
Én is – de amíg nem lesz párhuzamos ebookformátum-szolgáltatás (sem a e-könyvesboltokban, sem az e-könyvtárakban), sem univerzális formátumkezelés a kütyüoldalon, addig ez elkerülhetetlen.

»de a normális szerintem az lenne, ha a forrás lenne normálisan összerakva (elvileg tiszta xml, gyakorlatilag mondjuk egy rtf, vagy html), és az egyes publikációformátumokat abból gyártanánk, és nem egymásból.«
A „gyakorlatilag mondjuk egy rtf, vagy html”-t kihúzni – az „elvileg tiszta xml” átírni „gyakorlatilg”-ra és tökéletesen egyetértünk. :D
Még pontosabban:
mind a MEK-nek mind a DIA-nak ezzel kellene foglalkozni:
        legyen egy és csakis egy xml, amiből bárki bármilyen formátumban lekérheti a művet.

kIára 2010.10.20. 14:37:03

@Dworkyll:
»Nem vitatom a megfigyeléseidet, valóban nem elegáns a publikáció belülről.«
Nem kekeckedésből kérdem: egy saját készítésű, ám nyilvánosság elé szánt epubot hány eszközön, oprendszeren és olvasószoftveren ellenőrzöl? Ha akár egyen is elhasal, vagy a megjelenítés az elvárt alatt teljesít, akkor azt az epubot _Nem Adhatod Ki_.

(így belegondolva mennyivel jobb a mobi… huh.)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.10.20. 22:22:05

@kIára: Ehh, túlértékelsz.

Amit _itt_ ajánlgatok, az a háztáji megoldás, amit akárki megléphet. Én vagyok a legszomorúbb, hogy még ez is kihívást okoz sok embernek. Másfelől az eredménye meg örömet okoz szintén sok embernek.

Vannak mondásaim ipari minőségben is, de az nem blogtéma. Annyit már megtapasztaltam velük, hogy az ipari megoldásokhoz ipari minőségű nyersanyag se ártana, és ismerve a kiadók legjobb esetben is csak manufakturális módszereit, az ipari megoldások költségviszonyai egyszerűen nem finanszírozhatók meg mégoly sikeres kiadók által sem. Sajnos.

Igen, gondos és hozzártő szakember kell. De az drága. Addig maradnak ezek a civilközeli megoldások.

(Most néztem, egy meztelen publi Kindle optimalizálásáért 200 dollárt kér egy átlagos kovertáló szaki, és erre jönnek az extrák, további 50-80 dezsőkért).

Szerinted melyik magyar kiadvány termeli ezt ki, a többi költésgelemen _felül_

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.10.20. 22:28:31

@kIára: Ennél azért egyszerűbb az élet.

Van három lehetséges játékos: Adobe/eInk, iOS, Android. A második kettő szénne konfigurálható a felhasználónak általa, cserébe nem érdekli a beágyazott stíluslap. Gyakorlatilag bármit megeszik.

A munkafolyamatomat addig csiszolgattam, amíg az Adobe parser PC-s és eInkes vonalán is elfogadható eredményt nem produkált, innetől már csak etetni kell a gépezetet, és az extrákat kell leellenőrizni. Amiket. meglepő módon az iOS appok nem szeretnek, megint csak a CSS ignore okán.

Nem ebből élek. Elsősorban magamnak gyártom az olvasnivalót. És az eredmény még így is teljesen versenyképes, a máshol elérhető anyagokkal, hidd el ;-)

SaGa 2010.10.21. 07:41:16

Kicsit vissza a témához...

Egy ideje készítgetek epubokat, Atlantissal és nélküle egyaránt. Az Atlantissal az a bajom, amiket már rtatok: szemetes lesz az eredmény, az általa kiadott cuccot még egy-két órát polírozgatni kell, kiszedni a teljesen felesleges, nem is használt vagy megduplázott classokat, helyretenni az ő és ű betűk köré rakott felesleges körítést, stb.
Ami jó, hogy az így kitisztított, és "em"-esített (pt és in hel yett) méretekkel ellátott css működik szépen.

Kicsit korábban elkezdtem a saját konverziós gépsorom kialakítását, amit azóta is "nevelgetek" és néhányszor belefutottam egy eddig - számomra - érthetetlen hibába.
Ha háromnál több betűfájl került az epub-ba, meggárgyult az egész és összekavarodtak a bold, italic és normál formázások...

Azt hiszem rájöttem a dolog nyitjára. Az okát nem tudom, lehet, hogy css formázásnál így kell lennie (mint már írtam nem vagyok html/xml szakértő), nekem azonban meglepetés volt.

DTP-hez (DOS-os Ventura, Pagemaker, és társai) szokott formázási gyakorlatommal alakítottam ki a css-ben is a bekezdések formázásait. Azaz a bekezdéshez (<p class="EgyBekezdes">) rendeltem a css-ben az összes, arra jellemző beállítást. Azaz a szövegbeosztást, behúzást, margót, sortávot, betűnagyságot, típust, döntést, vastagítást, stb... Ez utóbbiakat akkor, ha az adot bekezdés egésze dőlt vagy vastagon szedett. Egy már jól működött epub-ban próbaképpen lecseréltem a betűtípusokat Gentium Book Basic-ról "Magyar Linux Libertine O"-ra (csak a content opf és a style.css megfelelő javításával) és bekövetkezett az "elformátlanodás".
Gyanítom azért, mert bekerült egy negyedik font is, a "Magyar Linux Libertine C O" is, ami a smallcap szövegek spéci formázási kényszerét kényelmesen ki tudja váltani. Ehhez persze a szövegbe is belenyúltam a megfelelő helyeken.

Ugyanazt a forrást beküldtem az Atlantisba, immár az új betűtípussal és abból meg jól jött ki (csak tele fölösleggel).

Alaposabban tanulmányozni kezdtem a különbséget és azt hiszem rájöttem:
Az Atlantis által kiadott css-ben a bekezdés formázási osztályok (.px) kizárólag az adott bekezdés elhelyezkedését (sortáv, behúzás, igazítás, margók) határozzák meg, maximum még a betű méretet, de semmi egyebet. Illetve a "p" osztálynál van megadva az alapértelmezett betűtípus, de csak itt.

Minden mást (betűtípus, méret, döntés, vastagítás, elhelyezkedés) a ".tx" osztályok hordoznak.

Azaz egy sor kinézetét akkor is a
<p class="bekezdésforma"><span class="szövegforma">
páros határozza meg, ha a teljes bekezdés azonos specialitásokkal rendelkezik a betűk alakjában, méretében, azaz egy jól megadott "bekezdésforma" class tartalmazhatná ezeket is...

Még hegesztgetem a konverter scriptet, ami ilyenné alakítja a dolgot, így az elmélet bizonyítása még hátravan, de érdekelne, hogy ez a dolog az xhtml/css sajátsága, vagy az ADE ilyen lüke...

Dr. Schwanzkopf Rudolf 2010.10.27. 10:10:20

Atlantisszal akarok sima rtf-ből epubot gyártani. El is készül, beágyazott Gentium Book Basic, minden rendben, nézem a style.css-t, szövegkizárás mindenhol justify, tehát rendben van. Fellövöm az olvasóra, és tádááá, nincs justify, minden balra zárt. (Sony PRS 600 touch).

Akkor most mi?

Emberzetvédelmi Pszichomérnök 2010.10.27. 10:26:03

A PRS 600 epubban nem tud sorkizárni. Más formátumban (pl. RTF-ben) tud.

Dr. Schwanzkopf Rudolf 2010.10.27. 10:46:47

@Emberzetvédelmi Pszichomérnök:

Hát akkor marad az LRF, ha kibogozom a formázási rejtvényeket. pl. sorköz annak ellenére, hogy szólok a kalibernek, hogy vegye ki, vagy hogy inaktív a justify opció a Look and Feel-ben :(

Dr. Schwanzkopf Rudolf 2010.10.27. 21:43:36

Ha már Atlantis és html-szemét:

Ma tudtam meg, hogy nem tudok a Sony PRS600-ra sorkizárt epubot gyártani, ezért lrf-ket kell. Ami nem is olyan katasztrofális probléma.

Szóval a lényeg az, hogy epub-ból kell nekem lrf.
1. Calibre-rel epub-ból átteszem txt-be.
2. a txt szöveg megy az Atlantisba (MS Worddal még nem próbáltam). Itt rövid gyomlálás, majd
3. mentés htm-be.

Na ez a htm-fájl NINCS TELE SZEMÉTTEL. Szinte sima szöveg, akár a forrást is lehetne könyvként olvasni.

3. Calibre-rel a htm-ből lrf-t csinálok, megy bele a Gentium Book Basic bold 11-es.

Az eredmény egy maximálisan olvasható lrf-könyv. Tartalomjegyzékkel nem bíbelődöm, nincs rá szükségem.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.10.27. 22:11:35

@Dr. Schwanzkopf Rudolf:

Nem baj, hogy a text nem viszi át a tipográfiát? Dőlt, félkövér, stb?

Amúgy meg jó nagy suttyóság, hogy a Sony egyik elcseszett epub parsere visszakényszerít téged egy általuk is meghaladott formátumra...

Dr. Schwanzkopf Rudolf 2010.10.27. 22:31:08

@Dworkyll: Nem túl régóta van meg a reader, eddig csak néhány könyvet olvastam el rajta, epub-ot nem bírok teljes sorkizárás nélkül látni, tehát marad a lrf. Eddig nem zavart a tipográfia hiánya, meg aztán az is van, hogy én általában olvasni szeretem a szövegeket :) nem nézegetni, hogy a serif lába hogyan keskenyedik el a merített papíron. (na jó, kinyomtatott A4-esen kifejezetten utálok TNR-betűs dolgokat olvasni)

Viszont így valóban fapados egy kissé a fíling, merthogy ugyebár úgy kellene lennie, hogy csilivili epub átmásol az olvasóra és olvassuk, slusszpász.

De hát a sikerélmény, hogy kezünk verejtékes munkájával gyártjuk magunknak az olvasnivalót...

WJ2 2010.11.13. 21:43:50

Hali!
És ehhez mit szóltok? Nekem (Sony PRS 505) elég jól bevált...

code.google.com/p/epub-tools/downloads/detail?name=epubgen-0.5.0.jar&can=2&q=

Dr. Schwanzkopf Rudolf 2010.11.18. 11:25:51

Hogyan lehet a legegyszerűbben félkövérré tenni a szöveget egy kész epubban? Pusztán csak ennyi: legyen minden félkövér benne.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.11.18. 12:01:16

@Dr. Schwanzkopf Rudolf:

Két módja van, nagyon durván.

1. A forrásban állítasz át mindent és újrahúzod az epubot, (bár ebben az esetben én inkább a fontot váltanám valami olvashatóbbra, mert a félövér kiemelésnek amúgy megvan a maga értelme) vagy

2. szétszereled az epubot, és a css-ben megpiszkálod a default fontbeállítást, mondjuk úgy, hogy a normal font hivatkozást átírod, hogy a félkövér készletre mutasson. De ezt nem tartom elegánsnak vagy szerencsésnek.

Grisha 2010.12.22. 01:05:31

Uraim és vaskohásznék!
Lehet az Atlantis-t vhol macro-zni? Vagy úgy tenni vele, mintha előre definiált utasításokat akrnék végrehajtani vele?
BTW: nekem a jetBook lite-hoz és a Pandigital Nvel-hez prímán bevált a konvertere!

Ciuc Ottó 2010.12.30. 07:22:37

Sziasztok! Koobe klasszikomon a TXT formátumnál nincs (vagy nem találom) könyvjelző!
Lehet valamit buherálni ezügyben?

Ciuc Ottó 2010.12.31. 15:42:46

Közben meglett! BÚÉK

piettro 2011.01.05. 10:02:33

Jelentem, a szerszámosládában ismertetett "Calibre tuning és plugin - fontbeágyazáshoz (via Atyaman :-)" megfelelő megoldás az Iriver Story-hoz gyártott epub-hoz (is). E nélkül ugyanis az ő, ű betűket nem jelenítette meg a vas.

Kicsit más: elismerésem, csodálatom, stb. munkásságotok (szerkesztők és kommentelők is) iránt!

Ciuc Ottó 2011.01.09. 16:32:51

A koobe klasszikon a txt formátumnál - a beállításokban - ki lehet választani a magyar elválasztást.
Üröm az örömben, hogy nem működik jól. Tudtok erről valamit?

Feldin · http://teateka.hu/ 2011.01.09. 20:37:10

@piettro: Hogy raktad fel?
Én mac-en próbálgatom, de nem akar összejönni... :(

piettro 2011.01.10. 09:02:56

@Feldin: én Windows 7 alatt használom, sajnos nem tudom, mi a különbség, a környezetemben senki nem használ mac-et. Hol akadtál el? Nem települt, vagy nem működik?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.15. 00:15:37

@SaGa: Figyifigyi! Újabban nem doc-kal, hanem rtf-fel etetem az atlantist, és csodák csodája, a <span> szemetelést mintha nem csinálná. Érdekes mindenesetre.

SaGa 2011.01.17. 07:20:39

@Dworkyll: Kipróbáltam, valóban nem szemeteli tele az epubot annyira, cserébe az ő-ket lecserélte tilde-s ő-re.

Ugyanazt odt-ből teliszemetelte, de rendes ő-ket tartalmaz...

Ebből nekem az következik, hogy az Atlantis a kódlapokkal bajban van...

Valahol be kéne állítani az rtf kódlapját, de nem tudom, hogyan.
Am biztos, hogy ha OOo-ból mentek rtf-be, akkor nem minden rtf olvasó jeleníti meg jól a szöveget, így az OOo-ból odt-t, és doc-ot csinálok, majd ezt a doc-ot egy worddel beolvastatom, kimentem doc-ba és rtf-be, így minden rtf olvasó jól jeleníti meg és a doc-ok is teljesen "kompatibilisak" a doc olvasókkal...

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.17. 09:32:39

@SaGa: Van ott baj sok mindennel. Kezdve a Times New Roman fonttal, mert azzal nálam is kalapos őket hoz az epubba az atlantis. Bármi mással meg, feltéve hogy megvan a készletben, tök penge. Gentium Book Basic rulez :-)

A másik, hogy a word rtf kimenete se százas, mert pl a koobe classic simán kalaposnak látja az ő-ket, itt ugye nincs beágyazott fontkészlet. De ha átküldöd ezen a uniocode egyengetőn ( www.roomarranger.com/reader/ ) akkor frankó lesz.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.17. 09:33:42

@SaGa: Próbáld ki azt a unicode rtf pucolót az OO rtf-jeiden, hátha segít.

SaGa 2011.01.17. 10:35:53

@Dworkyll: Köszi, letesztelem...

kIára 2011.01.17. 23:57:26

Nem ismertek a Caecilia-hoz nagyon hasonlító, de ingyenes és lehetőleg szabad licencű betűkészletet?
A hétvégén végigpróbáltam egy csomó serif betűtípust és rájöttem, hogy szépnek szépek, de e-inken valahogy nem az igaziak, és nem véletlen, hogy a Kindle ezt használja (legkisebb betűméret, condensed typeface és tökéletesen olvasható).
Azon gondolkodom, hogy epub-ban is érdemes lenne egy ilyenre rátérni, különösen azoknak akik elsősorban e-könyvolvasóra készítenek olvasnivalót.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.18. 00:10:38

@kIára: A deja vut és a droidot próbáltad már? Amúgy ismerem az érzést, amikor fontot próbálsz választani... strapás.

Arturo 2011.01.18. 08:27:51

@kIára: Dworkyll jól mondja, ez a kettő szóba jöhet. A Droidot direkt kisképernyős olvasásra tervezték, a DejaVunek pedig van condensed változata.
en.wikipedia.org/wiki/Droid_(font)
en.wikipedia.org/wiki/DejaVu_fonts
Mindkettőt használtam néhány hónapig az olvasómon és jók voltak. Aztán rájöttem, hogy a jó helykihasználás nem minden. :) Inkább legyen kicsit kevesebb szöveg a kijelzőn, de lehessen teljesen kényelmesen olvasni. Nem mintha ezt a kettőt nem lehetne, de most épp mást használok (Palatino).

kIára 2011.01.18. 09:32:51

@Dworkyll: @Arturo:
Teljesen szubjektív vélemény következik.
Szerintem e-inken legjobban mutat: Droid (én ezt használom) és Gentium; LCD-n legjobban mutat: Nimbus Roman; CRT-n legjobb: Nimbus Roman, Times New Roman; papíron legszebb: Garamond, Libertine. (Tableten sajnos nem tudtam tesztelni).

Nagy szívfájdalmam, hogy a Libertine e-inken utolsó helyre került (mondhatni olvashatatlan), pedig ez lenne az ideális.
Érdekes, hogy a DejaVu eszembe se jutott, pedig szoktam használni. Hamarosan ezt is kipróbálom.
Hm… kérhetnék Professoretól egy objektív, mérésekkel teletűzdelt postot e-ink/fontok viszonylatban? Monjuk egy szavazásnak is örülnék arról, hogy az idelátogató felhasználók melyik fontot kedvelik.

Arturo 2011.01.18. 09:47:23

@kIára: Sajnos nem ilyen egyszerű a helyzet. A parserek is különbözőképpen kezelik a fontokat, ami az egyiken szép és komfortos, az a másikon teljesen olvashatatlan. Jó példa a Gentium - az ADE gyönyörűen jeleníti meg, a Coolreader förtelmesen. A CoolReaderen viszont a Libertine korrekt (bár van nála sok jobb), Nálad viszont (Kindle?) pocsék.
Először legyen olyan font, amit minden olvasó jól jelenít meg, azután jöhet a szubjektivitás. :)
Ha van lehetőséged rá, próbáld ki a Palatino Linotype-ot. Nálam most ez a legszebb - igaz, nem ingyenes.

kIára 2011.01.18. 11:07:53

@Arturo:
Világos, hogy sok múlik a parseren és gondolom az adott e-ink-technológia is jelentősen befolyásolja a megjelenést.
Az én magánvéleményem és esztétikainak vélt érzékem önmagában valóban irreleváns. Ezért lenne jó egy szubjektív szavazás és egy (a lehetőségekhez képest) objektív mérés. Különösen azok számára, akik nem kizárólag magáncélra nevelgetik az epubokat, hanem nagyobb közönséghez szólnak. Pl. a MEK egy rosszul választott betűkészlettel nem biztos, hogy osztatlan sikert arat.
Egyelőre ott tartok, hogy a nagyon finoman metszett serif apró méretben nem ideális, a darabosabb serifek pedig az LCD-s kütyükön csúnyácskák. Igaz, hogy néhány desktop/tablet olvasószoftver képes a felhasználói preferenciákra úgyhogy ebben az esetben talán nem annyira életbe vágó a kérdés. (A középút megtalálását nem tartom lehetetlennek).

A Palatino felkerült a listára :) – köszönöm a tippet.

Pelesz 2011.01.18. 11:32:37

Én 'Century Schoolbook L'-t használok, mondjuk nem tudom, hogy ez szabadon használható-e, ooo-ból lett kibányászva. Szép talpas betűket produkál, őű sem hiányzik belőle. Ilyenkor örülök, hogy az olvasom magasról tojik a gyári beállításokra. :p

Atyaman 2011.01.18. 11:48:43

Én a magam részéről a fonts101.com-ról válogattam össze egy Souvenir készletet. Az alap (souveni1.ttf) számomra nagyon kényelmes a Kindle-ön. Tény, hogy már a félkövér kategóriát kezdi közelíteni, de pont ettől olyan jó a kontrasztja. A méretét pedig pont a Kindle-re szabták, mert a megjelenése nagyon sima (kb. mint a Caecilia). Egy hátulütője van, hogy nincs benne ő és ű betű, de ezen egy rövid hegesztéssel már segítettem, úgyhogy most már van XD

Mivel nálam csak a Serif fontok jöhetnek szóba második számú betűtípusnak a Regular helyére a már sokat emlegetett Palatinot választottam. Nekem kicsit szellős a megjelenítése, és a kontrasztja is elmarad a Caecilia-tól (ami, most Condensed fontként van fenn) és a Souvenirtől (a Sans Serif helyén). Viszont az tény, hogy jobban néz ki, mint pl. a Souvenir, aminek kicsit azért szokni kell a külalakját (de csak egy picit :).

SaGa 2011.01.18. 12:03:02

@kIára: A Libertine ttf vagy otf formában rossz?

kIára 2011.01.26. 16:10:52

@SaGa:
      Csak ttf-ben próbáltam.
      Nem azt írtam, hogy rossz, hanem azt hogy alkalmatlan. Annyira finomak a betűszárak és a serifek, hogy az e-inken (kindle-n legalábbis) legkisebb méretben egyszerűen nem látszanak. Nyomtatásban persze pazar. A Garamonddal is ugyanez a baj.
      Közben kipróbáltam a Palatinót. Nagyon jól olvasható, leginkább az alapértelmezett sormagassága zavar. Objektíve nem tudnék dönteni a Droid és a Palatino között, hiszen egyformán jól olvashatók. A Droid valami miatt jobban tetszik. (A Gentium csöndben hátrébb kullogott).

Xingyi 2011.02.23. 11:13:41

Sziasztok!
Tanácsra lenne szükségem.
Elkészítem az epub-ot az Atlantisban, 1% margóval. Minden jó, csak annyi esztétikai problémám van, hogy az olvasómon az Adobe olvasó-szoftvere, ha egybefüggő szövegről van szó, lapozás után, a szöveget a kijelző széléhez illeszti, nem hagy margót.
Erre tudtok valami megoldást?
Válaszotokat előre is köszönöm.

SaGa 2011.02.23. 12:26:29

@Xingyi: Gyanús, hogy parser hiba, így gyógyíthatatlan, de ha kibontod az epub-ot (winzip, 7zip szétszedi, de ha átnevezed zip-nek epub helyett, akkor a windows maga is bele tud nézni) és megkeresed a styles.css-t, meg tudod nézni, hogy a margót a body leírásnál állította-e be (ott kellene, pontosabban a többi margó az az ott megadott margón belül értelmezendő, tehát ennyit mindig ki kellene hagynia), vagy a p-nél. Ha ez utóbbi, akkor formázási hiba, és a parser valóban meghülyülhet, ugyanis az oldalakon átnyúló bekezdés esetében sokszor nem tudják kiértékelni a bekezdés elején, még az előző oldalon volt formázási utasításokat. Ez is programozói hiba, de sok olvasó programnál láttam ilyet.
Ha a body-nál jól vannak az alapértelmezett margók megadva, és így hibázik, az egyértelműen az olvasó program hibája, és kénytelen leszel vele együtt élni...

Feldin · http://teateka.hu/ 2011.02.28. 01:52:51

@piettro:
még ugyanaz a font beágyazós problémám van calibre-ben.
plugin rendben felment, fontot beraktam a helyére de ezt mondja konveruió végén:

Running file type plugin EPUB Font embedding plugin failed with traceback:
EPUB output written to /var/folders/3h/3hq0-aokHg4Nwzlf04kuok+++TI/-Tmp-/calibre_0.7.47_tmp_6a8aq8/calibre_0.7.47_AmX983.epub

nincs valami ötletetek?

Xingyi 2011.03.07. 18:04:57

@SaGa: Sikerült a problémát megoldani. Leírom, hátha másnak is van ilyen gondja és lehet, hogy téged is érdekel SaGa.
A body-ban mindenhol benne van a 2%-os margó, mégsem hagy helyet az Adobe szoftvere a kijelző tetejétől lapozáskor.
Ha megnyitom az Atlantis által generált css-t és beírom neki:

@page{margin-top:x pt;margin-bottom:x pt;}

Utána már az Adobe olvasó-szoftvere is hagy helyet a kijelző tetejétől.
Remélem másnak is hasznos volt ez az információ.

SaGa 2011.03.08. 09:11:55

@Xingyi: Köszi...
Ezek szerint az Adobe a saját szabványát is furcsán értelmezi, ugyanis a @page kezdetű bejegyzések az "oldalakra szedhető" megjelenítéskor (nyomtatás) érvényes szabályokat tartalmazzák, az ADE meg - elvileg - "folyamatos" megjelenítő...
Mindegy, akkor erre is figyelünk majd, köszi még egyszer...

megvakarom 2011.03.23. 13:36:25

www.pdftoword.com/
ezt most próbáltam egy telelábjegyzetelt, karakterformázott könyv pdf-jével, és működik. Minden karakterformázás megtartva! Kurzív, kiskapitális, minden. Idézőjelek, belső idézőjelek.
Már csak a stílusokat kell bekattintgatni, és célegyenes.

ff48bp 2011.11.02. 11:16:52

Van egy könyv, amit ajándgyanánt szeretnék a szerzőnek e-pubba áttenni. Sima szöveget csinálnék belőle, csak a tematikus címnél lenne egy grafika, illetve felette a grafikus jellegű címsort is megtartanám, hogy emlékeztessen a könyv hangulatára. A gondom az, hogy ha a tematikus címet a Sigilben kicserélem a grafikára (amiben benne van a cím), akkor látszólag jó lesz a tartalomjegyzék, de az olvasóprogramokban mégsem ugrik a tartalomnál a megfelelő helyre. Ezek szerint itt nem lehet olyasfajta bookmarkot megcsinálni, mint a pdfben? A másik gond, hogy nem ismerem a Sigilt, így nem tudom hogy állíthatom be a képek nagyíthatóságát, vagy hogy méretezhetem esetleg át azt. Azt sem tudom, hogy tudom megadni, hogy a szöveg sorkizárt lehessen. Egyébként Indesignból csinálom az e-pubot, de ez nem lehet ok arra, hogy nem sorkizárt a szöveg. Az a gond, hogy ha Calibre-n átfuttatom, akkor meg a Sigil ír ki hibát és nem olvassa be a könyvet.

Atyaman 2011.11.02. 13:51:09

@ff48bp: Én nem Sigillel készítem az epub-okat, így az arra vonatkozó specifikus kérdésekre nem tudok sajnos válaszolni.

A grafikus címsort viszont úgy oldanám meg, hogy amivel szeretném, hogy kezdődjenek a fejezetek az lenne a tartalomjegyzék hivatkozott pontja. Pl. ha az adott konvertáló program a Címsor/Heading stílusú elemekből készíti a TOC-ot, akkor jelen esetben nem a címet, hanem a legfelső grafikus címsort látnám el stílussal. Ezáltal a tartalomjegyzék megfelelő pontja arra mutatna. Annyi meló lenne vele, hogy így utólag kell majd az epub-on belüli toc fájlban (.ncx kiterjesztésű) beírni a címeket (mert azt a képből nem tudja kitalálni a konverter).

Persze ideálisabb lenne ha valahogy a címet össze lehetne láncolni az előtte lévő grafikákkal, és mindenképp együtt jelennének meg. Valaki hozzáértőbb biztos tudná ezt hogyan lehet elérni.

A szöveget a már kész epub-ban is könnyen lehet sorkizárttá tenni. Csak minimális szintű html ismeret kell hozzá. Meg kell az epub-on belül a stílusleírót (.css kiterjesztésű), azon belül pedig a törzsszöveg formázására vonatkozó részt és a text-align-t kell átírni justify-ra, mert valószínűleg left-re van állítva.

Atyaman 2011.11.02. 13:53:12

@Atyaman: javítás:
»Meg kell« +keresni »az epub-on belül a stílusleírót«

ff48bp 2011.11.02. 18:21:44

@Atyaman: Köszönöm, ez nagyon jó ötlet, kipróbálom, bár az a helyzet, hogy végül is ugyanezt csináltam akkor, amikor a szöveget cseréltem a képre, hiszen úgy megvolt már a tartalomjegyzék és a Sigilben azt csináltam, hogy a szöveget kitöröltem és oda linkeltem be a képet. Lehet, hogy az volt a baj, hogy a teljes bekezdést töröltem, s így már hiába maradt ott a tartalomban a szöveg, nem volt hivatkozási hely.

Atyaman 2011.11.02. 19:30:36

@ff48bp: Igen, ha kitörölted a bekezdést, azzal a bekezdés stílusformázása valószínűleg elveszett. És utána nem jött létre megfelelően a TOC.

A hivatkozási pont nem fog elveszni valószínűleg. Eddig én azt tapasztaltam (Atlantisszal készítve az e-könyveket), hogy az epub fejezetenként tagolja a szöveget, azaz minden fejezetnek külön html-t (vagy xhtml-t) hoz létre, és a toc pedig magára a html fájlra mutat. Tehát ha ezeknek a html-eknek az elejére tesszük be utólag a képeket, akkor is a kívánt formában fognak megjelenni. Csak ez kézzel csinálva, sok fejezet esetén elég melós. Plusz ilyenkor nem elfelejteni, hogy az opf manifest leírásában részében meg kell adni az így bekerült képeket.

SaGa 2011.11.03. 12:06:25

@Atyaman: Az Atlantis két helyen szedi szét a könyvet fájlokra:
a címsoroknál és a beillesztett oldaltöréseknél.

A képekkel való "játszadozást" sem az Atlantis, sem a Sigil nem tudja rendesen megoldani, mindenképp kézzel kell balanyúlni a megfelelő html fájlokba.

Én úgy oldanám meg a grafikus címeket, hogy a Sigilben szöveggelkezelném a címeket, hogy a toc.ncx megfelelően ki legyen töltve, ne kelljen benne turkálni. Nem túl bonyolult, de nem is triviális a szintaxisa.
A képeket bepakolnám a Sigilben az Images mappába, majd kimenteném az egészet epubként.
Aztán jön a "varázslás": szét kell szedni az epub-ot, és a megfelelő html-ekben kijavítani a címsorokat úgy, hogy a szöveg helyére az "img" meghatározás kerüljön be, megfelelő formázással.
A Sigil a képek formázásához mindenképp az adott xhtml headerében definiált sgc-x szílusokkal adja meg, nem a css-ből szedi. Ha nem kerül vissza a javítás után a sigil-be az epub, akkor lehet direkt "style" megadással is dolgozni.

A kép formázáshoz leeht, hogy div-ekkel, és "float" formázással kell kicsit kísérletezni. Az epub-ban a képek az oldalhoz arányított %-ban pozícionálhatóak és méretezhetőek legjobban, de lehet direkt px vagy pt méretekkel is operálni, csak nem érdemes, mert más méretű olvasón elmászik az egész.

Javaslom a kézi javítás után a visszacsomagolt e-pub-ot mindenképp beolvastatni a tweak_epub.exe-vel, kiválasztani egy tetszőleges fájlt, abba belejavítani valamit (mindegy mit, csak ki kelljen mentani a fájlt) és aktualizálni a tweak_epub-bal. Ez helyreállítja az epub belső szerkezetét úgy, hogy még az Azardi is hajlandó lesz elfogadni.

Még valami: a sigil az "i" taget midenképp kiemeli az adott html headerébe illesztett sgc classokba. Ennek elekrülésére jvasolt az 'em' tag-ek használata, azt nem alakítja át.

SaGa 2011.11.03. 12:07:58

@SaGa: Bocs a sok elütésért...

ff48bp 2011.11.03. 14:00:12

Nem tudom mi lehet a gond, de hiába van a stílusban, hogy magyar a szöveg és sorkizárt, az olvasók csak nagyon nyögve és óriási szóközökkel választják el a sorokat. Mint mikor egy prc fájlt próbál a program sorkizárttá tenni, olyan az egész.
Erre van valami megoldás?

ff48bp 2011.11.03. 14:03:04

@SaGa: Na, ebből azt hiszem semmit sem értettem, amit leírtál, ez most nekem túlságosan új.

ff48bp 2011.11.03. 14:08:11

Valahol ide kellene a kép méretezését beírni? Muszáj ehhez html parancsokat ismernem? Azok ugyanis nem mennek.

@font-face {
font-family: Liberation Sans;
font-style: italic;
font-weight: bold;
src:url("../Fonts/LiberationSans-BoldItalic.ttf");
}

div.generated-style {
}
div.generated-style-2 {
}
div.generated-style-3 {
}
h1.heading-1 {
font-family: "Liberation Sans";
font-weight: bold;
font-style: normal;
font-size: 1.9em;
line-height: 1.20em;
text-decoration: none;
font-variant: normal;
text-indent: 0em;
text-align: left;
color: #000000;
margin: 0em 0em 0.49em 0em;
}

Atyaman 2011.11.03. 15:36:34

@SaGa: Nekem közben még az is eszembe jutott, hogy ugyanezzel a munkafolyamattal lehetne azt is csinálni, hogy a fejezetcímet beírjuk és szövegkezeljük, hogy a fejezetek jól meglegyenek, de már eleve ebben a szakaszban betennénk alájuk a képeket. Így az utólagos matatásban a képet már nem kéne nekünk beszerkesztenünk a html fájlba, elég lenne csak a felette lévő címet törölni.

Atyaman 2011.11.03. 15:44:24

@ff48bp: ez a css fájlban van. Itt lehet alakítani a szövegképen. Pl. a h1.heading-1 valószínűleg maga a fejezetcím formázás, ami itt éppen balra van igazítva. Ha pl. középre szeretnéd, akkor a
text-align:left; -> text-align:center;
módosítást kell elvégezni. A törzsszövegnél (bodytext, normal, p vagy valami ilyesmi neve van valószínűleg) lehet ez még fontos, ahol mondtad, hogy az balra zárt. Annak az értékét justify-ra kéne változtatni, hogy sorkizárt legyen.

A képet nem ide kell beilleszteni. Ellenben nem árt ide tenni hozzá egy stílusleírót (mint a h1 vagy a törzsszöveg stílusleírója), amiben be lehet állítani pl. a méretezését, igazítását. Így azt nem kell minden esetben a fejezetek html fájljaiban megejteni, mikor oda betesszük a kép hivatkozását.

ff48bp 2011.11.03. 15:51:34

A kép méretezését megtaláltam és sikerült százalékosan megadnom. Úgy látom működik. Mivel 6 képről van szó, így egyelőre ez volt a legegyszerűbb számomra.

<div class="generated-style-2">
<h1 class="heading-1" id="toc-anchor-2" xml:lang="hu" xmlns:xml="http://www.w3.org/XML/1998/namespace"><img alt="" height="60%" src="../Images/2.png" /><br /></h1>
</div>

A body text a cssben:
}
p.basic-paragraph {
font-family: "Liberation Sans";
font-weight: normal;
font-style: normal;
font-size: 0.88889em;
line-height: 1.30em;
text-decoration: none;
font-variant: normal;
text-indent: 1.30em;
text-align: justify;
color: #000000;
margin: 0em;
}

Őszintén szólva ezek után nem értem az elválasztási problémát. Persze az is lehet, hogy az FBreaderben van a hiba?

Atyaman 2011.11.03. 15:55:21

@ff48bp: A sorok közti szünetet a line-height definiálja. Próbáld meg annak az értékét csökkenteni, és akkor nem lesz akkora térköz a sorok közt.

ff48bp 2011.11.03. 15:59:59

Ok, de nem is ez a gondom, hanem az, hogy az olvasóprogram nagy szóközöket csinál. Beférne az elválasztás, de inkább hatalmas szóközt hagy.

ff48bp 2011.11.03. 16:04:09

Itt most az a gond, hogy egy már kész könyvet, ami szét van darabolva kis novellákra, nehéz lenne kiszedni az Indesign programból, s így azzal kellene e-pubot gyártanom. És végül is működik, a Sigilben be tudom tenni a képeket, ki tudom gyomlálni a nagyobb hibákat, sőt már a kép méretezését is meg tudom adni és egy ilyen kis dolgon, hogy a justified mégsem az, ezen bukik meg az egész. Pedig sima szöveg, ennél egyszerűbb nem is lehetne.

Atyaman 2011.11.03. 16:21:49

@ff48bp: akkor lehet, hogy az indesign még becsempészett valami "ajándék" beállítást a szóközökre vagy az elválasztás kezelésére nézve. De sajnos erre nincs ötletem, hogy merre lehet, és milyen néven, mert én is csak tippelek :(

ff48bp 2011.11.03. 17:24:51

Ha gondolok, akkor egy mintát tudok küldeni a könyvből, abból biztos többet látni.

kopogi 2011.11.03. 17:29:19

Sziasztok!
Lenne egy kérdésem! Az egyik könyv konvertálásánál az "ő" betű helyére "i"-t tesz be - akár a Calibre, akár a Mobipocket - az "ű" helyére pedig "ő"-t.
Hogyan lehetne ezt megváltoztatni?

Atyaman 2011.11.03. 17:31:49

@ff48bp: Jöhet nyugodtan. Több szem többet lát ;)

ff48bp 2011.11.03. 17:32:52

Küldeném, de nem látom a címed.

Atyaman 2011.11.03. 17:35:35

@kopogi: pdf-et konvertáltál? Ha igen, akkor valószínűleg abban vannak elszúrva kicsit a karakterkódok. Javítani csak úgy lehet, ha valami köztes formátumba konvertálod először (pl.: rtf, html) és ott kicseréled a kérdéses karaktereket.

Mobipocket gyik 2. pont:
forum.ekonyvolvaso.info/topic/9-mobipocket-creator/page__view__findpost__p__97

(Tudom, hogy epub-os topik, én meg mobipocketes linket adtam, de úgy tűnik, mintha ez a probléma állna fenn.)

Atyaman 2011.11.03. 17:36:43

@ff48bp: régebben már váltottunk e-mailt. Előkereslek és onnan dobok egy mail-t, hogy meglegyen megint ;)

kopogi 2011.11.03. 20:31:38

@Atyaman: Köszi! Akkor majd próbálkozom...

SaGa 2011.11.04. 13:33:37

@ff48bp: Az FBReaderben bekezdésfajtánként kell megadni, hogy elválasztást használjon-e vagy sem. A "p.basic-paragraph" valószínűleg nem illeszkedik az általa értelmezett bekezdésstílusok közé. Ne feledjük, hogy az fbreader egy FB2 olvasó, ami csak annyira képes az epubokat kezelni, ameddig azok nem haladják meg egy fb2 formátum képességeit és bonyolultságát. Ezekben meg csak azok a bekezdéstipusok szerepelhetnek, amelyek az fbreader beállításainál megtalálhatóak. Ezekkel a p.xxx tipusokkal mit sem tud kezdeni.
Próbáld meg az
alábbiakat:
Az elkészült epub-ot told be a sigilbe. ott nyisd meg a css-t és javítsd ki a "p.basic-paragraph" szöveget egyszerűen "p"-re, majd ugyanezt ismételd meg egy keres-csere az "összes html fájlon" opcióval.
Mentsd el és nézd meg az olvasóval. Ha így már elválaszt, akkor ez volt a baja, ha nem, akkor is ezen a nyomon kellene elindulni.

Megjegyzem: az fbreaderen és a coolreaderen kívül nem is tudok olyan olvasóról, amelyik hajlandó lenne elválasztást használni az epubokban. Létezik egy java scriptes megoldás, de az meg magyarul nem tud, meg talán csak az ADE képes használni.

ff48bp 2011.11.04. 16:37:54

sajnos nem változott semmi, de azért köszönöm a választ.

ff48bp 2011.11.04. 16:57:56

Lehet, hogy az a baj, hogy nem ismeri fel a magyar nyelvet? De hát a sorok elején ott van, hogy:

<p class="p" xml:lang="hu" xmlns:xml="http://www.w3.org/XML/1998/namespace">Mielőtt hozzámfog, gondolja meg jól, hogy a drága idejéből kíván-e értékes perceket, netán egy-két órát is eltölteni a könyv olvasgatásával.</p>

És így tovább.

Atyaman 2011.11.04. 19:44:00

@SaGa: @ff48bp: Nekem az is eszembe jutott az elválasztásnál, hogy az .opf fájlba viszont angol volt megadva alapértelmezett nyelvnek (ff48bp küldött egy mintát) és az fbreader abból indul ki. Vagy a parsere nem ismeri az xml:lang="hu" kifejezést, ami amúgy minden bekezdésnél benne van a kódban.

ff48bp 2011.11.05. 09:10:21

@Atyaman: Köszönöm az ötletet. Ez a pici dolog megoldotta a problémát. Ezenkívül még a nevet is módosítottam, úgyhogy nem tudom, mi a legegyszerűbb megoldás, de most lett tökéletes.

ff48bp 2011.11.10. 06:15:27

Nos, Atyaman segítségével sikerült a könyvet helyrepofozni és ez a word-atlantis páros egész ígéretes technológia számomra. A következő lépés azt hiszem a képek kezelésének megismerése, hogy lehet egy képet iniciálészerűen betenni, vagy esetleg támogatja-e az e-pub a kép nagyításának funkcióját, ilyesmi. Persze azt nem tudom, hogy ha támogatja, akkor egy nagyított kép, ha kilóg a képernyőből, akkor mi van, lehet-e tolni ide-oda, vagy csak kilóg? Ilyesmiben biztos van itt jó pár embernek tapasztalata.

ff48bp 2011.11.10. 14:43:14

Amúgy bocs, hogy itt kérdezek, nem a fórumban, de oda hiába regisztráltam, nem kaptam visszajelzést, s így nem tudok oda belépni.

Atyaman 2011.11.10. 15:32:34

@ff48bp: Egy admin vagy mod azt hiszem tudja érvényesíteni saját kezűleg is a regisztrációd. De egyébként talán nem is baj, hogy nem oda írsz. Sajnos az egyik bug (a legfrissebb kommentek nem megjelenítése) miatt nem kizárt hogy észre se vennénk :(

Iniciálé egyébként lehetséges az epub-ban, de az Atlantisszal sajnos kicsit nehézkes lehet (még nem próbáltam), mert nem ismeri a kép formázásnál a körbe futtatást, ami a süllyesztett iniciáléhoz kellene.

ff48bp 2011.11.10. 18:54:02

Azt hiszem a képpel kapcsolatos dolgokat a Sigilben írnám be, ha a megfelelő szintaxist tudom. Remélem, hogy ezek a dolgok egy kis próbálkozás után már elég automatikusak lehetnek, csak forrás kellene hozzá. Esetleg egy e-pubból is ki lehetne nézni. És a nagyítással hogy állunk? Láttál már olyan e-pubot, amiben rákattintással/mutatással nagyítódik a kép? A Kindle újságjaiban láttam már, hogy van ilyen, pedig az csak prc.

Atyaman 2011.11.10. 19:50:13

@ff48bp: A Kindle szoftverében (talán a többi prc olvasóban is, de ezt inkább passzolom) alapértelmezett funkció, ha van kép, akkor arra kattintva a lehető legnagyobb méretbe kinagyítja (méretarányosan, de ha kell fektetve teszi ki teljes képernyőre).

Az epub nem ilyen. Ott még nem találkoztam ezzel a funkcióval. Így jobb híján azt tudnám elképzelni, hogy a kép linkként működhetne és rákattintva pl. a könyv végre helyezett illusztrációk közt a neki megfelelő képhez vinne. A két kép közt elég lenne annyi különbség, hogy a html kódban az elsőt kis méretűre állítjuk (pl. 20-40% a kijelzőhöz képest), míg utóbbit, ami az illusztrációknál van teljes képernyősre lőnénk be.

SaGa 2011.11.11. 07:37:46

@ff48bp: A képet olvasás közben nem tudod nagyítani. Pontosabban még nem találkoztam olyan olvasóval, ami ezt tudná. A fapados olvasók eleve teljes képernyőre kiteszik a képet, függetlenül attól, hogy az mekkora lenne és milyen "körülfolyatást" kapott.

A kép méretezését ta dod meg, vagy abszolut pixelekben, vagy a kijelző adott irányú méreténeke százalékában. Az elhelyezést szintén. Tanulmányozd a már többször említett és fentebb is linkelt Alice in wonderland epubot, abban gyakorlatilag minden benne van, amit a képek méretezéséről
és elhelyezéséről tudni lehet.

A sigil mindenképp gy külön "sgc" stílust ad a képeknek, abban tudsz mókolni. Mindig az adott html headerében van, nem a css-ben.

Iniciálé: kedvenc témám, a prc-ből nagyon hiányzik.

Megoldható, a float attributumot kell használni.
Pl:

A html tartalma:

<p class="pa"><span class="ta">A</span></p>

<p class="pFP"><span class="t10">&nbsp; két hajó</span> gyenge hátszéllel suhanva, pirkadatra érte el a szigeteket. Némán és sötéten, szinte vitorlalebbenés nélkül siklottak a kikötő felé.</p>

A hozzá tartozó css sorok:

p{text-indent:1em;margin-left:0;line-height:120%;margin-right:0;text-align:justify;margin-top:0;margin-bottom:0;font-family:"Magyar Linux Libertine N";font-size:109%}

.pFP{text-indent:0;margin-left:0;margin-top:2em}

.pa, .pai, .pb, .pbi, .pc, .pd, .peh, .pe, .pf, .phi, .pi, .pk, .pl,

.pt{text-indent:0;float:left;line-height:300%;margin-top:2.3em;margin-right:.25em;margin-bottom:0}

.ta, .tci, .th, .tk, .tn, .tr, .tuh{font-family:GregorianFLF;font-size:3.8em;vertical-align:top}

.t10{font-family:"Magyar Linux Libertine N C"}

A css sorokból látszik, hogy az iniciálé betűit gyakorlatilag majdnem karakterenként kell méretezni. Lehet, hogy egy igényesebb, kereskedelmi betűtípusnál nem kell, de a Gregorian FLF egy szabadon használható óangol változat és csak eyszer kell végigzongorázni, melyik betűt mekkorára kell méretezni és hova kell pozícionálni, ha minden nagyításban szép iniciálét akarok belőle csinálni.

Amivel mostanában küzdök: egy iniciálé szerű megoldást (nagy kezdőbetű, harmadakkora folytatás a felső margóhoz tapadva, majd a cím második sora szorosan a folytatás alá becsúsztatva ötöd akkorában, mint a kezdőbetű) tartalmazó címsort szeretnék középre állítani. Na ez nem megy. Pontosabban az nem megy, hogy az olvasó által átállított betűméretek mindegyikében középre kerüljön.

Úgy meg tudom oldani, hogy az adott szöveg fix méretű és berakom egy "div" dobozba, de az nem tetszik. Az epubnak pont az az előnye, hogy ha az alap betűtípust átméretezi az olvasó, akkor minden egyéb (címsor, kiemelés, sortáv) is új méretet kap, de az arányai nem változnak. Már ha jól van megcsinálva az epub.

ff48bp 2011.11.11. 08:57:00

@SaGa: Köszönöm a tippeket, próbálkozni fogok.
Igazából az iniciálénál arra gondoltam, hogy iniciálészerűen körbefolyatott kép kellene, vagyis a bekezdésbe kellene süllyeszteni. Úgy látom a soraidból, hogy ez nem fog menni.

SaGa 2011.11.11. 10:12:28

@ff48bp: Megy az, csak nem egyszerű...
Ismét csak az Alice in wonderland-ra tudok hivatkozni.
Erre a verzióra:

www.mobileread.com/forums/showthread.php?t=69867

Vigyázat, csak ADE-val élvezhető maradéktalanul.

Csomagold ki és tanulmányozd a megoldásait.
Keresd meg azt a szövegrészt a könyvben, ott van egy gyönyörű megoldása az ilyen képnek, ami ráadásul nem is egy sima téglalap:

So she set the little creature down, and felt quite relieved to
see it trot away quietly into the wood

Amúgy maga a fájl nem teljesen "szabványos" epub, de a formázási beállításokból van mit tanulni.

SaGa 2011.11.11. 10:15:24

@SaGa: Elnézést, rossz link maradt az előzőben. A jó verziója az Alice csodaországban kötetnek itt található:

www.megaupload.com/?d=OOYS26P1

ff48bp 2011.11.11. 11:27:04

Hát ez tényleg látványos, de majd letesztelem egy kis telefonon is, mit tud ebből mutatni egy coolreader mondjuk. Ezek az sgc parancsok nagyon fontosak a beágyazáshoz, meg kell őket ismernem, de azt hiszem a float részét még kihagyom.

SaGa 2011.11.11. 12:07:28

A coolreaderben - ha megjelenik egyáltalán a kép - vagy középen lesz és a szöveg alatta, vagy a bal szélen, de a szöveg akkor is alatta.
Az "sgc-x" stílusokban semmi különleges nincs. Azokat az opciókat tartalmazza, amit normális esetben a style="..." beállításban adnál meg egy bekezdésnek, képnek.
Csak a Sigil "modorossága", hogy inkább így oldják meg.

ff48bp 2011.11.12. 09:14:34

Szinte belelát a Coolreader programozója a gondolataimba, mert pont most adott ki egy frissítést a programhoz, amivel a képeket lehet nagyítani és a pan funkció is működik. Azt hiszem számomra ez most egy hatalmas buzdítás, hogy igenis, még nagyobb erővel kell foglalkoznom az e-pubbal, mert ha már egy egyszerű olvasó ilyen funkciókat tud, akkor az illusztrációs könyveket is bátrabban lehet csinálni. A meglepően intelligens e-pubkezelés és a magyar elválasztás számomra ezt programot egészen kiemelkedővé teszi a sok közül.

cinamon 2011.11.12. 10:46:01

Sziasztok!

Szeretném megkérdezni, hátha tudja valaki, hogy Sony prs 600-as csak fülhallgatóval működik, és nincs beépített hangszórója, vagy az enyémmel van valami probléma, hogy nem szól.
Előre is köszönöm a válaszokat!

Atyaman 2011.11.12. 12:38:22

@cinamon: A legjobb tudomásom szerint nincs beépített hangszórója. A biztonság kedvéért megnéztem néhány oldalt is, de sehol nem írnak hangszóróról. Ha lenne akkor biztos feltüntették volna a Sony honlapján, vagy a kézikönyvben:
store.sony.com/wcsstore/SonyStyleStorefrontAssetStore/pdf/warranty/SEL-asset-166216.pdf

ff48bp 2011.11.14. 19:44:13

A Multimédiapláza oldaláról letöltöttem egy e-pubot és meglepődve láttam, hogy Garamondból van. Én úgy tudom ez nem ingyenes font és kötve hiszem, hogy a Kossuth Kiadó megvette a font terjesztési jogát. Szerintem vigyázni kellene az ilyesmire, mert ha egy fontgyártó vagy viszonteladó ezt megneszeli, az nem lesz jó senkinek sem.

urielz29 2011.11.17. 10:51:02

Sziasztok !
Elnézést, hogy ide írok mert nem tudom hogy hová kellene írni...Segítségre lenne szükségem, éspedig: egy ismerősöm vett egy Sony PRS-T1 olvasót ( meglepetés lenne karácsonyra valakinek...) . A gond az, hogy nem jeleníti meg a hosszú ő és ű karaktereket. Mivel életemben először jár ilyen eszköz a kezemben ( úgy értem, hogy epub formátumot kezelő eszköz, mert amúgy Kindle 3 tulaj vagyok, és az erre az eszközre való könyvkészítés - kezdve a word-kezelésen át a mobipocket-es mobi-k készítéséig - nem gond ), fogalmam sincs, hogy erre van-e valami megoldás. Calibre-vel próbáltam átkonvertálni prc-ket, de ugyanaz a helyzet, mintha egy eredeti epub-ot olvastatnék be vele. Van erre valami megoldás, vagy egész komolyan neki kell fogni az epub-piszkálásnak??? (fontbeágyazás???). Ez nem lenne a legmegfelelőbb opció - sem időm, sem kedvem hozzá....elég sok magyar mobi meg prc átkonvertálásáról lenne szó.
Köszönöm szépen, ha valaki tud válaszolni...
(amúgy az eszköz nem rossz, a kijelző szép, az érintéses kezelés eléggé jó; tetszetős kis masina (lenne), ha a Kindle nem létezne...)

Atyaman 2011.11.17. 11:47:57

@urielz29: Több megoldás is létezik. Az a közös, hogy fontbeágyazásra mindenképp szükség lesz, mivel a legtöbb epub-os olvasó alap betűkészlete nem támogatja az "őű" karaktereket.

A "legegyszerűbb" megoldás: calibre-rel epub-ba konvertálni, majd ellátogatni erre a honlapra: www.e-konyvtar.com/ és ez elvégzi a fontbeágyazást az epub-ban a választható betűtípusok valamelyikére.

A "nem biztos, hogy működő, de ha igen, akkor gyorsabb" megoldás: a fenti poszt V. pontjában lévő Calibre tuning és plugin leírást végigkövetni. Így a Calibre magától végzi el a fontbeágyazást a konvertáláskor, de a Calibre folyamatos fejlesztése miatt már nem biztos, hogy kompatibilis a plugin.

A "legjobb, de leghosszabb" megoldás: amennyiben elmentettük a könyveink prc-vé konvertálása előtt megformázott dokumentumot (pl.: rtf, html, xml, doc, odt, stb. formátumban), akkor a fenti leírást követve az Atlantis Word Processorral (rtf kell hozzá), vagy Sigillel, Jutohval készítsük el az epub-ot, figyelve a fontbeágyazásra.

urielz29 2011.11.17. 12:39:32

Köszönöm a gyors választ !

Az online átalakítás: már próbáltam de nem működött; tisztázandó, hogy nem-e a Calibre-vel konvertált epub-bal van-e baj, letöltöttem egy mek-es epub-ot; ezt a Stanza ( PC) jól jeleníti meg, ellenben az olvasón ( és a PC-n lévő Sony Reader-en is) rosszul jelennek meg...

Gyorsabb megoldás: ezt is próbáltam már - ez sem működik, valószínű a plugin nem kompatibilis már ( mindig a legújabb Calibre van fent nekem)

Tehát akkor marad a legutolsó megoldás..hát ez, őszintén szólva nem a szívem csücske, nem egy kevés munka lenne pár száz könyvvel dolgozgatni másnak - eléggé időigényes, gondolom...Egy mobi készítésével is el tudok szöszölni órák hosszat a minőség igénye miatt. Inkább megmondom hogy vegyen egy Kindlét, arra félóra alatt rakok annyi kész anyagot, hogy évekig elég lesz..:-)
Mégegyszer, nagyon köszönöm !

Atyaman 2011.11.17. 13:01:26

@urielz29: Fura, hogy az online átalakítás nem vezetett jó megoldáshoz. A T1 biztosan támogatja a beágyazott fontokat. Esetleg ezen fórum alapján nézd meg, hogy mi lehet a gond az epub fájlon belül (css, beágyazott fontok könyvtára): www.mobileread.com/forums/showthread.php?t=153778

Vagy passzold át, és belenézhetek én is, hátha kiderül hol van a turpisság: atyaman kukatsz gmail ponty com

Atyaman 2011.11.17. 13:04:08

@urielz29: Jut eszembe. Nem lehet, hogy a Sony-n van olyan beállítás, hogy felülírja az epub-ba beágyazott fontot a sajátjára? Szerintem esélyes, hogy van ilyen, és ha igen, akkor ki kell kapcsolni. További tipp, hogy a könyv megnyitása után a betűtípus, betűméret beállítások környékén kell keresni.

Atyaman 2011.11.17. 13:10:21

Elnézést a tripláért :(

Itt a Sony PRS-T1 User Guide-ja epub-ban:
www.mobileread.com/forums/showpost.php?p=1782513&postcount=2

E szerint a Selected Font Type-ot kell Original-ra állítani.

Egyébként a fontbeágyazás sikerességét úgy a legcélszerűbb ellenőrizni, ha az Adobe Digital Editions-ben megnyitod az epub-ot. Ha ott jó, akkor a legtöbb e-olvasón is jónak kell lennie (Sony, Nook, Koobe, Kobo...).

urielz29 2011.11.17. 14:05:06

@Atyaman: "The PRST1 needs the fonts to be fully embedded. The old method which worked on previous models, where you could store the fonts on the reader and use Calibre to add the necessary css @font-faces, doesn't work on the T1." - ezt találtam a fórumon. Ezek szerint csak a teljes beágyazás működik, ergo jöhet a leglassabb, harmadik módszer...
A mek-ről letöltött példaanyag ( Protestáns Biblia) úgy az Adobe D.E.-ban, mint a Sony Ereader-jében hibásan jelenik meg. A Stanzá-ban pedig helyesen( Ezt a progit találtam még, mint epub-olvasót pc-re).Azért választottam épp ezt az anyagot, mert gondolom hogy jól elkészített epub, és ha olvassa az olvasó akkor csakis a Calibre-s (vagy egyéb) konvertálásokkal lehet baj. Calibre-vel is próbáltam prc-t konvertálni és felküldeni az eszközre ( Calibre beállításaihoz prc-ről epub-ba nem nyúltam), de ez sem vezet eredményre. Sony olvasón sok beállítási lehetőség nincs, úgy "original" karakterekkel mint mással ugyanazt csinálja.
Nem egy adott epub-bal próbáltam, hanem mindenfélével, mert az a helyzet, hogy amennyire ismerem a leendő tulajdonost aszerint én leszek az, aki az ilyesfajta könyves feltöltéseket intézi neki...ha most nem tudom egyszerűen megoldani, akkor eszközcsere lesz, mert nem fogok/nem tudok minden könyvvel bíbelődni órákig...
Ehhh, esett a Sony a szememben, pedig gondoltam hogy én is beruházok egyre, annyira jók voltak az első benyomások...

Jah, persze, triplázás elnézve:-))) Hálás vagyok a fáradságért

SaGa 2011.11.17. 15:22:03

@urielz29: Epub ügyben a sony a legjobb pedig. Tudomásul kell venni, hogy az apub csak akkor teljes, ha be vannak ágyazva a szükséges betűkészletek, másképp csak féligkész valami. A Stanza pont azért mutatja "jól", mert nem érdekli a beágyazott font, azaz az epub legfontosabb előnyét a prcvel szemben nem használja ki.

A kész epub-ot told be a Sigil-be add hozzá a kívánt betűkészletet (kell az itailc és esetleg a bold, bold-italic verzió is) és a styles.css-hez a szükséges sorokat. Ennél profibb és gyorsabb megoldása nincs a dolognak.
Illetve van, de ahhoz scriptet kell írni.

Atyaman 2011.11.17. 15:32:44

Az idézet csak arra utal, hogy korábban (PRS-505-nél) úgy is meg tudták oldani a beágyazást, hogy a betűtípust magára az olvasó eszközre másolták fel, és nem ágyazták be az epub-ba, hanem elég volt a .css stílusleíróban megadni a font elérési útvonalát. A T1-nél nem tudják a pontos útvonalat – megj.: amit a felhasználó gyökérkönyvtárnak lát az e-olvasókon az valójában csak egy alkönyvtára a teljes rendszernek, amit elrejtenek a hozzá nem értő szemek elől –, ezért a teljes beágyazásra van szükség, azaz az epub fájlba kell bemásolni a fontot.
És az online konverter pont ezt csinálja meg.

A mek-es epub-ok közt nem találtam meg az említett művet, helyette letöltöttem ezt: mek.oszk.hu/04800/04833/index.phtml és bizony az a helyzet, hogy valamit elrontottak a beágyazásnál, mert nem jól működik. Ami az ADE-ben nem jelenik meg jól, az a Sony-n sem fog.

De meg is mondom mit rontottak el. Az epub stílusleírójában a style.css-ben mikor a szövegtörzs betűtípusát definiálják, akkor lemaradt két idézőjel:

font-family:Tex Gyre Pagella;

helyett ez kéne és így máris jó:

font-family:"Tex Gyre Pagella";

voilá ;)

Szerény véleményem szerint, a Sony T1 jobb e-könyv olvasó, mint a Kindle. Én biztosan nem cserélném le, mivel a hiba nem a készülékben van, de ha mégis váltásra kerülne a sor először engem keressetek meg mennyért adnátok el ;)
(Pedig most nagyon nem akarnék új készüléket venni, de a T1 jó, ehhez nem fér kétség :-D)

urielz29 2011.11.17. 22:44:09

@Atyaman: Igen, én is valami ilyesmire gondoltam: buherálni az olvasót, nem pedig a könyveket...én biztos nem fogom a kért prc anyagot könyvenként megcsinálni, ennyire nem érint személyesen. De ha tényleg komolyra fordul az eladós dolog ( márpedig fog, ha a Saturn-nal nem tudjuk megoldani) akkor lesz egy eladó, vadiúj Sony PRS-T1 :-)
( Jobb, nem jobb azt nem tudom - én a Kindle formáját, minőségét és fogását jobban szeretem, de maga az eszköz tetszett; különösen kíváncsi voltam az érintőképernyős e-ink kezelésének élményére; az igazság az, hogy túl sokat is tud, én nem használnám ki :-))

SaGa 2011.11.18. 07:12:44

@urielz29: Ha eladósorba kerül, engem is érdekelhet...

ff48bp 2011.11.18. 13:05:29

Már elég sok mindent meg tudok csinálni az e-pubban, de a táblázat nem megy. Nem tudtok olyan szövegszerkesztőt, amelyiknek jó a táblázatos e-pub exportja? Nekem csak arra kellene, hogy a Sigillel a táblát belemásoljam a már kész e-pubba.

SaGa 2011.11.18. 13:49:36

@ff48bp: Rossz hírem van: táblázatot epubban is kézzel kell csinálni, mint mobiban, mert egyetlen jól működő konverter sincs rá...

ff48bp 2011.11.18. 18:47:19

Ez tényleg nem jó hír. De azért a szövegszerkesztők közül biztos van olyan, amelyik legalább az alapot jobban megadja hozzá, mint a többi, gondolom.

urielz29 2011.11.18. 20:27:21

@SaGa: Jó, jegyzem, holnap visszük vissza a Saturn-ba, oszt majd elválik...

ff48bp 2011.11.18. 21:05:21

Próbálkoztam a táblázattal és úgy látom itt lesz talán a legtöbb probléma. Ha az oszlopszélességet százalékosan adom meg, akkor a Sigilben jó, bármint változtatom a szélességet, a Firefox e-pub olvasójával is tökéletesen méreteződik, sőt a coolreader is szépen méretezi, de pont a digital editionsban nem jó, pedig azt mondtátok, az az etalon, abban kell, hogy jó legyen. Az is igaz, hogy ha elfelejtenénk az Adobe drmjét és áttérnénk puhára, akkor meg is érdemli, aki ADE-t használ.

Atyaman 2011.11.18. 22:26:03

@ff48bp: A táblázatban én sajna nem tudok segíteni, azokat még nem nagyon próbáltam. Amúgy valószínűleg úgy fognék hozzá, hogy levadásznék a netről pár normálisabban elkészített táblázatos epub-ot (pl. ADE 1.8 Preview verzió Welcome.epub vagy a Sony PRS-T1 userguide.epub), és azokban megnézném, hogyan varázsolták össze a táblázatokat a profik.

Az ADE-ról viszont azt érdemes megjegyezni, hogy nem azért etalon, mert az kell az Adobe DRM-es könyvek megnyitásához, hanem azért, mert a legtöbb dedikált, epubos e-olvasó úgy fogja megjeleníteni az adott epubot, ahogy az ADE-ban látod. Mivel, hogy elvileg ő lenne a szabvány :)

Gukker 2011.11.19. 10:55:18

@SandraManson: Asszem ezen a spam-szótár programon még van mit fejleszteni... :)
Sebaj, majd legközelebb.

Atyaman 2011.11.19. 10:56:45

@SandraManson: Már kerestem a report gombot, de aztán rájöttem, hogy ez nem a fórum :)
Na, szóval spam. Ráadásul az érthetetlenebb (géppel fordított) fajtából.

ff48bp 2011.11.20. 11:29:20

Néztem ezeket a táblázatokat, de ezek tényleg korrektül meg vannak csinálva, css stílussal. Ha viszont csinálok egy könyvet, amibe bele kell tenni jó pár táblázatot, az nem járható út, hogy htmlben írom be, mert azzal nem lehet gyorsan megcsinálni, hacsak nincs erre valami spéci program, de akkor is jóval lassúbb, mint ha mondjuk már készen van az rtfben és a wordből csinálok htmlt és azt emelem be Sigillel. A gond viszont ott van, hogy a Sigil sgc stílust ad, ami működik is az olvasok nagy részénél, de az ADE pont nem szereti. Szóval az még nem világos előttem, hogy tudnék táblázatos e-pubot olcsón előállítani, hogy minél kisebb lehessen az eladási ára, mert az alacsony árhoz viszonylag kis élőmunka kell, hiszen az eladott példányok száma mindig kevés lesz.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.11.21. 12:28:53

@ff48bp: És még simán belefuthatsz abba, hogy az egyik platformon szuperül kinéző táblázatod egy másik platformon szétesik :-(, Ugye epub alatt lehet adobe, annak módosított alfajai, iOS, és a vihar tudja mi még. Én most még biztos nem optimalizálnék táblázatokat, max pixelekre, képként. Ami úgy eretnekség ahogy van, de ráfordítás/eredmény arányban még sajnos ez a nyerő. Szerintem.

ff48bp 2011.11.21. 14:29:58

@Dworkyll: Az a helyzet, hogy eredetileg én is képként gondoltam a táblázatokat kezelni, de féltem, hogy ha ilyen könyvvel találkozik valaki, akkor le fog érte nézni. Viszont ha már Te is ezt tanácsolod, akkor így fogok csinálni én is. Tényleg ez a legkorrektebb megoldás.
Arról nem is beszélve, hogy egy pici megjelenítőn hiába a százalékos szélesség, lehet hogy úgy se férne sokszor a szöveg a cellába. Képként pedig be tudom tenni, aztán majd nagyítja az olvashatóság miatt.

ff48bp 2011.11.21. 15:06:01

Küldtem egy privi levelet is, kérlek olvasd majd el.

Atyaman 2011.12.05. 00:08:35

Urielz29 problémájára visszatérve: most végre nekem is előfordult, hogy nem volt sikeres a fontbeágyazás ezen a honlapon: www.e-konyvtar.com/

Annyi történt, hogy a könyvben a szokásos calibre féle kotvány css volt – na jó, nem kotvány, de hogy nem is teljesen áttekinthető az is biztos, persze erről első sorban nem a calibre tehet –, stylesheet1.css néven. A fontbeágyazás után ez a css érintetlenül maradt és létrejött egy stylesheet.css nevű, ami kvázi ennek a másolata volt hozzáadva a fontok definiálását. Azért csak kvázi, mert gyakorlatilag nem stimmelt a formázás, mikor az epubban ennek a használatát állítottam be.
Ami viszont működött az az volt, hogy fogtam a fontok definiálását, vagyis ezt a részt: @font-face {... és bemásoltam az eredeti stylesheet1.css elejére. Ripsz-ropsz meg is javult a publikáció, ami így már a beágyazott fontokat használja :)

ff48bp 2011.12.17. 17:28:36

Van valami forrás, hogy lehet Sigilben a képekkel játszadozni? Most épp a háttérkép-körülírt kép egy bekezdésen belül érdekelne, a háttérkép transzparensként alkalmazva, bár ezt végül is meg lehet máshogy is oldani.

Mango131 2012.01.19. 00:10:44

Tudna valaki nekem segíteni? Iriver Story-m lesz. Sajnos már nem lehet a rendelést visszavonni, pedig ez brutális, amit csinálni kell a szöveggel, hogy azt a két hülye betűt megjelenítse. :((( Számomra teljesen érthetetlen ez a leírás. A gentium book basicet, hogy rakjam bele az office 2007be? A bekezdés meg a címsor résznél mi van leírva??? Mi az a törzsbekezdés és minek olyannal babrálni? Mi az a heading, a bold??? Meg ilyen jelek után böngésszem át az összes könyv összes sorát????
Kidobtam 45ezret a kukába. :(((((

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.01.19. 00:36:33

@Mango131: Nem kell pánikolni :-) Maradjunk annyiban, hogy
1. beszerzel egy atlantist,
2. letöltöd a Gentium Book Basic nevű fontot.
3. az anyagodat, (word, rtf) az atlantisból nyitod meg
4. Az egészet átváltod Times New Romanból Gentium Book Basicbe
5. Save as epub, úgy az embed fonts opció be van kapcsolva

Kész.

Ekkor már az összes betűt látni fogod. Ha szebbet akarsz, akkor olvasd újra a posztot, és rá fogsz jönni, hogy az egyes blokkok követése hogy finomítja a szövegképet, kiadványminőséget.

Mango131 2012.01.19. 00:39:13

jajj köszönöm!! :) Még annyi, hogy hogy tudom a gentiumot berakni a programba hogy használhassam?:)

Mango131 2012.01.20. 15:07:49

Hello!
Még 1 problémám lenne: Nem veszi észre a gép az olvasót. :( Ha bedugom, akkor elkezd töltődni, szóval az olvasó észleli, de a gép egyáltalán nem reagál rá. "Biztonságosan" sem lehet leválasztani meg semmi sem jön fel. Kell valami program még vagy mi? Mert elvileg semmi. Ennyire számít, hogy nem Xp-m van, hanem Win7-em? :((

Mango131 2012.01.20. 15:33:41

Na kipróbáltam a másik gépemen, Xp-n sem működik.

Komavary · http://orokorom.freeblog.hu 2012.01.20. 15:53:16

@Mango131: Ez néha teljesen mágia.

A kézikönyvben tuti le van írva, de ki olvas kézikönyvet? :)

próbáld meg kikapcsolva, bekapcsolva rátenni, vagy kikapcsolva, és kapcsold be után.
Próbáld meg úgy, hogy az usb töltő előbb az olvasóra van csatlakoztatva, azután úgy, hogy előbb a gépre.

Valamelyik csak működik, utána meg csak annyi a dolgod, hogy megjegyezd a következő rákötésig (én mindig elfelejtem).

Mango131 2012.01.20. 16:02:11

@Komavary: Köszi a gyors választ! :)
Elolvastam a kézikönyvet, kivételesen rövid. :D Sőt végignéztem a bemutatót magában az olvasóban is róla, kéne neki működnie egyből rákötésnél.
Megpróbálom még azokat, amiket javasoltál hátha valamelyiknél észreveszi. :D Ha nem, akkor megy vissza a drága a boltba. :)

Mango131 2012.01.20. 16:05:52

Na sikerült észrevetetni!! De sajnos azt írja ki, hogy az eszköz telepítése sikertelen. :(

Mango131 2012.01.20. 16:11:21

Megvan! De szerintem nem ez lesz az utolsó problémám! :D

Mango131 2012.01.22. 22:58:28

Mit lehet olyankor csinálni, hogyha az Atlantisnál a Save as-nál nem lehet epubot kiválasztani, csak rtf, cod, és doc-ot?

Mango131 2012.01.22. 23:07:14

A másik gond a Calibre-vel van. Az sem konvertál epub-ba (eddig igen), hanem azt írja ki, hogy nem sikerült a könyv konvertálása, mert nem található a megfelelő forrásformátum. Eddig jó volt minden... Most ezt írja .doc-nál meg .pdf-nél is.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.01.22. 23:38:44

@Mango131: Mert nem ott készül. Saves Special, és ott save as Ebook, na az az epub. Ha sűrűn használod, érdemes kitenni (Customize toolbar) az ikonok közé, és akkor egy klikkel meghívhatod.

Mango131 2012.01.22. 23:41:51

Először ott sem volt epub. Letöltöttem, amit ajánlottál a cikkben, abban már volt save as epub. :)
Köszönöm a segítséget, újdonság ez még nekem. :))

Gukker 2012.01.23. 02:12:54

@Mango131: "azt írja ki, hogy nem sikerült a könyv konvertálása, mert nem található a megfelelő forrásformátum. Eddig jó volt minden... Most ezt írja .doc-nál meg .pdf-nél is. "
Nem fogod kitalálni. Azért írja ezt, mert a doc neki nem megfelelő forrásformátum. A pdf-et elvileg ismernie kéne. Hacsak nem scannelt pdf. Azzal lehet probléma.

Mango131 2012.01.23. 16:11:44

@Gukker: Nem scannelt a pdf, ezért is lepett meg, hogy most ezt írogatja ki sorban. Eddig a .doc-ot meg a .pdf-et is konvertálta szépen, de párnál mégis kiírja. De mind1 is, annyira nem nagy probléma. :)

Gukker 2012.01.23. 16:19:24

@Mango131: Akkor ott valami tényleg nem stimmelhet, mert a Calibre _nem_ tud .doc-ot konvertálni. Soha nem is tudott.

Polemius 2012.05.14. 14:58:26

Gyártásban rutinos kollégákat kérdezném: ePub teszteléshez ki milyen készüléket javasol?
(Kompatibilitási problémák megelőzéséhez.)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.05.14. 16:55:29

@Polemius: legalább két vagy három vas kell. Alapnak az ADE, sok dedikált vas ugyanazt a parsert használja. Ha azzal jó, nagy gond már nem lehet. Aztán kéne egy iOS vas, mert z máshogy parsol, pl. fölülvágja a beágyazott fontokat, cserébe el van nélkülük. És én vetnék egy pillantást valami Androidos app-ra is, pl. Aldiko vagy fbreader egy okostelefonon, vagy galaxy tabon. De csak ha perfekcionista vagy ;-)

Polemius 2012.05.14. 22:13:13

@Dworkyll: Az a kérdés, hogy vajon melyik epub-os dedikált e-könyv olvasó típus az elterjedt felénk? Vagy melyik a legkényesebb?
Első lépésként legalább a kindle meg az epub-os olvasók egyék meg hiba nélkül az állományt.
Mobil platform más tészta kicsit, ott ugye több sw is versenyben van egyből.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.05.15. 16:10:10

@Polemius: A legelterjedtebb, legalábbis a helyi képviselet okán a Kooe és az Onyx. A Koobe-t tök jól szimulálja az Adobe Digital Editions. Akad még pár sony, iriver, elvétve kobo és nook, de azok olyan ritkák, hogy tapasztalataim szerint a tulajaik teljesen képben vannak a faxnijaikkal. Úgyhogy ha az ADE-vel jó vagy, akkor már nagy baj nincsen.

Az egyetlen csavar amúgy is a fontbeágyazás, az gyakorlatilag kötelező, mert az ADE alapúak nem jelzik ki a z ő-t ű-t különben. Viszont a legkisebb közös többszörös az egy font, mert sok olvasó, (mint amilyen pl. az iBooks is) amelyik _ignorálja_ a beágyazott fontot, az nem fogja kijelezni a fontváltozásokat, ha többet használnál.

MOndjuk pont az iBooksnál látszik valami workaround féle, hogy férjen bele egy monospaced font is a törzsfont mellé, de még volt időm kipróbálni.

scan_dal 2012.05.15. 21:08:04

@Polemius:
KOBO elso generaacioo
szepen eszi a formazasokat , beaagyazott fontokat stb.
babraas ratolteni (Calibre kell hozzaa) de utaanaa ....

Polemius 2012.05.15. 21:45:39

@Dworkyll: Az ADE önmagában azért problémás, mert olyat is megeszik, ami készülékeken elhasal (a saját Sony 505-ömmel tapasztaltam). Az ékezetes betűk és a túl nagy xml állományok is mennek vele, amik "élesben" esetleg nem.

@scan_dal: Éppen az a lényeg, hogy problémás (kényes) legyen a készülék. Teszteléshez kellene kitalálnom, milyen készüléket lenne érdemes beszerezni, ami elég elterjedt itthon* és ha azon jól jelenik meg, akkor jó eséllyel rá lehessen mondani, hogy a többi epub-os készüléken is jó lesz.

*A Kindle verziók mellett.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.05.17. 15:59:46

@Polemius: A Koobeból azért elment párezer errefelé és az onyxból is sok. Referencia-olvasónak (epubra persze) én azt venném. A Kindle-vel nem számolva a többiből töredékennyi van a piacon.

Szóval én vennék erre egy Juniort 30 ropiért, ennyit, főleg erre a célra szerintem simán megér.

Polemius 2012.05.20. 20:21:45

Közben visszanéztem a korábbi felméréseket is, valószínűleg Koobe lesz a megfelelő.

Más:
A kiinduló állományok indesign formátumúak. A gyári ePub export gyakorlatilag ipari hulladékot eredményez. Viszont némi utómunkával valamennyire használható XML-t lehet exportálni belőle.
A kérdés, hogy innen (XML) ki merre lépne, mihez nyúlna, hogy aztán epub és prc legyen a végeredmény?
A legjobb persze valami kész megoldás lenne, ami xml-ből tud egyből ilyeneket exportálni.

Szóval hálás lennék minden irányt mutató ötletért, tapasztalatért, akár csak pár tőmondatban is.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.05.20. 21:11:48

@Polemius: Az a kérdés, milyen "stílusban" dolgozol.

Ha inkább az ipari megoldásokat kedveled, keresd Ignist, meg az IVB projektjét, elképesztően nagy királyság, de finoman szólva is "kódközeli", script-szüzeknek nagy kihívás ;-).

Ha kézimunkázol, akkor epubhoz Atlantis, prc-hez notepad++ és Mobipocket Creator, illetve, ha kindlegenezni akarsz a MPC után, mert mondjuk ipari módon csinálnál perszonalizált példányokat, akkor szólj, küldök egy "kindlegenesített" opf-et, amivel fölül kell vágjad a MPC által generált opf-et.

SaGa 2012.05.21. 08:36:04

@Polemius: xml-ből vagy xslt-vel, vagy (amennyiben otthon vagy, illetve hajlandó vagy pár órát belefeccölni a megtanulásba a "regular expression" szépségei[ben|nek]), akkor sed, grep, cat, és társaik. Azaz a unixos szövegfeldolgozó programocskákból összerakott shellscriptek. Ilyet használtam egy jódarabig.
Aztán átnyergeltem előbb az OOo->Atlantis->Sigil gépsorra.
Közben kijött az OOo-hoz a writer2epub extension és végre hasznáhatóvá izmosodott, így OOo->Sigil.
A writer2epub (még) nem tud fontbeágyazást, de ezt pár kattintás, nem jól kezeli az iniciálékat (ez fél-egy órányi kézimunka egy nagy, sok iniciálét tartalmazó kötetnél), ellenben tökéletesen átemeli a táblázatokat az epub-ba.
Az epub-ból meg egy klikk a mobi/prc a kindelegennel.
Az xml-t próbáld meg beolvastatni az OOo (LibreOffice) writerrel, majd nézd meg, hogy érdemes-e tovább foglalkozni vele. Ha igen, akkor a writer2epub a barátod lesz. Egyetlen trükkje van: a szabvány (címsor x, lábjegyzet, stb...) bekezdés stílusokat automatikusan bedolgozza, a sajátjaidat meg akkor, ha a nevük a "w2e_" karaktersorral kezdődik.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.05.21. 09:34:59

@SaGa: Wow :-)

Kérdések jöhetnek?

Mit csináltál/csinálsz a Sigillel? Mire kell az az atlantis vagy az OOo után?

Milyen kindlegen verziót használsz? HOgy csinálsz olyat, hogy lapozható és kattintható fejezetek is legyenek, azaz a Go to Table of Contents és a fejezetenkénti lapozás is működjön? Nálam az utolsó kindlegen nem generál, csak lapozható fejezeteket.

A kindlegen meg tudja enni a táblázatokat, és azok élvezhetőek a mobiban? A táblázatra tudnál küldeni mintakódot? Még piszokul küzdök a táblázat-témával a mobiban, de nem uralom :-(

Hála és köszönet, előre is :-)

SaGa 2012.05.21. 13:19:54

@Dworkyll: Az atlantis után kell a sigil, mert az atlantis által elkövetett epub csak hasonlít a "szabványra", de nem olyan. A sigil automatice átalakítja szabványosra. Aztán a szerkesztőjében lecserélgetem az elrontott őű betűket (ha dőlt, vastag, vagy más módon formázott, akkor randán lezárja a formázást az ő vagy ő előtt, újranyitja, beleteszi azt az egy betűt, lezárja, újranyitja és folytatja a szöveget. Ugyanezt az nbsp-vel is megcsinálja), kiszedem a felesleges/duplikált formázásokat, stb...
Az atlantis-szal lehet toc-ot csináltatni, csak be kell dobni egy rámutató linket a címsor után.

Ha writer2epub-bal készül az epub, akkor kevesebb benne a szemét (gyakorlatilag nincs, csak pár "szabvány" stílus a css-ben akkor is, ha nem használtam őket), de még nem tudja beágyazni a betűkészleteket. Előbb-utóbb tudja majd, mert a jelölőnégyzet már rajta van a felületen, de addig a sigil-ben kell ezt is megcsinálni. Nem bonyolult.

Ha az OOo-ban van tartalomjegyzék (oldalszámok nélkülit érdemes csináltatni vele), azt exportálja a writer2epub, de a horgonyokat <a> kézzel kell belepakolni. Ismét egy link a címoldalra és van rendes tartalom is. Meg bele szoktam tenni a sigilben a toc.ncx-be is, a végére egy lezáró navpointba.

A kindlegen átveszi ezt az epubból és használható.

A táblázatokat is. Utoljára volt egy kis gondom: egy táblázatban 5 oszlop. Az első 40%, a másik 4 egyformán 15% szélesre állítva. Az epubban és a prc-ben jó, a mobiban (kf8) ellenben az utolsó oszlopot kitolta a képernyő jobb szélén túlra. Ez a Kindle for PC hibája, a previewer jól kezeli.

A kód meg a legprimitívebb (pár sort kihagytam belőle, de a szerkezet ilyen), nincs kerete, van pár összevont mező:

<table border="0" cellpadding="1" cellspacing="2" rules="all" width="100%">
<tr>
<td width="40%"><em>tárolók</em></td>

<td colspan="2" width="30%">
<p class="center"><em>első időpont</em></p>
</td>

<td colspan="2" width="30%">
<p class="center"><em>második időpont</em></p>
</td>
</tr>

<tr>
<td></td>

<td width="15%">
<p class="center"><em>mennyiség</em></p>
</td>

<td width="15%">
<p class="center"><em>tömeg</em></p>
</td>

<td width="15%">
<p class="center"><em>mennyiség</em></p>
</td>

<td width="15%">
<p class="center"><em>tömeg</em></p>
</td>
</tr>

<tr>
<td>konténer</td>

<td>
<p class="right">143</p>
</td>

<td>
<p class="right">34 655</p>
</td>

<td>
<p class="right">24</p>
</td>

<td>
<p class="right">27 656</p>
</td>
</tr>
<tr>
<td>Összesen</td>

<td>
<p class="right">327</p>
</td>

<td>
<p class="right">87 654</p>
</td>

<td>
<p class="right">242</p>
</td>

<td>
<p class="right">46 765</p>
</td>
</tr>
</table>

Semmi extra.
Az iniciálék keményebb feladat.
Két bekezdésstílust kell definiálni minimum, de ha valami érdekes betűtípust használsz, akkor az elsőből többet is az eltérő méretű betűk miatt:
pl:
.initials
{
text-indent: 0;
float: left;
line-height:180%;
margin-top: 3.94em;
margin-right: .2em;
margin-bottom: 0;
}
.FirstParagraph
{
font-size: 1.00em;
text-indent: 0em;
text-align: justify;
margin-top: 4em;
}

Az első az iniciálé, a második azé a bekezdésé, amibe kerül.

SaGa 2012.05.21. 13:36:57

@SaGa: Kiegészítés: a mobi igen nagy darab, mert tartalmazza a prc-t is (meg talán az eredeti epub-ot is becsomagolva és "kibontva" egyaránt.
A calibre-hez van egy plugin, ami kibontja a mobit, és szétpakolja egy kf8 és egy kf7 (ez a prc) könyvtárba. Ez utóbbit (a benne lévő opf-et) simán be kell küldeni a mobipocket creatorba, hozzá kell adni a borítót, az isbn-t, és megadni mi a műfaja és kész is van. Minden egyebet örököl. Így ebben is van lapozható és "rendes" tartalomjegyzék is. A plugin érzékeny a célkönyvtár nevében található ékezetes betűkre, ha bárhol az útvonalon van egy, akkor elhasal, érdemes egy külön könyvtárat csinálni neki, valahova a \-ba.

Még annyi: a sigilben az epub content.opf-jében át szoktam írni a Table of Contents, Cover és egyéb "guide objektumok" megjelenő nevét magyarra, amit némelyik olvasó jól kezel, mások meg nem törődnek vele és az eredeti angol megfelelőjüket mutogatják helyette...

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.05.21. 14:42:01

@SaGa: Istenkirály vagy, köszönöm.

Re: atlantis-epub. Az megvolt, hogy nem egyformán gyártja ám, attól függően, hogy mi a forrás. Doc-ból tényleg spanolja az ékezeteket, ha kell, ha nem, de rtf-ből pl. egészen kultúrált epub (-beli html) esik ki.

SaGa 2012.05.22. 10:15:25

@Dworkyll: Nincs mit.

Tudom, hogy rtf-ből másképp gyártja, mert a kódlapokkal kavarodik össze, de sajna az atlantis mást is elront de alaposan, amit faragni kell. Ha a writer2epub tényleg tudja majd a fontbeágyazást, jobb lesz mint az atlantis, ráadásul ingyenes.

Pl az atlantis nem hozza át a bekezdésstílusok neveit, csak a "sorszámaikat" (.p1, .p2, .t1, .t2, stb...), a w2e meg szépen azt adja vissza, amit az ooo-ban megadtam névnek (a "w2e_" karaktersor nélkül), így keresgélés nélkül tudom, hogy melyikkel mit is akartam beállítani.

Gaudi 2012.05.22. 15:15:09

@SaGa: Szia! Fontbeágyazás kész epub-ba: "de addig a sigil-ben kell ezt is megcsinálni. Nem bonyolult." Nekem kicsorbult a fejszém. Egy amolyan lamers howto-t tudnál hozzá írni?

Gaudi 2012.05.22. 15:57:49

@Gaudi: Hümm... Nem voltam elég alapos a CSS-sel. Most már sikerült.

SaGa 2012.05.23. 08:04:06

@Gaudi: Azért azoknak, akiknek nem megy:

Első lépés: a Sigil-ben megnyitott epub Fonts mappájába be kell pakolni a megfelelő ttf és/vagy otf fájlokat.

A content.opf-be bekerül automatikusan, de a styles.ccs.be kézzel kell beírni. Először definiálni kell a betűkészleteket, a ccs fájl elején:

@font-face{font-family:"GregorianFLF";font-style:normal;font-weight:normal;src:url(../Fonts/GregorianFLF.ttf)}
@font-face{font-family:"Magyar Linux Libertine N";font-style:normal;font-weight:normal;src:url(../Fonts/MagyarLinLibertineN.ttf)}
@font-face{font-family:"Magyar Linux Libertine N";font-style:italic;font-weight:normal;src:url(../Fonts/MagyarLinLibertineNI_0.ttf)}
@font-face{font-family:"Magyar Linux Libertine N C";font-style:normal;font-weight:normal;src:url(../Fonts/MagyarLinLibertineNC_Re.ttf)}
@font-face{font-family:"Magyar Linux Libertine N";font-style:normal;font-weight:bold;src:url(../Fonts/MagyarLinLibertineNB.ttf)}
@font-face{font-family:"GregorianFLF";font-style:italic;font-weight:normal;src:url(../Fonts/GregorianFLF-Italic.ttf)}
@font-face{font-family:"Magyar Linux Libertine N C";font-style:italic;font-weight:normal;src:url(../Fonts/MagyarLinLibertineNC_I_0.ttf)}

Itt megadjuk a fontkészlet nevét (font-family: tulajdonképpen mindegy, csak így hivatkozzunk rájuk később), a stílust, amit az adott fájl képvisel (font-style: normal vagy italic), a "tömeget" (font-weight: normal vagy bold) és a tényleges fájl elérési útját és nevét (src:url(....).
Észre kell venni, hogy a parserek csak akkor fognak vastagított vagy dőlt betűt megjeleníteni, ha ténylegesen ott van a csomagban az adott betűkészlet vastag vagy dőlt verziója, külön fájlként.

A bekezdés- vagy szövegstílusokban a font-family-t kell megadni. Pl:

p{text-indent:1em;margin-left:0;line-height:120%;margin-right:0;text-align:justify;margin-top:0;margin-bottom:0;font-family:"Magyar Linux Libertine N";font-size:109%}

A "p" stílusnak (alapértelmezett vagy normál bekezdés) mindenképp meg kell adni, hogy milyen betűtípust használjon és minden olyan további stílusnak, ami ettől eltérő betűvel van szedve.

Az, hogy egy bekezdés stílusban (azaz a /p class="valami"\), vagy egy szövegstílusban ( /p\/span class="valamimas"\) adjuk meg az eltérő betűkészletet, tulajdonképpen mindegy. Az Atlantis konzekvensen ketté választja a dolgot, a .px (bekezdés)stílusokban nem ad meg font-family meghatározást, azt kizárólag a .tx (azaz a "span class=" jellegű szöveg)stílusokban használja. Amennyiben van olyan bekezdésünk (pl címsorok), ami kizárólag az alap bekezdésstílustól eltérő betűvel van szedve, akkor ennek a meghatározásában is megadhatjuk a font-family meghatározást, egyéni döntés kérdése. Én ez utóbbit jobban szeretem, de a css fájl (ember által) olvashatóságát a másik változat jobban segíti.

Az atlantis által generált css ilyen szerkezetű:

.p0{text-indent:0;margin-left:0;line-height:100%;text-align:center}
.p2{text-indent:0;margin-left:0;line-height:100%;text-align:center;margin-top:2em}
.p3{text-indent:0;margin-left:0;line-height:100%;text-align:center;margin-top:3em}
.p4{text-indent:0;margin-left:0;line-height:100%;text-align:center;margin-top:2em;page-break-before:always}

.t1{font-family:GregorianFLF,monospace;font-size:2em;line-height:100%}
.t3{font-family:GregorianFLF,monospace;font-size:4em;line-height:100%}
.t4{font-family:GregorianFLF,monospace;font-size:2.3em;line-height:115%}
.t6{font-family:GregorianFLF,monospace;font-size:3em;line-height:115%}

a w2e által generált ilyen:

body
{
font-family: Magyar Linux Libertine N, serif;
}
p
{
margin:0pt;
text-indent: 1em;
text-align: justify;
font-size: 1.00em;
}
p+p
{
text-indent:1em;
text-align: justify;
font-size: 1.00em;
}
h1
{
margin-top:2em;
margin-bottom:2em;
page-break-after:avoid;
font-family:GregorianFLF,monospace;
font-size: 2em;
text-align: center;
text-indent:0em;
}

Látható, hogy itt a "p" (alapértelmezett) stílusban nincs megadva font-family, de a body-ban benne van és ez is ugyanazt eredményezi. A "body"-ba a w2e konfigjában megadott betűkészlet kerül bele, nem az amit az adott dokuban ténylegesen használok, így lehet, hogy kézzel át kell írni, ahogy a h1-be is kézzel, utólag került bele ez a sor.

Polemius 2012.06.19. 16:11:15

Újabb kérdés merült fel előttem:
Okoz-e problémát (akár epubban akár mobiban), ha az xhtml-ben saját tag-eket használok?
Vagyis használhatok-e mondjuk

<idezet>blablabla</idezet>

megoldást, vagy kénytelen vagyok a

<p> class="idezet">blablabla</p>
(vagy <p> name="idezet">blablabla</p> )

formát használni mindenképp?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.06.19. 18:18:42

@Polemius: Ki kell próbálni. Az biztos, hogy valahol, le kell írnod, hogy a saját tag pontosanhogy értelmeződjön. És biztosan lesznek olyan olvasóplatformok, amik ignorálják a css-t, vagy annak bizonyos részeit.

Polemius 2012.06.19. 18:27:02

Igen, én is attól tartok, hogy esetleg nem minden értelmezné.
Ugyanakkor "hajlékonyabban" használható lenne, ha nem kellene külön definiálni a css-ben annyiféle formázást, mert egyszerűen class-ként lehetne módosítani (behúzásokat például).

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.06.19. 18:30:09

@Polemius: Ja. És a ki kell próbálni az legalább egy ADE-n, egy Androidos cuccon, fbreader pl, és egy iOS-en (iBooks). Ez utóbbi epub parsere pl. sokkal inkább "mobisabb", mint ADE-s, alapból ignorálja a css bizonyos részeit, pl. több font, de rá lehet venni a multifontra, ha jól néztem <kbd> taggel.

_iMaginer_ 2012.08.24. 13:54:57

tudna ajánlani valaki egy mintakönyvet, amiben működik a magyar elválasztás rootolt nookon az alap olvasóval? akár csak pár oldal is jó lenne (epub)

nagygabe 2012.08.24. 14:13:28

@_iMaginer_: Pl.: A felhúzhatós lány

Így néz ki pl. egy lap:
[url=http://kepfeltoltes.hu/view/120824/IMG_20120824_140852_www.kepfeltoltes.hu_.jpg][img]http://kepfeltoltes.hu/thumb/120824/IMG_20120824_140852_www.kepfeltoltes.hu_.jpg[/img][/url]
A képet a Képfeltöltés.hu tárolja. [url=http://www.kepfeltoltes.hu]http://www.kepfeltoltes.hu[/url]

Látszik az is, hogy az epub-ban lévő font nem túl szép ezen az eszközön.

_iMaginer_ 2012.08.24. 14:26:50

@nagygabe: köszönöm, eddig nem volt probléma az ipaden, de itt rövidebbek a sorok és muszály néha elválasztani

Mercator 2012.08.29. 12:48:23

@ff48bp: Kedves Olvtárs!

Több problémám akadt InDesign CS6-ból történő ePub konvertálással.
A jelentkezett problémák:
1, Az Id CS6-ból exportált epub az Adobe Digital Editions programban mindent dőlt betűvel ír (valójában nem az),
az őŐ űŰ betűk helyett kérdőjelet ír. A többi programban jól jelenik meg, ha PDF-et készítek, akkor abban is.
A használt fontkészlet: Adobe Garamond Pro.

2, Az exportált verzióból eltűnnek az ugróhivatkozásos tartalomjegyzék linkjei, szövegei. A cím1 (h1) formátumú
címsor bekezdés szövege helyett az epub tartalomban ilyen jelenik meg 1.1 szint. Ha erre kattintunk, akkor az
1. oldalra ugrik (minden címsorról). PDF-ben ez is működik.

Előre köszönöm a segítséget!
Köszönettel:
Mercator

_iMaginer_ 2012.08.29. 14:39:45

@Mercator: erre én is kíváncsi lennék, hogy valakinek sikerült e rendes ekönyvet csinálni indesignból :)

Mercator 2012.08.29. 14:52:05

@_iMaginer_: Ezekben e kérdésekben egyelőre a hivatalos szakértők tanácstalanok, én meg egy hete reszelgetek, de a súgó pocsék, a program meg nem úgy működik, ahogy leírják...

Mercator 2012.08.29. 14:54:30

@_iMaginer_: a többi program, amelyben jól jelent meg az ékezetes betű: Sigil, Calibre (ez utóbbiban meg úgy látom a beágyazott fontkészletek telepítési lehetősége szűnt meg).

_iMaginer_ 2012.08.29. 14:59:55

@Mercator: ennél még a quark9 is százszor jobban működik. ott gyakorlatilag meg lehet szerkeszteni egy ekönyvet mindenestöl. akár ipad applikációként is

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.08.29. 17:51:48

Én még az 5.0-ás inDesignről pattantam le anno, iszonyat volt. Mondjuk, hogy a lábjegyzetek külön szövegtdobozkét fussanak, és az oldalhoz kötődnek, nem a szöveghez, az azért sok mindent elmond.

De hogy jó hír is legyen, ha amúgy jó volt az indd file-od, akkor az elég normális bemenetet ad egy rendes epub szerkesztéshez. Exportálj egy epubot és egy rtf-et, na abból már lehet dolgozni. Még egyszer, ha az indd nem volt széthekkelve.

Amúgy még lehet próbálkozni az openoffice+writer2epub+sigil (a fontok miatt) kombinációval is esetleg.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.08.29. 17:52:39

@Mercator: az őű helyett kérdőjel fontbeágyazási hibára utal. Nézz bele, hoyg egyáltalán bent vannak-e a fontjaid.

_iMaginer_ 2012.08.29. 19:18:49

@Dworkyll: az 5.0-n nem a cs5-öt érted? mert a cs5-ben teljesen krrekt a lábjegyzet kezelése

Mercator 2012.08.29. 19:46:14

Köszönöm.
A lábjegyzet tényleg jó a CS5-6-ban. A fontok benne vannak. A Sigill is ezt mondja, meg is jeleníti rendben. A Calibre is. Az Adobe viszont ezt mondja:
"az Adobe Digital Editions aktuális, 1.7.2-es változata az angolon kívül jelen pillanatban csak ezeket a nyelveket támogatja:

Digital Editions is also available in French, German,Italian, Spanish, Dutch, Brazilian Portuguese, Japanese, Korean, Chinese Simplified and Chinese Traditional. Other languages will be released over time."

Csak az ő meg az ű tér el ezen nyelvek alkészletétől. Hogy 2012-ben az Adobenak ez miért olyan nagy etwas, mikor tudtommal az Unicodehoz is van kis köze...

Mercator 2012.08.29. 20:00:34

@Dworkyll: Bővebben lejjebb, ide csak annyit, hogy semmi hekkelés nincs a dologban, gyári a program...

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.08.29. 20:18:51

@Mercator: bocs, a hekkelést úgy értettem, hogy valaki olyan oldalszemléletű módszereket alkalmaz, ami nem kompatibilis a folyószöveg-szemléletű epubbal. Mint az emlegetett "lábjegyzet egy dobozban" dolog.

a fontokról meg annyit, hogy vannak olyanok, amiknek nem teljesen korrekt a kódolása, pl. a times new roman, a windowsos, tutira rossz. Lehet még, hogy egy ilyenbe nyúltál bele.

Ja és a calibre nem jó a fontok ellenőrzésére, mert teljesen ügyesen kihelyettesíti, ha valami gondot lát. Azaz nem fogod észrevenni, ha baj van. Addig kell az anyagod gyűrni, ameddig az ADE nem mutatja jól. Nem mintha az ADE akkora király alkalmazás lenne, de nagyon sok eInkes olvasóban ADE alapok vannak.

Mercator 2012.08.29. 20:55:37

@Dworkyll: a Timest cseréltem Adobe Garamond Pro-ra (jogdíj viták elkerülése miatt is). Egy kósza Times sincs benne, elvétve van Wingdings. Az "alap művet" készként kaptam és tényleg sok kiirtani való volt benne és volt egy-két dolog, amit az Id egészen jól megoldott, pedig borzalmasan nézett ki (egymást fedő képek meg ilyesmik).

Mercator 2012.08.29. 21:30:18

Van valami valahol...
Az biztos, de nem találom. Van egy mintám - egy másik könyv -, ami egészen jó. Ugyanazok a fontok vannak beágyazva. Ez jó az ADE-nek is. A CSS-t ennek alapján módosítottam (Sigilben). Az eredmény semmi... Vagyis minden maradt a régiben.

Mercator 2012.08.30. 10:48:34

@Dworkyll: További próbálkozásaim: Garamond Pro cseréje Minion Prora - hiba maradt.
A jól működő minta css-ének és teljes fontkészletének átvétele - a hiba maradt.
...egyébként a Times meg jól jelenik meg...

SaGa 2012.08.30. 14:49:35

@Mercator: Attól, hogy a betűkészletet és a css-t cseréled, még nem biztos, hogy a betűkről au olvasó program is tudomást szerez. Az opf fájlt is megfelelően módosítani kell. Elvileg a sigil ezt jól kezeli, ha rajta keresztül cseréled a fontokat (törlés, majd hozzáadás). Ha kívül cserélsz (mondjuk zip-pel), akkor nem fogja kijavítani...

SaGa 2012.08.30. 14:53:31

@Mercator: Megjegyzésként: eddig a legjobb eredményt az Open(Libre)Office, abban a writer2epub kiegészítő és a sigil egymás táni haszálata hozta.
A writer2epub azokat a bekezdésformázásokat hozza át, amelyek a "szabvány készlet" részei (pl címsor) vagy a "w2e_" karaktersorral kezdődik a nevük. Ezek mind megfelelően bekerülnek a css-be. A táblázatokat is egész jól megcsinálja, lábjegyzeteket tökéletesen átemeli, a körbefolyatott képekkel és az iniciálékkal kell kézzel mókolni kicsit.
Betűbeágyazást is csinál az utolsó verzió, de nem azt ágyazza be, amit használsz, hanem azt, amit beállítasz a kionfigjában. Azt az egyet...

Mercator 2012.08.30. 15:10:21

@SaGa: Ez tetszetősnek tűnik, de indd-ből kellene előbb a Libreoffice Writernek megfelelő formátumba menteni, és valószínű, hogy már ez a konverzió is rengeteg más hibát tenne a könyvbe.
Különben fontot, css-t cseréltem már sigilen belül és zip kibontással, kívül is, de maradtak a kérdőjeles őű betűk...

Polemius 2012.08.31. 22:44:02

Én az indd->xml->xhtml vonalon indultam el.
(A gyári exportálással való kínlódás elvetése után.)

Mercator 2012.09.03. 13:42:15

@Polemius: Köszönöm, ez jött be! Az exportálásnál rengeteg hiba jött elő, fontokat, classokat hagyott ki, ezeket mind kézzel kellet a Sigilben helyrerakni.

Mercator 2012.09.03. 13:42:47

@Mercator: bocsánat, természetesen: kellett

Dworkyll · http://ekonyvolvaso.blog.hu/ 2012.10.25. 00:29:59

Hopp, aki iBooksba akar saját fontot, annak - a normál beágyazós trükkökön felül ezt az xmlt kell még a megfelelő helyre beszúrni:

META-INF/com.apple.ibooks.display-options.xml

nagyon pontosan ezzel a tartalommal:

<?xml version="1.0" encoding="UTF-8"?>
<display_options>
<platform name="*">
<option name="specified-fonts">true</option>
</platform>
</display_options>

Forrás: www.mobileread.com/forums/showthread.php?t=190073

A tippadó: Joxer the Mighty, örök hála
ekonyvolvaso.blog.hu/2012/08/04/az_idealis_olvaso_app/fullcommentlist/1#c17474661

blash 2013.05.27. 15:21:41

@nagygabe: ez az epub már ilyen volt, vagy mivel kellett kiegészítened? Style.css-ben a megfelelő paragrafushoz adobe-hyphens:auto?

Calibre megjelenítőjével és Sumatrával probálgattam, de egyik sem jelenít meg elválasztást, amit vagy nem tudnak, vagy nem jól írkáltam bele a style.css-be. Nook Simple Touchon szeretnék elválasztást.