Á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

Hogyan csináljunk igényes mobipocket publikációt?

2009.05.11. 23:15 Dworkyll

Intro

A mobipocket a legtöbb eszközön egy nagyon kényelmesen olvasható dokumentum-forma, de van egy csomó apró részlet, amitől igazán komfortossá válik az olvasása. Évek óta konvertálok állományokat ebbe a formátumba, és mindig lehet találni valamit, amitől az eredmény még "olvashatóbbá" válik.

Az alant leírt munkafolyamat és eszköztár csak egy a lehetséges nagyszámú módszerből. Ahogy egy tanult ismerősöm mondaná, lehet 5 perc és 5 óra alatt is publikációt gyártani. Ez nem az 5 perces változat. Próbáld ki, hogy neked mi áll a kezedere.

Hozzávalók:

  • Egy nyersanyag, saját írás, vagy ingyenesen letöltött anyag valamelyik publikus oldalról, pl. a MEK-ről.
  • Egy jó kényelmes szövegszerkeztő. A flamewartól most tekintsünk el, itt most a MS word fog ebben a szerepben megjelenni. A lényeg, hogy legyen a szerkesztőnek html kimenete.
  • A "kipucolószkript". Jvoq és Elminster munkája, ami a Word (és momentán csakis a MS Word) html exportállományából kitakarítja azt a sok sallangot, amire semmi szükség a publikációgyártáshoz, ellenben békén hagyja a szükséges formázásokat.
  • Egy kényelmes html szerkesztő. Ebben fogjuk a bemenő szöveg publikálás előtti finomhangolását elvégezni. Én a FrontPage nevű alkalmazás egy régi változatát szeretem, mert kellően egyszerű, de támogat bizonyos automatizmusokat, gyorsbillentyűket, van együttes WYSIWYG és kód nézet, és működnek a regular expression-ök.
  • A MobiPocket Creator. Egy ingyenes alkalmazás Mobiéktól, ami a jól előkészített html-ből, metaadatokból és fedlapból full extrás publikációt készít. (FIGYELMEZTETÉS: ebből egy install kit van, de kétféleképpen lehet telepíteni. A PUBLISHER változatot tessék választani, ne a HOME verziót. Ugyanannyiba kerül (ingyen van), de több az opció.)
  • Idő.
  • Türelem.
  • Gyakorlás
  • Kísérletezés.

 

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

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

  • Ne maradjon bent a szövegben feltételes elválasztójel.
  • A gondolatjel legyen gondolatjel és ne kötőjel! Nagyon nem ugyanaz.
  • Egy bekezdésben egy bekezdésjel legyen, ne soronként. A bekezdésket, ha nincs tematikus törés, ne válassza el üres bekezdés.
  • A formázások, dőlt betűk és egyéb kiemelések legynek rendben. Dőlt betűk szoktak lenni pl. a versidézetek, a hajónevek, néha az egyes szám első személyű gondolatok, ez utóbbiak nem mindig.
  • Ha vannak (voltak) a szövegben lábjegyzetek, ez egy kényelmes stáció, hogy egységesen endnote-ra cseréld őket.

A szakasz végén az anyagot mentsd el szűrt html-be.

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

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

II. Stáció - sallangtalanítás

 A word által generált html-t a mellékelt kis script (a txt kitejesztés levágása után) szépen lepucolja. Ha véletlenül beszakadna, akkor a temp file végét megnézve ki lehet deríteni, a hogy a forrás melyik sora okozta, általában valami fifikásabb formázás (pl. kézi lapdobás). Ha a vad trükköktől eltekintünk, akkor egy nagyon letisztult html lesz az eredmény.

A script használata végtelenül egyszerű, egy explorer ablakban csak húzzuk rá a html állományt.

Érdemes egy szövegszerkesztővel belekukucskálni, pár opciót lehet állítani a REM ki- és bekapcsolásával.

Köszönet Jvoqnak és Elminsternek érte.

III. Stáció - a html "finomhangolása"

Hogy a prc megjelenítés összes finomságát kihasználjuk, nem árt, ha az alábbi módosításokat elvégezzük a forrásállományunkon.

  • A legfontosabb, hogy a bekezdések ne <p> taggel legyenek elválasztva, hanem </br>-rel. Search&replace a barátod. A <p> taggel ábrázolt bekezdések ugyanis alapértelmezve behúzott első sorral, és (A Kindle 3 kivételével) másfeles sorugrással kezdődnek. Viszont nekünk minden pixelre szükségünk van. A bekezdés eleji behúzás ellen, ha szükséges (lásd tompasor) az alábbi attribútum is véd:<p width="0">

UPDATE 2009 november

A <br/> tages bekezdés-elválasztás még a QVGA időkből származik, amikor is tényleg minden pixelre szükség volt. VGA vagy jobb felbontás esetén az első sor behúzása már korántsem olyan fájdalmas, viszont javítja az olvashatóságot.

A másfeles sortáv ellen pedig jól véd a

<p height="0">

 tag használata. Ezt lehet search&replace-szel, vagy a "kipucolóscript" megfelelő sorának bekapcsolásával intézni.

Kellemes mellékhatás, hogy a korábban a <br/> tag használata miatt elkódorgó szöveg-igazítások nem okoznak problémát. (Bekezdésen belül ugyanis csak egyféle igazítás lehet, és a <br/> csere jól megkavarhatta a szövegképet, ha belefutott egy középre- vagy egy jobbraigazításba.

  • Használjuk a címsor stílusokat, mégpedig így: h2: szerző, h1: cím, h3: könyv, vagy kötet, h4: fejezet. Ha nincsen elvileg szükség a h3 szintre, mert csak fejezetek vannak, akkor is célszerű a h4 tag használata, mert a h3 túlságosan nagy a normál szöveghez képest.

UPDATE 2010 szeptember

Mint kiderült, a szerző és a cím megjelölésére nem a h1 és h2 a legszerencsésebb. Bizonyos parserek ugyanis szolgaian átveszik a heading hierarchiát és azt erőltetik a tartalomjegyzékben, illetve ha ilyet látnak, a magasabb szinteket odateszik az alacsonyabbak elé, ha kell ha nem.

Ilyen parsert használ pl. a stanza, és ha prc-t konvertálunk epubra, akkor is vannak kellemetlen mellékhatások.

Ezért a tudomány jelenlegi állása szerint kötetek/fejezetek tagolására kiváló a h3/h4, szerzőre címre meg ajánlott egy sima középre igazítás, félkövér/nagyobb font használatával.

UPDATE 2010 december

Maradhat a h2: szerző, h1: cím hagyomány, mert gyakorlatilag az összes platformra, (BlackBerry, iPhone, Android, MacOS, PC) elérhető a Kindle alkalmazás, mint natív prc megjelenítő program. A hagyománnyal viszont jól használható az alább bemutatott css kódrészlet

  • FIGYELEM: a nulla magas (height="0") ÉS üres sorok nem fognak látszani, nem működnek elválasztásként. Ha szövegközi üres sorra van szükség, ezt a kódot használjuk:

<p>&nbsp;</p>

  • Az állomány "fejébe" beszúrt alábbi css bejegyzés sokat dob az olvashatóságon. Html-ben ez amúgy majdnem teljesen értelmetlen, de így a fejezeteink mindig új lapon fognak kezdődni, és szabályozható a távolság a lapszéltől és a kenyérszövegtől.

UPDATE 2010 december
<html>
<head>
<title>A könyvem címe</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-16"/>
<style type="text/css">
 h1   {
      text-align: center;
      margin-top: 35;
      }
 h2   {
      margin-top: 25;
      text-align: center;
      }
 h3   {
      page-break-before: always;
      text-align: center;
      margin-top: 30;
      margin-bottom: 1em;
      }
 h4   {
      page-break-before: always;
      text-align: center;
      margin-top: 30;
      margin-bottom: 1em;
      }
p.noind {
        text-indent: 0;
        }
</style>

  • Ez a css lekezeli az előre beadott headingekkel a teljes publikációt. A noind class-t használhatjuk a tompasorok vezérlésére, címek és üres sorok után, ahogy az a nyomdásztankönyvekben írva vagyon. FIGYELEM: Az egyes attribútumok sorrendje kötött. Ilyen a mobi parser, ha megvariálod a sorrendet, nem mindet fogja értelmezni.

<p class="noind">

 

  • Optikai tuning. Néha nem árt bizonyos szövegrészeket (pl. levelek, újságcikk-részletek, emailek stb.) más betűvel szedni. A Kindle a default fonton kívül tud még monospacedet kezelni. Ezt a <tt> vagy a <kbd> taggel lehet jelezni. Hogy a méretek passzoljanak én ezt még megfejelem egy <small> taggel valahogy így:

<p class="noind"><tt><small>Email a hitveshez</small></tt></p>Célszerű a sok search and replace után még gyorsan átfutni a szövegen. (Ez itt egy minta-html, ez eredetije a MEKről való).

 

IV. Stáció - a publikáció összerakása.

Ehhez kell a Mobipocket Creator (Publisher install).

  1. Nyissunk egy üres publikációt. Ha jót akarsz, itt ne használj ékezetes karaktereket, mert ronda filenevet fog generálni. Húzzuk be a publikációs állományok közé az imént letisztított és kipolírozott html állományt.
  2. Másold be a publikációs alkönyvtárba a fedlap-képet, és a creatorban jelöld meg, hogy ez lesz a fedlap.
  3. Töltsd ki a metaadatokat, úgymint cím, szerző, műfaj stb. Beszúrhatsz egy rövid fülszöveget. És újfent meg kell erősíteni a fedlap képét.
  4. Csinálj tartalomjegyzéket. Egyszerűen írd be az tartalom-form első sorába, hogy Tartalom, és add meg a használt tageket. Pl h3 és h4, vagy csak h4. Ellenőrizd le a Preview in browser funkcióval, hogy minden fejezetcím jól látszik, és csakis a fejezetcímek látszanak. (Ha hibát látsz, pl üres sorok, vagy hiányzó fejezetcímek, a forrás html-ben javítsd).
  5. KINDLE EXTRA. A Kindle kezeli a fizikai tartalomjegyzéket (a.k.a. toc.ncx). Az alábbi poszt szerinti eljárással csináld ezt meg és fűzd bele az elmentett opf-be. A Kindle innentől kijelzi a fejezethatárokat a progress baron, és lehet fejezetenként lapozni.
  6. BUILD. Válaszd ki a kívánt tömörítést és titkosítást. Az egyszerűség kedvéért én standard tömörítést és zéró titkosítást szoktam választani. Nem is kérek pénzt az anyagokért.

Lehet olvasni.

V. Stáció - Post processing

Olvasgatjuk a jó kis anyagunkat, elvégre azért csináltuk. És beleszaladunk egy hibába. Vagy valamit átírnánk. Már nem úgy gondoljuk. Digitalizált és legálisan letöltött könyveinkben sajtó- vagy OCR-hibát lelünk. Vagy valami értelemzavaró félrefordítást. Ilyenkor célszerű a Highlight funkciót alkalmazni. A TFT platformok ezt tudják, az e-Inkes eszközök (a Cybook és a Kindle kivételével) sajnos még nem. Ha elég korrigálni valót találtunk, mehetünk vissza a Creatorba (duplaklikk az illetékes opf állományra), ott pedig a szöveg-htmlre kattintva elérhetővé válik az Edit with html editor funkció. Ez utóbbihoz célszerű a kedvenc editorunkat beállítani, hogy ne word vagy notepad nyissa meg az állományt. A szöveget a forrás html-ben javítsuk, utána újra build. És kész. Vagy legalábbis kezdhetjük újra az V. Stációt.

 

Jó munkát és jó olvasást!

 

Költözés: az eszmecsere és kérdezz-felelek elköltözött ide: 

http://forum.ekonyvolvaso.info/topic/9-mobipocket-creator/

454 komment

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

A bejegyzés trackback címe:

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

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.

pappito · http://pappito.com 2009.05.15. 01:48:56

példás munka, köszönet érte!

blö 2009.05.15. 08:00:19

Remek anyag, köszönöm.
Az V. Stáció-nál a 'Highlight'-nak van valami értelme a readeren kívül? Magyarán ha a creatorból nyitom meg a html-t, látszik a kiemelés? Vagy csak a readerben tudom később ellenőrizni a javítást?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2009.05.15. 10:50:32

@blö: Bocs, ha nem lettem volna egyértelmű. A highlight csak a readerben látszik, a szöveg ugye szent. Ez igazából csak egy társ-file-ban tárolódik.

Ergo, a javítás két ablakban történik, a readerben látod a tennivalókat, a html szerkesztőben meg csinálod. És törlöd az highlight-ját az elvégzett javításnak. A hiba ilyenkor még értelemszerűen bent van a publikációban, az csak a javított html újrabuildelése után tűnik el.

Az ötleted nekem is eszembe jutott, csak a fejlesztőket nem érdekelte eléggé :-(
www.mobipocket.com/forum/viewtopic.php?t=5844

blö 2009.05.15. 12:13:24

Sejtettem. Bár reménykedtem, hogy félreértem. :)

szs. · http://szabosandor.blog.hu 2009.09.16. 15:16:27

A kipucolószkript OpenOffice-ban MS Word XP formátumban mentett fájloknál is működik, vagy ne kísérletezzek vele?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2009.09.17. 20:46:31

@szs.: Sajnos fogalmam sincs. Viszont 1. próbálgatással kárt nem csinálsz, max a script nem fut le, vagy nem pucol rendesen 2. ha vágod a témát, nyugodtan átolvashatod, hogy hogyan működik a script, sőt még variálhatod is.

Szerintem nyugodtan kísérletezz, és számolj be az eredményekről, hogy mi is okosodjunk.

Ha meg nagyon megszorulsz, van egy emilcímem az írójához, meg lehet kérdezni direktben.

szs. · http://szabosandor.blog.hu 2009.09.17. 21:50:31

Oké, megpróbálom, aztán ha nem jelentkezem többé, tudjátok, mi történt. :)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2009.09.18. 11:03:38

@szs.: Semmi pánik, még a forrásfile-odat is csak olvassa a script. Az eredményt egy CLEAN_forrásnév.html-be rakja le. Ha meg gondja van, akkor beszakad, és egy .tmp-t hagy maga után, amiben meg lehet nézni, hogy meddig jutott a script.

Utána megnézheted a forrásban, hogy mi volt a trükk a szakadás táján, pl a kézi lapdobást mintha nem szeretné.

Ja és a forrásfile is legyen html, ne doc!

aesopus · http://blog.hu 2010.09.17. 16:31:07

OSX alá igényes mobipocket készítőt ismer valaki?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.09.18. 04:01:56

@aesopus: Nézd meg a Calibrét. Én nem szeretem túlzottan, de tény, hogy lekezel olyan dolgokat, amit a Creator se tud: kiskapitális, vagy behúzások. Vagy pl. epubból át tud venni tartalomjegyzéket, ezt se tudja a Mobi saját konvertere.

Egyre figyelj, hogy az üres sort a MOBI parser nem szereti, ha ilyen kell, legalább egy nonbreaking space legyen benne.

Amire nem jöttem rá, igaz nem is nagyon kerestem, hogy hogyan vihetné át a Calibre konverzió a sormagasság-attribútumokat.

Atyaman 2010.09.18. 11:35:28

@Dworkyll: Nálam fura módon a nonbreaking space sem volt elég. Avval együtt is törölte a sort Calibre epub->mobi konvertálás esetén. Sőt, az epub-okban, amiket Atlantis hozott létre az üres sorokban automatikusan szerepelt a nonbreaking space:
<p class="p0">&nbsp;</p>
Ami végül működött az a Line Break. Sima keresés-csere algoritmussal pakolom be: keres: "^p^p" csere:"^p^l^p"
Az epub megjelenítéskor ezek az üres line breakek nem látszódnak, míg az üres sorok maradnak. Az epub-ból calibre-rel konvertált mobikban pedig pont fordított a helyzet :D

ehran 2010.09.18. 11:47:13

@Dworkyll: Azt nem tudom, hogy a Creator az ePubból hogyan konvertál, de rtf-ből/doc-ból átveszi rendesen a tartalomjegyzéket.
Az üres sorral kapcsolatban meg egyetértek @Atyaman: -nel, nem volt elég a nonbreaking space, de bevallom, nem kutakodtam sokáig, lehet, kissé gányolás, de nálam az volt a megoldás, hogy a dokumentumba az üres sorokba tettem egy középre rendezett *-ot. :)

Atyaman 2010.09.18. 12:00:56

@ehran: Az a megoldás még jól is néz ki :D

zsendice 2010.10.20. 11:28:50

Szia Dworkyll,

Segítséget kérnék, hogy az itt található könyveket, hogy lehet átrakni Kindle formátumra.
pim.hu/object.d8f182da-fdfa-45ba-914f-2688ce822346.ivy

Ha mutatsz egy példát akkor felajánlok érte egy üveg bort - majd szólj , hogy milyen fajtát kedvelsz.

Üdvözlettel...Püspöki

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.10.20. 12:20:40

@zsendice: Fogós ravasz kérdés.

Először is írnék nekik, hogy csinálják meg ők, mégiscsak az az autentikus :-)

A második, hogy elkérnék valami, az xml-nél civilizáltabb formátumot, mert ezeket az anyagokat szemmel láthatóan online olvasásra hegyezték ki. Ha ez sikerül, akkor kb, a II. Stációról indulhatsz.

Ha ez nem megy, akkor ráállsz a kívánt anyagra, és letöltöd egy SAVE FRAME AS funkcióval. Ez egy xml lesz, de átnevezheted html-re, és onnantól GOTO III.Stáció. Kipolírozod, és Mobi Creatorral legenerálod.

Van ami sima ügy, pl. Nemes Nagy Ágnes versei. Ott csak a formázással kell mókolni.

Van ami rázósabb, Pl. Spiró Fogsága tele van lapszámokkal. De azt is lehet automatizálva takarítani.

Összefoglalva, egyesével kell csinálni. Egy konverzióra a vendégem vagy, ha megmondod mit szeretnél. (És nem csillagháború ;-), mint egy Kassák képvers.

Arturo 2010.11.02. 22:05:07

Kicsit megint kísérleteztem a prc-vel, hátha ez lesz a jövő a Kindle-dömping folyományaként. :)
Egy dolgot hiányolok a fenti leírásból, mégpedig az igazi tartalomjegyzéket. Persze, jó, hogy van egy olyan oldal a könyvben, amiről linkek vezetnek az egyes fejezetekhez, de ezt nem minden olvasón kényelmes használni. Kooben pl. nekem sokkal gyorsabb a "7" gombot megnyomni és (jobb esetben) a következő gombnyomással az adott fejezetre ugrani, mint ide-oda csalinkázni.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.11.03. 07:30:26

@Arturo: őőő, ezt most nem értem. IV. stáció, 4. pont. Ennél igazibb tartalomjegyzéket hogy csinálsz? Vágom, hogy pont a Kooben van komfortosabb tartalomjegyzék-megoldás, mondjuk az epubra, de hogyan csinálsz ilyet prc-ből?

Amúgy gyűlnek az update-ek a poszthoz, mondj te is egyet.

Arturo 2010.11.03. 08:17:20

@Dworkyll: Ha Mobipocket Readerben a "Contents" gombra kattintva látod a fejezetcímeket, akkor az "igazi" tartalomjegyzék:
img6.indafoto.hu/7/9/20649_77557109d117fbb70757f8f00d6ed5e4/9866635_095cf6efe7f0804cc174c1e20e1fe3da_m.jpg
Ha ilyen van a PRC-idben, akkor én értettem félre valamit. Ha nincs, csak szólj, és leírom, hogyan készül. :)
Koobe képernyőképet most sajnos nem tudok készíteni, de ott a tartalomjegyzék gomb (7) megnyomására előjönnek a fejezetcímek. Ha nyolcnál hosszabb a lista, akkor lapozgatni kell benne. A fejezetekre az 1-8 gombokkal lehet ugrani.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.11.03. 10:03:25

@Arturo: Megnyugodtam :-) A IV. stáció, 4. pont. majdnem pont ezt írja le. Mondjuk te mintha a _tartalom_ fölötti szintre emelnéd be a fejezethivatkozásokat, ez hogy jön össze?

Ami a Koobeban trükkös, hogy két ugrás után landolsz a tartalomjegyzékben, mert más Guide tipusú anyagokat is szeretne kijelezni, ami alapból nincs, utána viszont - a mobipocket desktophoz, winmohoz vagy kindle-hez hasonlóan - linkként jeleníti meg az elemeket, nem sorszámozva, mint az epubot. Ez tényleg lehetne jobb, de ez szerintem a Koobe standardizált mobi parsere és nem a file miatt ilyen.

AMi érdekes lehet, hogy hogyan lehetne NCX tipusú jegyzéket IS beszúrni, mert akkor pl. működnének a kindle D-padjének a gombjai is.

Arturo 2010.11.03. 10:34:14

@Dworkyll: Még ne nyugodj meg, mert ami ott le van írva, az nagyon nem olyan. :) Az csakegy oldal linkekkel teli. ;)
A Kooben épp a linkeket kényelmetlen használni, ezt lehet a Guide használatával kiküszöbölni. Amit leírtál, nem a parser miatt olyan, amilyen, hanem a file miatt.
Csak gyorsan leírom a lényeget, ha lesz tíz perced, próbáld ki. Szerintem Koobe parser alatt sokat hozzáad a használhatósághoz, kíváncsi vagyok, Kindle esetén mi lesz a hatása.
A Mobipocket Creator "Guide" menüjében kell egy új bejegyzést hozzáadni ("New guide item" gomb).
A következőket kell kitölteni:
- Title - ide írd a fejezetcímet (lehet más is, mint a könyvben)
- Type - "Text"-et szoktam választani a fejezetcímekhez
- Filename - a html fájl nevét kell beírni, vagy "Browse"-zal kiválasztani. Amikor a Creator importál egy html dokumentumot, a fejezetcímekhez hozzáad egy-egy könyvjelzőt. Ezeket például a fenti IV/4-ben készített tartalomjegyzékből tudod kinyerni. Ezt kell a html fájl neve után beírni, a következő formában: Teszt.html:#mbp_toc_0
Én persze nem egyenként hozom létre a bejegyzéseket, de azt leírni most nincs időm, meg kell hozzá egy segéd XLS táblázat is.
Ha van még kérdés, megpróbálok válaszolni. :)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.11.03. 10:58:32

@Arturo: Wow. Milyen verziójú creatort használsz? A 4.2 Build 35 nem ismer text típusú guide elementet. De érdekel a processz mindenképpen.

SaGa 2010.11.03. 14:29:26

@Arturo: Hogyan csinálsz több szintű tartalomjegyzéket ebben a formában? Amikor pl egy 15 fejezetből és ezen belül úgy 40-50 alfejezetből álló könyvnél csak a fejezetcímek, majd valamelyiket megnyitva a benne lévő alfejezetcímek jelennek meg...

Arturo 2010.11.03. 15:03:33

@Dworkyll: Ahogy SaGa írta, 41. Pedig szívesebben írtam volna be a végső választ. ;)

Arturo 2010.11.03. 15:12:40

@SaGa: A válasz rövid: sehogy. :(
Majdnem két éve foglalkoztam PRC-vel utoljára, de úgy rémlik, csak egy szintet sikerült kihozni belőle. Lehet persze trükközni, mondjuk a második szint címei elé teszünk néhány space-t, pontot, aláhúzást - kinek mi tetszik. Itt jön jól, hogy a Guide-ban nem kell ugyanannak a szövegnek szerepelni, mint a könyvben a fejezetcím.

Ignis_veneficus 2010.11.10. 21:29:26

van valami jo kis osszefoglalo, hogy a nagy HTML vilagbol mit eszik meg az mobipocket kreator, es mit mas konverter es mit tud ertelmezni a kindle3?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.11.10. 22:56:21

Keresd meg at Amazon Kindle Publishing Guidelines pdf-et és annak van egy Supported html tags című melléklete. Előtte meg részletesen végigvesz, hogy mit hogyan támogat.

És ez is érdekes lehet:
www.mobipocket.com/dev/article.asp?BaseFolder=prcgen&File=TagRef_OEB.htm

Ignis_veneficus 2010.11.10. 23:37:06

@Dworkyll: kosz.
Van valami Kindlegen is az amazon oldalon.
Nem akar valaki egy postot irni a kulonbozo konvertalo progikbol?
(mobipocket, kindlegen stb)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.11.10. 23:59:29

@Ignis_veneficus: Háát, figyelemfelhívót tudnék, de technikait kevésbé. Nem szeretem őket, ahogy a batch konverziót sem. Jobban fekszik a kézimunka a MPCreatorral.

A kindlegen két szempontból szopós, epubból úgy konvertál, hogy megőrzi a teljes forrásállományt fontostul (bazi nagy lesz), de nem tud az ncx-ből tartalomjegyzéket csinálni.

Ignis_veneficus 2010.11.11. 20:58:06

@Dworkyll: megneztem a "Publishing on Kindle: Guidelines for Publishers"-t..
egyedul a css support leirasa hianyzik, helyette pedig van utf-8 kodtabla amit kihagyhattak volna, vagy rakhattak volna egy kulon file-ba
Viszont talaltam egy ilyet:
Kindle Formatting: The Complete Guide
csak sajnos fizetos :(

csabcikácska 2010.11.19. 05:43:36

Sziasztok!

Használom azt a tisztító scriptet, illetve csak használnám...
2-3 könyv esetében teljesen jól működött, de most már a másodiknál hal meg.
Elindul, fut majd ugyanabba a könyvtárba, ahol van a szövegem, létrehoz egy tmp.tmp vagy tmp2.tmp fájlt és ennyi.
Az eredeti fájlt megnyitva pedig csak az első, borító utáni oldal van meg.
Valakinek valami ötlete?

A Mobipocket Creator-rel próbáltam már simán konvertálni az adott doc vagy pdf doksikat, de nagyon nem szépek. Ez meg így valamiért nem megy.

cs

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.11.19. 10:26:52

@csabcikácska: nézz bele a temp állományba, hogy meddif jutott. Utána nézd meg a forrást, hogy mi volt a szakadási pont előtt. Van, amit nem szeret a script, ilyen pl. a kézi lapdobás, a.k.a manial page break. Ezt szedd ki a forrásból, és futtasd újra. És lehet még egy pár hasonló csapda, a temp meg a forrás összevetéséből lehet kisütni, hogy mi akasztotta ki a tisztító scriptet. Ha valami trükköst látsz, azt próbáld kivágni, és aha lefut a script, akkor az volt a hunyó.

elminster 2010.11.19. 11:19:35

@csabcikácska: a szóban forgó szkript feltuningolt változata jvoq eredeti programocskájának. Csak jól felkészített Word DOC-ból készült HTML tisztítására jó. (PDF-et én nem konvertálnék Creatorral, először profi programmal kiszedném és Worddel megformáznám a szöveget!)

A szkript egy buta kis dolog, főleg a HTML Tidy-hoz képest (amit még mindig nem tudtam hasznos munkára fogni, bár nem is töröm magam...)
A szkript gyakorlatilag a törzsszövegből csak a <p> és <h#> sorokkal foglalkozik, az összes többit szimplán másolja. És itt vannak a problémák. A szimplán másolt sorok okozhatják azt, hogy egy-egy rutin végtelen ciklusba kerül. Ezt elkerülendő, javasolt a <p> és <h#> sorokon kívül mindent még a szkript futtatása előtt kézzel rendbetenni, hogy szép szabályos HTML kód legyen. (Például ne legyen egy <hr.. vagy <td.. sor kétsorba törve, a táblázatos rész legyen rendberakva stb.)

Általában egy jól felkészített egyszerű formázású DOC fájl nem tartalmaz a HTML-be fordítás után sem olyasmit, ami a szkriptet kiakasztaná. A bonyolult formázású DOC persze már másik eset...

csabcikácska 2010.11.19. 20:23:31

@elminster: @Dworkyll:
Köszönöm a válaszokat.
Rászánom a ma estémet, kell a rutin.

csabcikácska 2010.11.19. 21:21:34

Kiküszöböltem a hibákat, valóban csak az oldaltörés volt problémás.
Még egy dolog, ha már itt vagyok...
A már kész prc-ben általában nagyon szép sorkizárt szövegem van, de helyenként a sorok nem a lap szélén végződnek. Megnéztem egy-két ilyen helyet a html forrásban és nincs ott semmi az égvilágon, sortörés sem.
Mi történne, ha az egész dokumetumra ráküldenék egy sorkizárt stílust. Pl. html-ben: <p align="justify">

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.11.19. 23:25:54

@csabcikácska: ez egyrész pocsékolás lenne, mert nem hozná a kívánt eredményt, másrészt szembemennél az amazon ajánlásával, ne tegyél igazítási infót a te standard stílusodba neki.

Ez a "szelektív balrazárás" nem a publiból jön, hanem a vasból, ugyanaz a fájl mondjuk mobipocket platformon nem fog ilyet csinálni, mert az tud (többé kevésbé) elválasztani. A Kindle meg nem.

Ehelyett a kindle, ha túl levegős lenne a sor a sorkizárás miatt, a kérdéses sort (és nem az egész bekezdést) balra zárja. Kicsit fura, elismerem, de gyorsan meg lehet szokni.

Ha elég mélyre mennénk a konfigba, biztos ki lehetne iktatni, mint a széles margót, de a magyar nyelv tele van hosszú szavakkal.

eNeL 2010.11.24. 19:35:52

Basszus! Két napja szenvedek egy anyaggal, amiben keretes szövegek is vannak. Praktikusan ez egy egycellás táblázat.

Epubban már elértem, hogy látszódnak szépen (most az ADE-t hagyjuk, ott még véletlenül sem akkora a keret, mint kellene, hanem teljes oldalszélességű, viszont Azarditól kezdve Calibrén keresztül OK-s).

De prc-ben eltűnik minden keret. Mindegy, hogy Calibrében konvertálom, vagy Mobipocket Creatorba húzott html állományból készítem. Html-ben pedig jó.

Ötlet?

Ignis_veneficus 2010.11.24. 21:47:55

@eNeL: Tabla:
<table border="1'>
...
</table>
Es berantod a kindlegen-be

En csak a kindle-n neztem, ott jo.

eNeL 2010.11.25. 00:07:35

@Ignis_veneficus: Bár ilyen egyszerű lenne egy több sorba tördelt szöveggel egy cellán belül...

A másik gond, hogy normál esetben - mint Dwo tanácsolta volt - illene kipucolni a html fájlt. No a script ki is akad az első táblázat felső vonalának meghúzása után.

Hiába, no: az élet nem habostorta.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.11.25. 00:28:05

@eNeL: a kipucolt fileba kézzel rakd be a tábla html kódját. csak egy ötlet.

eNeL 2010.11.25. 16:43:43

@Dworkyll: Brrr! Kiszedtem az összes táblázat keretet (eltartott egy darabig). Mentés szűrt webben (MS Word).

A tisztító script megint kiakadt, ugyanannál a sornál :( Viszont az elkészült tmp fájlban ott van az egész :) Igaz: tele mindenféle őrült karakterekkel - fél nap csere funkció használat.

Kézileg a táblázatok bevitele. Mobipocket Creator kimenet: nincs keret, ugyanakkor a konverziónál belepiszkított a html fájlba.

Még egy kicsit küzdök, lehet, hogy a szintaxisban van valami kehe.

A KindleGennel is lehet címlapot, metaadatot betenni? Esetleg kipróbálom (az Amazon ezt ajánlja, de nem látom egyelőre a fent említett anyagok hogyan kerülnek be a kész anyagba).

eNeL 2010.11.25. 17:26:14

Na, volt szintaxis hiba (bár ettől még minden html megjelenítőben jól nézett ki a dolog - ennyit a szabvány szigorúságáról).

A KindleGen legenerálta a mobi fájlt, jelezte, hogy nincs címlap megadva; majd a végén kiírta: 1 figyelmeztetéssel befejezte a munkát.

Keretek meg vannak!! Igaz nincs középre igazítva (mint szerettem volna), hanem balra zárt a keret, viszont benne középen van a szöveg. Lehet ezt valahogyan középre tenni?

A megadott példa így nézett ki:
<table border="1" align=center>
<tr>
<td><p align="center"><i>OKBUR OÁZIS</i><br/>200 kilométer</p></td>
</tr>
</table>

eNeL 2010.11.25. 18:32:16

Addig políroztam, amíg a Creator is normális kimenetet adott :))

