Állandó rovatok

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

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

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

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

Ha adakozni akarsz, itt megteheted:

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

GYIK - Szerszámosláda

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

Vannak még:

Válassz és rendelj Kindle-t innen

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

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

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

Sok Kindle trükk.

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

Eszközismertetők

Boltismertetők

 

Utolsó kommentek

Címkék

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

Linkek - források

A barátaim, innen onnan

Scriptvarázslók, segítsetek!

2011.01.06. 23:19 Dworkyll

Először is elnézést kérek azoktól, akiket nem érdekel az e-könyv-gyártástechnológia (bocs, Prof :-), de ez most száraz poszt lesz és kétségbeesett.

Szóval. Az a nagy helyzet, hogy a Kindle3 olyan prc-ket eszik, sőt az Amazon olyan anyagokat fogad csak be terjesztésre, amelyeknek nemcsak logikai tartalomjegyzékük van (ú.n. mbp_toc.html ) hanem fizikai is (toc.ncx). Ez utóbbi teszi lehetővé, hogy a kurzorgombokkal fejezetet ugorjunk, és hogy a progress baron látszódjanak az ugrópontok, praktikusan a fejezetcímek. Szóval ez egy nagyon kellemes (és addiktív!) lehetőség.

Viszont, sem a Mobipocket Creator, se más hivatalos eszköz nem csinálja meg ezt a toc.ncx-et, pedig elvileg egy spéci függvény (a.k.a transzformáció) le tudná generálni.

A feladat kétlépcsős. Kell egy valami, ami az ismert mbp_toc.html és könyv.opf-ből kigenerálja a toc.ncx-et, és a második lépcsőben -- ha lehet -- beinjektálja az opf megfelelő helyére a toc.ncx hivatkozást.

A jó hír, hogy nem föltétlenül kell nulláról indulni. eNeL olvtárs már írt egy VBS scriptet, ami elvileg elvégzi ezt a manőverpárt, sőt sokszor működik is, de sajnos sokszor ki is akad, és nem jöttem rá, mitől. 

Licenc:

A VB Script felhasználható a GNU Általános Nyilvános Licenc (GNU GPL) V3 szerint. Lásd a forrásfájl elejét. A korábbi V2 változat nem hivatalos magyar fordítása például itt található: http://www.drdudas.hu/gpl_v2_magyarul.

Használat és tudnivalók:

  1. A szokásos módon elindítjuk a MP Creatort, és végrehajtjuk az összes lépést (beleértve a prc build-et is). A MP Creatort ne zárjuk be, szükség lesz még rá. Fontos, hogy lehetőleg ne legyen a Build után figyelmeztetésünk.
  2. A mobitoc2ncx.vbs fájlt be kell másolni a MP Creator által létrehozott ~\Dokumentumok\My Publications\"könyv/publikáció cím" könyvtárba a többi fájl mellé. A korábban létrejött "könyvcím".prc fájlt le is lehet törölni, de aki nem bízik a scriptben át is nevezheti :) A script alapbeállításban nem bántja a korábban létrejött mpb_toc.html fájlt; az eredeti "könyvcím".opf fájlt pedig (alap beállításban) "Regi_" előtaggal elmenti.
  3. Ha valakinek nincs szüksége az eredeti opf fájlra, az a script elején az opf_felulir változót állítsa "True" értékre (más állítási opció nincs is :)). Ilyenkor természetesen nem lesz "Regi_" előtagú fájlunk.
  4. Kettős kattintással (vagy Total Commanderben Enterrel) indítsuk el a scriptet. Normális esetben a művelet végén egy "A toc.ncx fájl elkészült, az .opf fájl módosítása megtörtént!" üzenetet kapunk (ami persze nem jelenti azt, hogy minden rendben lesz később is...)
  5. A könyvtárban megjelenik egy, az eredetinél nagyobb méretű "könyvcím".opf, valamint egy toc.ncx fájl.
  6. Térjünk vissza a MP Creatorba, és újra indítsuk el a "Build"-et.
  7. Jó esetben (ha korábban nem volt figyelmeztetésünk) most sem lesz. Ha van,akkor például a létrehozott prc mérete azonos lehet az előzővel: ilyenkor az ncx nem épült be a prc-be. De előfordulhat, hogy ugyanazt a figyelmeztetést kapjuk, mint amit az eredeti építésnél is (pl. nem megfelelő címlap kép fájlméret). Ebben az esetben - ha amúgy a korább prc működött - most is működni fog, de az ncx bekerülése kérdéses lesz, de akár működhet is.
  8. Készen is vagyunk. Ellenőrizzuk a fájlt a Kindle Previewer-rel. Ha minden sikerült, akkor az NCX tartalom megtekinthető a megfelelő gombra kattintva, illetve alul látható a tartalom sáv a kis jelekkel :))

FONTOS!

Nem tudtam kipróbálni, de minden irodalom szerint a KindleGen által létrehozott OPF fájl jelentősen különbözik a MP Creator által generálttól (leginkább a metaadatok listázásában). Tehát egy az egyben KindleGenhez a létrehozott fájl nem használható! Elvileg az MP Creator által létrehozott OPF fájl a KindleGen formázási szabályai szerinti átírása után a két fájl használható lehet a KindleGenhez is.

Naszóval ezt kéne kiegyenesíteni, vagy hasonlóan egyszerű (SQL szerver telepítését nem igénylő) megoldást találni.