De a táblázat továbbra sem akar középre állni.

Ignis_veneficus 2010.11.25. 20:32:12

@eNeL: HTML forras:
En helybol a ODF XML-jebol indulnek el.
Tobb sor:
Kindle tudja, masban sajnos nem utazok
Tablazat kozepen:
Probald ki:
<center>
<table>...</table>
</center>

szakértőbb 2010.11.25. 21:56:25

@eNeL:
Ezt ugy ertsuk, hogy te Word-ben irsz HTML-kodot??????

aztan:
<table border="1" align=center> - itt a centert is idezojelbe, ha mar szabvanyosan akarod...
AZt, hogy egy HTML jo-e, ne IE (Internet Explorer)-ben nezd mar meg. Vannak HTML Validatorok a neten is. Pont az volt az Explorer egyik "szepsege", hogy a sz@r HTML kodot is siman megjeleniti, es Te meg azt hiszed, hogy az jo... Na, ilyen a felhasznalobarat bongeszo.

eNeL 2010.11.26. 00:20:08

@Ignis_veneficus: A több sor működik, az általad javasoltat (<center>) meg kipróbálom, de nem most (ma/holnap).

eNeL 2010.11.26. 00:28:53

@szakértőbb: Nem, dehogy. Wordben a meglevő rtf állományt polírozgatom makrókkal, azután elmentem szűrt web formátumban. Ez még tele van szeméttel (hála a Wordnek), ezért kell a Dwo által javasolt pucoló szkript.

Ez utóbbi is rendszeresen hagy egyéb szemetet, tehát azt még alakítgatni kell (Notepad++).

IE-t már régen nem használok :) A javítgatott állományt csak az eredmény gyors ellenőrzésére nyitom meg Firefox-al, vagy Worddel (a 2003-as megnyit htm fájlt).

Ha szabvány, legyen szabvány: teszek idézőjelet :))

SaGa 2010.11.26. 13:29:51

@eNeL: A táblázatot tedd egy div-be, amit középre igazítasz.
<div align="center">
<table style="border: 1px solid;">

<tr align="center">
<th colspan="2" align="center">A hét napjai</th>
</tr>

</table>
</div>

eNeL 2010.11.26. 23:43:37

@SaGa: Most jutottam odáig, hogy benéztem a blogra :) Kb. abban az időben, amikor írtál, éppen ehhez tökéletesen hasonló megoldást ellenőriztem. A működő változatom:

<div align="center">

<table border="1">
<tr>
<td><p align="center"><i>OKBUR OÁZIS</i><br/>200 kilométer</p></td>
</tr>
</table>

</div>

Egyébként a korábban javasolt <center> is működik, de a div-es változat inkább szabvány közeli.

Persze, még lehet cifrázni paddinggal, meg egyebekkel (pl. a Te solid-od és pixeled), de a lényeg, hogy így már működik a dolog :))

elminster 2010.11.27. 10:58:47

@eNeL: Na most untam meg a szerencsétlenkedésedet.
Két módon lehet a mobiban keretet készíteni:
- táblázattal
- div blokkal

Sajnos, ahogy ellenőriztem, a kindle nem képes a többcellás táblázat celláit külön keretezni (esetleg az egészet igen), pedig egy ilyen megoldás a Mobipocket Reader-ekben kiváló eredményt ad:

<table width="100%">
<tr>
<td width="10%"></td>
<td width="80%" border="1">Ez itt a hasznos szöveg helye</td>
<td width="10%"></td>
</tr>
</table>

A másik lehetőség az, hogy már eleve a <div> elemnek adsz keretet! Nem kell bele az a táblázat, bőven elég ez:

<div style="border:solid windowtext .5pt; padding: 4.0pt 4.0pt 4.0pt 4.0pt"><center>Ez itt a hasznos szöveg helye</center></div>

Ez margótól-margóig keretez, működik Mobipocketen és Kindle-n is. Hátránya, hogy a teljes szélességű keret rondán néz ki a Rejtő könyvek táblafeliratainál.

Én azt javasolnám, hogy használd a százalékos táblázat megoldást a középső cella keretezésével, az Mobipocketen kiváló képet ad, a Kindle meg le van sz...va, ott keret nélkül lesz középen a felirat. (Esetleg, hogy látszódjon a felirat jellege, még állíts be rá egy monospace paramétert!)

elminster 2010.11.27. 11:46:38

Hoppá!
Módosítok. A stílusozott div sem rajzol keretet Kindle-n. Most megint próbáltam. (Fel nem foghatom, hogy mit csináltam pontosan a korábbi próbánál, mert akkor emlékeim szerint volt keret.)

Akkor Kindle esetén annak ellenére is csak a center-ek közé zárt egycellás táblázat rajzol keretet, hogy az általam ismertetett két módszer a Mobipocketen kiváló eredményt ad.

eNeL 2010.11.27. 23:34:51

@elminster: A százalékokkal az a bajom, hogy állandósítja a táblázat szélességét, függetlenül attól, egy szó, vagy több mondat is kerül bele.

A változatom - igaz csak Kindle for PC-n próbáltam - viszont a sor hosszától függően, "automatikusan" beáll, nem kell variálni a szélességgel.

Wierra 2010.12.08. 19:26:28

II. Stáció - sallangtalanítás rész nem túl evidens...Mit kell megnyitni és mit hogyan?!
(Nem vagyok analfabéta, de programozó sem :-S)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.12.09. 08:20:49

@Wierra: NO akkor mégegyszer. A sallangtalanításhoz két dolog kell. A wordből htmlként elmentett anyagod, amiből mentés előtt kitakarítod a kézi lapdobásokat. Mellé másolod a posztból letöltött scriptet (a kiterjesztése vbs, a txt a blogmotor miatt van hozzáadva). Aztán nyitsz egy explorer ablakot, amiben a a htmlt megfogod és ráhúzod a vbs-re. És kész. Lesz egy CLEAN_ kezdetű letisztított html-ed a további lépésekhez. Ha valami gubanc volt a forrás html-ben, ami miatt nem tudott a script végigfutni, nézd meg a tmp-t, hogy hol akadt el, és ott módosítsd a forrás-htmlt.

Wierra 2010.12.09. 10:01:10

@Dworkyll: Megvan a hiba, az explorer alatt Te az Intézőt én meg a Inet Explorert értettem. Így már működik, köszi!

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.12.09. 12:23:51

@Wierra: hacsak úgy nem :-)) Mi az az IExplorer? :-))))) Chrome vagy FF (aminek van amúgy epub pluginja).

gh14 2010.12.09. 13:04:32

Egyébként miért van szükség a sallangtalanításra?

Word szürt html export-ból a MobiPocket Creator teljesen jó prc-t készít; a behúzások a word-ben beállítottak, a sorugrás csak ott van, ahol a wordben is, toc-ot a word stílusaiból létre lehet hozni, lapdobások a word-ben beállítottak.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.12.09. 13:14:13

@guti.haz14: az őskorban még kellett, aztán így maradtam :-))

eNeL 2010.12.09. 14:05:52

@guti.haz14: Mert mi maximalisták vagyunk :))

Természetesen, ha a dolog működik, használd így. De ha belenézel a szűrt html-be, hát... Példának okáért csaknem az összes alap betűtípust megtalálod benne, teljesen feleslegesen; no meg tele van egyéb felesleges sallangokkal (stílusok, belezdésvariációk stb.) van tele.

Wierra 2010.12.09. 15:09:22

No, sikerült végre tartalomjegyzékes produktumot generálni.
Az mitől lehet, hogy a kidzsuvázott html-ben előfordulnak elválasztások, amik a szerkesztésben és a kész PRC-ben is látszanak...?!

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.12.09. 15:18:14

@Wierra: Kétfajta kötőjel van, nagyjából ugyanúgy látszanak. Az egyik a normál kötőjel, erre szükség van a kötőjeles szerkezetekhez. A másik a "feltételes" kötőjel, optional hyphen, ezeket tanácsos a forrásból, még doc korában kigyepálni. Mert a prc mindet ki fogja rakni, ha kell, ha nem. Rá tudsz keresni a word special karaktereivel.

@guti.haz14: A sallanangtalanított html-ben ezerszer könnyebb a korrekció, ha olvasáskor rájössz, hogy valamit igazítanál. A sallangtalanítás minimális erőfeszítés, de nagyon hasznos eredménnyel jár.

eNeL 2010.12.09. 16:33:19

@Dworkyll: És elérhető rá makró is :) De készíteni sem ördöngösség.

gh14 2010.12.09. 16:38:11

@Dworkyll: És a sallangtalanított html-ből készített prc és a sallangtalanítás nélküli html-ből készített prc között az olvasón látni a különbséget? Aki nem tudja miből készült meg tudja állapítani?

eNeL 2010.12.09. 16:51:35

@guti.haz14: Felesleges munka megtakarítása céljából nem próbáltam nagyon ki, de _elvileg_ nem lesz nagy különbség.

Viszont annak az esélye, hogy figyelmeztetések hegye jelenik meg a MC kimenetén jelentősen megnő. Ami azt jelenti: a végeredményben is látható lesz/lehet a hiba. A különböző olvasók gyakran különböző módon adják vissza a tartalmat, ezért nem mindegy, mennyire tiszta a forrás.

Volt olyan fájlom, aminek a kimenete 0 zéró lett egy, a Notepad++-ban sem látható speciális karakter miatt. Az ilyenek kiszűrésére is jó a sallangtalanítás: sokkal könnyebb megtalálni a hibát.

Ha működik az olvasón a fájl, nem feltétlenül látni a különbséget (hacsak nem látott már valaki egy korrekten elkészítettet korábban ugyanabból a műből). Hogy miből készült a fájl, az csak akkor látszik, ha valaki belemegy és megtekinti. Ezt meg nem mindenki teszi meg.

Volt már itt szó bizonyos virslikről (mármint: nem feltétlenül jó tudni, hogyan és miből készül)...

Wierra 2010.12.09. 16:58:30

Iniciálét (jpeg alapú) be lehet gyúrni valahogy PRC-be?

Wierra 2010.12.09. 17:03:17

@Wierra: Ez is megoldva, csak elérési út probléma volt. Van ellenben gond; iniciálé van, de körbefutás nincs :-S

eNeL 2010.12.09. 17:14:03

@Wierra: Lehet tévedek, de szerintem nem is fog működni. Az Amazon Kindle pl. csak a legalapvetőbb html funkciókat támogatja. Ebből következően elhelyezhetsz képet egy sorba, elhelyezhetsz akár egy üres sor közepébe is, de körbefolyatás nem fog működni.

Ebben szerintem Dwo erősíthet, vagy cáfolhat meg engem. A Kindle ajánlás egyébként ilyen esetekre (mármint kép, főleg táblázat, vagy az ilyen iniciálé) GIF-et ajánl.

Ignis_veneficus 2010.12.09. 17:14:17

@Wierra: Probalj adott betut nagyitani, lehet, hogy segit. A kep azert sem jo, mert nem lehet a szora keresni.

SaGa 2010.12.10. 07:17:31

@Wierra: Bele, én már csináltam ilyet, de nem az igazi. Nem tudod "besüllyeszteni" a szövegbe, csak az első sor aljával egy szintbe. Vagy ha lejjebb tolod, a következő sor mindenképp vele együtt megy lejjebb, így nagy lesz a sortáv.

Ha iniciálés a szöveg, akkor inkább a K3 méretű (256ptx340pt) oldalra igazított pdf-et javallom, 12-es betűmérettel. Ez jól olvasható, sem nem túl nagy, se nem túl kicsi a szöveg és az oldalakon is van elegendő belőle, nem kell túl gyakran lapozni.
Vigyázat, ha K3-on olvasod, akkor az oldal köré kell egy halványszürke (vagy bármi más, fehértől eltérő) keret, mert ha az nincs, a nem teljesen teleírt oldalakkal csúf trükköket csinál a Kindle...

SaGa 2010.12.10. 07:18:57

@Ignis_veneficus: A betű nagyítás (big) működik, de ott is csak úgy, hogy a sorból kiemelkedik a nagyobb betű, körbefolyatni nem lehet. A floatot nem ismeri a mobi formátum.

Wierra 2010.12.10. 12:07:56

Végül hagytam az iniciálé képeket és a nagybetűsítést sem erőltettem, így legalább jó lett. Mindenkinek köszönöm a segítséget!!!

phaid 2010.12.10. 19:59:23

A MEK-ről letöltött Tóth Árpád összes versei az Amazon konvertálásában olvasható, de szerintem szebb formába is lehetne önteni. Van valakinek már bevált technikája ilyen verses kötetek konvertálásában?

Ignis_veneficus 2010.12.10. 20:34:05

@phaid: ha gondolod, es tudsz varni vele mondjuk januarig, akkor megkapod tolem, mert nekem megvan, csak meg mobiba kell konvertalni.
Addig szeretnem kidolgozni a mobi konvertalomat.

Ignis_veneficus 2010.12.10. 20:39:28

@SaGa: A float-os iniciale mindig gazos. amivel probalkoznek, az a <big><big><big>... es ha tudna baseline-shift -et, akkor azzal popecul meg lehetne csinalni. A kulonallo azert gazos, mert nem tudsz ra keresni.

phaid 2010.12.10. 20:52:42

@Ignis_veneficus: köszönöm és elfogadom :-). Ezek szerint neked már van egy bevált eljárásod a html fájl(ok)ra verseskötetek esetén? Megosztanál egy-két tippet?
Saját mobi konvertert írsz? A MobiPocket nem elégíti ki az igényeidet?

Ignis_veneficus 2010.12.10. 22:49:43

@phaid: XML-bol dolgozok. igy HTML tippet nem tudok adni.
A konverter XML->mobi utvonalon dolgozik, es nem a mobipocket-et hasznalom hanem a kindlegen-t (mukodik parancssorbol)

drfaktor 2010.12.11. 16:52:46

@Dworkyll:
ahogy néztem, azért nem kis meló egy hosszabb iromány (mondjuk regény) rendes konvertálása. Ha igénytelen szeretnék maradni egy egyszerű konvertálással próbálkozva komolyabb elő/utómunka nélkül, akkor azt hogyan tehetem meg? MEK-es állomány -> prc

Köszönettel

elminster 2010.12.11. 18:29:08

@drfaktor: Nem olyan bonyolult a dolog, csak a net sötétebbik felén található szövegek minősége általában olyan is, úgyhogy nem árt nekik egy alaposabb felkészítés. A műveletsor nagyobbik része egy letisztult szövegváltozat előkészítő munkáiból áll (a másik fele meg a "menő vagyok a html-piszkálásban" kivagyiság). Esetedben a MEK html-ek használatával a szövegfelkésztéstől megszabadulsz, a html-piszkálásos csicsázás pedig tényleg csak tortadíszítés, nyugodtan el lehet hagyni.

Tennivalók:
1. MEK html változat beszerez
2. Mobipocket Creator html beimportál
3. Csinosít kicsit borítóval metadatokkal
(3a. ha kell, szótárprogrammal menüket lefordít, nem egy Shakespeare-összes...)
4. nyom neki "Build" és kész a PRC változat.

Megjegyzem, a Creator által gyártott publikációs mappában megtalálod az anyagodból készült OPF állományt, az tulajdonképpen tartalmaz minden beállítást, ha KINDLEGEN-nel eteted meg, akkor is kütyüretölthető változatot kapsz.

Atyaman 2010.12.11. 18:50:43

@drfaktor: @elminster: És még pár hasznos tudnivaló a Mobipocket Creator-höz, ami első használatnál nem biztos, hogy feltűnik:

A beimportált fájlból a Creator általt létrehozott html-t bizonyos esetekben újra kell menteni UTF-8 vagy Unicode kódolással, különben az ő, ű betűk helyet Q-kat fogsz látni.
A létrejött html fájlra rákattintasz, program bal felső sarkában edit with html editor. Ha mást nem állítasz rá, akkor notepad-ben (jegyzettömb) fogja megnyitni kattints a save as-re (mentés másként). Típusa ne txt legyen hanem bármi (*.*) és kódolásnak az ANSI helyett UTF-8 vagy Unicode választandó. Majd mentés (igen felülírod a régi fájlt)

Ha pedig csinosítod borítóval, metaadatokkal, tartalomjegyzékkel, akkor minden esetben nyomni kell neki egy update-et. Ez a gomb néha nem fog alapból látszani, le kell hozzá húzni a görgetősávot, de ha nem nyomod meg értelemszerűen elveszíti a változtatásokat.

Aztán ha megvan, a kész prc fájlt ellenőrizeted Mobipocket Readerrel vagy még inkább kindle previewerrel. Az majdnem olyan mint a kindle (annyi a különbség, hogy a 3. generációs kindle-ökben a felső információs sáv az első lapozás után eltűnik, így nagyobbá válig az olvasási felület kb. 1 sorral).

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.12.11. 20:00:03

@drfaktor: A ráfordított idő és a minőség egyenesen arányos. Vannak mégy gyorsabb (és meg kevésbé jó minőséget adó) módszerek. Pl. elküldöd a MEK anyagot ahogy van, a Kindle-d email címérése. Vagy nyomsz egy egygombos importot a MObipocket _desktop_ban, esetleg a Calibrében. SZerintem nem lesz szép, de olvasni lehet.

De az igényes munka sem csillagháború, piszok hamar bele lehet lendülni ;-)

zsotykai 2010.12.14. 16:41:01

Sziasztok!

Help I need somebody (or something): www.mobileread.com/forums/showthread.php?t=110646

A lényeg, hogy szeretnék amolyan igazi újságot szeretnék konvertálni. Cikkeket olyan formátumba összerakni, mint az Instapaper teszi (fejléc van, meg lábléc, és persze a "lap" alján tartalomjegyzék. De sehol nem találok dokumentációt róla.

Előre is köszönet...

phaid 2010.12.14. 17:20:43

Én most "Tóth Árpád összes verse" köteten kísérletezem, hogy a KindleGen megegye, de sajnos elakadtam. Látszólag minden meg van, ncx, opf, toc, jpeg a fedőlapnak és maga a html is, elvileg jók bennük a hivatkozások de a Kindle Previewer mégis azt mondja, hogy nincsenek meg ezek a file-ok.
Mit ronthatok el?

Tipp ha esetleg valaki nem ismerné: nekem a Notepad++ program nagyon bejön a html és XML szerkesztésekor.

phaid 2010.12.14. 19:18:10

Rájöttem, nem a html file-t kellett megadni a KindleGen bemenetének hanem az .opf-et. Logikus. :-)

csabcikácska 2010.12.16. 08:35:43

Megőrülök :)
Kérem a segítségeteket megint. Már megint karakterkódolási gondom van.
A .doc-omat htmlben elmentem, megnézem notepaddal is, hogy minden ok, mielőtt a scriptet ráküldöm. Minden ok, UTF-8-cal mentem. Jön a script és miután lefut már nincs ékezetes karakterem, megnézem és Unicode a kódolás. Innentől meg már hiába állítom vissza UTF-8-ra, nem lesz ékezetem, csak káosz.

Mit rontok el megint?

eNeL 2010.12.16. 10:45:57

@csabcikácska: Szerintem semmit nem csinálsz rosszul: ilyen a script. A dolog mindenképpen ilyen lesz, hiába állítod be a Word beállításainál, hogy a webes mentés UTF-8 legyen - akkor is ilyen a kimenet.

Amúgy a letöltött script sem úgy működik, mint azt Dwo leírta, mert a feldolgozott fájl nem kap CLEAN előtagot. Ehhez meg kell nyitnod mondjuk Notepad++-al a scriptet, és a "Const html_overw = True" változót "False"-ra kell állítanod.

Pont ilyenek miatt hanyagolom egyelőre ezt a scriptet. Nem próbáltam ki, de próba cseresznye alapon nézd meg, ha a "Const unicode_html = True" változót "False"-ra állítod, mi lesz... Főleg prc, vagy epub-ra alakítás után.

csabcikácska 2010.12.16. 10:49:00

@eNeL: Kipróbáltam a 'Const unicode_html = False' opciót is, de így sem jó.

A vicc az, hogy csináltam vagy 10 könyvet a fent leírtak alapján és semmi gond nem volt a karakterkódolással. Arra gondoltam ezzel a fájllal van a hiba, de kipróbáltam 3 másik doksit is, es egyik se lett jó.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.12.16. 10:57:05

@csabcikácska: nem váltottál véletenül területi beállítást (regional settings) közben?

A scriptet valóban lehet "kapcsolgatni", a kapcsolók ott vannak szépen az elején.

eNeL 2010.12.16. 11:01:24

@csabcikácska: Ettől jobbat mondok: a Wordben a Beállításoknál a webes mentésre állíts "Közép-európai Windows", vagy "Közép-európai ISO"-t és a script lefutása után elvileg jónak kell lennie a kimenetnek.

Ha a címben voltak ékezetes karakterek, azok jó eséllyel baromi rondák lesznek; tehát a kimenet head-jában a <title> tagok között ellenőrizd le a karaktereket. A törzsszöveg elvileg jó lesz (de a végterméket kell ellenőrizni, nem a script kimenetét, ha biztosra akarsz menni).

csabcikácska 2010.12.16. 11:02:02

@Dworkyll: Semmi ilyesmi.
A kapcsolokkal meg mar jatszottam eleget.

csabcikácska 2010.12.16. 11:03:53

@eNeL: Ha a script kimenetelében, vagyis a 'tiszta' htmlben nem jó a karakterkódolás, akkor aztán teljesen felesleges még megnyitni is a Mobipocket creatort, nem lesz jó.

eNeL 2010.12.16. 11:16:54

@csabcikácska: Ebben igazad van, de már láttam olyat, hogy a kötőjel, vagy az >> << idézőjelek furán néztek ki átkódolás után, a végeredményben meg valamiért teljesen jól nézett ki...

Unalmas is lenne az élet, ha mindig minden flottul menne :)

csabcikácska 2010.12.16. 11:19:05

Nem találom, hogy Wordben hogy lehet beállítani a karakterkódolást, eddig csak notepadban csináltam, az meg nem nyitja meg a .docot rendesen. Hol próbálkozzak wordben? Fél óra guglizás után sem jöttem rá.

csabcikácska 2010.12.16. 11:31:10

@eNeL: Na végül meglett. Ez sem segített, mármint a
"Közép-európai Windows", vagy "Közép-európai ISO"
kipróbáltam mind a kettőt.

elminster 2010.12.16. 12:14:29

@csabcikácska: A szkript csakis "windows-1250" kódolású HTML fájlt fogad el bemenetként. Ez nem is lenne probléma, mivel a magyar Word szövegszerkesztők az ennek a kódolásnak megfelelő "Közép-európai Windows" kódlappal mentik az anyagaikat alapértelmezésben.

Ha valaki elállítja a Word kódolását, akkor a kimeneti DOC vagy HTML eleve hibás kódolású lesz a szkript számára. A szkript futtatása előtt egy textes szövegszerkesztővel vissza kellene állítani a HTML-fájl kódolását "ANSI"-ra és a fálj fejlécébe vissza kell írni a "windows-1250" jelzést.
A problémát az jelenti, hogy általában a unicode készletek a bővebbek, így a visszakódolás ANSI-ra karaktervesztéssel járhat.

Érdemesebb a szkript használatának szándéka esetén eleve a Word-öt visszaállítani a "Közép-európai Windows" kódlapra. Ezt a "Mentés másként" párbeszédablakából kiindulva megtalálható "Webes beállítások" részen lehet megtenni. Ezután a DOC fájl és a HTML fájl kimenet is ANSI kódolású lesz, a szkript használható.

Alternatív lehetőség, hogy aki konyít valamit a VB-hez, keresse meg a kódban a nyersanyag megnyitását, és állítsa át a függvényben a kódolást. De figyelem! A VB csak és kizárólag ANSI-t és UTF-16-ot tud fájlkezelés során írni-olvasni. Ebből következőleg az UTF-8 mindenképpen almás a szkript használatakor.

Alternatív-alternatív lehetőség: a szkript helyett nyugodtan lehet használni a HTML-Tidy programot is, már ha a delikvens képes helyes beállításokkal hasznos munkára fogni.

eNeL 2010.12.16. 12:18:50

@csabcikácska: Furcsa, mert mielőtt írtam, kipróbáltam mindkét változatot a scripttel.

Én egyébként (Word2003) a Beállítások -> Általános fülön a "Weblapok mentése mindig az alapértelmezett kódolással"-nál kivettem a pipát; az így aktívvá vált kódlap választásnál állítottam az említetteket (a Közép-európai Windows elvileg a jobb, mert az a Windows-1250-es kódlap, amire a script igazában készült).

Ha így sem megy, fogalmam sincs honnan származhat a fájl...

eNeL 2010.12.16. 12:23:20

@csabcikácska: Bocsi. Helyesen az útvonal: Beállítások -> Általános fül, Webes beállítások gomb; utána, amit leírtam.

csabcikácska 2010.12.16. 13:06:07

@eNeL: Na alakul a dolog. Közép európai ISO-val már csak az 'ő' és 'ű' betűk nem jók.
Windows-1250 -t pedig nem próbáltam, elnéztem. De a Word-ben nem is találtam ilyet, pedig sok féle van. Windowsom és Office-om(2007) is angol. Hogy tudom hozzáaadni ezt a karaktertáblát?

eNeL 2010.12.16. 14:15:22

@csabcikácska: Hát, azt így most rögtön nem vágom...

De mi van akkor, ha felraksz egy Open Office-t és abban mented el? Ha nem akarsz telepíteni ilyet, akkor létezik az Ooo-nak pendrájvra felrakható változata is, amit ha arról futtatsz nem szemeteli össze a rendszeredet. Igaz annak a kimenete meg nem biztos, hogy jó a scriptnek :(

Esetleg másik workaround (de szintén Ooo): elmented a doksit odt formátumban. Ezután az odt kiterjesztést átnevezed zip-re, majd megnyitod, és kiveszed belőle a content.xml-t. Ezzel meg eteted a Creatort. Ez csak egy ötlet, nem próbáltam még ki.

Na, egyre bonyolultabb dolgokat találok ki :(

elminster 2010.12.16. 14:41:12

@csabcikácska: Látom, van még egy kis félreértés.

A Word "Közép-európai windows" kódolása azonosan egyenlő a HTML "windows-1250" kódolással és a Notepad "ANSI" kódolással.

Na jó, lehet, hogy csak tökéletesen csereszabatosak...

Ami a lényeg: "Közép-európai windows" kódolású DOC-ból "windows-1250" kódolású HTML készül (pl. Creatorral), amit Jegyzettőmbbel megnyitva "ANSI" kódolásnak ismer fel.

elminster 2010.12.16. 14:50:12

@eNeL: Nem olyan bonyolult ez, mint az agysebészet.
Office 2007-ben van egy formátum, a "Weblap szűrt", ami nagyjából olyan tiszta kódot ad, mint a Creator DOC importja.
Végig kell próbálni az összes Word karakterkódolást a szűrt HTML kimeneti fájlon. Mindegyikbe Jegyzettömbbel belenézni, hogy a fejlécben a <meta... sor milyen kódlapot tartalmaz, majd a "Mentés másként"-nél megnézni, hogy a szöveg valós kódolása milyen. Előbb-utóbb kiderül, hogy melyik Word karakterkódolás eredményes "windows-1250"-es kódlapú HTML fájlt.

csabcikácska problémájának az oka egyébként az angol szövegszerkesztő lehet.

csabcikácska 2010.12.16. 14:56:18

@elminster: Ez azért sok időbe kerülne, tekintve, hogy van úgy 40-50 féle kódolási variáció a listában.

És igen valószínűleg az angol word a gond, csak akkor azt nem értem, hogy ugyanezen a gépen, ugyanezzel a programmal miért sikerült 1-2 hete minden könyv jól elsőre.

csabcikácska 2010.12.17. 07:52:30

@elminster: Helyzetjelentés, remélem még nem untok nagyon.
Ma reggel is tettem egy próbát, és mentettem a Wordben egy html-t és persze jobb híján közép európai karakterkészlet volt beállítva.
Megnéztem a htmlben és
<meta http-equiv=Content-Type content="text/html; charset=windows-1250">.
Mondom akkor ez remek lesz.
A script után az 'ő'-kből 'õ' és az 'ű'-kből 'û' lett.

csabcikácska 2010.12.17. 09:01:24

@csabcikácska: ok, find & replace-szel megoldottam hamar.

Akkor még egy. PDF-ből doc-ot... találtam online konvertáló oldalakat, és szép docokat kapok, de tele van page és section brake-ekkel és ha ezeket kiszedem minden összeomlik. Nem is beszélve az oldalszámokról, amikre nincs szükség.
Ismer valaki olyan progit, amivel ezt gyönyörűségesen meg lehet csinálni?

elminster 2010.12.17. 10:32:20

@csabcikácska: "A script után az 'ő'-kből 'õ' és az 'ű'-kből 'û' lett."

Van egy olyan szörnyű gyanúm, hogy előtte is így volt, csak te egy olyan betűtípust használtál, amin eleve le vannak cserélve kalapos-hullámos karakterképek magyar ékezetesre. Ugyanis a kód az kód, egyértelmű hozzárendelés van a windows-1250 kódlap ő-betűje (kódja) és az UTF-16 kódlap ő-betűje (kódja) között, és ugyanígy egyértelmű hozzárendelés van a windows-1250 kódlap õ-betűje (kódja) és az UTF-16 kódlap õ-betűje (kódja) között. A VisualBasic nem olyan okos, hogy a karakterkép hasonlósága szerint csereberéljen kódlap váltáskor, az csak a karakterkód összerendelések alapján dolgozik. Ebből pedig az következik, hogy már a szkript előtt is kód szerint õ-betűjeid voltak a szövegben, csak ezt valamiért elrejtette előled a rendszer.

A PDF visszakonvertálásra pedig csakis profi programokat szabad használni, vagy pedig hagyni kell a fenébe a dolgot. (Harmadik lehetőség: megelégedni az igénytelen textes kimentéssel...)
A profi programok egyrészt az Adobe Acrobat fizetős programja, másrészt az Abby Finereader szintén fizetős OCR-programja. Megtalálhatók a warez neten, de nem bátorítalak az ilyen formában beszerzésre, a kockázatot neked kell mérlegelned, hogy néhány PDF konvertálására megéri-e törvényt szegni? (Mégha valószínűleg senki sem fog érte deresre húzni.)

meoindil 2010.12.17. 10:33:08

@csabcikácska: Abbyy PDF Transformer esetleg?

csabcikácska 2010.12.17. 10:35:17

@elminster: Konkrétan annyi PDF-em van, hogy lehet érdemes megvenni, na persze az ártól függ.
Köszönöm a tippeket.
@meoindil: Ezt is.

meoindil 2010.12.17. 10:42:42

@csabcikácska: Még meg lehet próbálni az OpenOffice/LibreOffice + PDF Import extension összeállítást, de nem tudom mennyire használható. Viszont garantáltan jogtiszta megoldás.
Én nem igazán szoktam pdf-ből konvertálni, vagy megelégszem azzal amit a MobiPocket Creator nyujt, persze az NEM igényes prc!.

csabcikácska 2010.12.17. 10:50:40

@meoindil: Az OpenOffice-os dolog a script miatt lenne gázos, nem igazán van időm ennyit játszani.
Mennyire lesz csúnya a prc ha a pdf-et simán beletolom a MobiPocket-be? Még nem próbáltam.

A baj, hogy a könyvforrásom jelentős százalékban pdf-fel lát el. 70% doc/rtf és a fennmaradó 30% pdf, és ez nagy mennyiség.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.12.17. 10:58:41

@csabcikácska: "Mennyire lesz csúnya a prc ha a pdf-et simán beletolom a MobiPocket-be? Még nem próbáltam."

Próbáld meg, szerintem nagyon. Itt jön elő ugyanis, hogy a pdf lapképet konzervál, az összes lap- és sortörés meg fog érkezni a prc-be, leginkább ott, ahol nem kéne. Ezért fából vaskarika (most még) a pdf reflow, mert elvileg ugyan el lehetne tárolni, hogy mely töréseket ne vegyen figyelembe a rendszer a reflow-nál, de normális reflow-t még nem láttam.

Arturo 2010.12.17. 11:54:08

@Dworkyll: Szerintem még te sem próbáltad. :)
Én egyszer-kétszer konvertáltam már pdf-et Mobipockettel, és jobb volt, mint az Acrobat. Az oldalszámokat és a fejlécet eltüntette, valamint a felesleges sortörések nagy részét is. Így is maradt persze javítanivaló, de csak az eredeti sortörések 10-20 százaléka.
Nekem nem is a PRC kellett, az átmeneti könyvtárban lévő html-t használtam.
Esetleg itt is előjön az, hogy az a régi verziójú Creator, amit használsz, még ilyen téren sem túl szofisztikált?

eNeL 2010.12.17. 12:48:31

@Arturo: "régi verziójú Creator" - valamiről lemaradtam? Nem a 4.2 Build 41 a legutolsó?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.12.17. 13:54:54

@Arturo: Próbáltam, igaz nem tegnap, és nulla másodperc alatt feladtam, ez tény. KOmoly bajaim voltak vele, tán a formázásokat se hozta át...

Viszont. Volt itt ez a szál: ekonyvolvaso.blog.hu/2009/10/04/radar_4/fullcommentlist/1#c11910064

amit áthoznék ide. Nem olvas bennünket véletlenül valami XSLT guru? Ez a Mobi toc-to-ncx dolog érdekel, amiben az az érdekes, hogy mind a két állomány tulajdonképpen xml, ergo az XSLT működhetne. Nem ugrik rá valaki?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.12.17. 13:55:55

@eNeL: Viszont a régi motorosok, (pl én :-) a Build 35-öt használjuk ;-)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.12.18. 20:51:46

@eNeL: Nabakker. Átálltam én is a build 41-re és másképp parsolja a width attribútumot. A build 35ben még volt egy default soremelés, na az elmúlt. Az összes újrabuildeléskor lehet kézimunkázni.

elminster 2010.12.18. 21:23:06

@Dworkyll:
"A build 35ben még volt egy default soremelés, na az elmúlt."

Egyrészt az a height attribútum, másrészt gondolom Kindle-n ellenőrizted.
Nem a build 41 tüntette el a soremelést, hanem a Kindle.
Egy p {margin-top: 6px;} stílussal azon is vissza lehet csalogatni a default soremelést.

A build 41-el egyetlen dologra kell figyelni: csak unicode bemenetet kezel (UTF-8 vagy 16). Ha ANSI bemenetet etetünk meg vele, akkor gyakorlatilag minden az alap latin karakterek felett szerteszét cserélődik. (Nem véletlen került bele a szkriptbe a kódlap váltás.)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.12.18. 21:38:55

@elminster: Jaja. Tök vicces, hogy a MPDesktop, és a Kindle for PC használja ezt az implicit height-t, a Kindle Previewer és a Kindle maga meg nem.

Kösz a stílustippet, egy fél órát variáltam, hogy mennyi legyen az annyi a soremeléshez, amit így kézzel kell definiálni. Előbb az em móddal próbálkoztam, de abból nem érti a törteket. A height="12" szép eredményt adott. Viszont ezt észben kell tartani a régi publik frissítésekor (most ezt csinálom, Kindle-re frissítem a régi klasszikusokat...)

elminster 2010.12.19. 00:28:34

@Dworkyll: Az is tök "vicces", hogy a Kindle3 nem képes megjeleníteni a PRC-be rakott GIF képet. Ilyenkor nyílik ki a bicska az ember zsebében...

Eredetileg a mobi szabvány csak GIF-el működött, aztán jött csak a JPG-kezelés. Erre valaki elbarmolta a Kindle3 parserében a GIF képeket kitömörítő algoritmust, pedig még régről milliónyi GIF-es PRC-je van az embernek...

Dworkyll · http://ekonyvolvaso.blog.hu/ 2010.12.19. 00:36:48

@elminster: Ebben biztos vagy? Még a 35-el buildelve éppen azt vettem észre, hogy a nagyobb jpg-ket átdobja gifbe, és azzal simán működik. Legalábbis a borító, belső gifekkel nem sok dolgom van.

elminster 2010.12.19. 11:48:41

@Dworkyll: Biztos. Kettő Kindle-n ellenőriztük.

A borító egy külön állatfaj, a belső GIF képek GIF-ként kerülnek a PRC-be. A Kindle viszont nem tudja megjeleníteni.

Tettem egy próbát a Kindlegen-en, az eredmény detto: Mobipocketen van kép, Kindle-n csak szemét a kép helyén.

Tettem egy próbát az e-mailes automata konvertálással, beküldtem egy GIF-et tartalmazó DOC fájlt, visszajött egy megfelelő képet tartalmazó PRC. Csakhogy már nem tiszta olvasható 16 színű térkép-GIF volt benne, hanem egy átméretezett, olvashatatlan, túltömörített kásás JPG.

Ennyit erről.

elminster 2010.12.19. 11:49:47

Javítok:
"visszajött egy megfelelő képet tartalmazó AZW."

elminster 2010.12.19. 18:10:51

@Ignis_veneficus: Sajnos JPG-re konvertálva kerül be a PRC-be (AZW-be). Nagyon jól látszott, hogy a tiszta 4-8-16 szürkeárnyalatos PNG-ből tipikus JPG-szemcsézett kép készült kindlegen-el.
Tehát a PNG-t eszi ugyan a konvertáló, de rögtön JPG-vé alakítja, ha kell megerőszakolva a felbontást és a képminőséget.

eNeL 2010.12.27. 21:37:22

Na. Nem vagyok programozó, de ez az ncx dolog izgatta a fantáziám.

Úgy döntöttem, hogy vért izzadva, menet közben tanulva a VBScript gyönyörűségeit alkotok egy scriptet. Mindezek mellett több napig szívtam a MP Creator által alkotott fájlokkal, mert van amit Unikóddal, és van amit ANSI kódolással gyárt le.

Most ott tartok, hogy a script működik, jelenleg tesztelem. Ki kellene tisztítanom a rengeteg sallangtól. Nincs továbbá hibakezelése sem.

Viszont egyelőre - úgy tűnik - működik a MP Creatorral:)) Szépen néz ki a Kindle Previewerben a sáv :)

Ignis_veneficus 2010.12.28. 22:45:21

@eNeL: Az NCX nem logikai tartalomjegyzek?
ha igen akkor mi koze van a savhoz?
amugy kindle-ben hogyan lehet elobanyaszni? a guide azt javasolja, hogy legyen ncx-es TOC is meg HTML-es is, de eddig nekem csak a HTML-st sikerul elocsalogatnom.

eNeL 2010.12.29. 00:23:34

@Ignis_veneficus: Szóval az úgy van, hogy "igazi" tartalomjegyzéknek a html-est használják általában. Az ncx-es TOC valóban logikai jegyzék, a Kindle-ben ez csak egy szintű, míg más eszközöknél ez lehet több szintű is (pl. a h1, h2, h3-nak megfelelően, úgy mint az vizuálisan a html-nél látszik). Ez a tartalomjegyzék is előhívható, navigálni hasonlóan lehet benne, mint a html-ben (azzal a különbséggel, hogy az egy szint miatt csak egy listaszerű valami az egész). A poén a vizuális ábrázolás, ami alul látható egy sávban.

Egy sima generálásnál ez a sáv csak százalékosan mutatja a könyvben történő "előre haladást". A vizualitás a K-nál azt jelenti, hogy ebben a sávban apró kis vonalkák jelennek meg, amik a részek, fejezetek, alfejezetek (vagy egyéb megjelölt helyek) pozícióit jelölik a könyvön belül. Ahogy haladsz a könyvben, úgy kúszik egy fekete vonal a vége felé, a kis vonalkákkal pedig érzékelni tudod, hogy pl. mennyi lehet még hátra az adott fejezetből.

És itt jön be, miért is csak egy szintű a K-ban ez a TOC: a vékonyka sávban másképpen nincs is értelme jelölni az olvasási helyzetet a fejezetekhez viszonyítva. Mondjuk azért ilyen a sáv, mert ilyenre alakították :)

Igazában ez egy kényelmi szolgáltatás, aki nem maximalista, az bőven elvan nélküle is.

elminster 2010.12.29. 10:03:00

@eNeL: Valamint, ha van a PRC-ben ncx-es tartalomjegyzék, akkor a PC Mobipocket Reader fejléc-sorában (a menügombok alatti rész, balra egy kék háromszöggel kezdődve) nemcsak a könyv címe jelenik, meg, hanem az éppen olvasott fejezet címe is, mintha egy valódi könyv fejléce lenne.
Tényleg csak egy kényelmi funkció. Azt nem értem, hogy ha láthatóan figyeltek az ncx-re is, akkor miért nem vették a fáradságot a Mobipocket Creatorban legalább egy kipipálható kapcsoló erejéig, hogy az ncx készítését bekapcsolhassa, aki akarja?

(Egyébként, ha nem írod bele direkt a <guide>-ba az ncx-es tartalomjegyzéket, akkor nem érhető el sehonnan, "csak úgy van" az anyagban.)

SaGa 2010.12.29. 12:00:50

@eNeL: Kipróbáltam és lehet több szintű ncx-et is csinálni. A kinslw previewer-ben gyönyörűen látszik is, K3-on még nem néztem...

A módszer:
ahogy jönnek egymás után a fejezetcímek, a kezdő fő fejezetcím (h1) után nem teszed be a </navPoint>-ot, hanem a <content src... sor után rögtön beszúrod az első alfejezet (h2) <navPoint> szakaszát. A hiányzó </navPoint>-ot meg beszúrod az adott fejezet utolsó alfejezetének </navPoint>-ja után, így kettő lesz egymás után, majd ez után jön a következő fő fejezet cím (h1)...

Pont úgy, ahogy az epub többszintű toc.ncx-ben is kell.

Az automatizmust az epubnál úgy oldottam meg, hogy van egy változó, ami akkor kap "1" értéket, ha az adott címsor h1 típusú, egyébként 0.
Ha a beolvasott cím h1 típusú és ez az érték 1, akkor beszúr egy plusz </navPoint>-ot a toc.ncx-be az aktuális <navPoint> elé, és ezt a változót nulláza.
Ha a változó értéke 0, akkor és az adott cím h1, akkor beállítja az értéket 1-re, egy másik változót (ami azt jelöli, hogy egyáltaán volt egy h1 típusú címsor a fájlban) is 1-be billenti, de nem fűz be </navPoint-ot> pluszban.
A vizsgálatokat ebben a sorrendben kell elvégezni, másképp hibázni fog.
A szakasz lezárásaként, ha az aktuális sor nem h1 típusú, akkor teszünk egy </navPoint> sort a fájlba, ha h1, akkor ez kimarad, mert már korábban megtettük.

A "volth1" változót a végén arra használom föl, hogy ha az értéke 1, akkor kell egy </navPoint> az utolsó bejegyzés után, ha 0, akkor nem.

Az mbp_toc.html-ben sajnos nem látszik, hogy melyik a h1 és h2, így annyit utólag kézzel meg kell csinálni, hogy a megfelelő helyeken ki kell emelni és áttenni a jó helyre a </navPoint> sorokat.

Azon gondolkodom, hogy a jelenlegi scriptemet kicsit átgyúrom. Az epub legenerálása után a létrejött html fájlokban átcserélem a formázási utasításokat mobi formázásokra, majd összerakom a mobihoz szükséges opf-et és azt betolom a kindlegenbe. Így egy több html-ből összerakott mobi jön létre, benne a megfelelő ncx-szel, de a fontok és egyéb epub specialitások nélkül...

Ignis_veneficus 2010.12.29. 14:46:03

NCX: az epub oldalrol kerultem, ide, ott is van NCX. De ott az ADE azt hasznalja bal oldalon oldalon
(nem is ertettem, hogy minek neki a html alapu)
a GUIDE-ba hogyan kell az ncx-et belerakni? (a SPINE-ba tudom, de a guide-rol nagy csond van a kindle guide-ban)

SaGa 2010.12.29. 18:55:13

@Ignis_veneficus: A guide-be az mbp_toc.html-t raktam bele:

manifest>
<item id="item1" media-type="text/x-oeb1-document" href="Hadak%20arja.html"></item>
<item id="item2" media-type="image/jpg" href="map.jpg"></item>
<item id="toc" media-type="text/x-oeb1-document" href="mbp_toc.html"></item>
<item id="navigation-map" media-type="application/x-dtbncx+xml" href="toc.ncx"/>
</manifest>
<spine toc="navigation-map">
<itemref idref="item1"/>
<itemref idref="toc"/>
<itemref idref="item2"/>
</spine>
<tours></tours>
<guide>
<reference type="toc" title="Tartalom" href="mbp_toc.html">
</reference>
</guide>

K3-on, az alsó "progressbar"-on a vonalkák az első szintű (h1) bejegyzéseket mutatják, és a "joystick" jobbra-balra irányával ezek között lehet lapozni.

Ignis_veneficus 2010.12.29. 20:28:07

@SaGa: Kosz, a HTML-eset ismerem, hasznalom.
Csak az zavar, hogy a kindlegen-nek kell a ncx, a kindlepreview tudja hasznalni (megmutatni), de a kindle-ne mintha nem tudna..
ezert csaptam le a guide-ra hatha oda bele lehet rakni, es akkor a kindle is hasznalni tudja.
(sosem ertettem minek egy konyvbe "normal" tartalomjegyzek, ha vannak metaadatok, es ott is van tartalomjegyzek pl ncx)

elminster 2010.12.29. 21:58:19

@Ignis_veneficus:

Mindent meg lehet csinálni, csak akarni kell:

<guide>
<reference type="toc" title="NCX-tartalom" href="toc.ncx">
</reference>
</guide>

Csak ne nekem sírjál, ha nem műkszik. :-))

A guide-ba bármit be lehet rakni, és ekkor kap egy kis menüelemet, amire rákattintva hipp-hopp odaugrik az olvasó. Az már egy másik kérdés, hogy az erősen XML alapú ncx-es tartalomjegyzék miképpen fog megjelenni.
De "elérhető" lesz, mivel van hozzá egy link a navigációs menüben. Ez a lényeg.

SaGa 2010.12.30. 08:36:32

@Ignis_veneficus: Belenéztem a Kindle Formatting című könyvbe. Ott is az a helyzet, hogy a toc.ncx fel van tüntetve a manifest szekcióban, illetve a <spine toc="toc"> sorban, de a Guide-ben egy külön, html-es tartalomjegyzék van megadva:

<manifest>
<item id="toc" href="toc.ncx" media-type="application/x-dtbncx+xml"></item>
<item id="item1" media-type="application/xhtml+xml" href="0-cover.html"></item>
<item id="item2" media-type="application/xhtml+xml" href="1-titlepage.html"></item>
<item id="item3" media-type="application/xhtml+xml" href="2-copyright.html"></item>
<item id="item4" media-type="application/xhtml+xml" href="3-dedication.html"></item>
<item id="item5" media-type="application/xhtml+xml" href="4-TOC.html"></item>
...

<spine toc="toc">
<itemref idref="item1"/>
<itemref idref="item2"/>
<itemref idref="item3"/>
<itemref idref="item4"/>
<itemref idref="item5"/>
....

<guide>
<reference type="title-page" title="Title Page" href="1-titlepage.html"></reference>
<reference type="copyright-page" title="Copyright Page" href="2-copyright.html"></reference>
<reference type="toc" title="Table of Contents" href="4-TOC.html"></reference>
<reference type="start" title="Startup Page" href="6-start.html"></reference>
</guide>

Ignis_veneficus 2010.12.31. 21:40:30

Kepek kindle-n.
Szal ugy tunik (kindle preview-n) hogy maximalizalja a kepet (kihuzza addig, mig van hely) es nagyon nem erdekli sem a width sem a height attributum. (sem %-ban, se konkretan megadva)
valakinek tapasztalata?
A feladat: van mondjuk 100*100 pixeles kepe, es azt akarom, hogy kb ennyiben is jelenjen meg a kindle-n.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.01. 00:21:00

@Ignis_veneficus: Épp most csináltam egy képekkel zsúfolt prc-t, jpg-kkel, és kajakra tartja a pixelméretet. Creator, Build 41. Ha kell, átküldöm.

szakértőbb 2011.01.01. 14:20:19

@Ignis_veneficus:
Ha beteszek egy kepet a Kindlere, az akkoraban jelenik meg, ahany pixel valosagban nalam. Te hogy erted, hogy kihuzza?

Ignis_veneficus 2011.01.01. 14:33:42

@szakértőbb:
@Dworkyll:
(kihuzza: akkorara nagyitja, hogy vagy vizszintesen, vagy fuggolegesen elfer a kepernyon)
Na kiderult: fifikas a kindlegen. csak abban az esetben meretezi be a kepet, ha a width, es a height pixelben van megadva, es oda id van irva "px" (vagyis:
width="25" <- ervenytelen
width="25%" <- ervenytelen
width="25.0px" <- ervenytelen
width="25px" <- az egyetlen amit ertelmes, es rendesen megjelenit)

Topy 2011.01.02. 09:20:21

Hirtelen nem találtam jobb helyet, úgyhogy ide írom. :)
A "Giveaway of the Day"-en csak ma(2011.01.02) PDFZilla 1.2.9 regisztráltan letölthető. Legális, ám a feltételek sajátságosak. Csak ma(!), tölthető le, support/upgrade nem jár hozzá és csak akkor legális az install, ha még ma felkerül a gépre.
www.giveawayoftheday.com/pdfzilla-129/

Gaboro · http://goo.gl/MULS 2011.01.03. 14:14:26

Tudnátok még mutatni lecsupaszított, sallangmentes minta-html-t?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.03. 22:43:45

@Gaboro: Például:

<html>
<head>
<title>Rejtő Jenő – AZ ELÁTKOZOTT PART</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-16"/>
<style type="text/css">
h1 {
text-align: center;
margin-top: 35;
}
h2 {
margin-top: 25;
text-align: center;
}

h3 {
page-break-before: always;
text-align: center;
margin-top: 30;
margin-bottom: 1em;
}
h4 {
page-break-before: always;
text-align: center;
margin-top: 30;
margin-bottom: 1em;
}
h5 {
text-align: center;
margin-top: 20;
margin-bottom: 1em;
}
p.noind {
text-indent: 0;
}

</style>
</head>
<body>

<div class="Section1">

<h2>Rejtő Jenő</h2>

<h1>AZ ELÁTKOZOTT PART</h1>

<p>&nbsp;</p>

<p>&nbsp;</p>

<h4 id="mbp_toc_0">Első fejezet</h4>

<p height="0" align="center"><i>Néhány szó egy nadrágról, egy asztalkendőről, magamról és más kétes egyénekről</i></p>

....

<h5>3.</h5>

<p class="noind">Anyám neve napja volt minden baj okozója. A festői Oranban vesztegeltem éppen, állás nélkül, durva lelkű kapitányom miatt, ugyanis a <i>Pokróc</i> nevű háromárbocoson teljesítettem szolgálatot mint másod-alkoholcsempész. Istentelen, erőszakos fráter volt a kapitány, nagy testi erejével sűrűn visszaélt, lelketlenül ütött, és nem nézte hová. Valami csekélység miatt megrohant az a barom, beverte az orromat, és fejbe ütött egy léccel. Mert szívtelensége, ha kínt okozhatott, nem ismert határt. Csak nehezen sikerült elkerülnöm a további brutalizálást. Közben a fél szemére világtalan lett. De a bordáihoz nem nyúltam. Azok akkor törtek be, amikor a csigalépcsőn legurult a fenékbe. Erről én nem tehettem. Rendes hajón a lépcsőnyílásokat csapóajtóval fedik.</p>

<p height="0">A civódás után nem maradhattam tovább szolgálatában, és ott álltam a kies Oran festői éhségében, fillér nélkül. Egy matróz. Írásaim sem voltak. Régi ellenségem, a bürokrácia megfosztott ettől a fontos matrózkelléktől.</p>

<p height="0">Szerencsére néhány üzlettársam és barátom éppen szabadlábon időzött a városban, és mint nagy tisztelői az antik műveltségnek, egy karthágói eredetű ciszternában laktak a kültelkek mögött. Tuskó Hopkinstól tudtam meg ezt, miután találkoztunk egy ismerős orgazdánál. Tuskó Hopkins tömzsi volt, de nem kövér, és egy nézeteltérés alkalmával valamivel az arcába vágtak, hogy az orra apró lett, és egészen vörös. A hangja recsegett, mintha egy századot vezényelne állandóan, keménykalapját a tarkójára tolta, egészen apró szivarokat szívott, bizonyára másodkézből, és rendkívül csámpás volt.</p>

<p height="0">Ő vett előbb észre, az utca emberáradatában, amint ott mentem előtte.</p>

<p height="0">Barátságosan a vállamra veregetett, majd felsegített és leporolt.</p>

<p height="0">–&nbsp;Szervusz, Csülök!</p>

<p height="0">–&nbsp;Tuskó! – Kiáltottam örömmel. – Téged az ég küldött. Nincs lakásom, és mindössze tíz frankot kaptam a kapitány viharkabátjáért.</p>

<p height="0">–&nbsp;Nem tesz semmit fiam! Nem tesz semmit, fel a fejjel – mondta, mert mindig bizakodott, hangosan és szélesen. – Nincs semmi baj!</p>

kIára 2011.01.04. 10:43:21

@Dworkyll:
Már elnézést, nem akarok kötekedni, de a » height="0" « _nem_ html p attribútum. Ergo a htlm _nem_ tiszta. Lényegesen egyszerűbb és hatékonyabb, a css-ben a » p margin: 0; «

Szóval helyesen: Dworkyll mintája egy xhtml-szerű, mobipocket forrásállomány, de nem "tiszta html".
Az teljesen más kérdés, hogy a mobipocket creator ez alapján nem hagy sorközt a bekezdések között, de ha pl. a Kindle számára készítünk mobit akkor érdemesebb a css-el játszani, a p-tag szemetelése helyett.

Ugyanúgy megfontolnám a <h1> <h2> tag-ek közé beszúrt
dupla <p>&nbsp;</p>-t és inkább a <h(n)> kapjon margin-top, margin-bottom értéket.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.04. 11:37:31

@kIára: Nem érzem ám kötekedésnek :-) hogy itt cikizitek a kódomat, kódhegesztő (ncx kreáló) scriptet meg nem csináltok :-)))

A css-t nem teljesen támogatja a mobi (sajnos), viszont ha oly alaposan megnézted a kódot, akkor láthattad, hogy pont a <h(n)> tagek formázását teljesen a css vezérli, ugye ;-)

Az üres soroknak meg nem szimplán távtartó szerepe van, bár épp a kódmintában tök fölöslegesek, ez igaz, hanem keresőmintákat is vezérlek vele.

Ugyanígy, a height="0" történelmi és gyártástechnikai örökség. Jól működik, jól használható. Ha írsz jobbat (css-t, cleaner-scriptet), az azért érdekel :-) Ne felejtsük el, hogy a mobi platform sokkal sokkal szélesebb, mint a Kindle, hiszen még az sem homogén önmagában.

Professzore · http://ekonyvolvaso.blog.hu 2011.01.04. 13:09:58

Hölgyek és urak! Dwoval gondolkodtunk rajta, hogy tudásunkat egybe köllene gyurmászni... Nem csinálunk egy privát "konferenciát" valamikor?

Más: nekem most pont a width="-30px" tag-gel van bajom. Bárhova, bárhogy teszem, nem hajlandó "negatív behúzást" csinálni, azt meg pláne nem, hogy a szöveg balról (és csak balról) alapértelmezettként beljebb kezdődjön. Vershez köllene.
A blockquote-tal az a bajom, hogy alul/fölül/elöl/hátul beosztást rak, plusz a hosszú sorokat balra (vagy kizárás szerint) igazítja, nem pedig egy-két kvirttel beljebb, ahogy szép lenne.

Tegnap 3 órát bíbelődtem vele, eredménytelenül.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.04. 13:55:19

@Professzore: Támogatom. SaGa, kIára, Ignis, Elminster?

sys_64738 2011.01.04. 20:38:32

Sziasztok!

Sajnos a "kód heggesztéshez" nem tudok hozzá szólni, csak felhasználó vagyok :)
Viszont a munkálatok elején meg van említve, hogy a "nyers" anyagokat a MEK honlapjáról is be lehet szerezni. Ezt tettem én is, és miután sikerült olvasható kinézetű prc-t készíteni az itt leírtak alapján, megkérdeztem a MEK könyvtárosait, hogy kell-e nekik. Nem zárkóztak el tőle:) Mivel nincs kapacitásuk rá, elég lassan haladnak az ebookosítással. Az lenne az ötletem, hogy tegyétek be mondjuk IV/a pontnak, hogy ftp-n, vagy emilben küldjük vissza a kész prc-t a MEK-nek. Az ő munkájukat is segítjük vele, meg egymásét is, mert ha már megvan egy könyv, azt nem kell mégegyszer konvertálni. Csak annyi a kérésük, hogy a címlapon legyen feltüntetve a MEK. (ami egyébként a tőlük letöltött anyagokban amúgy is benne van) Így egyszer csak feltűnik majd a txt, html, formátum mellett az ebook is :)

Professzore · http://ekonyvolvaso.blog.hu 2011.01.04. 20:47:28

@sys_64738:

Jó ötlet!

Dwo, rakd be a cikkbe, nem akarom, hogy a motor átkavarja lovárira a poszt nyelvét. :-)

Ignis_veneficus 2011.01.04. 21:01:48

@Dworkyll: tamogatom az otletet
@Professzore: kindle eseten a width es a blockquota eleg erdekesen viselkedik.
nekem a p elemben a style="text-indent:-1em" jott be
meg van egy silabuszom a kovetkezot javasolja versnek:
text-indent="-x" majd jon jo par nbsp annyi, hogy meg beljebb kezdodjon, de a kov sor meg beljebb.

en a text indent-et akartam keresztezni a blockquote-al, de a negativ behuzast nem tudam elerni.

viszont. a blockquote-ba lehet szepen p-et pakolni. igy pl egy verszakot vagy az egesz verset lehet egy blockquote-ba belerakni

eNeL 2011.01.04. 21:35:58

@Dworkyll: Már elnézést, de éppen 27-én emlegettem, hogy tesztelgetem a scriptemet :)

Működik, csak időnként akad ki, ha valamelyik olyan hxx akarok tartalomjegyzékbe tenni, ami több sor hosszú. De amúgy működik. Lehetne persze tökéletesebb...