Hálánk örökké üldözni fogja azt, aki megtalálja ezt a Grált :-)

UPDATE 2010.01.08

Ignisnek hála, készült egy xsl állomány, amelyiket ha jól megszólítunk egy xsl futtató környezettel (ez most xalan), és paraméterként átadjuk a forrás toc_html-t, akkor megcsinálja toc.ncx-et. Utána ezt még be kell fűzni az opf-be, és mehet a jöhet.

Alakulunk, alakulunk :-)

Részletes megoldás az alábbi posztban

 

 

62 komment

Címkék: prc kindle mobipocket gyakorlati kérdések

A bejegyzés trackback címe:

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

Kommentek:

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

KTamas · http://ktamas.com/ 2011.01.07. 00:35:43

Utanajarok, programozo vagyok, es erdeklodo ebookos is :)

zsotykai 2011.01.07. 06:42:00

Miből szeretnél ilyent? Vagyis kérném a .html fájlt (mintát is) is.

Professzore · http://ekonyvolvaso.blog.hu 2011.01.07. 07:04:57

Álmaimban valami olyasmi szerepel, ami a KindleGen alá dolgozik, akár parancssorosan, esetleg egyszerűbb grafikus felülettel. És nem csak a tox.ncx-et és az .opd-t generálja le, hanem a teljes kindlegen-sort, sőt, ellenőrzi a tartalom koherenciáját is.

Másrészt, bár én nem vagyok programozó, van egy olyan elképzelésem, hogy pontos leírásból (mi kell?) könnyebb dolgozni, mint egy meglévő kódhalmazból "reverse engineering"-et csinálni. A nyers scriptekkel még annyi fenntartásom van, hogy pl. én más struktúrában használom a cím-hivatkozásokat, sokszor nem is egységesen könyvről-könyvre. Erre pedig a borotválkozógép-effektus húzható csak rá.

beavereater [AT] 2011.01.07. 08:37:49

@Professzore: mondjuk ezt a vbscriptet reverselje akinek három anyja van és abból kettő Béla... tipikus amatőr munka, borzalmas minőségben... (mondjuk én ipari minőségű (általában java) kódhoz vagyok szokva)
szinte biztos, hogy ha valaki olyan hajlandó a témával foglalkozni, aki érdemi megoldást tud adni rá, akkor az inkább újraírja az egészet

de a kindlegen érdekesen hangzik, ránézek, főleg hogy mostanában felmerült nálunk, hogy több ezer pdf-ből kellene kindle/egyéb ebook formátumot gyártanunk... (ipari alkalmazás, nem klasszikus könyvkiadás)

Professzore · http://ekonyvolvaso.blog.hu 2011.01.07. 08:48:22

Én a következőre gondoltam...
Adott egy minta html, amely NEM FELTÉTLENÜL egységes a benne lévő formázások tekintetében, viszont bizonyos rendszert azért mutat (h tag-ek, struktúra stb.). Ebből kiindulva kellene felállítani egy lehetőleg egységes rendszert, amely alapján a most legnagyobb gondot okozó toc.ncx-et és toc.html-t (vagy mi a rossebet) le lehet gyártani, továbbá összehozni az opd-t. Innentől a Kindlegen paraméterezése már pofon egyszerű.

Eddig én ezt kézzel csináltam és/vagy ugye a Mobipocket Creator -- elvben -- pontosan ugyanezt csinálja (kivéve ugye két dolgot, a toc.ncx-et és a zip-elt mobit, mert ő teljesen bezárja a cuccot, a Kindlegen pedig csak sima csomagolt zip-et gyárt, ez utóbbi nekem rokonszenvesebb).

Ezügyben szerintem igen-igen sürgető lenne egyeztetnünk...

Gergely Trisza 2011.01.07. 08:59:48

Mesekönyv e-könyben? Ez az én kérdésem. (Talán elnézitek nekem, hogy itt és most teszem fel ezt a kérdést és nem pár hónappal ezelőtt olyan témánál, amiről így most lemaradtam...) Azért kérdezem, mert mesekönyvet írtam. Persze én is, mint minden kezdő író kiadatnám... A nagy kérdés, hogyan? Nem fontos nekem a nyomtatott példány, viszont lehet színes egy e-könyv is? Mivelhogy a mesekönyvem illusztrációkkal teli, magam készítettem őket, bár sajnos nem vagyok grafikus. (Azért talán akad, akinek tetszeni fog a mai - véleményem szerint - nagyon elfuserált, túldimenzionált rajzos világban...) Egy kisgyereknek mégis fontos a képi megjelenítés! Nem vagyok benne biztos, hogy egy kisgyerek szívesebben olvasná a könyvet pdf-ben (jelenlegi állapota a könyvemnek) vagy e-könyv formájában, főleg, ha fekete-fehér, mint nyomtatott formában, vagy tévednék?

beavereater [AT] 2011.01.07. 09:11:02

@Professzore: nos, nem tudom ezt a hozzászólást kinek szántad, de ahhoz, hogy bárki (akár én) elkezdjen foglalkozni ezzel a kérdéssel, definiálni kell egy feltétlenül egységes, xhtml alapú forrást.
Azaz kell egy mintafájl, amiben mindenre van példa, amit használni szeretnél (és ami abban nincs benne, azzal nem foglalkozunk). Utána érdemes elgondolkozni azon, hogy ebből hogyan lesz prc. (Mondjuk egy well-formed xhtml-ből más SGML alapú anyagot gyártani már nem túl nagy feladat, persze nem vbscriptben...).

Professzore · http://ekonyvolvaso.blog.hu 2011.01.07. 09:28:32

Általános érvényű felvetés volt.
Én nem vagyok programozó, de azt tudom, hogy a programozók hogy gondolkodnak (van körülöttem jópár). Abban biztos vagyok, hogy "na, itt egy script, keress benne hibát" csak a Swordfish-ben működőképes, Hale Berryvel, egyébként nem.

Szóval. Igen, a kiindulási alap az, hogy egységes xhtml kell(ene). Ha lesz időm hétvégén, csinálok egy részletes leírást arról, hogy én hogy gondolom a program működését (toc.ncx és mobi_toc.html összerakás, hivatkozásbefűzés, opd-összerakás). Karácsonykor már visszafejtettem, csak nem jutottam a leírás végére.

beavereater [AT] 2011.01.07. 09:32:15

@Professzore: szerintem ne azt írd le, hogy hogyan kell összerakni a toc.ncx stb. állományokat, hanem a kiindulóformátummal (egységes xhtml) foglalkozz, abból polírozz egy csodálatosat.
A toc.ntx, mobi_toc.html és az opd témakörében szerintem tele van a net csodálatos anyagokkal, csak kicsit kutakodni kell.

beavereater [AT] 2011.01.07. 09:33:00

@Professzore: mondjuk Hale Berry kedvéért még én is hajlandó lennék low-grade vbscriptet debuggolni... ;-o

zsotykai 2011.01.07. 10:03:16

OK, Dworkyll, keress meg mailben a zsoltika kjukacz gmail pötty komon. Megoldottam kb. 95%-ban.

martin78 2011.01.07. 10:42:36

Nem mint megoldásként írom, de én Calibre -t használok konverzióra, az megfelelően előkészített doc, rtf fájlból MS Word -el HTML -be mentve, majd a Calibre -el mobi formátumra alakítva simán csinál ilyen tartalomjegyzéket.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.07. 11:17:02

Bocsi bocsi, ha nem lettem volna egyértelmű. A közös nevező, ami bemenetként szolgál, az a mbp_toc.html, ami a mobi gyártás egyik köztes terméke. Annyira egységes, amennyire egy szoftver (a creator parser) csinálja. Bármilyen publiból lehúzható, aminek van tartalomjegyzéke.

A kimenet meg a toc.ncx, aminek a formátuma szintén kötött és ismert.

Aki kéri, annak szivesen küldök mbp_toc.html+opf+toc.ncx hármast, hogy legyen minta, hogy miből minek kell kijönnie.

eNeL-t meg lécci ne ekézzétek, leírta, hogy tök kezdő a vbs-ben, de legalább nekifutott, és megoldotta a feladatot. Legalábbis valamennyire.

Aki nem akarja ezt javítani, az ne tegye. De tippeket, ötleteket csak talál benne.

Kösz, kösz, kösz :-)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.07. 11:47:26

@beavereater: Találtál már ilyen konvertert valahol?

SaGa 2011.01.07. 12:37:14

@Dworkyll: Szerintem is ez a legjobb megoldás.
Az mbp_toc.htm-lt a mobipocket creator a leggázabb forrásból is összerakja, ha van valami, amire hivatkoztatni lehet.
Onnan meg egyszerű (ha egy szintű a toc.ncx):
A fájlt sorokra kell bontani (sajna egyetlen hosszú sorból áll) az <ul> tag-ek előtt.
Ha ez megvan, akkor a sorokból ki kell vadászni az alábbi mintát:

".*" (a macsakörmök is részei a kivágott mintának!)
és berakni a $hol változóba

meg ezt:

">.*<

és ebből kivágni a "> szakaszt és a <-t és a maradékot betolni a $cim változóba

majd bedobni ezeket a toc.ncx-be.

Ehhez kell egy számláló rutin, ami 0-tól számol amíg kell, legyen a változó $i

a fájlba szép sorban be kell tolni az alábbi sorokat:

<navPoint id="navPoint-$i" playOrder="$i">
<navLabel>
<text>$cim</text>
</navLabel>
<content src=$hol/>
</navpoint>

számláló rutin visszaugrik, ha van még feldolgozatlan sor, az elejére, ha már nincs, akkor itt a vége...

Ami előtte meg mögötte van, az állandó, csak a kötet azonosító változik, annyit meg akár kézzel is bele lehet dobni.

beavereater [AT] 2011.01.07. 13:18:59

@Dworkyll: még nem, de mivel várhatóan feladatom lesz többezer (4000+) PDF átkonvertálása valamilyen e-book formátumra, előbb-utóbb növesztek egy ilyet.
A tapasztalataim alapján első körben úgy fogom megcsinálni, hogy két lépéses legyen:
a) pdf->xml, (ezt sajnos "kézzel le kell programozni);
b) xml->(bármilyen ebook formátum) (erre meg ott a stíluslap).
Ha egy ilyen eszközöm lesz, a b) lépés innentől kezdve bármire ráhúzható, ami SGML alapú... (azaz nem csak xml, hanem egy normális xhtml is lehet az alapja).

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.07. 14:01:50

Szép feladat. A bemenet egységesítésbe szerintem még Sziszifusznak is beletörne a bicskája.