Ignis_veneficus 2011.01.04. 21:51:46

@eNeL: fiuk, fiuk..
szivtok a kulonbozo html=> tartalomjegyzek scriptekkel...
ugyebar a html-t xhtml-nek csinaljatok..
akkor meg miert nem engedtek ra egy xslt-t es az megcsinalja a tartalomjegyzeket, akar html formaban, akar ncx formaban.

eNeL 2011.01.04. 22:36:08

@Ignis_veneficus: És azok majd megfelelnek a Creatornak, meg a KindleGennek prc gyártáshoz?

Ignis_veneficus 2011.01.04. 22:56:27

@eNeL: en eyyel inditom a file-t (xhtml):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

eddig meg a kindlegen nem szolt erte, a Creatort nem probaltam, de mivel az elvileg kepes a webrol feldolgozni, igy nem szolhat erte.

html-es transform:
(tegyuk fel, hogy a cimek: H1,H2, stb es rogton utana kovetkezik egy <a> aminek id az azonositoja:
<h1>cim</h1>
<a id="elso cim">
...
)

<?xml version='1.0' encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/1999/xhtml"
version="1.0">

<xsl:output method="XML"
version="1.0"
encoding="UTF-8"
doctype-public="-//W3C//DTD XHTML 1.1//EN"
doctype-system="http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"
indent="no" />

<xsl:template match="/html">
<html>
<!-- sallang, pl head, title stb-->
<body>
<xsl:apply-templates select="//h1|//h2|//h3"/>
</body>
</html>
</xsl:template>

<xsl:template match="h1">
<p width="0em"><a>
<xsl:attribute name="href">
<!-- document.html lecserelendo a tenylege html-re -->
<xsl:text>document.html#</xsl:text>
<xsl:value-of select="following-sibling::a/@id"/>
</xsl:attribute>
<xsl:apply-templates/>
</a></p>
</xsl:template>

<xsl:template match="h1">
<p width="2em"><a>
<xsl:attribute name="href">
<!-- document.html lecserelendo a tenylege html-re -->
<xsl:text>document.html#</xsl:text>
<xsl:value-of select="following-sibling::a/@id"/>
</xsl:attribute>
<xsl:apply-templates/>
</a></p>
</xsl:template>
<!-- ugyanigy megcsinalni a tobbit-->
</xsl:stylesheet>

kicsit fapados, lehetne rajta szepiteni, de szerintem a lenyeg latszik.

Ignis_veneficus 2011.01.04. 22:57:12

@Ignis_veneficus: a masodik match="h1" ertelemeszerune "h2" akart lenni

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.04. 23:01:36

@eNeL: Az eszköz tökmindegy, az ncx struktúrája kötött. Ha az ncx jó, akkor a kindlegenbe/creatorba is jó lesz.

Épp most kaptam egy pakkot, html+opf+css+ncx meg egy pár kép. Elvileg epub is lehetne, de nem az volt. Kicsit tücskölni kellett az opf-en, a Kindlegen ragaszkodik a pontos nyelvkódhoz pl, meg a filehivatkozások szintaktikáját kellett megigazítani az opf-ben és az ncx-ben.

Után a a Creator olyan prc-t galabintott belőle, hogy még. Volt tartalomjegyzéke ÉS ncx-e. Szóval ha van ncx. akkor azt be is lehet építeni a publiba szépen, akár Creatorral.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.04. 23:03:43

@Ignis_veneficus: Wazz, ezt hogyan futtatod, és hogy mondod meg neki, hogy miből mit csináljon?

eNeL 2011.01.04. 23:21:52

@Dworkyll: A Kindlegenről éppen azt olvastam, hogy meglehetősen más, és kötött szintaktikával dolgozik, mint egyebek (pl. Creator).

Minden esetre a prc_gen könyvtárba felraktam egy pakkot, ha akarod, próbáld ki a scriptet.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.05. 00:20:58

@eNeL: ÁÁÁÁÁÁÁÁ, isten vagy :-)) Mi volt a gondod vele? Egy teszt után teljesen fullosnak látszik.

Amúgy a Kindlegen ha finnyás, innentől csak az opf-et kell birizgálni (meg a forrás-html-t esetleg az eltérő parsing miatt) és a "publikációs csomagok" buildelhetőek azzal is.

Én pont azért komálom a Creatort, mert finom kézi kontroll van a metaadatok fölött, nem kell mindent előre a helyére rakni.

Ja és kérhetsz egy nagyot :-)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.05. 01:03:56

@eNeL: Áá vágom, nem szereti, ha <br/> tag van a headingben. Azért ezzel még így is jó messzire el lehet menni, a tört fejezet- és kötetcímek szerencsére elég ritkák.

(Mondjuk ez elég perverz, de volt olyan, hogy a fejezetcímem egy kétcellás táblában volt, és a másik cellában egy kép. Na arra még nem próbáltam.)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.05. 01:14:45

@Dworkyll: Kipróbáltam, a cellázott, és kétszintű headinget simán megette. Zsír ez a cucc :-))). Nem százas, de 99, es tutira megvan :-)))

SaGa 2011.01.05. 06:59:01

@Dworkyll: Ha ez alatt egy erre a célra létrehozott fórumszerűséget kell érteni, akkor OK, ha valami tényleges összejövetelt, akkor nem annyira, mert elég nehezen tudnék bármilyen időpontot választani...

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.06. 00:18:10

@eNeL: Mégsem frankó. Van két testvércsomagom. Az egyiken csont nélkül lefut, a másikon kihal. Line 347 Invalid procedure call.

Mit nem szeret? Azt hittem a <br>-t a headingben, de itt ilyen nincs. Semmi nincs már a headingekben, csak az id.

Nem lehet valami tempfileban kinézni, hogy mi volt az utolsó processzált sora? A forrás html-ben kutakodik csak, vagy az mbp_toc-ban?

A tisztítóscript se szereti pl a kézi lapdobást. Itt nincs valami hasonló "tiltott karakter"?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.06. 00:30:45

@Dworkyll: Az Atmeneti1.tmp elkészül, az opf-be belepiszkál, de a toc.ncx elakad a <navMap> után azonnal.

???

eNeL 2011.01.06. 17:27:19

@Dworkyll: Ezért jó, ha más is tesztelget :)

Ha nagy profi lennék, akkor valószínűleg már megoldottam volna a problémát. A hivatkozott sor egy adatkinyerő szubrutin része, ha hiba van, akkor általában itt szokott megállni. Ennek több oka lehet: lehet az említett <br/>, de jártam már úgy, hogy egy bennmaradt <a>, vagy </a> tag okozta a leállást. Olyan is volt, hogy egy záró ">" hiányzott. Ezért jó egy html tidy futtatása.

Egyébként úgy működik, hogy a "Language", "package unique-identifier", "Title", "Creator" változókat kiveszi az illető opf fájlból; ezt követően esik neki az mbp_toc-nak. Esetedben ez azt jelenti, hogy túl van az opf fájlon; az mbp_toc-nál akad ki.

Először kitakarítja az mbp_toc fájlt - és itt találkozhat olyan elemmel, ami kiakaszthatja.

Először másolja, majd átkódolja Unikóddá. Itt nem szokott baj lenni. Utána levágja a <body> és </body> tagek előtti és utáni részt, majd elkezdi tisztogatni a maradék részt. Na, itt szoktak a gondok lenni.

Ha itt hiba nélkül továbbmegy, akkor már általában be is fejezi a munkát sikeresen.

Ami a Tidy-t illeti: találtam egy GUI-t is hozzá (igaz 2005-ös), így nem kell parancs sorból futtatni, a főbb bajokat mutatja egy kis ablakban alul. A "tisztított" html-re pont ezért teljes egészében nem is jó, mert mindjárt az elején hiányolja a DOCUMENT sort, stb. De a lezáratlan, vagy hibás bejegyzéseket jelzi; és mivel az eredeti fájlod megmarad egy org_ előtaggal, ott könnyedén javítható a hiba.

Most ettől persze még nem fenékig tejfel az életed :)

Eredetileg terveztem egy előrehaladást jelölő fájl létrehozását is, csak - lustaság fél egészség - az eredmény volt fontosabb számomra. Ennek a fájlnak ugyanis akkor van értelme, ha minden lépést rögzítek, ez meg baromi sok plusz sorral járt volna. De, még előfordulhat, hogy erőt veszek magamon...

eNeL 2011.01.06. 17:35:24

@eNeL: Ja, és a Tidy átkódolja az eredeti "tisztított" fájlodat, mert látja a karakterkódokat, elöl meg nincs leíró rész; szóval óvatosan. A Tidy által így javított fájl garantáltan használhatatlan lesz a Creatorban - mert szegény teljesen és szolgaian a szabványt követi. Mondjuk, pont ezért találták ki.

eNeL 2011.01.06. 20:20:05

@Dworkyll: A korábbi helyre felraktam egy módosított scriptet, most már lesz egy "mobitoc2ncx.log" fájlod, ami egy sima txt fájl. Ez elvileg segíthet megtalálni a helyet, hol (illetve: mikor) akadt el a script. Bár még ez sem egy rendes hibakezeléssel ellátott script...

Pontosan megtalálható a hely (többnyire az mbp_toc fájlban) - elvileg - amennyiben teljesen megérted a script működését.

Remélem, egy kicsit segítettem.

Ignis_veneficus 2011.01.06. 21:01:38

@eNeL: valaki dobjon meg egy problemas mobi-toc -al, es megirom ra a generalo xslt-t egy fel este alatt..
(kell majd hozza xalan, de legalabb parancssorbol elfut, es nem szokott rinyalni a hianyzo DOCUMENT sortol, sot a dtd hianytol sem...)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.06. 22:11:43

@eNeL: Bánnád, ha kitenném a scripted egy posztba, és toboroznék rá még szakértést? Annyi okos ember olvassa a blogot, hátha...

@Ignis_veneficus:

Küldök mindjárt.

eNeL 2011.01.06. 22:16:58

@Dworkyll: Miért ne? Egyébként hosszú hónapokkal ezelőtt már valamelyik posztnál emlegettem, hogy sok (hozzáértő) emberrel biztosan össze lehet hozni olyan szoftveres dolgokat, ami mindannyiunk életét megkönnyíthetné.

Bizonyára sokféle változat lehetséges, mert ki ehhez, ki ahhoz ért. De egy próbát megér.

ananaszkonzerv 2011.01.14. 15:24:07

Hello!

Ma próbáltam létrehozni az első prc fileomat a fenti útmutató alapján. A script nekem nekem nem működött, de nem sokat próbáltam. A word-ből kimentett "egyszerű html" jól ment, így az lett az alap.

Az Editorral viszont sokat szenvedtem, mert sehogy nem találtam azt, hogy hol kell kitölteni a meta adatokat. Vagy egy órát szenvedtem, végig olvastam a helpet, de az istennek se találtam. Végül rájöttem mi a gond. A 4.2 volt fenn nekem, és amikor felinstalláltam, a "Home" verziót raktam fel, amiben nem lehet meta adatokat kitölteni, így nem is találhattam meg. (Nekem mint kezdőnek, a "home" verzió tűnt logikusnak, hiszen elsőre próbáltam.) Nem tudom másnak ez teljesen egyértelmű-e, de nekem nem volt az, hogy itt a 'Publisher" verzióról van szó. Lenne egy javaslatom: a szövegben szerintem utalni kéne rá, hogy nem a "home" verzióról van szó. Vagy én vagyok az egyetlen aki így járt?

Egyébként köszönet szerzőknek, a blog hatására vettem egy Koobe Juniort, pont egy hete.
Mint teljesen laikus kezdő, majd írok párt sort tapasztalataimról a Koobe poszthoz.

Ignis_veneficus 2011.01.14. 22:01:10

Fel mondat meg az NCX-el (eleg nagyot szivtam vele)

A kindle a status-vonalon nem csak a fejezeteket mutatja, hanem a jegyzeteket is

(es ott szivtam, hogy 2 napig szedtem szet az ncx-et es raktam ossze, mert a konyvben voltak "feles" jelolesek is. es nagyon nem cimeknek neztek ki. Az elejen arra gondoltam, hogy a file es az ID amire utal az ncx nem esik fizikailag egybe (van kozte par elem) es attol csuszott el.)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.14. 23:08:29

@ananaszkonzerv: Igazad van, kiegészítettem a posztot. Viszont a Junioron az epubbal jobban jársz. A Junior prc parsere eléggé hiányos, sajnos.

@Ignis_veneficus: Így jár, aki ritkán korrektúrázik ;-P

tivkov 2011.01.15. 17:43:14

Szaisztok, üdvözlet az olvtársaknak! Egy ideje érdeklődéssel olvasom a cikkeket és a hozzászólásokat, ennek eredményeként már K3 tulaj vagyok (nov30-i rendelés/jan12-i szállítás). Túl estemk az első regény olvasásán. Nagyon tetszik. Több könyvet már konvertáltam (a leírás alapján valóban egyszerű) és többnyire jól működnek. Most a MEK-ről szeretném Ady-t átteni, de ez több hivatkozott html-ből áll és az én tudásom itt megáll. Hogy lehet ezt prc-be tenni?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.15. 19:07:12

@tivkov: Van a matekos út, meg a fizikus. A matekos hogy cut&paste-tel összevágod a MEK-htmleket egy wordbe, és visszavezettük a problémát a poszt elejére. A fizikus, hogy sok htmlt is lehet a Creatorba rakni egyszerre, összefűzi őket szépen. Ezzel csak az a kaland, hogyha globális műveletet akarsz a szövegen csinálni, akkor azt minden állományon meg kell. Bár vannak olyan editorok, pl. a Notepad++ amik támogatják ezt.

Gyakorlat eszi a mestert :-)

tivkov 2011.01.15. 22:18:57

@Dworkyll: Köszönöm a tanácsokat, a "matekos" úttal próbálkoztam, de nagyon munkásnak tűnt, ezért kérdeztem, hátha van valami lustább lehetőség. Marad az utolsó mondatod :)

sys_64738 2011.01.16. 09:09:42

Halihóó!
Sikerült az itt leírtak alapján "igényes publikációt "csinálni! Tartalomjegyzékkel, pöttyökkel mindennel:)
Köszi az útmutatót :)

tivkov, ha sikerült legyártani, küld majd vissza a mek-nek a prc-t. (Hogy nekünk már egyszerűbb legyen Ady-t olvasni :)

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.16. 11:02:12

@sys_64738: Gratula! Remélem a TOC.NCX-et is bele tudtad varrni :-) Tudod, az erre járóknak csak a legjobb a jó ;-)

sys_64738 2011.01.16. 12:18:16

Hát ez azt jelenti, hogy a progress bar-on pöttyöz, és odébb tudok ugrani a következő fejezetre, akkor sikerült :)

xtraktor 2011.01.17. 07:54:45

Sziasztok.
Olyan kérdésem lenne, hogy egyes doc, docx fájlokban hiába javítom ki a helyesírási hibákat, miután átkonvertálom mobi, prc-be csak jelen vannak azok a szövegben. Pl. szóelválasztás. Habár az elmentett fájlban nem látszik mikor újra megnyitom az ebookban viszont igen. Tehát hogyan tudnám ezt a memóriát törölni az eredeti fájlból, úgy hogy a formázás is megmaradjon ?
(ha átalakítom pdf vagy txt-be akkor már eltűnik, de úgy vesztődnek az aktív linkek és a formázás)

Arturo 2011.01.17. 08:34:05

@xtraktor: Nem maradtak benne véletlenül a feltételes elválasztójelek?

xtraktor 2011.01.17. 09:42:47

@Arturo: Köszönöm szépen.
Ez volt a gond, rejtett szövegként bennemaradtak az eredeti (könyvből átvett) elválasztójelek és átalakításkor előjöttek.

speedysly 2011.01.20. 12:12:49

Sziasztok!

Linux ubuntu használó vagyok és calibre-vel konvertálok. Az a gondom, hogyha A/4-es pdf-ből prc file (egyébként nem tudom miért, de mobi-t ír ki) konvertálok akkor a file a kindle kijelzőjén nagyon kicsi betűkkel fog csak látszódni és a betűméretet sem lehet változtatni, csak egy kis nagyításra van lehetőség, ami nem elég (nem lehet még így sem jól látni a betűket). Tudna vki segíteni?
Előre is köszönöm!
Speed

Bandee007 2011.01.20. 12:40:15

@speedysly: Mobipocket creator, nem működik linux alatt? Ha igen, akkor szerintem azzal próbáld, ha nem akkor sajnos nem tudom. Én próbáltam mindkettőt, a calibre-al nem nagyon sikerült értelmesen átkonvertálnom egy könyvet se, mert össze-vissza tördelte nálam mindegyiket és undorítóbbnál undorítóbb eredmények jöttek, viszont a mobipocket creatorral nagyon szépen megcsinált egy csomót, persze némelyiknél volt olyan probléma, hogy az Ő és Ű betűk valamiért eltűntek vagy más jel lett helyettük, de azoknál meg beolvastattam az eredeti pdf-et egy másik programmal(aminek nem jut eszembe a neve, de ha kell megnézem otthon majd) és azzal mentettem doc-ba és úgy már jó lett.

SaGa 2011.01.21. 08:17:44

@speedysly: PDF-ből ocr-ezés és újraformázás nélkül nem fogsz prc/mobi-t gyártani, csak olyat, amiben elromlik minden. Vagy olyat, ami semmi egyebet nem tartalmaz, mint az oldalak képét, kép formában. Egyik sem jó semmire.
A pdf arra lett kitalálva, hogy az adott méretben egy oldal képét rögzítse, annak minden paraméterével és ezekből az oldalakból dokumentumot képezzen. Ha az oldal mérete nagyobb, mint a kijelző, akkor csak erős kompromisszumokkal (kicsinyítés, tologatva olvasás, vagy egy nagyon rossz eredményt produkáló áttördelés) lehet olvasni.

Ha rendes -ekönyvet akarsz a pdf-ből készíteni, az bizony munkás és befektetésigényes lesz. Egy jó OCR program, és egy szerkesztő program kell hozzá legalább.

SaGa 2011.01.21. 08:20:14

@Bandee007: Ha elolvasod az eredmények mellé fűzött értékelést, az is látszik, hogy egyik sem tekinthető használható megoldásnak.
Mint már többen is írtuk: valami ocr program (vagy a szöveg kiexportálása) és egy szerkesztő program kell hozzá, meg sok meló. Ugyanis végig kell olvasni az előállt szöveget, kijavítani az ocr hibákat, betördelni, helyreállítani a sorvégeket, megformázni és ez után lehet konvertálni...

speedysly 2011.01.21. 14:24:22

Köszönöm a sok segítő hozzászólást!

Igen, az a gond, hogy a pdf képekből áll és így nem tudom rendesen az átkonvertált prc-t/mobi-t nagyítani. Tegnap megpróbáltam a pdf-t szöveggé alakítani és azt követően a szöveget prc/mobi-ba átkonvertálni, de ez sem működött. Ez van sajnos, ma még munka után otthon megpróbálom azt, hogy a már átkonvertált mobi file-ból csinálok más szöveg file-t és a szövegfile-ból pedig egy újabb mobi-t, hátha így sikerül (valószínúleg nem).
Eddig normáils használható ocr alkalmazást (Linuxra) nem találtam, esetleg vki más?

Atyaman 2011.01.23. 17:23:12

Esetleg valaki tud-e olyan megoldásról, hogy a mobipocket creator által generált TOC-ba bekerüljön a borító is? Eddig úgy vettem észre, hogy a Kindle első megnyitáskor a TOC legelső eleménél nyitja a könyveket (hiába is lenne logikusabb a borító, de nem).

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.23. 18:45:03

A creatorban a guide elementsnél van ilyen, hogy startup page. Szerintem oda kéne meghivatkozni a borítót, ha ragaszkodsz hozzá.

Vagy jelöld meg ugyanazzal a taggel esetleg, amivel a toc_html-t gyártod.

Mondjuk csak tippelgetek, nekem jó így.

Ignis_veneficus 2011.01.23. 21:19:17

Most esett le, hogy a mobi egy zip file.
akkor tul keppen mit is csinal a kindlegen?
osszezippelni en is ossze tudom.
es legalabb megszabadulok egy csomo problematol, pl mit csinaljak a kigeneralt cuccal (hogyan torlom) meg ilyenek
Van valami speckoja a mobi zip-nek (mint a epub eseten a kovetelmenyek a mimetype file-ra)?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.24. 22:19:45

Táblakérdés.

Épp "táblázatokkal" küzdök K3-on. Az "egy sor - egy cella" meglepően jól sikerült, pl. középen van, és tudtam a gyári margónál szűkebbre venni.

Valahogy így:

<div class="docenter">
<table class="tabla1" width="65%" cellpadding="15" border="2" >
<tr>
<td width="100%" ><p class="pt1"><b>Giles Baddicombe</b></p>
<p>Robey, Robey, Redfearn and Bychance</p>
<p>ügyvédi munkaközösség</p>
<p>Demdyke Chambers 13</p>
<p>PRESTON</p></td>
</tr>
</table>
</div>

Hanem az "egy sor - két cella" ha fene fenét eszik is kitölti a margókat teljesen, ami a kisebbik baj, de nem tudom belőni, hogy egyenlő szélesek legyenek.

Van valakinek valami használható ötlete? Előre is köszi.

Ignis_veneficus 2011.01.25. 09:55:17

@Dworkyll: Probaltad a
<td width="50%">
...
</td>
<td>
...
</td> -t?
vagy asszem lehetne probalkozni a *-al is:
<td width="*">
</td>
<td width="*">
</td>

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.25. 11:21:28

S@Ignis_veneficus: Százalékot és pixelt megadni próbáltam már, sőt ilyet is <td style="width:50%">

A csillagot csak most, de valamiért ignorálja :-(

És továbbra sem értem, hogy ha az egy oszlopos táblázatot tudja szűkre húzni, mi a viharért "automatázik" két oszlopnál (oszlop és táblaszélesség), és ignorálja az attribútumaimat :-((

nagygabe 2011.01.25. 11:42:13

@Dworkyll:
Azt próbáltad, hogy csinálsz egyoszlopos szűkített táblázatot, és abba raksz egy kétoszlopost? Tehát tábla a táblában?

Ignis_veneficus 2011.01.25. 11:48:52

@Dworkyll: mi ignoralja? mobi creator vagy a kindlegen, vagy a kindle?
valahogy en megugrottam a feladatot, de most itt nem tudom elerni.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.25. 12:45:27

@nagygabe: nested táblával még nem próbálkoztam, mintha a doksiban azt olvastam volna, hogy nem okés. A blockquote mindenesetre nem volt jó

@Ignis_veneficus: creatorral buildelek, és a Kindle és a Kindle previewer is rosszul néz ki, a mobi desktop pl a szűk margót valahogy érti. Az egyenszéles oszlopok ott se működnek (build 41)

Köszi a tippeket, próbálkozom.

Ignis_veneficus 2011.01.25. 14:09:05

@Dworkyll: probald kizippelni es belenezni, hatha fejbecsapott valamit a creator.
vagy a kigeneralt cuccot a kindlegen-nel futtasd meg..

SaGa 2011.01.25. 14:52:00

@Dworkyll: Megnéztem a korábbi kísérleteimet és Joshua Talent leírását is, de sajnos az a helyzet, hogy a tábla oszlopai olyan szélesek, amekkora a legszélesebb szöveg bennük.
Trükközni lehet esetleg: valamelyik cellában &nbsp;-kel kiszélesíteni a leghosszabb szöveget azokban az oszlopokban, ahol nincs elég széles szöveg...

SaGa 2011.01.25. 14:57:25

@SaGa: Kipróbáltam, működik, csak figyelni kell, mert egy &nbsp; nagyjából egy n felét foglalja el, így
"a nap sorszáma" kb egyforma hosszú a "&nbsp;&nbsp;&nbsp;&nbsp;nap neve&nbsp;&nbsp;&nbsp;&nbsp;" szöveggel, vastagon szedve mindkettőt...

SaGa 2011.01.25. 15:02:18

@SaGa: Bocs, hogy így aprózom...
Mellékhatás: ha a táblázat szélessége be volt lőve és utólag megszélesítettem két oszlopot a fenti trükkel, a másik két oszlop leghosszabb szövege "elválasztódott" és két sorra tört, mert másképp nem fért volna ki a táblázat az oldalon.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.25. 16:10:54

@SaGa: Tartottam ilyesmitől, de ez nagyon kőbaltás megoldásnak látszik :-( Fene a parserjükbe.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.26. 04:06:22

@SaGa: Lehetséges, hogy a cellákba kell egy egy sor, nulla magas, kellő nbsp-t tartalmazó sor, hogy egyforma szélesek legyenek? Hmm...

Elegánsnak nem elegáns, de ha működik...

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.26. 04:56:40

@Dworkyll: Nem működik. Most jönnek azok a tigriscselek, hogy fehér színű monospace aláhúzások. Szánalmas...

Ignis_veneficus 2011.01.26. 06:32:59

@Dworkyll: probald meg, hogy, colspan-t adsz mindket cellanak, es az legyen egyforma, pl 2.
hatha mukodik.

kIára 2011.01.26. 17:35:19

@Ignis_veneficus:
A kindlegen HUFFDIC (Huffman) tömörítést használ. A linuxos unzip simán kibontja.
Egy kindle-mobiban a következő mappák vannak:

css/
html/
image/
misc/
content.opf

Nagyon hasonlít az epubra. Érdekes, hogy a html/ és misc/ mappák tartalma szinte teljesen azonos. Nagyon jó lenne egy ilyet kézzel előállítani, de a sima zip-tömörítés sajnos nem elég.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.26. 21:13:05

@Ignis_veneficus: nem működik :-( Ha nem lenne egymás után hét táblám, nem is lenne feltűnő, ahogy a <tt>nbsp-kel becsirikézem a táblaszélességet. Tiszta középkor.

Nagy Levin 2011.01.26. 22:36:25

A segítségeteket kérném. A MEK-ről leszedtem a Háború és békét és remekül sikerült is konvertálnom. A lábjegyzetből viszont egy link lesz, amit ha el akarok olvasni akkor külön oldalon megnyitja ha rákattintok. A baj az, hogy egy oldalon gyakran 3-4 megjegyzés is van, amit nagyon macerás mindig megnyitni majd mindig visszamenni. Hogyan lehetne megoldani, hogy a lábjegyzetben lévő szövegek mondjuk zárójelben álljanak a megfelelő rész után? Vagy legyenek mondjuk ugyanúgy az adott oldal alján? Köszi a segítséget!

Pelesz 2011.01.26. 22:49:04

A zárójeles megoldást úgy tudod előállítani, ha a forrás fájlt szerkesztőben megnyitod és egyenként bemásolod a megfelelő helyre. Rendes lábjegyzetre mobitól ne számíts, fb2 az egyetlen formátum ami tudja, a többi csak linkekkel átszőtt végjegyzetre képes.

Ignis_veneficus 2011.01.26. 23:11:24

@Nagy Levin: a lap aljan sosem fog megjelenni, azt nem tamogatja se a kindle, se a mobipocket reader.
a zarojelezest egyszeruen meg lehet oldani xslt-vel (ha egy filebol all az egesz), de ahoz latni kellene a kesz html-t.

Ignis_veneficus 2011.01.26. 23:12:38

@kIára: a wincmd zip-je is kibontja. sajnos nincs hozza java api, ugyhogy a problema egyenlore hanyagolva, marad a kindlegen

Ignis_veneficus 2011.01.26. 23:14:18

@Dworkyll: ja, csak probald ki fontmeret valtas utan is.. ott mas a darabszam...

Nagy Levin 2011.01.26. 23:51:15

@Pelesz: Nyilván manuális munka nélkül szeretném megoldani. Arra gondoltam, ha nincs kész megoldás wordben lehet egy makrot írni rá, ami a lábjegyzetet átteszi a szöveg mögé zárójelbe majd törli a lábjegyzetet.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.27. 07:28:09

@Nagy Levin: Én ezt nem tenném a helyedbe., vagy legalábbis nem addig, ameddig el nem olvasol egy ilyen módon tördelt könyvet (lábjegyzetek szögletes zárójellel beszúrva). Szerintem zavaróan megbontja a szövegképet/olvasási élményt, nem véletlen, hogy a szerző kiemelte a szövegtörzsből, főleg ha gyakran használta ezt a megoldást.

Nem véletlen, hogy a végjegyzet irányba ment el a világ, kis megszokás után teljesen élvezhető.

SaGa 2011.01.27. 07:40:22

@Pelesz: Nem az fb2, hanem a coolreader tudja az fb2-ben...
Az fb2 ugyanúgy végjegyzetet csinál a lábjegyzetből, ráadásul még külön body-ba is teszi a fájlon belül...

Pelesz 2011.01.27. 07:45:26

@SaGa: igazad lehet. :) Mindenesetre így kényelmesebb, az egyszer biztos.

kIára 2011.01.27. 11:44:57

@Dworkyll:
Csak egy ötlet.
Mi lenne, ha a táblázat legelső vagy legutolsó celláiba beszúrnátok egy-egy 1px magas és (n)px (mondjuk 260) széles képecskét? Ennél biztosabb szélességmegoldás nem jut eszembe.
Nálam működni látszik:
Border="1": data.hu/get/3443571/tablazat.mobi
Border="0" data.hu/get/3443573/tablazat_2.mobi

kIára 2011.01.27. 12:21:51

@Dworkyll:
A Háború és béke estén saját olvasásra én is meggondolnám a linkelt végjegyzeteket. Irdatlan mennyiségben tobzódnak (több mint 1200 jegyzet, önmagukban kitesznek egy kisregényt), a kindle meg bármennyire is gyors, az olvasási élményt teljesen tönkrevágja. Ebben az esetben a zárójeles megoldás sokkal hatékonyabbnak tűnik. Lásd:
mek.niif.hu/03100/03113/html/01.htm

Ha nem tudnék franciául, engem is halálra idegesítene a kindle navigálás.
Amúgy nem a szerző jegyzetelte, hanem a regény fordítója és szerkesztője. Pontosan ezért nem is szerves része a műnek.
Én Nagy Levin helyében előbb azt mérlegelném, hogy mennyi az én valós jegyzetigényem. Ha tud franciául, akkor azokat lehet törölni; ha a kultúrtörténeti utalások nagy része megvan: kuka; ha ismeri a történelmi korszakot, a sok történelmi adat: kuka.
Mondjuk nem is kell törölni ezeket, csak ellenállni a késztetésnek, hogy a jegyzeteket – amennyiben szellemi erőforrásaink engedik – _ne_ olvassuk.

Ignis_veneficus 2011.01.27. 13:45:47

@Dworkyll: (egymas utan het tabla)
a kov otletem van: egy nagy tabla az egesz, ket oszlopppal es a tablak kozott, ha szoveg van, akkor ott cellspan = 2
az 50% nem garantalt, de hogy a tablazatok osztasa ugyanott lesz az tuti..

Kiszámoló · http://kiszamolo.hu/ 2011.01.28. 13:14:46

A mobipocket az ékezetes betűimből más karaktereket gyárt, mindegy, hogy html, vagy pdf.

Karakterkódolást össze-vissza kettőt enged választani.

Hogyan kellene megoldani a gondot? Mi van roszul beállítva?

Előre is köszi.

tivkov 2011.01.28. 17:25:14

A K3 az egyszintű tartalomjegyzéket kezeli (alsó sáv,5 funkciós gomb j/b). Ha a MPcreatorral 3 szintet adok meg (h1,h2,h3), akkor a prc-ben a tartalomjegyzék ezt szépen mutatja is, de az ncx-be az első kerül be (h1). Hogyan lehetne megoldani, hogy választani lehessen a második vagy harmadik szint közül. Gondolom, a toc2ncx fájlt kéne manipulálni, de ahhoz nem értek. Van más megoldás?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.28. 20:46:18

@tivkov: És valóban. Van a toc2ncx-nek egy olyan változata (Ingnisnek hála) amelyik egy szintre lapítja a toc-ot, minden bejegyzés egy szintre kerül. Köll? :-))

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.28. 20:47:32

@Dworkyll: Ez addig jó lehet, ameddig a Kindle meg nem tanulja kezelni a többszintű toc-ot, ha egyáltalán.

tivkov 2011.01.29. 09:23:17

@Dworkyll: Megköszönöm, ha átküldöd. (kofalvi at gmail dot com). Én igazából arra gondoltam, hogy pl egy költő több kötetét a tartalomjegyzék alapján keresem meg, abban viszont versenként lépkedek, de az "Ignis-féle" nivellálás talán még jobb.

Atyaman 2011.01.31. 22:08:32

Megint egy kis segítségre szorulok :(

Hogyan oldjátok meg a 0-ás első sor behúzást? MS Worddel formázok, abból szűrt weblapba mentek, majd Mobipocket Creatorral készítek prc-t.
Út közben valami elromlik, mert a 0-ásból rendre ~1 cm-es első sor behúzások keletkeznek.
És ez igaz arra is, amikor a teljes bekezdést szeretném kb 3 cm-re behúzni. Ott is kb 1 cm-es behúzás jön létre.

Mit csinálok rosszul?

kIára 2011.01.31. 22:26:28

@Atyaman:
Ha MobipocketCreatorral eteted, akkor a html-ben:
<p width="0"> a tuti megoldás.
Ha kindlegen, akkor a sima css megteszi:
p { margin-left: 0; }
Ugyanígy, ha bármilyen értéket adsz, akkor a Creatornak:
<p width="n"> lehet em, px, %, pt stb.
kindlegenhez pedig:
p { margin-left: n; } itt is lehet em, px, %, pt stb.

Atyaman 2011.01.31. 22:43:09

@kIára: Köszi!
Kicsit sok meló lenne kikeresni az adott bekezdéseket a html-kódban és ott beállítani nekik a behúzást, így egyelőre azt csinálom, hogy készítek egy stílust, majd a html-ben a stílus leírásnál beállítom ezt az értéket:
text-indent:0pt;

Az ideális persze az lenne, ha a szövegszerkesztő után nem kéne turkálni a kódban. Gondolom ott lehet a kutya elásva, hogy a Wordben a 0-ás behúzás az alap, ezért ezt külön nem jegyzi be a html-ben, mig a prc esetén meg a ~1 cm-es behúzás az alap, ezért a konverzió azt alkalmazza.

SaGa 2011.02.01. 07:18:06

@Atyaman: Elég a html elejére beszúrni a

<style type="text/css">

p {text-indent:0
}
</style>

sorokat.

Nem a konverziónál, hanem a parsernél "romlik el" a dolog. A Kindle alapértelmezett <p> formázása a behúzott, ahogy van neki alapértelmezett h1, h2, stb formázása is...

Atyaman 2011.02.01. 07:26:21

@SaGa: Örök hála érte! Valami ilyesmi egyszerű megoldást kerestem ;)

SaGa 2011.02.01. 08:37:36

@Atyaman: pontosítom magam: a html headerbe (a <head> </head> közé valahova) kell beszúrni...
Ha nem akarsz nagyobb sorközt a bekezdések közé, mint azon belül, akkor a teljes bejegyzés így néz ki:

<style type="text/css">

p {
text-indent:0;
margin-top:0;
margin-bottom:0
}
</style>

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.02.01. 10:08:48

@SaGa: Én ezt nem tenném, legalábbis a text-indent:0; sorát. A behúzásnélküliség (tompasor) maradjon kivétel, a normál bekezdés legyen csak szépen behúzott.

Azaz a nem behúzott bekezdés lehet egy speciális class valahogy így:

p.noind { text-indent: 0; }

És aztán lehet így használni

<p class="noind">

Ignis_veneficus 2011.02.01. 10:18:13

@Dworkyll: a :first-child pseudo-class nem mukodik?
es akkor nem kell semmit jatszani, csak eleg fejezeteket kulon <div>-be rakni
www.w3schools.com/css/pr_pseudo_first-child.asp

kIára 2011.02.01. 13:40:17

@Ignis_veneficus:
Sajnos nem működik. Nekem is nagy bánatom ez, meg egyáltalán az, hogy a pseudo-class-ok nem működnek [legjobban a :before :after hiányzik].
Sajnos a mobi css-támogatása messze lemarad az epub formázások mellett, de nem biztos, hogy ez hátrány.
A puritán megoldások, és a szűkös lehetőségek több kreativitásra sarkallnak.

Amúgy engem a legjobban az zavar, hogy a H(n) tag-eket az istennek sem lehet lebeszélni a bold-ról, pedig sokszor kellene.

kIára 2011.02.01. 13:49:16

@Dworkyll:
Teljes mértékben egyetértek. A tompasor _mindig_ kivétel.
Egyszer belefutottam egy nagyobb prc-állományba, ahol minden könyv, minden bekezdése 0-ra volt állítva.      Rettenetesen zavaró, se pda-n, se pc-n, se e-inken nem mutat jól, és az olvashatóságon is sokat ront.

És eleve nem értem. Általában egy bekezdés több mint egy sor. Teret, karaktert nem lehet vele spórolni, mert az utolsó sor mindig kompenzál. ———
     Talán minden ezredik bekezdéssel lehet nyerni kijelzőként egy-két karaktert. Feltételezem, hogy aki ilyen bekezdéseket használ, annak nagyon pici lehet a kijelzője, vagy betegesen spórolós. ———

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.02.01. 13:56:18

@kIára: Őő, az úgy volt, hogy ezer éve, még 320x240 pixelen nagyon fájt a másfeles bekezdésugrás, és a mobi fejlesztők akkor azt mondták, hogy a megoldás a <br/> tag.

Ezzel viszont együtt jár a behúzástalanság, és jól megszoktam. Aztán jóval később bejött a nulla magas sor, és lehetett behúzást csinálni, és tetszett. Ma már az is zavar, ha nincsenek tompasorok. Öregszem, na ;-)

Ignis_veneficus 2011.02.01. 13:56:43

@kIára: Dobd ki. hasznalj helyette mast.
ha kell irok olyan xslt, ami lecsereli a <H(n)> -et <div class="H(n)">-re
es olyan formazast adsz neki amit akarsz.

kIára 2011.02.01. 14:13:53

@Dworkyll:
     Ööö nem hiszem hogy az említett prc-állományokat te készítetted, mert mind angol nyelvűek voltak.
     Amúgy igen. Emlékszem az őskorra amikor csak a <br>-rel lehetett a sortávot megszüntetni, és akkor én három darab &nbsp;-vel oldottam meg magamnak a behúzást. Mit mondjak, nem volt egy leányálom.
     Amúgy a mai napig én is használok egy 240×320-as kijelzőjű ipaq-ot, hiszen a régi szerelem soha nem múlik. Kicsi, kopott és a tenyeremhez nőtt. Kindle, okostelefon, subnotebook ide vagy oda barlangban, éjszakai sátorozáskor, vagy paplan alatt még mindig ez az igazi :)