Viszont én nem is lőnék ilyen grandióz megoldásra, csak egy sima kis toc.html->toc.ncx konverterre, meg opf injektorra (ez utóbbit már kézzel is megcsinálom, ha kell). A vbs meg azért szimatikus, mert egyszerű, mint a faék. De ha valaki javában, vagy akár valami parancssoros exében rakná össze a konvertert, annak is piszokul tudnék örülni.

Atyaman 2011.01.07. 15:46:49

@Gergely Trisza: Szerintem egyértelműen a tableteket azaz iPad és társait kell megcélozni evvel, pdf vagy akár interaktív formában (erről linkelte be a cikket Dworkyll az imént). Ha angol nyelvterületen lennénk, akkor pedig szerintem a nook color lenne a kézenfekvő platform (legalábbis támogatottság szempontjából, azt már nem tudom mennyire terjedt el az olvasók között maga a készülék).

Ignis_veneficus 2011.01.07. 19:30:03

megvan a szep megoldas este fogom postazni, es lehet tesztelni.

Ignis_veneficus 2011.01.07. 21:13:32

@beavereater: En pont ezt csinalom.
van kb 300 konyven XML-ben (kb 1,5 eve csinalom munka mellett)
van egy
xml=> pdf-em (eleg jol mukodik)
xml=> epub (ugy ahogy mukodik)
xml=> mobi (ezt csiszolom)
ez utobbi 2 nem trivialis xslt-vel megoldani.
ja, es tamogatom a matml-t, svg-t.

Ignis_veneficus 2011.01.07. 21:31:52

@Professzore: Ha kuldesz egy leirast, hogy az XHTML-ed hogyan nez ki (mit, mivel jelolsz es egyebek), akkor megirom a 2 xslt-t ami legeneralja a toc-ot, es az ncx-et.
Okolszabalyok kellenek: vagyis
a H1 minden esetben Szakaszcim,
cimben nincs tablazat (table)
stb.

Meg egy feltetel: csak XHTML lehet.

Gergely Trisza 2011.01.08. 07:21:37

@Atyaman: De a pdf-formátumom nekem nem elég igényes, hogy az olvasási élményt vissza tudja adni, jobb lenne az e-könyv forma, de hogy készítek ilyet a pdf-emből??, mert akkor lapozgatható, mint a nyomtatott társa :-), most pedig megyek a másik posztra, ott folytatom, köszönöm a választ.

beavereater [AT] 2011.01.08. 13:41:55

@Ignis_veneficus: engem a számomra kötelező pdf->xml irány aggaszt inkább... legalábbis az eddig tapasztalataim alapján...

beavereater [AT] 2011.01.08. 13:42:58

@Ignis_veneficus: egyébként az "xml->pdf" irányra azt írtad, hogy "elég jól működik". Szerintem az xsl:fo istenkirály, nem "elég jól működik"...

Ignis_veneficus 2011.01.08. 15:17:23

@beavereater: igen, de en az xsl:fo-t a apache fop-al dolgozom fel, es vannak hianyossagi a temanak: pl csak az 1.0 tud igazi labjegyzetet tenni a tablazatba, az viszont elszall az en xslt-men (gyakorlatilag kifagy)
ezenkivul a kep meretezessel is problemak vannak.
es ha ugy nezzuk akkor a jelenlegi kb 5K soros XSLT-m sem kerek 100%-osan, es tervbe van veve par dolog amit tamogatnom illene, pl a szoszedet generalas.
Igy ertem az "eleg jol mukodik"-et.

PDF->xml: egyszer csinaltam, az is elge volt. eloszor a PDF-et atalakitottam rtf-e (szinte ORC-zes lett belole), majd a stilusokat kellett kiirtani, osszefuzni az oldatoreseket, lekezelni a labjegyzeteket...
soha tobbet

Atyaman 2011.01.08. 19:04:44

Hali! Kicsit én is eluntam a várakozást a hibátlan scriptre, úgyhogy írtam egy winword-ös vba-t.
A mobipocket által létrehozott mbp_toc.html fájl szövegét varázsolja át toc.ncx-be valóra plusz még van egy rövid is ami befüzi az opf szövegébe tartalmába az ncx-re vonatkozó szöveget.

Működés: Mobipocket Creatorban elvégzem az alap lépéseket (import, toc, metadata, save...). Ezután lemásolom az így létrejött mbp_toc.html kódját, bedobom winwordbe a makróba beállítok 5 változót (író, cím, mobipocket által létrehozott html elérése, ennek a html-nek a neve és, hogy hány elemből áll a toc).
Makrót lefuttatom a tartalmat bemásolom egy üres toc.ncx fájlba.
Másolom az opf fájl kódját wordbe, második makrót futtatom, ami kijöttt azt visszamásolom az opf-ba.
Creatorban build és kész is ;)

Egyelőre két szintű TOC-ot kezel, a hármasat majd megcsinálom ha lesz olyan könyvem amihez az is kell.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.08. 20:53:32

@Atyaman: :-)) Kicsit olyannak érzem ezt, hogy "akinek kalapácsa van, mindent szögnek néz". De ha működik, akkor hajrá!, Előre a full-extrás prc-kért.

(Most kezdenek zavarni azok az apró inkonzisztenciák, hogy a fejezetcímek alatt néha elmarad a tompasor, meg nem egyezik a cím-szöveg távolság...)

Atyaman 2011.01.08. 21:16:35

@Dworkyll: Igazából ti adtátok a kezembe a kalapácsot ;)
Amíg a blogon nem olvastam a Word-ös makrókról addig azt se tudtam, hogy eszik-e vagy isszák őket.

Azóta pedig, ha valami monoton szövegformázás felmerül, akkor egyből a makrókhoz nyúlok (fejezetcímek stílussal való ellátása, oldalszámok törlése, rossz helyen lévő bekezdés jelek...). Amúgy is mind1, hogy vmi szög vagy sem, egy jó kalapáccsal ígyis-úgyis be lehet verni :D

Viccet félretéve tény, hogy az ncx megoldásom nem egy 2 kattintásos script, de még így is sokkal rövidebb, mint egy toc.ncx sablonba kézzel átmásolni a fejezetek címeit a <navlabel>-ekhez és aztán átírni az egyéb apróságokat.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.08. 21:52:17

@Atyaman: "...fejezetcímek stílussal való ellátása..."

Ez érdekel, ezt hogy csinálod? Én a select text with similar formatting funkcióval, de minden trükk jöhet.

Atyaman 2011.01.08. 22:19:18

@Dworkyll: A select text with similar formatting az azt figyeli, hogy pl. azonos betűméret, stílus típus, sormagasság, igazítás stb.?
Mert ha igen akkor ilyet opcionálisan én is használok.

Első sorban viszont inkább arra építek, hogy a fejezet címekben van-e valami közös nevező. Pl. Első/One/First fejezet/rész/chapter...(+ opcionálisan ^pAlcím), akkor erre tudok keresni és ellátni stílussal (+ ^lAlcím és így az alcím is bekerül a headingbe)

Az alábbi módszerrel oldottam meg feltöltöttem 4 tömböt a számokat betűvel leírva (EGY, KETTŐ, HÁROM... ELSŐ, MÁSODIK, HARMADIK..., ONE, TWO, THREE..., FIRST, SECOND, THIRD...), aztán egy for ciklussal keresek és cserélek/látom el stílussal. Pl.:

...
PartHun(0) = "ELSŐ"
PartHun(1) = "MÁSODIK"
...
for i = 0 to 25
...
.Text = PartHun(i) & " FEJEZET^p"
.Replacement.Text = PartHun(i) & " FEJEZET^p"
...
.Format = True
...
Selection.Find.Execute Replace:=wdReplaceAll
Next i
Erase PartHun()
...

Nyílván a végén még érdemes átfutni a toc-ot, mert ha valahol elütés volt, akkor ott nem tudott cserélni. Ezt első körön úgy szoktam ellenőrizni, hogy megnézem hány elem van heading2 stílussal formázva, mivel az csak egy kattintás. Abból egyből kiderül ha kevesebb, mint amennyi fejezet van.

kIára 2011.01.09. 14:22:54

Én semennyire sem értek a programozáshoz, úgyhogy csak okoskodom.

Megnéztem a Kindlegen-hez adott guide példát. (A Sample mappában található KUG.ncx-et)
Namost ez egyetlen sorral tér el a Sigill által készített toc.ncx-től. Nem szúrja be a
<docAuthor><text> Szerzo Neve </text></docAuthor>
sort. Na bumm.

Ismétlem, nem értek hozzá. De ha a Sigill nyílt forráskódú, és egy teljesen kindle-kompatibilis ncx-et készít, akkor nem egyszerűbb a forráskódot lecsupaszítani csak erre, és akkor lenne egy önálló, kész Ncx szerkesztő. Gondolom a Sigil-0.3.3-Code/src/Sigil/Exporters/NCXWriter.cpp
-vel kellene valamit kezdeni.
(Bocs, ha nagy hülyeséget írtam).

Ignis_veneficus 2011.01.09. 14:56:14

Elvegeztem egy kiserletet.
A kindlegen megeszi azt az NCX-et is, amiben nincs sem
docTitle, sem docAuthor.
Amugy sem ertettem, minek bele, hiszen a metaadatok ugyis benne vannak a opf-ben.
Szal: legalabb azzal nem kell szivni.

kIára 2011.01.09. 18:43:32

@Ignis_veneficus:
Persze, az csak elvárt opció.
Szerintem ezt elsősorban azoktól a kiadóktól követeli meg az Amazon, akik rajtuk keresztül akarnak publikálni.
Szóval egy gonddal kevesebb.

Ignis_veneficus 2011.01.09. 19:59:11

@kIára: Nem ertem, hogy minek bele, ott az opf, abban is van cim, meg szerzo, meg egyeb mas metadat.
hasznaljak azt.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.09. 20:26:21

@kIára: Az a baj, hogy a logikai tartalomjegyzék fontosabb, és azt a sigil nem csinálja meg. A sigil nekem is eszembe ötlött, mint ncx generáló eszköz, csak elég fapados, viszont barátságtalan volt. Például nem találtam meg rajta azt az opciót, hogy valamilyen algoritmus szerint szedje össze a fejezetcímeket.

Maga feladat, egy darab (jó komplex) függvény, ami a toc.html-ből kigenerálja a toc.ncx-et, valami parancssorért kiállt.

Úgy fest Ignis xsl-je tök jól zúzza, az egyetlen warning, amit generált azért lehetett, mert az egyik fejezetcím cirillbetűs volt. Amúgy atomtuti. Nemsokára frissítem vele a posztot.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.09. 22:05:01