kIára 2011.02.01. 14:15:40

@Ignis_veneficus:
Ezt tettem :) Vagy <div class="hn">, vagy ritkább esetben szimplán csak <p class="hn">

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.02.01. 14:45:40

@kIára: Ugye hogy ugye? A legnagyobb királyság ebben a műfajban a 214-es iPaq. Azt hittem egy HTC Desire, a maga 800x480 pixelével leveri, de nem. A Mobipocket for WinMo elég sokkal jobb, mint _bármi_ az Androidra.

Ignis_veneficus 2011.02.01. 16:14:18

@kIára: barlanban, ejszaka satrazasnal, en fenykepezogepet hasznalok alvannyal :)

Azert mondtam a cserelot, mert nem ismerem a mobi creatort, nem tudom miket esz meg fejezetcimnek..

SaGa 2011.02.01. 19:48:38

@Dworkyll: Én sem tennék 0-ás behúzást, maximum fejezetkezdőnek (ha már olyan jól meggyőztetek róla, hogy ez úgy jó), vagy felsorolásokhoz, de ez volt a kérdés, én meg válaszoltam.

Atyaman 2011.02.01. 21:15:53

Köszönöm a válaszokat!

Természetesen én, sem az alap bekezdéseket akartam 0-ra venni.
Tulajdonképpen felsorolást készítettem. A szereplők bemutatása történik a könyv elején. Az a megoldás túl unalmasnak tűnt, hogy "név: ismertetés^p". Így csináltam egy "izgalmasabbat": másfeles sormagasság minden bekezdésre, név balra igazítva félkövér betűkkel, ismertetés a következő bekezdésbe jobbra húzva normál betűvel, üres sor, majd a következő szereplő...
De úgy viszont hülyén nézett ki ha a név bevolt húzva. Erre kerestem a megoldást és ti egyszerre többel is szolgáltatok.
So again. Thanks! :)

Ignis_veneficus 2011.02.08. 08:48:07

Tudja valaki, hogy mit kell majd csinalni a tenyleges oldalszamozashoz, amit az uj kindle firmware ismer?
(kindlestuff.wordpress.com/2011/02/08/kindle-software-update-version-3-1-early-preview-release/)

SaGa 2011.02.08. 10:25:25

@Ignis_veneficus: Tudásnak ugyan nem nevezném, de némi nyomozás után annyit sikerült kitúrni a net bugyraiból, hogy a mobiban használható az epub-ban is ismert lapszámozási metódus. Gyanítom, ehhez építettek egy értelmező rutint a parserba.

Az epub-ban egy ncx-et kell létrehozni, a toc.ncx mintájára, ilyen szerkezettel:

<pageList id="page-mapping">

<navLabel><text>Paper Edition Page Mapping</text></navLabel>

<pageTarget id="page-iii" value="3" type="front" playOrder="82">
<navLabel><text>Page iii</text></navLabel>
<content src="frontmatter.html#pageiii"/>
</pageTarget>

<!-- ... -->

<pageTarget id="page-105" value="105" type="normal" playOrder="192">
<navLabel><text>Page 105</text></navLabel>
<content src="chap5.html#page105"/>
</pageTarget>

</pageList>

Ebből meg az következik, hogy a megfelelő <a> tag-eket létre kell hozni a szöveget tartalmazó fájlokban és ezeket kell összegyüjteni az ncx-be.

A kódot innen ollóztam:

www.epubbooks.com/blog/346/marking-up-page-numbers-in-the-epub-ncx

SaGa 2011.02.08. 10:26:53

@SaGa: Kiegészítés: ahogy elnézem, vagy a már ismert toc.ncx, vagy ez az oldalszámos. Bár lehet, hogy tévedek...

Atyaman 2011.02.08. 11:11:06

@Ignis_veneficus: @SaGa: A mobileread fórumról:

"Amazon is downloading a new file for each book called an .apnx. Amazon Page Number... Something. It's in the Documents folder just like the .mbp file. 2-4kb each. Something is also appearing called an .ea file? They aren't there for all my books yet."

Ignis_veneficus 2011.02.08. 13:55:13

@SaGa: @Atyaman: Akkor ezt beneztem. Azt hittem, hogy valami olyat csinaltam ami a kindleben alul nem a 12454-12485 as szamot jeleniti meg, hanem rendes jobb/kozepen/bal oldalszamot.
Nem pedig jelolom, hogy "ez az 5. oldal volt a papir konyvben"

Atyaman 2011.02.10. 01:04:35

@SaGa: Én is efelé az elmélet felé húznék. De most találtam vele egy kis bökkenőt.
Ránéztem azokra a könyveimre a kindle-ön amelyikeket ellátták oldalszámokkal és arra jutottam, hogy az .azw fájlokat nem töltötte le újra a k3. Csak az .apnx fájl tölti le (99%, hogy nem a könyv alapján készítí el a kindle, hanem letölti, mivel wifi nélkül nem jön létre).

Most akkor vagy hónapokkal ezelőtt megcsinálták a kiadványokban az oldalszámokat az <a> tag-ekkel (furcsa lenne imho), vagy itt valami csudát művel az .apnx (ezt meg el nem tudom képzelni, hogyan megvalósítható).

szakértőbb 2011.02.10. 01:33:05

@Atyaman:
Amazon:
" We’ve already added real page numbers to tens of thousands of Kindle books, including the top 100 bestselling books in the Kindle Store that have matching print editions and thousands more of the most popular books."

Atyaman 2011.02.10. 13:09:21

@szakértőbb: Persze ezt olvastam. De ez az írás is az új firmware-rel együtt jelent meg. Így ebből is két dolog következik. Vagy már régen elkezdték, vagy nagyon gyorsan tudnak vele haladni (vagyis gyors a folyamat vagy sok emberük van a melóra).

De amúgy persze, hogy valószínűbbnek tartom azt, hogy a könyvekben vannak a tag-ek és hogy az .apnx csak összegyűjti azokat. Csak eddig még semmi nem támasztja alá 100%-osan egyik vagy másik lehetőséget sem. Most még van egy ötletem, amiből talán kiderülhet, azt leelenőrzöm.

szakértőbb 2011.02.10. 13:33:22

@Atyaman:
Ez igy eleg izgalmas:-)
En is elmelkedtem rajta, szerintem a sok emberuk van ra, az nem jatszik.
Szerintem egy ideje elkezdtek mar, es most leptek tul egy eleg nagy hatart, hogy mar erdemes volt kijonni vele.

Egy tipp a nyomozashoz: ha tudsz egy regebbi konyvet (ahol meg ugye nem voltak), de amiben most mar vannak oldalszamok, annak az apnx-et a regi konyv melle teve mi tortenik?
Az is elkepzelheto, hogy az apnx tartalmazza a hozzarendelest, a konyvben meg nem valtozik semmi, hm?

En osszehasonlitanak egy "regi" es egy uj konyvet (ha lenne). De ezek csak tippek:-)

Atyaman 2011.02.10. 15:10:57

@szakértőbb: Próbálgatom, nézegetem.
Ugye az eredeti felvetésem az volt, hogy most vajon a könyvben vannak-e a tag-ek (ez az esélyesebb) vagy csak az .apnx tartalmaz az oldalszámokra nézve infot. Utóbbi fel sem merült bennem addig, amíg nem azt láttam, hogy 48 .apnx fájl jött létre a Kindle-ömön és 0! .azw. Ezt erősíti az is, hogy az egyik ilyen .azw-t leszedtem és kicseréltem avval, amit még múlt év októberében töltöttem le az amazonról (gondolva arra, hátha valami anomália miatt nem lett átírva a date modified az .azw fájlokban). Az oldalszámok így is megjelentek abban a könyvben (a wifi ki volt kapcsolva, szal tuti nem frissítette).
Szóval ha az .azw-ben vannak információk az oldalszámokról, akkor azoknak már 4 hónappal ezelőtt is ott kellett lenniük.

Ha a 48 könyv között akár csak 1 olyan lenne, ahol új azw fájlt töltött le, akkor tiszta sor lenne a megvalósítás (tag-ekkel), de most még ezt nem lehet 100%-osan kijelenteni.

Egy másik idetartozó probléma, ha tag-ekkel van megvalósítva az oldalszámozás és új .azw fájlt kell leszedni, mert a régiben még nem voltak benne ezek a tag-ek, akkor a jegyzeteink és highlight-jaink elvesznek?

szakértőbb 2011.02.10. 15:58:50

@Atyaman:
Nagyon mélyen nem gondoltam bele, de igazán bennem fel sem merült, hogy a tag-eket irják bele az összes könyvbe. Úgy érzem, összehasonlíthatatlanul néhezebb (több és macerásabb) munka lenne. A gyanumat leirtam:-)

>mert a régiben még nem voltak benne ezek a tag-ek, akkor a >jegyzeteink és highlight-jaink elvesznek?

ezt miért gondolod? mi köze a jegyzeteknek a tag-ekhez? Nem inkabb a poziciohoz kotodnek? (az meg fix)

Atyaman 2011.02.10. 16:02:13

A mobileread megint megoldással szolgál:

www.mobileread.com/forums/showthread.php?p=1385108

Ha jól értem. Az .azw fájlok tényleg nem tartalmaznak értékes információt arra nézve, hogy melyik oldalon járunk. Minden erre vonatkozó info az .apnx-ben van.

Sőt valószínűleg a következő Calibre verziban (0.7.45) már implementálnak egy epub-hoz hasonlatos verziót a mobi fájlokhoz. Azaz 1024 karakterenként lennének az oldalak következik.

Én ezeknek a fejleményeknek nagyon örülök. Bár jelenleg hidegen hagynak az oldalszámok, de jó tudni, hogy ilyen módon létrehozhatóak anélkül, hogy a prc/mobi/azw fájlba tag-eket kéne tenni minden egyes oldalhoz.
Tény hogy ha pontosan akarjuk csinálni az oldalszámokat megfeleltetve azokat egy könyv fizikai verziójának az hosszú és pepecs munka (effelől egy percig nem kételkedtem). De ha valakinek elég az epub-os oldalszámozás az pillanatok alatt megvan. Sőt szerintem biztos lehet majd olyan scriptet írni, aminek ha megadod, hogy egy könyvnél mondjuk 416 oldalt szeretnél, akkor megvizsgálja a forrást és az alapján lövi be, hogy hány karakterenként készítsen egy oldalt, hogy azok egyenletesen oszoljanak el 416 felé.

szakértőbb 2011.02.10. 16:13:48

@Atyaman:
eloszor egy kis adalek:
A Go To mar oldalszamozassal is mukodik (forras szinten a mobileread).

>De ha valakinek elég az epub-os oldalszámozás az pillanatok >alatt megvan. Sőt szerintem biztos lehet majd olyan scriptet >írni, aminek ha megadod, hogy egy könyvnél mondjuk 416 >oldalt szeretnél, akkor megvizsgálja a forrást és az alapján >lövi be, hogy hány karakterenként készítsen egy oldalt, hogy >azok egyenletesen oszoljanak el 416 felé.

hat, en meg mindig nem erzem, hogyan lehet ezt gyorsan csinalni, mert nem biztos, hogy az oldalak egyenletesen oszlanak el. Pl. rovid parbeszed egy oldlaon keresztul, es teljes sorok egy masikon, akkor nem egyenletesen 1024 karakter eg yoldal, hm? Illetve hogy teljesen megfeleljen ugyebar a nyomtatott kotetnek...

szakértőbb 2011.02.10. 16:26:12

Hat, azt irja asrac a mobilereade-en, hogy visszafejtette az apnx-et, valoban. Azert erdekelne, hogy is lesz ebbol oldalszam az elobb emlitett esetben:-)

Ignis_veneficus 2011.02.10. 16:31:49

@szakértőbb: Az epub sorok/karakterek apaljan szmol oldalt (az ADE), jol be is lehet szivatni, pl egy inline (XHTML-be agyazott) SVG-vel. A kep maga kb 200 oldal :)

szakértőbb 2011.02.10. 16:39:16

@Ignis_veneficus:
Koszi! ezert ertetlenkedem, mert egy nem egyenletesen elosztott szovegu konyvben maximum a "saccperkb" mukodik, de a szamolas nem, ha a papirkonyv tukorkepet akarjuk, nem?

A mobileread-en is utalnak erre egyebkent, hogy tobbe-kevesbe linearis. Na most ezt matematikus szemmel gondolkodva csak korbemosolyogni lehet, hiszen akkor most vagy megegyezik a papir konyvvel, vagy csak tobbe-kevesbe?! Utobbi esetben ertelmetlennek tartom.
Kivancsian varom, mi a trukkje:-)

Ignis_veneficus 2011.02.10. 16:47:18

@szakértőbb: En csak azt nem ertem, hogyha egy bongeszo meg tudja mondani, hogy az adott weboldal nyomtatva hany oldal, akkor ugyanezt egy ebook reader egy viszonylag egyszerubb strukturabol miert nem?

szakértőbb 2011.02.10. 16:53:55

@Ignis_veneficus:
szerintem egesz masrol beszelunk.
A Kindle is meg tudna mondani, hany oldal, ha csak szoveges. En amiatt furcsallom/gyanakszom, hogy a nyomtatott konyvvel kell szinkronban lennie. Tehat egy Amazon e-book eseteben az adott (es feltuntetett) ISBN szamu papir konyvnek felel meg. Na, ezt hogy csinalja? (ugy ertem, hogy csinalja, hogy algoritmussal, gyorsan, nem pedig minden konyvet kezzel vegignyalazva be irni az emlitett apnx-be:-)

Atyaman 2011.02.10. 17:01:35

@szakértőbb:
>>Pl. rovid parbeszed egy oldlaon keresztul, es teljes sorok egy masikon, akkor nem egyenletesen 1024 karakter eg yoldal, hm?<<

>>csak korbemosolyogni lehet, hiszen akkor most vagy megegyezik a papir konyvvel, vagy csak tobbe-kevesbe?! Utobbi esetben ertelmetlennek tartom.<<

Idézem amit eddig írtam:

>>Tény hogy ha pontosan akarjuk csinálni az oldalszámokat megfeleltetve azokat egy könyv fizikai verziójának az hosszú és pepecs munka (effelől egy percig nem kételkedtem).<<

>>De ha valakinek elég az epub-os oldalszámozás az pillanatok alatt megvan.<<

Én se látom nagyon értelmét az ilyen oldalszámozásnak, de ettől még vannak akik ezt szerették volna a Locations helyett.
Ráadásul ha nem a karakterek hanem a sorok alapján lehet létrehozni az oldalakat, ahogy Ignis_veneficus említette, azért az már egész jó közelítést ad. Ez pl. olyankor lehet hasznos, ha egyszerre olvasunk egy könyvet fizikai formában és a kindle-ön.

Atyaman 2011.02.10. 17:04:29

@szakértőbb:
>>(ugy ertem, hogy csinalja, hogy algoritmussal, gyorsan, nem pedig minden konyvet kezzel vegignyalazva be irni az emlitett apnx-be:-) <<

Rövid válasz: sehogy ;)

szakértőbb 2011.02.10. 17:08:30

@Atyaman:
En nem Veletek vitatkozom itt most, csak hangosan elmelkedtem:-) Az oldalszamozast tobben a publikaciokban torteno hivatkozasok miatt hianyoltak, viszont abban az esetben emlitett kozelito megoldas halottnak a puszi.

>Ez pl. olyankor lehet hasznos, ha egyszerre olvasunk egy >könyvet fizikai formában és a kindle-ön.

ezt nem egyszerubb egy sima search-el megoldani, hogy hol tartasz? erre firmware-t frissiteni, meg apnxet generalni??? haaaaaaaaaat...

Atyaman 2011.02.10. 17:21:28

@szakértőbb: Nem vitatkozott itt senki. Csak a kérdéseidre válaszoltam ;)

Sokan kérték referenci miatt az oldalszámokat, de mellettük vannak, akik csak szimplán a Locations-szel nem tudtak megbarátkozni, nekik bőven jó ez a megoldás is.

>>ezt nem egyszerubb egy sima search-el megoldani, hogy hol tartasz? erre firmware-t frissiteni, meg apnxet generalni??? haaaaaaaaaat... <<

Ez az egyik irányba működik. De a fizikai (DTB) könyvben nem nagyon tudsz keresni. :P
Firmware-t nem emiatt frissítesz. Én pl. azért tettem, mert kicsit javított a sebességen (lapozás és böngésző is), és a magazinok Layoutja frankóbb lett.
Ha az apnx generálása 3 sec akkor miért ne?

szakértőbb 2011.02.10. 17:29:51

@Atyaman:

>Firmware-t nem emiatt frissítesz. Én pl. azért tettem, mert >kicsit javított a sebességen (lapozás és böngésző is), és a >magazinok Layoutja frankóbb lett.

Te igen, de ez az elenyeszo kisebbseg, azt hiszem. A nepet az oldalszam huzza...
Ne feledd, ez csak egy Early Preview, nem igazi firmware frissites:-)))

>Ha az apnx generálása 3 sec akkor miért ne?

Akkor meg ket lehetoseg van: vagy nem igy csinaljak, ahoyg en (mi) gondoljuk, vagy ido kerdese, es valaki beszol, hogy a kiraly meztelen, mert nem jo az adott papir konyvvel valo szinkron

Atyaman 2011.02.10. 17:41:59

@szakértőbb: De te se feledd, hogy ha már nem Early Preview lesz hanem rendes Release, akkor az Amazon lenyomja a torkodon, ha be mered kapcsolni a 3G-t vagy WiFi-t :P
Persze annak függvényében, hogy a 3.0.2 és a 3.0.3 sosem lépett túl az Early Preview-n lehet, hogy a 3.1 sem fog. De ebben nem lehetsz biztos ;)

Az Amazon igenis végignyálazza a könyveket és megadja ISBN szám alapján, hogy éppen melyikre vonatkozik az oldalszámozás.
Amiről mi beszélünk az egy olyan alternatív felhasználás, ami valakiknek hasznos lehet, míg a többséget nem hozza lázba.

szakértőbb 2011.02.10. 17:46:47

@Atyaman:
>akkor az Amazon lenyomja a torkodon, ha be mered kapcsolni >a 3G-t vagy WiFi-t :P

ez majd akkor kiderul:-))

>Az Amazon igenis végignyálazza a könyveket

akkor most vegul is kideritettuk, hogy kezzel vegignyalazzak, es ugy csinaljak az apnx-et?
az elobb ezt irtad: "Ha az apnx generálása 3 sec akkor miért ne?" felreertelek?

Atyaman 2011.02.10. 17:56:20

@szakértőbb: Személy szerint nem tudtam ellenőrizni (könyv hiányában), hogy az amazon pontosan csinálja-e az oldalszámozást, de ettől függetlenül még egészen biztos vagyok benne hogy nem csak egy pontatlan generálás alapján. Ha nem lenne igazam, akkor vállalom, hogy a blogtalin betérdelek a sarokba 3 percre ;)

Amit a gyors generálásról írtam, az a saját készítésű könyvekre vonatkozik.

szakértőbb 2011.02.10. 18:01:47

>Ha nem lenne igazam, akkor vállalom, hogy a blogtalin >betérdelek a sarokba 3 percre ;)

ok, erre majd visszaterunk:-)
De szerintem nem dontottuk el, mi is a megoldas, csak ugytunt nekem, mintha azt sugallnad, hogy automatikus. En meg azt, hogy fogalmam sincs, de pontosan/konyvenek megfelelve - algoritmussal - nem tudom egyelore, hogyan csinalhatjak.
Ha nem lenne igazam, szivesen atadom akkor is Neked a sarokba terdelest:-)))))

Atyaman 2011.02.10. 18:23:39

@szakértőbb: Szerintem meg egy percig nem sugalltam, hogy automatikusan a megoldás. Tudom, hogy snassz kétszer is ugyanazt idézni magamtól (;-)), de szerinted ez a mondat az automatikusságot sugallja?

>>Tény hogy ha pontosan akarjuk csinálni az oldalszámokat megfeleltetve azokat egy könyv fizikai verziójának az hosszú és pepecs munka (effelől egy percig nem kételkedtem).<<
(és az Amazon szerintem pont ezt csinálja)

vagy ez a válaszom is elkerülte a figyelmedet?

>> >>(ugy ertem, hogy csinalja, hogy algoritmussal, gyorsan, nem pedig minden konyvet kezzel vegignyalazva be irni az emlitett apnx-be:-) <<

Rövid válasz: sehogy ;)<<

A mobileread-en olvasott .apnx visszafejtés óta. Az automatikusságról annyit állítottam csak, hogy az epub oldalszámozás mintájára (az sem felel meg a könyvek oldalszámainak!) készíthetünk ezentúl a mobi könyvekhez is ilyet. Ezt a funkciót te és nem tartjuk hasznosnak (mondjuk egy felhasználási lehetőséget találtam, amennyiben lehet kicsit módosítani azon, hogy milyen távonként jöjjön létre egy oldal, ami által közelíthető a fizikai példány számozása), de ettől még vannak mások akinek tetszik és szeretnének ilyet. Nekik pedig tök jó :)

szakértőbb 2011.02.10. 18:38:30

@Atyaman:
Tökjó, ahogy el tudunk beszélni egymás mellett:-))
Nem kétlem, hogy nehéz a felfogásom, de szerintem nincsen az amazonnak egy rabszolga serege, aki mondjuk kézzel nézegeti at az egymillió könyvüket es kézzel rendeli hozzá a papir oldalszámokat az elektronikus verziokhoz. (Persze, lehet, hogy tevedek, es van:-))

>de ettől még vannak mások akinek tetszik és szeretnének >ilyet. Nekik pedig tök jó :)

ebben igazad van. De itthon is es kulfoldon is van olyan blog (es szamtalan igeny), ami a tudomanyos/oktatasi celu hivatkozast hianyolja/targyalja. Erre az ilyen nem lenne megfelelo.

>(az sem felel meg a könyvek oldalszámainak!)