@Ignis_veneficus: Mobi Creatorral gyártom a prcket. Annál a bizonyos publinál az egyik fejezetcím cirillbetűs volt. Buildkor ezt a warningot dobta a creator: SRING CONVERSION WAS INEXACT IN FILE. blablabla/TOC.NCX. Kicsit paráztam, mert ez volt az első, de onnantól kő stabilul darál, minden nyikk nélkül, pedig igen igen szemetes, pl. keresztbe taggelt forráshtml-ekkel) próbálom kiakasztani. De nem megy :-) Működik az xsl :-)))

Ja és a warning ellenére fullos a publi is, és gondolom az ncx is.

Ignis_veneficus 2011.01.09. 22:21:19

@Dworkyll: A kindlegen is allandoan dobalta a warningot:
"Warning(core): String conversion was inexact."
ezt valszeg a nem latin karakteres reszeken dobalja .

kIára 2011.01.10. 11:39:52

@Dworkyll:
A Sigil nekem sem a szívem csücske. Csak azért jutott eszembe, mert tettem egy kísérletet.
Egy régi prc forráscsomagmagban található html-t nyitottam meg vele és azonnal generálta a teljesen pontos ncx-et. Ez kevesebb, mint 2 másodperc.
Ezért gondoltam arra, hogy ha valaki megbütykölné a Sigil forráskódot, akkor lehetne készíteni egy olyan programocskát, ami képes átszaladni több régi Mobipocket Creator forrásfájlon és kidobálná az ncx-eket.

Persze ha Ignis_veneficus xsl-je hatékony, akkor kár ezzel vesződni.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.10. 11:48:27

@kIára: Szerencsére ignis megoldása nagyon robosztus, és nagyon gyors, gyakorlatilag, miután elhelyeztük a megfelelő helyekre az alkatrészeket, egy darab duplaklikk. Nincs GUI, se csicsa. Lesz róla részletes poszt viszont, pont az alkotótól.

Amúgy a sigil mostani verziója egész ügyesen kiszedegette a headingeket egy ncx számára. (én meg most szaladtam bele, egy class és nem tag alapú fejezetcímkezelésbe)

Gergely Trisza 2011.01.10. 15:47:14

@Ignis_veneficus: Na, akkor hogy is lesz a pdf-ből e-könyv formátum? Hát ez az, nagyon fáradságos munkával, ha jól értem... :-(
Rtf-et már én is csináltam belőle, odáig eljutottam nagy nehezen! (Mivel nem vagyok hozzáértől.) Gondolom, ez az alap. Hogyan tovább? Vagy "tessék rábízni a szakemberre, asszonyom", annak is meg kell valamiből élnie... :-)

Ignis_veneficus 2011.01.10. 16:25:23

@Gergely Trisza:
RTF-bol a legegyeszrubben XML-t a OpenOffice-al lehet gyartani: el kell menteni ODT formatumba, atnevezni ZIP-re, es benne van egy content.xml ami a tartalom XML formatumban.

Hogy RTF-bol hogyan lesz ekonyv?
Oldalt a "Szerszamoslada" dobozban van ket link, ket regebbi bejegyzeshez:
* Hogyan csináljunk igényes mobipocket publikációt?
* Így neveld az az epubodat!
mindketto vegigvezet egy-egy utvonalom, aminek a vegen kiesik a megfelelo e-konyv.

Ezenkivul van meg az emlegetett "tessék rábízni a szakemberre, asszonyom" is.
Ha jol ertelmeztem az elszort info morzsakat tobben is foglalkoznak ezzel (fel)hivatasszeruen a blog-on.

Gergely Trisza 2011.01.10. 18:14:20

@Ignis_veneficus: Köszönöm, de ezek nagyrészt windows-zos programok, nekem mac-es megoldás kellene!

Ignis_veneficus 2011.01.11. 10:27:14

@Gergely Trisza: Mind a két formátum esetben igaz, hogy az elején HTML-t kell előállítani és legalább két file-t egy opt-t (metadatok, file-ok listája stb) és egy ncx-et (logikai tartalomjegyzék)
Ezeket kézzel is elő lehet állítani akár XSLT-vel a html-ből.
Ezek a file-okból lehet előállítani a ekönyv formátumot:
prc: a kindlegen letölthető MAC-re is.
epub: az Epub egy átnevezett zip file.
Tehát fapados módszerekkel mindkettő előállítható Mac-en.
(más dedikált programot nem tudok mondani, tekintve, hogy nekem windows-om van)

csigasfiu 2011.01.11. 21:45:58

Egy kis segítséget szeretnék kérni prc ügyben, és látom itt elég sok a profi, hátha valakinek van valami ötlete. :)

Készítettem már néhány prc-t, de most olyan problémával szembesültem, amivel még korábban nem, és nem tudom, hol lehet a bibi.

Adott egy word fájl. Ha mobipocket cratorral átkonvertálom, akkor a szöveg egy része dőlt, más része pedig vastagon szedett lesz, holott word-ben csak normál szöveg van.

Megpróbálakoztam azzal is, hogy elküldtem átkonvertálni az amazonnak, de a visszaérkezett fájl esetében is ugyanez a probléma lépett fel.

Úgyhogy, valószínűleg az alap word-el lehet valami, csak sajnos sejtelmem sincs, hogy mi. :)

De hátha itt valaki tudja. :)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.11. 22:33:52

@csigasfiu: Hát így látatlanban elég nehéz megtippelni. Olyan lehet, hogy a normálnak kinéző szöveg valamilyen heading. A headingre pedig automatikus formázások vannak, amiket parsoláskor a creator ráhúz az adott headingre.

Esetleg csinálj egy html mentést a szövegről, és nézz bele egy editorral. Az se baj, ha előtte lepucolod a html-t a pucolószlripttel. (ekonyvolvaso.blog.hu/2009/05/11/hogyan_csinaljunk_igenyes_mobipocket_publikaciot II. stáció)

Dragon Z. · http://www.dragonweb.hu 2011.01.22. 11:04:16

Épp most találtam: nekem így egyszerűbbnek tűnik a logikai tartalomjegyzék készítése, és még script sem kell hozzá: forums.kindledirectpublishing.com/kdpforums/thread.jspa?threadID=9978&tstart=0

SaGa 2011.01.22. 12:09:04

@Dragon Z.: Egyszerű, csak melós, ha van egy 120 alfejezetet tartalmazó könyved...
Erre van a script.

Atyaman 2011.01.22. 12:26:51

@Dragon Z.: Egyszerűbb? Most csak viccelsz ugye? Egy template-ből kialakítani copy&paste-ekkel az ncx fájlt miért lenne egyszerűbb mint lefuttatni egy scriptet ami megcsinálja helyetted? Aztán még törölheted a felesleges elemeket is, amik a 166 elemes template-ben vannak.

Ez a módszer nem egyszerűbb, cserébe viszont lassabb és igénytelenebb. Igénytelenebb mert az ilyen ncx fájlban nem a toc elemek nevei fognak szerepelni hanem pl.: Section 1, 2, 3...

Tény, hogy én se az itteni scriptet használom, mert a több szintű toc-ból minden elemet látni akarok a progressbaron, ezért a saját vba makrómat futtatom a toc fájl kódján. De még az is gyorsabb ennél a módszernél és az ncx viewban is az adott toc elemek neve szerepelnek nem egy generic sorozat.

Atyaman 2011.01.22. 12:36:44

@SaGa: Igen, de csak akkor, ha vagy annyira igényes, hogy a navlabel-öket beírd ;-)
Amennyiben teszel rá akkor már mind1, hogy a toc 12 vagy 120 elemből áll.
Ez a kiragadott mondat szerintem jól jellemzi a módszer hatékonyságát:

>>The biggest of my books contains 166 logical sections and it took me all day to write the NCX file (using NotePad).<<

Bwhaahhaa :-D

Ignis scriptjével ez mennyi lenne 1-2 sec?

Dragon Z. · http://www.dragonweb.hu 2011.01.23. 09:26:39

Valóban munkásabbnak tűnik, amennyiben 160 ugrást óhajt az ember beletenni, de mondjuk 20-30 szerintem még belefér az olyan lámáknak, mint amilyen én vagyok, akinek többszöri próbálkozásra sem sikerült a script-tel boldogulnia (kiírja, hogy sikeresen beszúrta toc.ncx-et, hurrá, aztán sehol semmi - nem tudom, mi lehet a gond, tényleg nem értek hozzá, figyelmesen követtem a leírásokat). Én is a script pártján volnék, de ha valaki idegenkedik tőle, vagy hozzám hasonlóan nem megy neki vmiért, akkor talán jó, ha tudja, hogy van alternatíva - még ha többet is kell dolgoznia vele. Ennyi. (@Atyaman: ezt a Section-fog-szerepelni dolgot nem értem: átírod arra, amire akarod. Így tettem. Simán, szépen, igényesen megcsinálta a dolgot. Igen, fél órával tovább tartott, de sikerült, és ez a lényeg.)

Atyaman 2011.01.23. 12:08:32

@Dragon Z.: A Section-ök kézi átírása egy sziszifuszi munka, mivel automatizálással teljesen megkerülhető. Csak gondloj bele mennyi időt takaríthatsz meg nélküle. Szerintem átlagosan könyvenként 10-15 percet.
A scripttel kapcsolatban meg ha nem megy valami, akkor kérdezősködj. Nekem is volt egy elsőre nem triviálisnak tűnő problémám, amit az okosok pikk-pakk megoldottak.
Ha meg az sem pálya, akkor szívesen átpasszolom a word makróm, avval aztán tuti nem lehet elakadni (feltételezve, hogy van microsoft word-öd).

Dragon Z. · http://www.dragonweb.hu 2011.01.23. 16:42:08

@Atyaman: persze, világos - a makrós dolog érdekel, lehet, hogy kopogtatok majd ;)

Egyébként utánanéztem, hogy az InDesign CS5 (tudom, tudom... de akkor is...) automatikusan megcsinálja a toc.ncx-et (telepítsük persze a hivatalos Kindlegen plugint) a mobi file-hoz. Egyetlen probléma ugye az, hogy ha több szintű tartalomjegyzékkel van dolgunk, akkor azt nem hozza automatikusan egy szintre - vagyis csak az első szint pontjai fognak működni az 5-irányúval. (Ennek kiküszöbölésére a generálás előtt minden címsort ki lehet húzni első szintre a toc style-ban, így minden oké lesz - viszont így meg az automatikusan a könyvünkbe illesztett jegyzék mutat mindent azonos szinten... Ha azonban a mobi-t átnevezzük zip-re, kibontjuk, megkeressük a toc.html-t, ott Notepad-ban pl. megcsináljuk a szintek behúzását, majd a mappában lévő content.opf-et a kindlegen-nel újrafuttatjuk, akkor minden szép és jó lesz. Oké, ez is bonyolult első olvasásra, és még mindig a script tűnik a legegyszerűbbnek, de talán van, akinek ez is segít.) Uff!