az Amazone megfelel, azert adjak meg, melyik ISBN-u konyvbol keszult az e-book.
Akkor egyelore marad a rejtveny megoldatlan - szamomra.

Atyaman 2011.02.11. 21:58:50

Újfent MobileRead-es találat. Valaki (goaspy) készített egy .apnx generátort. Pont az sült ki belőle, amit fentebb emlegettem. Megadod azt, hogy mennyi Location-öd van, hogy hanyadik Locationtól menjen a számozás, hány oldalt szeretnél + az ISBN számot, bár ez utóbbinak nulla értelme van :D
Ezután generálhatsz egy .apnx fájlt, amit a kindle-ön a könyved mellé teszel, majd átnevezed az .apnx-et a könyv nevére.

Kipróbáltam, müxik. Ja és nyilván 3.1-es firmware kell hozzá (hátha valaki nem olvasta az előzményeket).

Itt a link:
www.mobileread.com/forums/showpost.php?p=1388963&postcount=18

Atyaman 2011.02.11. 22:40:28

És ha már lúd legyen kövér! Kijött a 0.7.45-ös Calibre is. Az új feature-ök között pedig:

- Kindle driver: When uploading MOBI files to the device, upload page number information as well (used by the not yet released Kindle 3.1 firmware)

szakértőbb 2011.02.12. 12:36:40

@Atyaman:

>Pont az sült ki belőle, amit fentebb emlegettem. Megadod azt, >hogy mennyi Location-öd van, hogy hanyadik Locationtól menjen >a számozás, hány oldalt szeretnél + az ISBN számot, bár ez >utóbbinak nulla értelme van :D

Tenyleg nem erted?
Nem az volt a kerdes, hogy a Location szambol hogyan csinalsz oldalszamot, az sima matek. Az a kerdes, ez hogyan fog megegyezni az adott (egyaltalan nem felesleges ISBN-u) konyv oldalszamozasaval:-)))
Mit csinalsz, ha mondjuk 1024-el osztogatod az oldalakat, de pl. egyes oldalakon feloldalas kep van, mashol valamiert mas betumeret/stilus/felsorolas, mittudomen es nem 1024 karakter lesz az oldalon?
Meg egyszer: nem az a lenyeg, hogy valamilyen oldalszam legyen az oldalon, hanem megfeleljen a megadott ISBN-szamu kiadassal beturol beture. Kulonben nem tudsz hivatkozni ra helyesen.
Homogen szoveg eloszlasu konyveknel (hu de szepen hangzik) valoszinuleg/talan nincs gond.

szakértőbb 2011.02.12. 12:49:26

Hogy megerthetobb legyek:

ha peldaul megvan Oriana Fallaci: Ha meghal a nap cimu konyve, es azt mondom, tokjo poen van a 227.oldalan, sokra mesz vele, mert Neked meg a 2 kotetes verzio van meg ugyanabbol, ami ugye nem hasonlit a nekem meglevore oldalszamozasban:-)
Es ha generalunk egy harmadik kiadasbol egy ujabb oldalszamozast, az tokjo erzes lehet (sokaknak), de az ertelme valahogy nem latszodik (nekem):-)

En csupan ezert firtattam, mi lehet a megoldas, hogyan csinaljak ezt az Amazonok?!

szakértőbb 2011.02.12. 12:55:15

Par felvetes idezes ugyben:

blog.apastyle.org/apastyle/2009/09/how-do-i-cite-a-kindle.html

Citing Kindle text in formal papers
www.mobileread.com/forums/showthread.php?t=43949

"With academic texts, there is usually only either a hardcover or paperback version or, if both, the page numbers will still match so there is no confusion with citations. A Kindle edition with locations, or an ePub edition in which the page numbers vary from the print book, makes checking citations an unreliable process."
www.mobileread.com/forums/showthread.php?p=1384302

Atyaman 2011.02.12. 13:30:34

@szakértőbb: Kezd már kicsit fárasztó lenni...

Ha nem hozzád címzem a közlendőm valószínűleg nem a te kérdésedre válaszolok. Pláne, hogy ha az általad felvetett kérdésre mondanék valamit, jó eséllyel beidézem a szóban forgó kérdést.

Jelen esetben erről volna szó:

>>En csupan ezert firtattam, mi lehet a megoldas, hogyan csinaljak ezt az Amazonok?!<<

Ezt a kérdést már elég alaposan túl tárgyaltuk, amíg újabb információk nem derülnek ki addig már tényleg nem akartam vele foglalkozni.
Most megint foglaljam össze, hogy mire jutottunk? Rendben van:
Szerintem az Amazonnak végig kell mennie a könyveken kézzel és úgy készítik. Ez alól egy kivétel lehet, ha a kiadótól megkapják a könyvet valami olyan formátumban amiben a nyomdába küldenék, azaz amiben már megvannak az oldaltörések és az oldalszámozás, erre már lehet írni valami algoritmust. Talán újra scannelik a könyveket, és abból ollózzák ki algoritmussal. Bármelyik verzió elképzelhető, sok okos ember dolgozik ott.

Amiről én beszéltem és folyamatosan hangoztattam is, az nem jó arra, hogy forrás megjelelöléskor oldalakra hivatkozzhass, ezt elmondtam párszor, de ettől még egy hasznos dolognak tartom. Szóval nem kell az oktatásod arról, amit tudok és én is felhívtam rá a figyelmet. Kössz.

szakértőbb 2011.02.12. 13:47:30

@Atyaman:
Szia!

csak ketten beszelgettunk itt mar jo nehany hozzaszolas ota, engem meg nem faraszt.

Meg egy hozzaszolason belul sem tudsz megegyezni magaddal, mi is az allaspontod:-)

>Szerintem az Amazonnak végig kell mennie a könyveken >kézzel és úgy készítik..

aztan

>Amiről én beszéltem és folyamatosan hangoztattam is az nem >jó arra, hogy forrás megjelelöléskor oldalakra hivatkozzhass,

AZ volt a kerdes, az Amazon hogyan oldja meg. Nem kivantalak oktatni, csak felhivtam a figyelmet arra, hogy a jelzett modszer nem az, amire szuksege van sokaknak - ergo nem is valasz a kerdesre, akarmennyit is hangoztatod.

Atyaman 2011.02.12. 14:14:02

@szakértőbb: Attól még, hogy egy ideje csak mi kettenk szólunk hozzá ehhez a poszthoz, az nem jelenti automatikusan azt, hogy csak neked szól, amit írok. Ha így lenne, akkor privátban tenném.

Az .apnx generálás szerintem hozzá tartozhat a mobipocket készítéshez, ezért bátorkodtam itt írni a fejleményekről.

NEM. Hangsúlyozom NEM mondtam ellent a saját állításaimnak!

Az, hogy az Amazon pontosan készíti az oldalszámozást adott ISBN számú könyv alapján teljesen más lapra tartozik, mint hogy Jóska Pista, otthon a házi készítésű mobi fájljához generál egy olyan alapokon nyugvó oldalszámozást, mint ami az átlag epubokban van.

AZ pedig a te kérdésed volt, hogy az Amazon hogyan oldja meg. És legalább 3x válaszoltam rá, hogy NEM TUDOM. Ötleteim voltak: van rá valami algoritmusuk vagy van egy rabszolgaseregük.
De olyan algoritmus jelenleg nincs, amivel egy átlag user otthon pontosan tudjal generálni az oldalszámokat.

Ezért van az, hogy amit mutattam .apnx generátor nem válasz az általad felvetett kérdésre, MERT AVVAL NEM A TE KÉRDÉSEDRE VÁLASZOLTAM! Fogd már fel, légyszíves!

Ezt pedig fejezzük be végre, mert csak ugatjuk a semmit, miközben teljesen szét OFFoljuk ezt a fontos topikot! Úgyhogy részemről ennyi.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.02.12. 23:41:17

Bélaim az Úrban, egy évben egyszer megyek le a hálóról, ti meg rögtön hajba kaptok ilyen finoman szólva is csak kísérleti stádiumban lévő fejlesztésen?

Irgum burgum :-))

Egy picit még legyetek türelemmel, amíg öszehozzuk a fórumot, vagy vonuljatok el jól a Dühöngőbe gumicsontokon csatázni.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.02.12. 23:47:56

@Ignis_veneficus: Pont ezzel szívok, kicsit más origóból. A böngésző azért tud lapszámot mondani, mert az adott nyomtatási beállításokból (fontméret, margók, lapméret stb.) csinál egy virtuális nyomtatást, és megszámolja a virtuális lapokat. Megváltoztatod a paramétereket, és változik a lapszám.

Az Amazonos lapszám-indexhez meg, az idézhetőség végett tuti tartozik valami olyan procedúra, ami végigmegy mondjuk az ISBN-nel egyedileg azonosított forráskiadvány mondjuk pdf változatán, és abból generálja ki azt a fránya indexállományt.

De csak spekulálok. Még a location-t is csak arra használom, hogy nagyjából lássam, mekkora egy anyag. Nekem mindig faltól falig ér a progress-bar, nektek nem? :-))

szakértőbb 2011.02.13. 12:01:24

@Dworkyll:
Elnezest kerek az OFF-ert, Atyamantol es a nagykozonsegtol egyarant!

tivkov 2011.02.22. 22:26:40

Mobipockettel készítettem olvasnivalómat és nagyon elégedett voltam szolgáltatásaival, különösen szerettem a TOC kezelését, amiben nagy segítséget jelentett a blogon közölt sok megoldás. Az IE9 RC telepítése után meghalt a MP-ben a TOC készítés számomra értelmezhetetlen hibaüzenettel. Ezután a Calibre új verziójával (0.7.46) kezdtem ismerkedni. A szöveg előkészítése ua. mint korábban, de a program működése számomra konfortosabb. A blogban is közzétett plug-in segítségével többnyire lejönnek a könyv metaadatai - nem kell gépelgetni, keresni :) - lejön a borító is. A TOC beállítás is egyszerű és egyből működik a fejezetléptetés is. A 3.1-et használom és igy az oldalszám is automatikusan jelenik meg. Habár ezt nem tudom hogyan csinálja, mert egy-két könyvnél megnéztem az ugyanolyan ISBN számu papírost és eltérést láttam (ez most azért nem különösen izgat).Érdekes volt számomra, hogy a programon keresztül átküldött könyveket a K3 documents mappájában külön alkönyvtárakba rakta. A K3 ezeket ugyanúgy kezeli, mint a könyvtár káoszában lévő többit.
Próbaképp beállítottam néhány hírpoltált is (HVG, ÉS,TechNet, Computer act!v) és feltettem szerverre, ahol az éjszakai forgalommentes időben ráér gyüjtögetni és küldeni. A reggeli mellett már látom is az új híreket.
Mindezeket alternativaként írtam le, van élet a MP után/mellet is :).

gh14 2011.02.27. 09:58:53

Hola!
A MP Creator nem működik IE9-cel? Van erről valami info?

Vlaci69 2011.03.17. 18:08:22

Innen-onnan ráugrott a gépemre néhány PRC állomány. Tele vannak helyesírási és egyéb hibákkal, ami engem nagyon zavar. Szívesen szánnék időt a javítgatásra, de nem tudom, hogy lehetne editálható formába visszafejteni a szöveget. Ha esetleg valakinek van rá eszköze, boldog lennék, ha segítene.

Atyaman 2011.03.17. 18:32:29

@Vlaci69: Próbáld meg Calibre-rel pl. rtf-be konvertálni.

calibre-ebook.com/download

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.03.17. 20:57:02

@Vlaci69: Sajnos kelleni fog a forrás, ha content encryptionnal csinálták. Ekkor se a calibre, se a Kindle previewer nem nyitja meg.

Kérdés, hogy ilyenek-e ezek a prc-k, vagy se.

SaGa 2011.03.18. 09:29:21

@guti.haz14: Kipróbáltam, működik...
Windows 7 64 bit, IE9 64 bit, MPCreator 4.2 Build 41

gh14 2011.03.18. 16:53:53

@SaGa: Tartalomjegyzéket is csináltál? Mert nálam annál bukik ki.
Szintén Win7 64bit, IE9, MPCreator 4.2 Build 41

tivkov 2011.03.18. 18:53:44

@guti.haz14: Nálam is a tartalomjegyzéknél szállt el, viszont a Calibre tök jól műkszik.

SaGa 2011.03.19. 07:45:53

@guti.haz14: Azt nekem sem...
A fene...

Mindegy, mivel szép lassan átállok az epub-ból kindlegennel gyártott mobi-kra, annyira nem tragikus veszteség, illetve virtuális gépen van xp, IE8-cal, ha kell megcsinálom azon.

gh14 2011.03.19. 10:39:25

@SaGa: Én is csináltam egy virtuális XP-t, amin nincs is más csak a MP Creator.

Mennyire szeretnék egy olyan szoftvert, ami egy jól megformázott .doc-ból egy lépésben készít jó .prc-t.
A címsorokból, vagy stílusokból vett tartalomjegyzékkel, esetleg a fejezetek jelölésével progresbar-on...

Álmodozni jó! :)

SaGa 2011.03.19. 11:14:59

@guti.haz14: Jól megformázott doc-ból egy lépésben (na jó, kettőben) a creator megcsinálja, de ennek vannak feltételei:

1: a creatorral közös XP-n legyen egy word (azt hívja meg és azzal alakíttatja át html-lé a forrás doc-ot)
2: legyen fent az Ignis által készített mbp_toc.html-ből toc.ncx-et generáló script és a hozzá szükséges dolgok...

Az mbp_toc.html-t egy jól összerakott (tehát a címsorok címsor 1, címsor 2, címsor 3... stílusokkal szerelve) doc-ból a szokásos h1, h2, h3 tag-ből tartalomjegyzéket generáló saját rutinjával megcsinálja a creator.

Gukker 2011.03.19. 11:28:07

@SaGa:
Két lépésben Calibre-vel is lehet. DOC-HTM-MOBI.
Sőt ha a Wordben eleve csak a htm-et használod akkor doc sem kell.
Bár őszintén nem értem mi ez a rugózás a tartalomjegyzéken. Az esetek 99%-ában semmi szükség rá. (Jójó, tudom ott az az 1% :)

Atyaman 2011.03.19. 12:32:31

@Gukker: Habár ezt a 99%-ot erős túlzásnak tartom, de hajlok arra, hogy egyetértsek veled abban, hogy sok esetben nincs igazán szükség a tartalomjegyzékre (egy kezemen megtudom számolni hányszor használtam az elmúlt évben mióta van olvasóm).

A rugózás szerintem azért megy rajta, mert vagyunk páran, akik a tökéletesre törekszünk. Ehhez pedig hozzátartozik a toc.

Egy másik vonzata pedig az ncx, ami szerintem(!) "must have". Legalábbis antológiák esetén, ahol így gyorsan lehet navigálni és be tudjuk lőni milyen hosszú egy adott novella. De én még regényekben is szeretem tudni, hol tartok az adott fejezetben, milyen messze van a következő. Az ncx-et pedig jelenleg a toc-ból buheráljuk ki.

Gukker 2011.03.19. 12:34:36

@Atyaman: a tocot még tudom, de miazaz ncx?

elminster 2011.03.19. 12:49:53

@guti.haz14:
>>Mennyire szeretnék egy olyan szoftvert, ami egy jól megformázott .doc-ból egy lépésben készít jó .prc-t.
A címsorokból, vagy stílusokból vett tartalomjegyzékkel, esetleg a fejezetek jelölésével progresbar-on...

Álmodozni jó! :)<<

Épp a napokban keresett meg egy illető, aki vette a fáradságot és a kipucolószkriptet átírta C#-ra, és afelől érdeklődött, hogy érdekel-e valakit a dolog, és hogy merre tovább lehet fejlődni.
Megkapta válaszul, hogy ha tovább szeretné fejleszteni, akkor egy komplett Kindlegen-GUI program készítéséért istenként fogják imádni. Hát ez bejött.

Most már csak meg kéne írni azt a GUI programot, ami mondjuk szűrt-HTML word forrásból minden pucolást-átalakítást megcsinál, tartalomjegyzékeket fabrikál, és összeállítja az OPF-et, hogy az egész csomag megetethető legyen a Kindlegen-nel a régi ósdi MP Creator teljes kihagyásával.

Atyaman 2011.03.19. 13:01:57

@Gukker: Az ncx a virtuális tartalomjegyzék kiterjesztése. Ez a toc.ncx fájl, amit ha befűzöl az .opf-be, akkor lesznek kis pöttyeid a progressbar-on (vagy sem, amennyiben több szintű az ncx), amik a fejezeteket jelentik és lehet köztük navigálni a kurzor gombokkal.

Gukker 2011.03.19. 13:07:03

@Atyaman: Ah, így már értem. Azért ez így... hogy is mondjam... kicsit körülményes dolog, nem?
Novelláskötetekre/cikkgyűjteményekre meg teljesen jogos a toc, visszaszívom amit mondtam :)

Atyaman 2011.03.19. 13:07:38

@Gukker: Még annyit hozzátennék, hogy ha Calibre-rel dolgozol (úgy sejtem ezt használod, de javíts ki ha tévedek ;-)) az automatikusan megcsinálja az ncx-et, ha talál vagy tud készíteni tartalomjegyzéket. A MPC-nál viszont külön kell elkészíteni majd befűzni az .opf-be mert azt nem csinálja meg. Kindlegen-nél nem tudom, hogy történik a létrehozása vagy befűzése :$

Ignis_veneficus 2011.03.19. 13:11:43

@guti.haz14: Nekem van cuccom, ami jol megformazott word-bol egy lepesben epub-ot csinal, es fejlesztes alatt a mobi valtozat is.
(sajnos nem publikus)

@Gukker: toc a tartalomjegyzek html-ben.
az ncx ugyanez "kodoltan".
A ketto kozott az a kulonbseg, hogy a toc-ban barmi elofordulhat, barmilyen formazasban, strukturaban, addig a ncx-nek nagyon szigoru szabalyai vannak (es ennek kovetkezteben egyszerubb is).
A toc-ot renderelni kell (mint egy tetszoleges html oldalt), addig a ncx (a szabalyok miatt) feldolgozható, es olyan infok nyerhetoek ki belole, mint a progressbar.
(normalis olvasoban elvarhato lenne a toc mellozese es az ncx hasznalata tartalomjegyzeknek, lasd ADE az epub-al. szemben a kindle-vel ami megkoveteli mindkettot)

Atyaman 2011.03.19. 13:12:20

@Gukker: Ne szívd vissza ;) Nagy vonalakban egyetértek vele, csak soknak tartottam a 99%-ot :)

Egy kicsit körülményes ez így van. Ezért volt guti.haz14 első felvetése, hogy milyen jó is lenne egy olyan progi, ami egy lépésben megoldja ezt a macerát.
Jelenleg ehhez szerintem a Calibre áll a legközelebb, csak nem ástam bele magam az ottani toc készítésbe és testre szabhatóságba, ezért használom a MBC-t és készítem makróval az .ncx-et.

Gukker 2011.03.19. 13:12:33

@Atyaman: Calibre-t használok, de ennyire mélyen nem merültem bele, hogy tartalomjegyzéket is készíttessek vele. Túl bonyolultnak tűnt és szükségem sincs rá.
Őszintén én az opf file-okat nem is szoktam a Kindle-re másolni.

Az opf-et (ha van benne info) használja is a Kindle?
Láttam már olyan mobi file-t, amihez nem volt opf mégis voltak benne fejezetek, azt hogy csinálják?
A MPC miben/mennyivel jobb a Calibre-nél?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.03.19. 13:12:48

@elminster: Jövök bétateszternek!! :-)

Annyi kéne még, hogy a headig formázó css-t is magára tudja húzni, és akkor tényleg minden nap imádkozni fogok érte.

Meg kéne egy kicsatolás a html utolsó simogatására, a tompasorokat most azzal vezérlem.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.03.19. 13:15:49

@Gukker: az opf a munka vagy projektállomány, ami összehúzza a publi részeit, szöveg, toc, fedlap, képek stb, a prc-be. Értelemszerűen ezt nem kell fölrakni az olvasóra, mert ebben csak a hivatkozások vannak.

A MPC csinálja ezt, de nincs felülete az ncx kezelésére. Kézzel (scriptekkel) kell belehegeszteni az ncx hivatkozást.

Gukker 2011.03.19. 13:16:17

Igazatok van egyébként, mert a poszt címe "Hogyan csináljunk igényes mobipocket publikációt?" és az igényesbe bele tartozik a toc is. :)

gh14 2011.03.19. 13:21:45

@SaGa: akkor lehet én vagyok béna, de nekem több lépés.
1. Doc mentése szürt weblapként
2. Html betöltése a MP Creatorba
3. Tartalomjegyzék létrehozása
4. Metaadatok feltöltése
5. Build
6. Ncx generálás
7. Ncx beépítés
8. Build
És kész!

Atyaman 2011.03.19. 13:24:17

@guti.haz14:

>>5. Build<<

Elég preview-ban megnézni a toc.html-t és menteni a projectet. Build-elni ezen a ponton szerintem felesleges.

gh14 2011.03.19. 13:25:39

@Gukker: nekem a Calibre nem igazán jött be. Soha nem úgy nézett ki, ahogy akartam.

@elminster: Hááát biztos sokan imádnák - köztük én is.

@Ignis_veneficus: felcsigázol, és utána azt írod, hogy nem publikus:).

gh14 2011.03.19. 13:28:32

@Atyaman: OK. Az eredeti leírásban így volt, ha jól emlékszem.

Gukker 2011.03.19. 13:28:58

@guti.haz14: Nekem nem volt ilyen bajom a Calibre-vel, bár én csak sima regényeket csináltam. Lehet, hogy az olvasó parserétől is függ.

SaGa 2011.03.19. 13:43:14

@elminster: Van ilyen, úgy hívják: Sigil. Igaz, nem prc-t, hanem epub-ot gyárt, de ezt aztán szépen kicsomagolva bele lehet tolni a kindlegenbe.

Ahhoz, hogy ne legyen elszállt a dolog (ne legyen túl epubos) csak annak a feltételnek kell megfelelni, hogy minél kevesebb formázást tegyél a doc-odba. Pl a bekezdések távolságát csak felső margóval állítsd be, az alsó margó mindenütt 0 legyen.

Amit utoljára küldtem Neked, az úgy készült, hogy a sigilből kijött epub-ból kiszedtem kézzel a fontokat (meg a hivatkozásokat rájuk a content.opf-ből), kihajítottam az epub styles.css-ét és beraktam helyette egy mobi-hoz leegyszerűsített verziót, majd az egészet áttoltam a kindlegenen. A mobipocket creator is megette változtatás nélkül, ráadásul a tartalomjegyzéket sem a MPCreatorral gyártottam, hanem benne volt az epub-ban.

Ennél kicsit hosszabb volt a dolog, de amit még kézzel kellett csinálni, az elég jól automatizálható. A fontok kiszórása, az egyes html-ekből a sigil által beillesztett stílusok (alapvetően az italic-ot oldja meg úgy, hogy tesz a headerbe egy sgc-x stílus definíciót és a szövegben az i /i teg-ek helyett ezt span-olja) kicserélése megfelelő tag-ekre, a styles.css kicserélése a megfelelően összerakottra, stb.

SaGa 2011.03.19. 13:44:38

@Atyaman: A kindlegennél mindent neked kell a content.opf-be belerakni, mert ő csak arra képes, hogy amit ott talál, azt feldolgozza. Kiegészíteni nem fogja...

elminster 2011.03.19. 13:45:45

@guti.haz14:
Nem vagy béna, ez tényleg ennyi lépés egyelőre.

Azért is lenne jó egy komplett Kindlegen-GUI-t hegeszteni, mert egyrészt a kindlegen lett az új mobi szabvány, de az csak egy parancssori izé, amihez a csomagot kézzel kell összeállítani. Másrészt egy saját GUI (gyk.: Graphics User Interface) eleve tartalmazhatná azokat a kiegészítő szkripteket, amivel jelenleg a MP Creatort megtámogatjuk kívülről.

Viszont elismerem: tényleg nagy munka egy működőképeset írni, ami mindent megcsinál a kedves felhasználó helyett, neki csak kattintgatnia, meg esetleg a hiányzó adatokat beírnia kell. (Azt is csak addig, amíg nem építjük be a metaadat keresőt, mert azután már csak ellenőrizni kell, hogy a jó könyvét találta-e meg a neten.)

SaGa 2011.03.19. 13:48:27

@Gukker: Ácsi! valamit félreértesz. Az opf egy leíró fájl, ami tartalmazza a prc-be (epubba) építendő fájlok listáját, azok "szerepkörét" (tartalomjegyzék, borító, impresszum, stb...) és a metaadatokat. Anélkül nem készül el a prc. Amikor elkezded a dolgot a MPCreatorral, akkor ilyened nincs, majd a creator előállítja és felhasználja.

SaGa 2011.03.19. 13:51:07

@guti.haz14: Ebből a folyamatból az 1-5 és 8. lépéseket az MPCreator megcsinálja maga (igaz neked kell kézzel beállítanod, hogy melyik jpg a borító, meg kitöltened a metaadatokat és a tartalomjegyzék alapadatait), azaz számomra ez egy lépés.
Ha ncx-et is akarsz, akkor az a másik...

SaGa 2011.03.19. 13:53:42

@SaGa: Kiegészítés: amit a sigilből kiesett epubon utómunkaként kézzel megcsinálok, az nem kötelező, csak tudom, kissé elbonyolítottnak tartottál pár általam elkövetett prc-t, így inkább egyszerűsítem, de a végeredmény kinézetében nem jelent változást, csak a forrás lesz visszafogottab, a mobi "szabványhoz" közelibb...

gh14 2011.03.19. 13:53:49

@elminster: gondolom, hogy nem könnyű ilyet írni, mert ha az lenne valaki már megcsinálta volna.
Viszont sok felhasználónak jelentős könnyebbséget jelentene. Főleg az olyanoknak, akik annyira azért nem járatosak ezekben a dolgokban.

Atyaman 2011.03.19. 17:21:08

@SaGa: Most már ezt is tudom. Köszi ;)
Hasznos lesz ha egyszer én is átállok a MBC-ről a Kindlegen-re.

Ignis_veneficus 2011.03.20. 11:18:55

@guti.haz14: Valamibol nekem is elnem kell ;)
De azert otleteket adhatok:
pl a OpenOffice (vagy most mar LibreOffice) tok jol konvertal Rtf, Doc-ot XML-e... Azt pedig tok jol lehet feldogozni pl XSLT-vel.

erasmus4 2011.03.20. 17:22:21

OCRezés után megnyílik wordben a szöveg de a gondolatjeleket automatikusan felsorolássá alakítja a word, megpróbáltam kikapcsolni ezt a funkciót de nem jött össze. Ha legalább le lehetne cserélni de nem jöttem rá hogy lehet a felsorolásokat lecserélni. Valami tipp?

gh14 2011.03.20. 18:04:08

@erasmus4: korábban feltöltöttem egy word makrót, ami a felsorolásokat megszűnteti, és kötőjelet tesz a sor elejére. Valamelyik makró posztba ha jól emlékszem. Nem tudom használta-e már valaki, nem kaptam semmilyen visszajelzést, de nekem jól müködik.

miklos0514 2011.03.20. 18:13:10

@guti.haz14: Megtennéd, hogy felteszed újra? Sajnos találkoztam már olyan jönyvvel, amihez szükséges lett volna a felsorolás átváltoztatása kötőjellé.köszi

SaGa 2011.03.21. 10:25:39

@erasmus4: Lecserélni igazából egyenként tudod csak.
Az ocr programodat és a word-ödet kell beállítani, hogy ne alakítsák automatikusan felsorolássá a gondolatjellen kezdődő sorokat. A wordben ezt úgy lehet beállítani, hogy az automatikus javítás konfigjánál megmondod, hogy a listákra nem érvényes.

Ignis_veneficus 2011.03.21. 14:19:09

@erasmus4: OOo, vagz libreoffice:
megnyitod, kimented a sajat formatumaba.
atnevezed Zip-re, majd kicsomagolod belole a content.xml file-t
megnyitod valami XML szerkesztovel es a kis turkalas utan megtalalod benne a felsorolast (asszem <text:list> vagy hasonlo, most nincs nalam egy sem, hogy megnezzem) es azokat kell lecserelni. (es a kornyezetet atnezni, mert a listat be is vezeti valami)
Ezt kovetoen elmenteni, visszacsomagolni, visszanevezni, es ujra meg lehet nyitni OOo-val, es visszamenteni rtf-be vagy doc-ba, vagy amibe akarod.
(a fenti modszert meg lehet probalni a docx-el is)

Gukker 2011.03.21. 15:58:04

@Ignis_veneficus: Ugyanez megy a 2007-2010-es Word docx-ével is. Az is zippelt xml :)
Ott a .docx/word/document.xml-t kell nézni.

Gukker 2011.03.21. 15:59:43

@Gukker: Ha meg a doksit elmented sima .txt-be, akkor a felsorolásokat átalakítja kötőjellé vagy csillaggá. Végső esetben ez is jó.

Atyaman 2011.03.21. 17:57:55

@SaGa: Írta, hogy megpróbálta kikapcsolni a wordben, de ez nem segített. Szerintem eleve az OCR program a ludas, nekem is ott kellett cserélnem a felismert szöveget (kötőjel + tab). Replace all rulz :)

@Ignis_veneficus: guti.haz14 makrója teljesen jó és azért csak gyorsabb, mint ez a konvertálás + csere módszer. De komolyan :)
Erasmus4 írta a makrós topikban, hogy a Word '10-ben le is futott neki, csak a végén nem állt le. Dehát erre van az Esc/stop gomb, attól függően honnan futtatjuk. Még elegánsabb lenne persze megkeresni miért nem áll le a '10-es Wordben, míg a '07-esben meg igen.

@Gukker: a txt-t nagyon nem nyerő (még végső esetben sem), az összes formázást kidobhatod + vajh mi lesz a láb-/végjegyzetekkel?

Vlaci69 2011.03.21. 23:49:15

@Atyaman: Köszönöm az ötletet, ami sajnos nem működik (gondolom a - Dworkyll által említett - titkosítás miatt). Ami viszont sikerült: calibre segítségével PDF-be nyomtatni, aminek eredményét elég jó hatásfokkal fel tudom ismertetni az ABBY FineReader 10-zel. Láthatóan eléggé nyögvenyelős a dolog, csak akkor éri meg, ha tényleg valami fontos, többször olvasandó műről van szó. Végiggondolva a folyamatot, még mindig az e-könyv vásárlás híve lennék.