Dragon Z. · http://www.dragonweb.hu 2011.01.23. 16:47:08

Egyébként ezt már nézte vki: www.library4science.com/ebookfmt/form.html ?

Egyelőre csak OpenOffice-ból generált html-lel megy, de ez is csinál toc.ncx-et - a végén persze itt is egy kindlegen futtatás kell, de ennyi.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.23. 21:47:09

@Dragon Z.: Őőő, az megvolt, hogy Ignis erősen továbbfejlesztette eNeL scriptjét, pontosabban új alapokra (xsl) rakta. eNeL scriptje nem volt elég robusztus, viszont "toc_injektorként" egy része tovább él a megoldásban.

A részletes megoldás ebben a posztban van: ekonyvolvaso.blog.hu/2011/01/10/svajci_bicska_xslt a fapados leírás a poszt végén. Kicsit munkás összerakni a készletet, elismerem, cserébe villámgyors (két darab duplaklikk) és atombiztos.

Ja és van olyan xsl változat, amelyik "kilapítja" a többszintű ncx tartalomjegyzéket, hogy az jól mutasson a progress baron. A html tartalomjegyzék többszintűségét ez nem érinti.

Kell ennél több? ;-)

SaGa 2011.01.24. 07:08:34

@Dragon Z.: Van itt egy alapos félreértés...
A több szintű toc.ncx ugyan alul a pozíciójelzőn csak az első szintet jeleníti meg, de az 5 irányú akármivel a teljeset használja, azaz a következő tényleges bejegyzésre ugrik, függetlenül attól, hogy az megjelenik-e a csíkon vagy sem.
Szerintem nem érdemes elrontani a már jól kigenerált több szintű toc.ncx-et csak azért, mert a mostani Kindle szoft nem mutatja csak az első szintet...

Dragon Z. · http://www.dragonweb.hu 2011.01.24. 09:23:05

@Dworkyll: öööö... az megvolt, hogy nekem az istennek nem akar működni? (Azt is mondtam, hogy nyilván nem a script a hibás, de ez van, nem ebbe akarok megőszülni.)

@SaGa: Lehet, hogy az én Kindle-példányom ért akkor valamit alaposan félre: csak az első szintet jelzi a pozíciójelzőn éééééés - dobpergés - csak az első szintekre is ugrik. ;) (Egyébként utánaolvastam, és írják is, hogy ja kérem, a Kindle nem eszi meg a nested toc dolgokat, de lehet, hogy ők is abból a szériából kaptak, amelyből nekem jutott.)

Mielőtt még erősen úgy tűnne, hogy trollkodni készülök, jelzem, hogy nem, csupán lelkes próbálkozó vagyok, és igyekszem a magam módján megoldani a dolgokat - csak néha kevés sikerrel, elnézést, ha ettől valakinél elkezd kiégni a biztosíték, esküszöm, abbahagyom, csendben tanulok tovább ;)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.24. 09:39:08

@Dragon Z.: NO akkor.
Kéne látni, hogy pontosan mely lépésnek mi a visszajelzése.

Pl. Tud-e a toc_generátor értelmes toc.ncx-et csinálni. Pl. mert ha valami gebasz van, akkor üres toc készül, és persze a build dob egy warningot, hogy valami nem kóser.

Valamiért az az érzésem, hogy te eNeL első scriptjével bírkózól, és nem az Ignis féle xsl batch-csel. Tehát, hogy segíteni tudjunk, látni kéne a pontos lépéseket, mondjuk onnantól, hogy megvan az mbp_toc.html-ed (fölteszem a normál tartalomjegyzéket azért használsz), és nekiesel a pontosan mivel is?

A másik, hogy tudok pár mintafile-t küldeni, mert egyszerűen nem tudom elképzelni, hogy rendes, akár többszintű toc.ncx mellett ne rendesen működjön a fejezetugrás. Én is beleszaladtam egy ilyen többszintű toc-ba, és frankón lapozta a fejezeteket.

Nem lehet, hogy a kézi gyártású tocban van valami inkonzisztencia?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.24. 09:47:29

@SaGa: Ignisnek hála a toc gyártás, legyen az egyszintű vagy több, ovis nyelven szólva "bébikönnyű". Azaz ameddig a Kindle nem mutatja a legfölső alatti szinteket, én simán nyomnám a földszintesített toc-okat, mert mégis csak a funkció fele a vizuális visszajelzés a progress bar-on. Kár lenne érte. Aztán ha változik a firmware, majd újrahúzom a toc-ot.

Mondjuk ebből is látszik, mennyire kétpályás a prc-epub viszon, epubbal ezt nem tenném, értelemszerűen, és ezért is kell alapjaiban kétfelé optimalizálni, sajnos.

Ignis_veneficus 2011.01.24. 15:06:51

@Dworkyll: Itt jon elo a script (ketpalyas jatek)
meg lehet csinalni a scriptet, hogy bemeno parameter legyen, hogy egyszinto/tobbszintu ncx kell.
onnantol csak egy lepes:
- epub kell : paramter = "A" (tobbszintu)
- prc kell: paramter ="B" (egyszintu)
süti beállítások módosítása