Atyaman 2011.03.22. 00:45:56

@Vlaci69: Az encryptiont és a DRM-et gond nélkül le lehet pattintani az ilyen fájlokról, még Calibre plugin is létezik erre a feladatra. Ha ez megvan utána konvertálhatod, amibe szeretnéd.

Bár nem rossz szándékú felhasználásról van szó, hiszen csak a hibákat szeretnéd javítani, de azért nézd el nekem, hogy a blog szabályaira hivatkozva nem linkelek be most ilyen programot/plugint :(

gh14 2011.03.23. 21:41:43

Hola!
Van egy könyvem .doc formátumban, illusztrációkkal díszítve. Hogy tudok olyan .prc-t csinálni, amiben benne maradnak a képek?
A hagyományos módszer nem működik. Doc-html-MPCreator.
A Creator-ban a html preview-ban még lászik, de a prc-be már nem kerül át.

gh14 2011.03.23. 22:44:45

@guti.haz14: megoldottam.
A végső .opf-et ráengedtem a kindlegen-re.
És tökéletes lett.

gh14 2011.03.23. 22:55:40

@guti.haz14:
Így módosítanám a sorrendet:
1. Doc mentése szürt weblapként
2. Html betöltése a MP Creatorba
3. Tartalomjegyzék létrehozása
4. Metaadatok feltöltése
5. Build
6. Ncx generálás
7. Ncx beépítés
8. Kindlegen

Atyaman 2011.03.23. 23:10:48

@guti.haz14: Kicsit szőrszálat hasogatok sorry érte, de ha végül a Kindlegen-t használod, akkor nem értem miért is van szükség a Buildre :-O

gh14 2011.03.23. 23:42:10

@Atyaman: amatőrként csak próbálkozom.:)
Eddig nem használtam a kindlegen-t, de most a képek problémát okoztak, így kipróbáltam.

Atyaman 2011.03.23. 23:58:40

@guti.haz14: Kindlegen-t eleddig még én sem használtam. Egyelőre még nincs is tervbe véve.
Az MPC-nál gondolom, azért használtad a Build-et mert az más egyebek mellett elmenti az .opf-ot és legenerálja fizikailag is a toc-ot. A múltkor is csak erre utaltam, hogy talán egyszerűbb nyomni egy save-et (.opf elmentése) és a Publication Files közt a toc-ot kijelölve rákattintani a Preview with Web Browser-re. Így egyúttal le is lehet ellenőrizni, hogy minden rendben van-e a tartalomjegyzékkel és nem kell a Build után még a mbp_toc.html-t külön megnyitni ezzel a céllal.
Segíteni szeretnék nem kötözködök ;)

szakértőbb 2011.03.24. 00:13:40

@guti.haz14:
5. Build felesleges
8. Kindlegen meg minek, ha az MPC-ben vagy? :-)

szakértőbb 2011.03.24. 00:15:27

@Atyaman:
Elnezest, de a Build utan mar minek megnyitni az mbp_toc-ot? Akkor mar a prc-t nezegeted, hogy hogy nez ki a Kindle-n:-)

Atyaman 2011.03.24. 00:35:25

@szakértőbb: Megint neked kell magyaráznom, amit leírtam? Azzal kezdtem, hogy felesleges azon a ponton Build-et csinálni. Majd levezettem, hogy mit érdemes az 5. lépésnél csinálni helyette. Mert úgy tippeltem, hogy az opf és a toc miatt használta guti.haz14 a Buildet, mert azok csak úgy maguktól nem fognak megjelenni. Mivel nem írta sehol a toc preview-ját ebből tippeltem arra, hogy a toc-ot a Build után ellenőrzi (mert preview vagy build nélkül nem jön létre a fájl!). És igen jól olvastad ellenőrzést írtam, mert amíg nem néztem meg, hogy jó-e, addig fel sem rakom az olvasóra.

8. Azért használt Kindlegen-t, mert a MPC eltüntette a könyvéből a képeket a Build során. Tett egy próbát a Kindlegen-nel és ott nem merült fel a hiba. De ezt te is tudnád ha elolvastad volna figyelmesen a hozzászólásait.

szakértőbb 2011.03.24. 00:48:57

@Atyaman:
Szia!
:-)
Figyelmesen olvastam. A leirtakbol az jon le, mintha ezt igy kene csinalni. Nem igy kell, csak azert volt igy valami ertelme, mert a kepeket nem tudta beizzitani.
Es valoban, a Save es a Preview eleg az OPF-hez es az mbp_toc-hoz.

Azt tovabbra sem vilagos, hogy egy warning nelkuli Build utan mit ellenorzol az mbp_toc-on, de a Te dolgod:-) Ha mar ennyire tutira mesz, miert nem a Kindle Preview-rrel ellenorzod?

Hozzaszolasaidat mindig megkulonboztetett, ketszeres figyelemmel olvasom:-))) igy kerlek, legy turelmes velem.

Atyaman 2011.03.24. 01:22:46

@szakértőbb:
>>Hozzaszolasaidat mindig megkulonboztetett, ketszeres figyelemmel olvasom:-))) igy kerlek, legy turelmes velem.<<

Nagyon megtisztelő és én igyekszem, tényleg igyekszem ;)
Jó lett volna beszélni egyet a blogtalin, de sajnos elkerültük egymást.

Azért ellenőrzöm a toc-ot, mert az ördög nem alszik. Lehet valahol lemaradt egy fejezet, vagy éppen elírás van benne. Ettől még a Creator nem fog kiabálni, hogy baj van, pedig ég a ház :)
A toc-ot pedig mivel a MPC preview-jával hozom létre itt azonnal lehet is azt ellenőrizni. A Kindle Previewer-ben már csak az összképet és az ncx-et nézem meg.

szakértőbb 2011.03.24. 01:50:17

@Atyaman:
>A toc-ot pedig mivel a MPC preview-jával hozom létre itt azonnal >lehet is azt ellenőrizni. A Kindle Previewer-ben már csak az >összképet és az ncx-et nézem meg.

Ez nem lehet igaz! Egyetertünk!!!!

Atyaman 2011.03.24. 02:27:53

@szakértőbb:
>>Ez nem lehet igaz! Egyetertünk!!!!<<

Pedig simán elképzelhető. Csak nem különbözhet mindenben a véleményünk :)

Inkább az nem lehet igaz, hogy 5-6 komment kellett mire eljutottunk a nyilvánvalóig ;)

gh14 2011.03.24. 08:11:51

@Atyaman: @szakértőbb:
Mint mondtam amatőr vagyok, és úgy gondoltam, hogy az .opf csak a Build-del jön létre. A toc-ot rögtön leellenőrzöm miután létrehoztam.
Azért kellett a kindlegen, mert az MPCreator nem ette meg a képeket.
Nem mondtam, hogy így kell csinálni, vagy hogy ez a tökéletes folyamat, csak, hogy én így csinálom.
Viszont köszönöm az építő hozzászólásokat, sokat tanulok belőlük. És örülök, ha egyszerűsíteni lehet.

szakértőbb 2011.03.24. 08:44:38

@guti.haz14:
En csak a felesleges lepeseket probaltam kigyomlalni.
Viszont: azt nem ertem, miert nem latszanak a kepeid. Ketlem, hogy a Mobi lenne a hunyo, ergo nem kell Kindlegen. (hasznalhatod nyugodtan, nehogy felreerts, csak nem KELL). Csak azert mondom, mert en is csinalok kepes prc-t is Mobival, nyilvan megvannak benne a kepek.
Tippem: a kepeket nem teszed megfelelo mappaba, vagy nem jo a meretuk?

erasmus4 2011.03.24. 08:59:09

@guti.haz14: Az írtad szűrt weblapként mented wordből úgy build után nekem sincsenek képek, valamint ha sima weplapban mentem és utána futtatom a kipucoló scroptet akkor sincs kép. Simán weplap build lesz kép, tartalomjegyzék és ha szerencséd van az ncx kreáló script lefut hibamentesen vagy nem, (nekem hol lefut hol nem :) ) annyira nem zavar mert nem nagyon használom elég a tartalomjegyzék.

gh14 2011.03.24. 11:09:00

@szakértőbb: persze, köszi, örülök, ha egyszerűsíteni lehet a folyamatot.
Most, hogy mondod, lehet tényleg nem találta a képeket, mert először a kindlegen-nel sem volt jó. Viszont ott végigolvastam a hibaüzeneteket, és megtaláltam a probléma okát.
Délután kipróbálom.

megvakarom 2011.03.24. 14:06:03

Kindle-n meg lehet oldani, hogy ha lábjegyzethivatkozást teszek indexbe, akkor ne tolja szét a sorokat?
epub jól csinálja ezzel:
.labhiv{font-size:.65em;vertical-align:super;line-height: 0.1em}

a kész epubot calibre átfordítja prc-be, de nem lesz jó a Kindle preview-ban, széttolja

köszönöm előre is a helpeteket

szakértőbb 2011.03.24. 14:11:24

@guti.haz14: Bocsi, a Mobi uzenetei nem voltak egyertelmuek? :-) A Warningra ranezel (sarga szinu jelek), azonnal latszik, mi a hiba oka.

gh14 2011.03.24. 14:32:47

@szakértőbb: Tudom.
Általában nem szoktam vele foglalkozni (talán az első egy-két esetben még megnéztem, és semmi érdemlegeset nem tartalmazott, asszem csak azt írta, hogy nincs cover), így ebben az esetben meg elfelejtettem megnézni. :-)

takatsa 2011.03.24. 14:59:35

Nekem van néhány problémám a mobipocket creatorral, ebben kérném a segítségeteket. Az egyik az, hogy a 4.2-es verzió a gépemen csak home formában települ fel, hiába adom meg telepítésekor, hogy publisher formában kívánom telepíteni (és így nem szerkeszthető a metadata). A 4.0-ás creatorral lehet szerkeszteni a metadata-t, de az így előállított prc-ben a Kindle nem látja ezeket az adatokat, így aztán nem lehet pl. szerző szerint rendezni a könyveket. Ha megszerkesztem a metadata-t, beállítom a borítóképet, akkor az ablak alján rákattintok updatera, majd jöhet a build. Ilyenkor a metadata automatikusan belekerül a prc-be, vagy van esetleg egy lépés, amit kihagytam?

takatsa 2011.03.24. 15:03:35

Ja, még egy dolog: a metadata szerkesztést most a már előállított prc-n végzem el, Mobi2Mobi_GUI_VB segítségével. Ez a program nagyon jól működik, és az így előállított prc kompatibilis a Kindle-vel, egy gondom van csak, hogy ékezetes betűket nem szereti, és azért az idegesítő, hogy a könyv címében, a szerző nevében, ill. a fülszövegben nem lehetnek ékezetek.

SaGa 2011.03.24. 15:12:11

@megvakarom: A super miatt tolja szét. Cseréld le egy <small><small><sup> </sup></small></small> párosra a html-ben a span-t...
Az sem mindegy, hogy az <a> </a> ezeken belül, vagy ezeket közrefogva van. Az egyik esetben az aláhúzás elválik a számtól, lekerül a sor aljára, a másikban viszont ott lesz a szám alatt közvetlenül.

Atyaman 2011.03.24. 15:13:32

@takatsa: Ha rendben megcsinálod a metaadatok bevitelelét az update gomb megnyomásával együtt, akkor nem tudom miért nem jelenik meg az író neve és a könyv címe a kindle-ön. Nem dob valamilyen figyelmeztetést a MPC a Build után?

Egyébként ajánlom figyelmedbe a Calibre-t. Könyv rendező, konvertáló, metaadat módosító és még kismillió másra is képes mindenes program.

calibre-ebook.com/

szakértőbb 2011.03.24. 15:32:27

@takatsa: Ez meg hogy van? Ha a Publisher-t kered, hogy mehet fel home verzio? WIn7? vagy mire teszed?
A 4.2-esben siman lehet szerkesztenia metaadatokat, nalam is megy, hidd el.
Azt nezted, mi a kulonbseg a Home/Publisher kozt?

megvakarom 2011.03.24. 15:39:34

@SaGa: köszönöm!
lehet, hogy az az igazi Kindle-n működik, de sem a Kindle Previewerben, sem a Calibre nézegetőjében nem akarja az igazságot, a kétféle aláhúzási módot sem csinálja meg, csak az emelt vonalkát.
Epubot a Calibre is szépen mutatja, ADE is.
Talán a sortávval kell valamit variálni, piszkálom még

takatsa 2011.03.24. 16:00:17

@szakértőbb: Hát, én sem értem, hogy miért a home-t telepíti. Lehet, hogy valami általános beállítási probléma van a gépemen. Ha nálatok megy gond nélkül, akkor én is próbálkozom tovább. :)

megvakarom 2011.03.24. 16:00:43

@SaGa: gugliztam egy megoldást:

css-be:
sup, sub { font-size:.8em; vertical-align: 0; position: relative; }
sup { bottom: 1ex; }
sub { top: 0.8ex; }

és mehet a <sup> </sup>, smallal.
ez mindenen egyenletes sortávot tart.

megvakarom 2011.03.24. 16:11:37

@megvakarom: aztán az android úgy is tesz rá magasról

megvakarom 2011.03.24. 17:25:06

Összefoglaltam ezt a kéféle superscript dolgot egy zipbe (0,5M):
bornemisszaadam.hu/sslab.zip
benne van a CSS és a HTML kód, ebből kreált epub és prc, és egy jpg-en összeprintscreenezve a nálam elért megjelenések: Calibre, ADE, Kindle Previewer

mind más, ez benne a szép:)

gh14 2011.03.24. 17:39:52

@szakértőbb:
Szóval, ha ránézek a MP Creator-ben a Warnings-ra, akkor megspórolok magamnak egy kis időt. :-)
Nem találta a képeket.
A .html fájlt és az elemeket tartalmazó mappa nevében volt egy á betű. Amit nem szeret. Mondjuk érdekes, hogy a preview-ban még látta.

SaGa 2011.03.25. 07:36:50

@megvakarom: workaround a problémára:

Amennyiben versek azok, amelyekhez a lábjegyzet tartozik, nem az utolsó versszak végére, hanem az első versszak első sorának végére teszem a linket, így belefér az eleve nagyobb sorközbe. A lábjegyzettől vissza linket meg eleve a versz címére, vagy ha egy fejezet kezdő verse, akkor a fejezet címére szoktam visszaküldeni, mert a mobipocket reader kicsit gyagya és ha a formázási utasítást tartalmazó sor a visszaugráskor az előző oldalra kerül, akkor az egész formázás megy a levesbe.

Ha nem lehet ilyen trükköt alkalmazni, akkor jön a másik lehetőség: nem teszem super pozícióba a linket, hanem marad a sorban, egy mérettel kisebb, és így néz ki: [1], vagy {1}...

megvakarom 2011.03.25. 09:44:11

@SaGa: Köszönöm, a verses jó ötlet, megjegyzem. Itt sajna tanulmányról van szó, így a második megoldás tűnik működőképesnek, bár a hagyományoktól idegen a különböző zárójelek használata (én is csak hanyagságból hagytam meg), és az index pozíció elhagyása. De még mindig jobb megoldás, mint a széttolt sorok.

Prc-ben a <small><sup><a href="../Text/notes.html#a20">{2}</a></sup></small> tűnik jobbnak, a sortávok jók mindenen.

Epub-ban me a .labhiv{font-size:.65em;vertical-align:super;line-height: 0.1em} css-megoldás a szebb.

Ha egy forrásból csinálnám mindkettő formátumra, akkor a <small><sup> tűnik a legjobb kompromisszumnak.

mano42 2011.03.27. 10:40:49

Furcsa problémát vettem észre a MPC-vel, egyes szavakat szétválaszt ha abban specifikus karakter van (ö,ü,ő,ű). Például "műhely" "m űhely" ként jelenik meg. Érdekes, hogy nem minden magyar karakterbe köt bele, tehát például a "fűt" már oké, nincs elválaszta. A Calibre nem csinál ilyesmit. Főleg PDF esetében fordul elő. Valami tapasztalat ezen a téren?

mano42 2011.03.27. 11:40:59

@mano42: Megnéztem a MPC által geberált html-t is, abban már benne van a hiba...

Ignis_veneficus 2011.03.27. 13:34:24

@mano42: Nincs a forras file-ban egy fontvaltas az adott helyen? pl a "m-hely" times-new-roman, mig az "ű" az pedig "times-extended" vagy mas valtozat?
probald ki a wordben hogy kijelolod, es a "stilusok" - >"hasonlo formazas kijelolese" parancssel megnezed, hogy meg mit jelol ki. Ha csak a kedeses karaktereket, akkor egy "formzas torles"-sel valoszinuleg rendbejon

mano42 2011.03.28. 08:21:23

@Ignis_veneficus: Koszi, megkaptam (gondolom) a problemat. Mint mondtam, inkabb PDF-nel jelentkezik a problema, es a koztes xml fileban ott csakugyan van egy furcsa formazas valtas:

<font size="10" face="AIBOGG+TimesNewRomanPSMT">
<text x="159" y="58" width="37" height="10">Kráter M</text>
</font>
<font size="10" face="AIBOEF+TimesNewRomanPSMT">
<text x="196" y="58" width="5" height="10">ű</text>
</font>
<font size="10" face="AIBOGG+TimesNewRomanPSMT">
<text x="201" y="58" width="61" height="10">hely Egyesület </text>

a html -be ez mar igy kerul at:

<p>Kiadja a Kráter M
űhely Egyesület<br/>

Az alpaszoveg "AIBOGG+TimesNewRomanPSMT", viszont az ű betu "AIBOEF+TimesNewRomanPSMT".

Feltetelezem ez azert van mert a PDFben beagyazott karakterek vannak, es a konverzio alatt az xml-ben ez helyettesitodott egy masik fontra. Viszont nem jottem ra mi ez a AIBOEF meg a AIBOGG.... a gugli sem volt a baratom...

Jol selytetted, a fontformazassal van a baj, viszont nem szertetnem atkonvertalni wordba, mert ugy elvesznek a pdf fajlban levo headingek.

Ignis_veneficus 2011.03.28. 09:21:41

@mano42: Nem ismerem a pdf felepiteset, de en kicspnam belole az osszes font allitastes osszevonnam a fenti harmat egy bekezdesse. A problemat a X,Y,Width parametereken latom ebben az esetben (osszevonas).
Kicsit kutakodni kellene, de megneznem, hogy mekkora egy sorszelesseg (width) hol kezdodik (x) es az alapjan irnak ra valami scriptet, ami ilyen esetben a AIBOEF fontot osszevonna az elotte, utana kovetkezo font elemmel
(Hogy a font micsoda, az lenyegtelen, a lenyeg a valtason van)

Pác Tivald 2011.03.28. 17:44:33

Hello,

kipróbáltam a tisztító script-et...

a <span teljes tisztításban kiakadt..

a html egy word-ből készült html ....

mi a gond vele?

Köszi

Pác Tivald 2011.03.29. 20:22:31

Bocs..

megoldódott, benne maradtak a szövegben a formázások...

KátaiKata 2011.04.10. 00:41:36

December óta olvasom ezt a blogot, és ennek köszönhetően a múlt héttől én is boldok Kindle tulajdonos lettem. Most, hogy már megvan, próbálok a felmerülő kérdéseimre célirányosan keresni, de bevallom, annyi mindent olvastam már, hogy nem tudom, mit hol, és így alig találok meg valamit.
Jól emlékszem, hogy már beszéltetek itt a DIA-n levő könyvekrő, hogy azokat hogyan lehet leszedni,stb...
Ha valaki tudja, hol találom, azt megköszönném.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.04.10. 01:02:47

@KátaiKata: Szia,

ha most csöppensz bele, akkor ne a DIÁval kezdd, mert az ottani anyagok elég furmányosan vannak összerakva. Pl ott figyelnek a szövegben a lapszámok, amit, ha nem akarod a szemeddel kerülgetni őket, ki kéne takarítani. Meg xml-ben vannak, és nem annyira triviális visszafejteni őket, mint mondjuk a MEK natív html-jeit.

Szóval azt javaslom, először kicsit gyakorolgass egyszerűbb struktúrájú szövegtestekkel, és mire belejössz, lehet a DIÁnak is lesz egy "off-line-barátabb" szolgáltatói felülete.

(A fejüket törik rajta, de nem egyszerű, és nem a technológia miatt)

Atyaman 2011.04.10. 01:46:34

@KátaiKata: Ha jól emlékszem itt volt egy kis eszme futtatás a DIÁs könyvekről:

ekonyvolvaso.blog.hu/2009/10/04/radar_4/fullcommentlist/1#c11783651

Amúgy Dworkyll-nek igaza van, tényleg nem a legcélszerűbb a DIÁval kezdeni az e-könyv szerkesztést.
De ha mondasz könyvcím(ek)et, akkor szívesen segítek az(oka)t gatyába rázni ;)

KátaiKata 2011.04.10. 11:12:07

@Atyaman: Köszönöm a gyors válaszokat, lehet, hogy most tényleg nem ezzel fogok bíbelődni, de amint lesz egy kis időm, kipróbálom. És akkor majd beváltom ezt a bónuszomat :))
Fantasztikus ez a blog. Köszönet még egyszer!

Atyaman 2011.04.10. 12:36:57

@KátaiKata: Szívesen :) Csak szólj! ;)

Nyeznajka · http://oroszorszag.blog.hu 2011.04.13. 20:12:04

Sziasztok!

A tartalomgyártáshoz lazán kapcsolódó ám számomra égető problémába ütköztem: egy kutatáshoz átnyálaztam, highlightoltam és kommenteltem jópár (nem amazon licences) könyvet, amikre most egy tanulmányban hivatkozni akarok. Azonban írás közben sokat kell ugrálni az egyes kiemelések és megjegyzések között, ezért kényelmesebb lenne nem a Kindle-n, hanem a laptopomon lavírozni közöttük. A talány: van arra mód, hogy a kiemelések és megjegyzések a Kindle for PC-n megnyitott e-könyvben is megjelenjenek? És más reader szoftver keresztül?

Azt tudom hogy a My Clippings fájlba ő kimásolgatja nekem, de sokszor szükség lenne a szövegkörnyezetre is (főleg megjegyzéseknél).

Azt is tudom, hogy az .mbp fájlba tárolja ezeket az infókat, de hiába másoltam fel a gépre a kindle-ről, a readerben nem jelenik meg. :(

Köszi

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.04.13. 20:15:33

@Nyeznajka: Hmm, elvileg, ha egymás mellett van a prc és az mbp file, akkor az aktuális olvasónak a prc megnyitásakor meg kell jelenítenie a highlightokat is. WinMo-n MObipocket for desktopnál és Kindle-n is így van. Legyen a két file egy alkönyvtárban.

Nyeznajka · http://oroszorszag.blog.hu 2011.04.13. 20:53:38

@Dworkyll: egy almappában vannak, azonos fájlnévvel és mégse. sőt, megpróbáltam a kindle-ről megnyitni a könyvet Amazon for PC-vel és úgyse működött. Letöltöttem a Mobipocket for desktopot, megnyitottam merevlemezről - nem lát kiemelést. Viszont felismerte a csatlakoztatott Kindle-t és - láss csodát - onnan megnyitva látszódnak a kiemelések és kommentek is. Sokat adnék érte ha megérteném hogy van ez... :) Mindenesetre köszi a tippet.

Atyaman 2011.04.13. 21:09:47

@Nyeznajka: Csak egy ötlet:
Az a mappa, amiben együtt van a prc és mbp az a K4PC content mappája?

K4PC->Tools->Options->Content - Current content folder:

Nyeznajka · http://oroszorszag.blog.hu 2011.04.13. 21:18:39

@Atyaman: A manóba, MŰKÖDIK! Nem tudtam hogy átmásolja magának egy külön mappába a dolgokat ez a rohadék. Ezer hála és köszönet. :)

Atyaman 2011.04.13. 21:25:10

@Nyeznajka: Örültem, hogy segítségre lehettem ;)

gh14 2011.04.14. 01:07:11

Hola!
Olyan problémám van, hogy pdf-ből alakítottam át egy dokumentumot. A fejezetcímek képként vannak tárolva, mivel különleges betűtípussal íródtak. Úgy gondoltam, hogy akkor meghagyom átalakítás után is.
Tehát a word dokumentumomban a fejezetcímek képek.

Arra szeretnék valamilyen megoldási javaslatot, vagy ötletet, hogy ilyen forrásból, hogy tudok tartalomjegyzéket készíteni?

Köszi

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.04.14. 08:27:41

@guti.haz14: Nem túl szerencsés sok dolog miatt.

Esetleg próbáld meg azt, hogy a képek elé beszúrod a fejezetcímeket a megfelelő headingben, szöveggel, abból ki tudja generálni a MPC a tartalomjegyzéket, kereshető marad stb. És hogy ne látszódjon duplán, a szövegben lévő szöveges fejezetcímek _színét_ vedd fehérre.

És amikor odaérsz, csak a kép látszik (legalábbis bizonyos platformokon), a szöveg nem.

Ja és a kép legyeb jpg, a gifet a Kindle parser nem nagyon komálja a szövegen belül.

szakértőbb 2011.04.14. 09:20:46

@Dworkyll:
Ez tokjo otlet, tecc!
En meg a kovetkezot is el tudnam kepzelni: siman legeneralod a tartalomjegyzeket a Cimsor1-ekkel, es aztan berakod a szoveg ele immar statikus szovegkent. Ha linkelhetore szeretned, akkor konyvjelzokkel a fejezetekre is lehet ugratni, az ncx-hez meg nem kell a hagyomanyos tartalomjegyzek...

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.04.14. 10:00:17

@szakértőbb: Azért ez fából vaskarika, lássuk be. Rögtön megbukik a mutatvány, mihelyt egy szines platformra kerül, ugyanis ott viszonylag ritka a tiszta fehér háttér.

És hál istennek vannak szines prc platformok. De Kindle-re ettől jó lehet.

Ignis_veneficus 2011.04.14. 10:21:08

@guti.haz14: rovid valasz: kezzel.
A feher szin helyett javasolnam meg a kicsinyitest, vagy egy style="display:none" probat is megerne a dolog
vagy ha mar megvan a tartalomjegyzek, akkor lehet torolni a forrasbol a szoveget es veletlenul sem ujrageneraltatani a tartalomjegyzeket.
Az osszes tobbi otletem hosszabb butykolest igenyel, de kesobb behozza az "elvesztegetett" idot
(pl sajat toc generator irasa)

szakértőbb 2011.04.14. 10:22:45

@Dworkyll: :-) Én a leleményességről beszéltem. Szerintem ez egy tökjo adhoc megoldas:-)
Viszont a valaszogbol ugy tunik, mintha az en megoldasom nem mukodne:-( Az nem szinfuggo:-)

gh14 2011.04.14. 12:23:17

@Dworkyll: @Ignis_veneficus: @szakértőbb:
Azt próbáltam tegnap este, hogy a fejezet első betűjéhez állítottam be stílust, és az alapján generáltam a tartalomjegyzéket.
Nem tökéletes, mert ha a fejezethez ugrok a cím pont nem látszik, de elfogadható kompromisszum lett volna (a képekkel nincs gond, jpg-ben vannak, tökéletesen látszanak a kindle-n, sőt nagyon is szép így:)).

Utána a toc.html-ben szerkesztőben átírtam a betűket a fejezet címére. De hiába, mert a kész prc toc-ban csak a kezdőbetűk látszottak. Nem tudom, hogy működik a prc/mobi összeállítása, de úgy tűnt, mintha összeállításkor (build) újragenerálná a tartalomjegyzéket.

gh14 2011.04.14. 12:23:58

@Ignis_veneficus: @Dworkyll: @szakértőbb:
Délután kirpróbálom a javaslataitokat.

SaGa 2011.04.14. 13:28:07

@guti.haz14: Igen, újragenerálje, de át lehet verni.
Miután legenerálta az mbp_toc.html-t, a creatorben menj el az utolsó "lapra" a guide gombbal. Ott töröld ki a tartalomjegyzéket. Ezzel el fog tünni a "Table of contents" gombbal nyíló ablakból is.
Javítsd ki kézzel az mbp_toc.html-t, majd a creator első lapján (Publication files) add hozzá ismét a fájlt és a "guide" lapon is add hozzá mint új elemet (New guide item). A neve Tartalom, type: toc, és ki kell tallózni a javított mbp_toc.html-t.
Így már nem építi újra. Ha megnézed a "Table of Contents" panelt, az most üres, és ne is készíttess vele újat!

szakértőbb 2011.04.14. 13:42:37

@SaGa: az en megoldasom nem egyszerubb? :-)

Atyaman 2011.04.14. 14:26:10

@SaGa:
>>majd a creator első lapján (Publication files) add hozzá ismét a fájlt<<

Most nem látszik, de éppen a fejemet ütögetem az asztalba :D
Nem keveset szenvedtem én evvel. Már régebben is próbáltam saját toc-ot csinálni, de mindig azon sírt be a Creator és a Kindlegen is (ahova a MPC-ből vettem az opf-et), hogy Hyperlink is not resolved. Ahol megoldást keresgéltem ott az volt mindig a mondás, hogy a toc-ban rosszak a linkek. Pedig azok jók voltak, csak a toc nem volt hozzáadva az állománylistához. Utólag pedig mennyire triviális. Vááá...

gh14 2011.04.14. 21:45:14

@SaGa: Nehezn indult de végül is sikerült.
Átgondoltam és úgy oldottam meg, hogy a fejezetcím kép elé ütöttem egy szóközt, így formáztam stílussal, amiből már a word és az MPC is tudott tartalomjegyzéket készíteni. Az MPC tartalomjegyzékét módosítottam. Majd az általad leírt módszerrel csináltam tartalomjegyzéket.
Tökéletes lett. És így már ha valamelyi fejezethez ugrok, akkor a cím is látszik.

Köszi mindenkinek!

Atyaman 2011.04.14. 22:28:47

@guti.haz14: Szóköz miért kellett? Én is csináltam egy próbát azon melegiben, hogy láttam Saga hozzászólásában mit rontottam el eddig.Úgy találtam, hogy elég volt a képeket kijelölni, majd stílussal ellátni, abból már simán elkészítette a MBC a tartalomjegyzéket.

gh14 2011.04.14. 23:04:30

@Atyaman: úgy emlékszem, hogy ha csak a képet láttam el stílussal, akkor a word nem csinált tartalomjegyzéket. Az MPC-ben nem próbáltam, de akkor ezek szerint az elkészíti.

Atyaman 2011.04.14. 23:27:37

@guti.haz14: Ez simán lehet. Mert én meg a word-ben nem csináltam tartalomjegyzéket :)

szakértőbb 2011.04.15. 08:07:59

@guti.haz14: A Word-ben nem kell megcsinalni a tartalomjegyzeket, csak a tartalomjegyzebe szant elemeket olyanra formazni, mintha...

gh14 2011.04.15. 08:18:18

@szakértőbb: tudom. Nem is szoktam csinálni, csak egyszerűbb volt ott próbálgatni, mint: megformázom - kimentem - betöltöm az MPC-be - létrehozom a tartalomjegyzéket.

elminster 2011.04.15. 08:44:35

Azt hiszem, már késő, hogy szólok: a Mobipocket Creatorban bármilyen HTML-tag-et össze lehet linkelni a tartalomjegyzékkel.
Tehát ha valakinek az a heppje, hogy a kép legyen a tartalomjegyzék linkjének a célpontja, akkor például a Creator TOC-készítőjében a "tag name" részre értelemszerűen az "img" megnevezést kell írni. Ekkor automatikusan minden <img...> tag-be a Creator rak egy id azonosítót, aminek a párját pedig az mbp_toc.html-ben szépen felsorolja. És tessék! Készen van a képes fejezetcímzés tartalomjegyzékének a logikai váza. Természetesen a váz csak a linkelést tartalmazza, úgyhogy az mbp_toc.html-ben minden linkhez kézzel be kell írni a fejezetcímet, mivel a képből nem tudta a Creator kiolvasni. Ezek után a SaGa által leírt módon az átalakított tartalomjegyzékfájllal le kell cserélni az eredetit.

De továbbmegyek!
Bármilyen szabványos (vagy szabványon kívüli) HTML azonosító lehet tartalomjegyzék alapja ha <> jelek közé van foglalva. Lehet tartalomjegyzéket készíteni például teljesen általános <p class="cimsor"> tagekből is. Ekkor a TOC-készítőt így kell kitölteni:

tag name: "p"
attribute: "class"
value: "cimsor"

És a program szépen kiválogatja a rengeteg <p> tag közül a "cimsor" stílusúakat. Vagy a középre rendezetteket. Vagy a 15-ös felső margóval rendezetteket. Vagy a... satöbbi. Csak a fantázia szab határt, hogy mi alapján kerestetjük meg a tartalomjegyzék elemeit a törzsszövegben. Az csak a legegyszerűbb, általános esetben javasolt módszer, hogy a címsor-stílusozást használjuk. Extra igények esetén extra megoldásokat is lehetővé tesz a rendszer.

SaGa 2011.04.23. 18:31:05

Mit találtam:
kindlevarazs.wordpress.com/2011/04/19/kell-egy-konyv-faragjunk-e-book-ot/

Nem tudom, hogy ki hogy van vele, de aki 9000 Ft-ért hirdet olyan tanfolyamot, aminek az anyagát tulajdonképpen innen vadászhatta össze, az számomra kissé ellenszenves...

Ignis_veneficus 2011.04.23. 23:35:56

@SaGa: Kivancsi lennek arra a " NCX-generálásban segítő programot (Personal verzió)" -ra.. foleg, hogy melyik valtozat az alapja...

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.04.24. 09:07:05

@SaGa: Ha valaki fizetni akar valamiért, ami ingyen is elérhető, tegye. Sokaknak kevés ám, hogy valahol elolvassa az okosságot, és kell nekik valami zártabb oktatási forma. Az oktatási infrastruktúra, az oktató ráfordítása sem feltétlenül ingyenes.

De tény, hogy érdekes kezdeményezés ;-)

Ignis_veneficus 2011.04.24. 13:32:41

@Ignis_veneficus: "Kivancsi lennek arra a " NCX-generálásban segítő programot (Personal verzió)" -ra.. foleg, hogy melyik valtozat az alapja..."
jo adag rosszindulatu feltelezes szorult a megjegyzesembe.

miklos0514 2011.04.24. 16:28:42

@SaGa: Szerintem minden oktatás lényege az, hogy valaki, aki tud valamit, előadja azoknak, akik nem tudják. Ez teljesen normális.

elminster 2011.04.24. 21:37:35

@miklos0514: Hát nem tudom. Én például teljesen ingyen osztottam meg a PRC-készítés során szerzett tapasztalataimat. Valahogy nem éreztem "segítségnyújtásnak" ha pénzt követelek érte.

És hogy romboljam más üzletét, elárulom, hogy a teljes útmutatóm mindenki számára elérhető a kindledxhu.blogspot.com/ oldalon is. Bár azt el kell ismerni, hogy ez még a Mobipocketes korszakban készült, így a Kindle követelmények és lehetőségek hiányoznak belőle.

szakértőbb 2011.04.24. 22:16:44

@elminster: Ez nagyon dicseretes!
Hogyan kovetkezik ebbol az, hogy mindenkinek ingyen kell dolgoznia? Ha Te ingyen megosztasz valamit masokkal, az a Te dontesed. Ha valaki mast gondol errol, az meg az ove:-)

Vannak peldaul programozok, akik free szoftvereket (is) irnak, es van, aki mondjuk az MS-nek dolgozik. Es akkor mi van?
Ha peldaul irok egy tankonyvet, akkor utana tobbet be sem kell mennem dolgozni, hiszen le van irva...?

Pelesz 2011.04.24. 23:08:11

@szakértőbb: nem az, hogy valaki ingyen akar dolgozni, avagy sem, itt inkább arról van szó, hogy valaki más munkájából akar pénzt keresni, beleértve azt, hogy az a más ingyen és bérmentve közzé tette/tették tudásuk tapasztalatuk. Ez egyértelmüen élősködés, és nem szimpatikus.

Aki viszont olyan sügér, hogy olyanért ad ki pénzt, ami gyakorlatilag "közkincs", hát úgy kell neki.

szakértőbb 2011.04.24. 23:52:38

@Pelesz:
Van egy erzesem, hogy itt valami szimpla irigyseg beszel beloled.
Csak mondom, manapsag barmit megtalalhatsz az interneten, akarmirol. Miert leteznek egyaltalan oktatasi intezmenyek? Olyan luzer vagy, hogy nem tudsz megtanulni barmit magadtol? (nem szemely szerint Rolad beszelek)

>Ez egyértelmüen élősködés, és nem szimpatikus.

Ezt leirni meg pofatlansag, nem tul szimpatikus. Tajekozodj!

Athidalo javaslatom az lenne: tarts Te is ilyen kurzusokat, hogy tonkre tedd masok "business"-et.

Pelesz 2011.04.25. 00:13:19

@szakértőbb: nem az irigység, hanem az ellenszenv. Az meg, hogy neked a véleményem pofátlanság , egyéni szocprob. Az ilyesmit, ha tetszik, ha nem parazitizmusnak veszem. Képzeld el, tájékozódtam, nem élek a világ végén.
Az áthidaló megoldásod meg nem tudom figyelembe venni, nem vagyok én prof, nincs nekem időm ilyenre.

szakértőbb 2011.04.25. 00:45:55

@Pelesz:
SZia!

Nem a velemenyed pofatlansag, hanem ez a mondatod:

> itt inkább arról van szó, hogy valaki más munkájából akar > pénzt keresni,

ezt honnan veszed?

>Az áthidaló megoldásod meg nem tudom figyelembe venni, >nem vagyok én prof, nincs nekem időm ilyenre.

akkor mi a gond? Masnak meg van.

Atyaman 2011.04.25. 13:41:02

Az e-könyv tanfolyamos témához hozzászólva:

Ha kontextusban nézem a dolgot a honlapból egyáltalán nem a nyerészkedés jön át. Mikor én anno olvastam ezt a posztjukat, akkor persze az én figyelmem is fenn akadt az áron. De biztos nem lehet olcsó termet bérelni sem. Hiába segítek én is szívesen neten keresztül, mégis csak egyszerűbb és sokak számára jobb is a személyes foglalkozás.

Amíg nem látom az ellenkezőjét addig, még az ncx programról sem lehet biztos állítani, hogy Ignis kódját használják alapnak (pl. én sem azzal készítem az ncx-et). Azt pedig mindenki eldöntheti, hogy az ingyenes tökéletesen működőt (Ignis-ét) hasznlja, vagy megveszi, amit a Kindle-varázs kínál.

Nekem sokkal visszatetszőbb például, mikor szakértőbb (bocsi :-(, de én így látom) gyakorta reklámozza itt a kindle-varázsos posztokat, míg azon az oldalon egyszer sem láttam, hogy e-könyv olvasó blogosat linkelt volna be.

szakértőbb 2011.04.25. 16:06:02

@Atyaman:
>Nekem sokkal visszatetszőbb például, mikor szakértőbb (bocsi :->(, de én így látom) gyakorta reklámozza itt a kindle-varázsos >posztokat,

Dworkyll kezeben a radir, ha nem tetszik, torolheti a nem ide illo bejegyzeseket! Szerintem amiket belinkeltem, azok sokak szamara erdekesek lehettek/voltak! A "gyakorta" azert szerintem nem nagyon lehetett tobb 4-5-nel... (bar nem szamolta most utana)
De ezen is konnyen segithetunk, a tovabbiakban mellozom. Igy OK?

szakértőbb 2011.04.25. 16:07:51

Ahogy nezem, a Kindlevarazs Blogrollja ezzel a szoveggel kezdodik:
"E-könyvolvasó Blog A témával foglalkozó legjobb magyar blog – fokozottan ajánlott!"

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.04.26. 10:35:21

Ejnye olvtársak,

nem kéne ennyire osztani egymást.

Ad1. Oktatni bizony strapás meló, és infrastruktúraigényes is. Ezért pénzt kérni szerintem abszolút jogos. Hogy pontosan hol lesz az egyensúly a kereslet és a kínálat között, az majd kiforrja magát.

Ad2. Ugyanezért, ha valaki tréninget akar venni, pl. mert nem tudja teljesen "magáévá tenni" a hálón föllelhető ingyenes és fizetős anyagokat, az had tehesse meg.

Ad3. A dolog kommunikációja szerintem picit lehetett volna jobb, pl. tőlem itt is nyugodtan lehetne reklámozni, elvégre az egész blog azért van, hogy minél több, minél jobb minőségű elektronikus publikáció legyen.
Ilyen szempontból _minden_ ami ebbe az irányba visz, az hasznos.

Ad4. Igen, van hagyománya az ingyenes ismeretterjesztésnek, és kódgyártásnak, de sajnos mindenkinek vannak prioritásai, hogy mennyit tud egy ingyenes csatornába fektetni anélkül, hogy a számára fontosabb dolgok sérülnének. P. a családdal való törődés. És van az a pont, amin túl már bizony pénzt kell kérni.
Megint csak kommunikációs hiba. Az rohadt rosszul néz ki, ha valaki ingyenes munkáját másvalaki pénzszerzésre használja. Egy jobb kommunikációs stratégiával nyílvánvalóvá válhatott volna, hogy a tréning mely anyagai honnan származnak, hogy pl. az NCX generáló megoldás _nem azonos_ az Ignis által fejlesztettel.

Nota bene, az ingyenes források is simán beépíthetők egy amúgy hozzáadott értéket tartalmazó tréningbe, ha azokat kellőképpen meghivatkozzák, megköszönik (esetleg elkérik). És ekkor nincs ez a homályos (és fölösleges) "árnyékkardozás".

Úgyhogy virágozzék száz virág, elvégre tavasz van, vagy mi ;-)

Pelesz 2011.04.26. 20:55:05

@Dworkyll: végülis igazad van, lássuk, mi sül ki a dologból, fogakat ráérünk később is élezni.

kIára 2011.04.30. 15:12:14

Elnézést, nem akartam hozzászólni de nem tudom megállni a kérdést.
@szakértőbb: a tanfolyamod alapja ez: kindlevarazs.wordpress.com/2011/03/18/konyvszerkesztes-egyszeruen-i-resz/ ?
Azaz te e-könyvgyártáshoz ezeket az alkalmazásokat használod ezzel a workflow-val?

mano42 2011.05.03. 08:30:03

Kicsit off, észrevettem, hogy a MPC egyes importált fájlokhoz egy sor kódot rak, másokhoz meg nem. Mi is az a kód, és hogy lehet beállítani, hogy ne tegye?

Atyaman 2011.05.03. 08:52:43

@mano42: Olyankor használja ezt a random generált kódsort, mikor pl. ékezetes betű szerepel az importált fájl nevében. Ilyenkor az ékezetes betűt az ékezet nélküli párjával helyettesíti és pár random karaktert csap a fájlnévhez.

Nyilván azért, mert a konvertáláskor probléma adódhatna bizonyos nem feltétlenül szabványos karakterekből.

martin78 2011.05.07. 17:41:19

Eddig a Calibre -el készített prc (mobi) fájljaim szépen működtek az olvasón, de most felfrissítettem a Calibre -t a legújabbra (kb. egy fél évvel ezelőtti változat volt fenn eddig), és olyan problémám van, hogy az elkészült mobi fájllal nem működik a Kindle -n a szótárazás. Pontosabban az angol-magyart nem használja, pedig az van beállítva, a többi könyvemmel (eredeti, és saját gyártmány) jól működik. Ennél viszont érdekes módon nem jó, átvált a magyar értelmező szótárra!? (Pl.: a so kifejezésre a Só meghatározását hozza fel.) Szerintetek mit rontok el? Vagy valami változott a Calibre -ben?
Ja ez egyébként egy mobi->html->kézi szerkesztgetés->mobi fájl volt most.

Atyaman 2011.05.07. 18:29:07

@martin78: Nemrég már volt erről szó a szótáras topikban. Az a helyzet, hogy a Calibre konvertáláskor el/rosszul állítja be a dokumentum nyelvét.

Bár majd egy éves mondás, szóval lehet azóta már nem áll, de a Calibre készítőjétől származik a 0.7.5-ös verzióval kapcsolatban:

"I'm guessing you used the GUI to convert. Since the GUI does not store language information, it is passing UND to the conversion system. I'[ve changed that to have it pass instead the language you have set the calibre interface to, which should be a reasonable interim solution."

Azaz a calibre a felhasználói felületnek választott nyelvet kényszeríti rá a könyvekre is.
Még azt megpróbálhatod, hogy megnyitod a Calibre-ben lévő könyv elérési útvonalát, ott találsz egy .opf fájlt és abban egy text editorral (pl. Notepad++) átírod ezt a részt:

<dc:language>en</dc:language>

erre:

<dc:language>hu</dc:language>

Van rá esély, hogy segíteni fog.

martin78 2011.05.07. 19:52:10

Köszi a választ. Az opf átírás nem segített, viszont a felület nyelvének átállítása bejött. Érdekes, hogy eddig is magyar volt a felület, és az eddig konvertált angol könyveknél működött a magyar szótárazás (igaz azoknál RTF, vagy DOC volt az eredeti), most meg nem.

hanog 2013.01.14. 20:14:21

@Dworkyll:

Ötlet, kérdés, felvetés.

Érdekesek és hasznosak ezek a leírások, én magam is sokat tanultam belőle, bár nem vagyok egy nagy e-book gyáros, sőt ált. mások munkájába csinosítok bele a magam örömére. :) Viszont felmerült egy gondolat, amit esetleg kivesézhetnél egy postban. Nevezetesen az X-Ray. Olvasgattam külföldi topikokban, hogy van is valami generátor ami beszipkáz pár adatot és házilag lehet gyártani, de lehet, sőt biztos, hogy te jobban körbe tudnád járni a témát. Nyilván, ha van időd rá és érdeklődésre számottartónak ítéled meg.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2013.08.02. 01:08:10

Addig is: itt egy pár okosság, amitől egész trükkös mobikat lehet csinálni. Pl. be lehez pakolni a tartalomjegyzéket, mondjuk az impresszum és a törzsszöveg közé.

kdp.amazon.com/self-publishing/help?topicId=A17W8UM0MMSQX6&ref_=pe_390220_30905230

gh14 2014.01.04. 11:11:14

Hello!

Tudja valaki, hogy mit kell beállítani a Calibre-ben, hogy ha .docx-ből konvertálok .azw3-ba, a végjegyzeteket ne külön oldalakon hozza (tehát ha van 5 végjegyzetem, azt most 5 oldalon hozza, és én egyen szeretném?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2014.01.05. 03:16:08

@guti.haz14: Valahogy úgy vagyok a Calibrével, mint SaGa mester az Atlantissal ;-). Apropó Atlantis. Egy ideje már képes arra, hogy ha a programkönyvtárba bemásolsz egy kindlegen.exé-t, akkor automatikusan húzzon egy kf8-as mobit.

És ha jól elő van készítve a doksid, pl. tettél bele bookmarkokat a guide itemekhez (azaz "toc" bookmarkot a tartalomjegyzék elé pl.) akkor egész dögös tud lenni az a mobi. Kétszer akkora lesz ugyan, mint egy vele összemérhető epub, meg be lesz ágyazva az összes font a mobiba is, de funkcionálisan rendben lesz.

gh14 2014.01.05. 20:52:50

@Gukker: és az miért van, hogy ha .mobi-ba konvertálok, akkor jó?

gh14 2014.01.05. 21:00:41

@Dworkyll: tudom, nem az ideális, de sem kedvem, sem energiám nincs megtanulni a .html-t, vagy mit. :)
Word-ben elég jó vagyok, abban megszerkesztem, és a lehető legegyszerűbb módon akarok abból Kindle-re való formátumot. Nem nagyok az elvárásaim: borító, metaadatok, tartalomjegyzék, fejezetjelölők, az állapotjelzőn, kézi oldaltörések megmaradjanak, végjegyzetek megmaradjanak. A Calibre többé-kevésbé teljesíti a feltételeket. Egyedül ez az .azw3-as végjegyzet a problémás, de akkor maradok a mobinál. :)
Van a Calibre-nél egyszerűbb, de jobb megoldás?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2014.01.05. 21:06:23

@guti.haz14: :-)

Mit tud az azw3, amit a mobi nem? Nekem már a kf8-ra váltás se jött be.

Amúgy van a calibrénél egyszerűbb mondás is (kindlegen ;-) meg jobb is, csak a kettő között kizáró vagy a logikai kapcsolat, sajnos.

Wordben amúgy hova teszed a metaadatokat? Vagy ahhoz kell a Calibre?

Mert amúgy pont ez az új atlantis+kindlegen kombó pont azt gyártja, amit szeretnél, gyakorlatilag elég egy save as, egy rtf-ből, vagy egy docból.

gh14 2014.01.05. 23:14:25

@Dworkyll:

Semmit. Úgyhogy maradok a mobi-nál. (Csak olyan vagyok, hogy szeretem a legújabbat használni mindenből. :) )

Igen, a metaadatokat Calibre-vel töltöm fel.

Ha lesz időm megpróbálom. Meglátjuk.

Egyébként, mitől jobb egy Atlantis+Kindlegen kombóval készített mobi, egy Calibre-vel készítettől?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2014.01.05. 23:18:25

@guti.haz14:

Hogy jobb-e azt nem tudom, de első blikkre szerintem egyszerűbb. Az atlanis mégiscsak szövegszerkesztő, szerkesztési funkciókban tuti erősebb, mint a calibre. Onnantól meg save as, és ad egy teljesen használható epub és mobi párost.

A calibre meg inkább egy rendszerező cucc, abban erős. A konverzióit max nyersanyagnak tudom eléképzelni, nagyon sok furcsaságot művel.

Gukker 2014.01.05. 23:44:50

@guti.haz14: Ha .docx-ből mobiba konvertálsz akkor is minden végjegyzet bejegyzést külön oldalra rak (bár megjegyzem, engem pl. nem zavar). Akkor csinálja úgy ahogy te szeretnéd, ha szűrt html-be mentesz és azt konvertálod.
Docx-es konvertálásnál az zavar, hogy ignorálja a tartalomjegyzék beállításokat. Az összes létező címsor stílust felveszi a tartalomjegyzékbe és bepöttyözi a progress barba.

@Dworkyll: Én is word-calibre párost használok. Hidd el, nincs egyszerűbb. Ráadásul az újabb Calbre-ben e-pubra és azw3-ra már saját könyv szerkesztője is van; olyasmi, mint a Sigil.

"Mit tud az azw3, amit a mobi nem?"
Ezt azért ugye te sem kérdezed komolyan. Sokkal többet tud. Az persze más kérdés, hogy egy hétköznapi regénynél ebből vajmi keveset használunk.
Ami még pl. előnye, hogy lehet soft hyphent varázsolni bele, amit a Kindle is ismer. Így lesz elválasztás.
Ezek ellenére 99,9%-ban én is mobi7-et használok azért, mert az a nagy minimális sortáv nagyon zavar az azw3-ban.

gh14 2014.01.05. 23:47:09

@Dworkyll:

Én a Calibre-ben nem is szerkesztek. :)
Wordben megcsinálom, betöltöm a Calibre-be, metaadatokat hozzáadom, konvertálás. Ennyi.
Ami tetszik, hogy ha jól címsorozom a Word doksit, a Calibre szépen megcsinálja a tartalomjegyzéket, anélkül, hogy a Word dokumentumban megcsinálnám.

Innentől kezdve az Atlantis is ennyi lépésből fog állni, ha az Atlantis-ban nem kell már szerkeszteni semmit. Atlantis-ban megnyit, metaatadok, save as.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2014.01.05. 23:58:16

Wahh, elvileg egy platform, és mégis mennyi varia. Azw3 milyen firmware-rel megy mondjuk a K3-on? Jól sejtem, hogy progress bart k3-on néztek? A PW-ről nekem hiányzik. Vszont az tudja a soft hyphent "szoftverből" (JBPatch).

Gukker 2014.01.06. 15:47:58

@Dworkyll:
"Azw3 milyen firmware-rel megy mondjuk a K3-on?"
3.4

"Jól sejtem, hogy progress bart k3-on néztek?"
Én igen, de ugye 4-esen is van. Nekem nagyon hiányozna.

SaGa 2014.03.02. 11:25:44

Sziasztok!

Kellene egy kis okosság a szakértőktől.
Van egy könyv, amiben a fejezetek első oldalán a bal margó a képernyő 10%-a. Csak a bal margó és csak az első oldalon.

E-pubban a dolog "egyszerű". A fejezetek elejére beszúrok egy "üres" div-et, ami float: left, a szélessége 10%, a magassága meg annyi pixel, ami biztosan több, mint bármely olvasóé (1200-2000px de lehet pt is). Az e-pub readerek lapozás után már nem hozzák a túlnyúló "lebegő" div-et. Így az első oldalon a 0 bal margójú bekezdések sorai a "lap" 10%-nál kezdődnek.

Mobi-ban ez nem működik. Ha a div magassága több, mint az olvasó kijelzője, akkor a következő oldal(ak)on ott lesz a maradék, azaz nem az első oldal aljáig tart, hanem ameddig a mérete kiadja.

Ha a div "position" absolute vagy relative, a magassága 100%, a "left" és a bottom 0, akkor jó lenne a div box mérete és helye, csak így nem érvényesül a "float: left", azaz a szöveg (ami a margóként használt div után van) az oldal szélén és nem a div után kezdődik... E-pubban és mobiban egyaránt.

Van valami okosság erre a problémára? Kindle 4-en próbáltam.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2014.03.02. 12:29:39

@SaGa: Jól értem, hogy te kihasználsz egy epub parsolási "hiányosságot", és számon kéred a mobin? :D Amúgy ez mire jó, ez az első oldalas behúzott margó?

Most éppen el van ásva a szerszámosládám :-(, de úgy emlékszem, hogy lehet variálni a divvel és hogy hogyan pakolsz bele pl. p tageket. Utánanézek, mert van ott valami huncutság, hogy igazából valami tagpárral dolgozol, amiből az egyik a div, de a másik most nem jut az eszembe :-(

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

@SaGa: MOndjuk ezzel a "mindjárt rájövök melyik tag kell hozzá" megoldással azt tudod megcsinálni, hogy tetszőleges bekezdés legyen beljebb húzva, azaz legalább sacc kell arra, hogy mi legyen beljebb húzva. Cserébe működik hierarchikusan is. (ezért is sajnálom, hogy a </Harmónia> nem jött ki villanyon, mert szebb lett ilyenformán mint a nyomtatott.)

SaGa 2014.03.02. 16:01:45

@Dworkyll: Arra jó, hogy ilyen a nyomtatott könyv szerkezete. A fejezet kezdő bekezdés iniciálés, de az iniciálé nem a bekezdésbe olvad bele, mint a megszokottak, hanem kilóg belőle balra. Hogy ez ne legyen csúnya, az egész oldal tartalmát betolták annyival, mint az iniciálé mérete.

Az e-pub parsernél ez szerintem nem hiányosság, hanem direkt így tervezték. Van olyan e-pub parser, ami pont úgy viselkedik, mint a mobi olvasó, de az nem "lapoz" olvasás közben, hanem az egész fejezet (lapdobástól lapdobásig) egyetlen "oldal", azaz olyan, mint egy irattekercs, lehet le-fel csúsztatgatni a szöveget. A "normális" parser meg lapozgat, mint egy könyvben az szokás.

Eredetileg én is azzal játszottam, hogy kiszámolom, hány bekezdés is egy oldal, és azokat behúzom balról, de semmiképp nem jó. Még ha egyforma sorszámra ki is tudom trükközni a bekezdések hosszát (ez is erősen parser függő, van amivel meg lehet csinálni, mással nem), amint változik a betűméret, már bukik a mutatvány. Vagy az első oldalon is lesz "kicsúszó" szöveg, vagy a következő oldalon is behúzott. Randa.

Egy dekort már így is el kellett vetnem az e-pubból (és az tényleg ade e-pub parser hiba). A címsor jobbra zárt s aláhúzott, de nem csak a szöveg, hanem az egész sor addig a pontig, ahol a vele egy szinten lévő "lebegő" dekoráció (egy speciális karakter) véget ér a bal oldalon. Ezt egy másik divvel (magassága 2pt, -2% felső margó, háttérszín sötétszürke; nem a hr tag nem jó, azt nem sikerült annyira felemelni, hogy aláhúzásként hasson). Na az összes e-pub parser (kivéve a Sigil-t, de az meg a lebegő karaktert tolta beljebb a kelleténél) tojott a jobbraigazított div-re és balra tette. A mobiba már nem is próbáltam beletenni.

Amennyire csak lehet, szeretem a nyomtatott könyv tördelési/formázási specialitásait ez e-bookba is beletenni, de van, amit még nem lehet.

mojo68 2014.03.25. 10:14:14

Sziasztok!

azw3/kf8-ban hogyan lehet csökkenteni a line-height (sortáv) méretét? Nem tudom ki hogy van vele de engem zavar a PW nagy sortávja.

Ezzel próbálkoztam, de nem igazán látom hogy használna:

p {
line-height:100%;
margin:0pt;
text-indent:1em;
text-align: justify;
font-size: 1.20em;
widows: 2;
orphans: 2;
}

Az ePub ban működik a sortáv csökkentése, de a PW tojik az alkotmányra.

Gukker 2014.03.25. 10:56:01

Nem tudod. Kindle alatt az awz3-nak van egy minimális sortávja, amit nem tudsz kisebbre venni. Én ezért nem használom, maradtam a mobinál.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2014.03.25. 10:56:32

@mojo68: Hmm, alapból én nullára veszem a sormagasságot, és kész. Csak az üres sorokra kell így vigyázni, mert azok tényleg nullások lesznek ;-)

A kindle parsere sajnos nem mindent visz át a css-ből, és amit átvisz, ott is érzékeny a css definíciók sorrendjére :-(

mojo68 2014.03.25. 16:46:05

@Gukker: Kaptam egy tippet hogy ágyazzak be kisebb sormagasságú fontot, a Constantia mintha tényleg kisebb sortávot adna.

@Dworkyll: Én úgy vettem észre hogy 100% alatt nem igazán érzékeli az azw a külömbséget.

Dé Neighbor 2014.08.13. 19:28:59

Sziasztok!

Calibre tartalomjegyzék problémám van konvertáláskor.
Célom egy szűrt html állományt mobiba áttenni. Ennek a html-nek van saját tartalomjegyzéke a könyv elején, ez eddig rendben is. Ha nem engedem a Calibrét, hogy tartalomjegyzéket generáljon, akkor ugye lesz egy tartalomjegyzékem (továbbiakban toc-om) az eredeti helyén, a linkek működnek rendesen, viszont az olvasón a toc menü inaktív marad.
Ha viszont azt szeretném, hogy az olvasón legyen go to table of content lehetőség, akkor a Calibrében konvertáláskor beállítom, hogy adjon hozzá toc-ot. És ha így teszek, kapom a következő problémát:
A generált toc minden tétele (fejezetcíme) után pont-pont-és egy szám áll, ami nagyon zavaró, lévén, hogy nem használok oldalszámokat értelemszerűen.
Valaki tapasztalt hasonlót?
Nagyon köszönöm a segítő tippeket!
G

gh14 2016.03.16. 16:01:40

Sziasztok,

Tapasztalt már valaki olyat, hogy a Calibre-vel felmásolt könyvet nem látja az olvasó (Paperwhite 2), de ha simán rá másolja (Windows Intéző), akkor igen?

Mi lehet az oka?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2016.03.17. 09:17:13

@guti.haz14: Hmm, misztikusan hangzik. A Calibre másolás után hova érkezik meg a file? A Documentsbe teszi? Illetve megnézném én azt a Calibre által odarakott file-t, nem konvertálta-e át véletlenül valami furába, és azért nem ismeri fel a PW.

gh14 2016.03.17. 13:07:34

@Dworkyll: ☺ A fájlt a ugyanúgy egy mappába teszi a Documentsen belül, ahogy más esetekben is. Kiterjesztés szerint mobi fájl (a Calibre-ben is az). Nem hiszem, hogy konvertálja, mert gyorsan végez, egy konvertálás általában tovább tart.
Arra gondolok, hogy vagy az ékezet, vagy a hosszú cím okozza, de még nem teszteltem.
süti beállítások módosítása