egyelőre nem egyenlőre. formátum érdekes, ki kell várni mi lesz belőle.

@PathosVerdesIII: Köszi, javítottam. Amúgy meg azt azért látni kell, hogy specifikációszinten a kf8 meg az epub3 eléggé hasonlít egymásra. A lényeges különbség, hogy egy jóval egységesebb vállalati háttér, és fene tudja mekkora tartalombázis van mögötte.

Kicsit messzebbről nézve meg van párhuzam mondjuk a szines könyvekkel. Szines könyvek voltak már jóval a nyomtatás előtt is, de nagyon nagyon sok kiadványhoz ma sem kellenek szinek. Ugyanezért a kf8 igen sok esetben lesz ágyúval verébre.

A kérdés az, hogy ez a formátum hogyan jut el mondjuk az én egyszerű Kindle 4-esemre. Update formájában? Vagy majd csak a következő generáció kapja meg a kompatibilitást?

na igen, erre én is kiváncsi lennék, csak k3-mal :)

e-book-ot maximum 15ezerért. ennél drágábban tabletet veszek.

html5+css?

Már látom magam előtt az animált fejezetcímeket, az eseményvezérelt kiadványokat. Mire is lesz ez jó? Lehet majd sok csilli-villi bannert tenni a háborúésbékébe? Meg lehet majd lövöldözős játékot játszani az egri csillagokban "István Dobó versus Jani cár" jeligére?

És vajon ez a formátum nyitott lesz-e? Vagy csak az Amazon olvasóival tudom elolvasni azt, amit ilyen formátumban tudok megszerezni?

Ha zárt, akkor eleve nem akarok hallani se róla.

Ha nyílt formátum lesz, akkor lesz egy csomó reader, ami tudja, meg egy csomó, ami nem. És a legrosszabb, hogy lesz egy csomó, ami csak tudogatja. Ahány reader, annyi formátumbug. Lehet majd reader-független ebook-okra törekedni, mint pár éve a böngészőfüggetlen html esetében.

Ha nyílt lesz, és lesznek hozzá konverterek, akkor a konverzió során mit veszítek? Csak eltűnik a címlapról a betűk vetett árnyéka, vagy nem fogom látni a könyvben a magyarázó ábrákat?

Nem tudom, Ti hogy vagytok vele, de szerintem a következő formátumokra van szükség formázott szöveghez:
- irodai dokumentum: továbbszerkeszthető, sok metainfót tud tárolni (változáskezelés, kommentelés, stb.), példa: ODT
- statikus nyomtatásra való: nem szerkeszthető tovább, mindig ugyanúgy néz ki, akár nyomtatom, akár elektronikusan olvasgatom, példa: PDF
- dinamikus megjelenítésre való (PC-n, okostelefonon, ebook reader-en, stb.): áttördelhető, a megjelenítés paraméterezhető (betűtípus, méret, sorköz, szín, stb.), stb, példa: ???

Szerintem ezt az utóbbit kellene megalkotni, de nem úgy, hogy elvisszük a könyvet a PC irányába, és előhozunk egy csomó új problémát, hanem úgy, hogy a meglévő hiányosságokat orvosoljuk. A cél, hogy azt tudja 100%-ig, amire való, nem pedig minden mást egy kicsit.

Szerintem.

kindlefire8 = magazinok, napilapok.

lepjetek tul azon, h

amazon = konyvesbolt
kindle = konyvolvaso.

jonnek vegre az ujsagok, nem csak az ipad-n lesznek csillivili "interaktiv" ujsagok.

ez azt is jelenti, hogy ertelmes modon videotartalmat is lehet belerakni a konyvekbe? Lehet, hogy buta a kerdes...., akkor bocs.

@Plumper_: Hiába van tableted, jön egy kis napfény és olvashatatlan. Főleg egy 15 ezres tablet képernyője esetén..

@Kohn Troll (Altdel): Html5 + css3:
A lenyeg szerintem nem a animacion van, hanem pl, meg lehessen csinalni egy normalis bal oldali behuzast, esetleg egy jobboldalit (mobiban jelenleg nem lehet)
hogy egy felsorolast ne tablazattal kelljen mar megcsinalni.
ne kelljen szivni a tablazatokkal,
a beagyazott fontok is jol jonnek ha kicsit kilepsz a latin-1 -s jelkeszetbol. (pl a kinai jeleket vagy tamogatja vagy nem)
nem artana normalisabb kepkezeles.
jol jon ha tudsz kenyszereket definialni, pl egy kepalairas minden esetben a keppel egy oldalra kerul.
soroljam?

Én még ott tartok, hogy Kindle3-ra mivel tudok publikálni? Úgy értem, a "hivatalos", "gyári" e-könyveket, milyen alkalmazásban szerkesztik?
Most az InDesignhoz elérhető valami Kindle plugin, ezzel dolgoznak Amazonék?
Amúgy próbáltam már százféle konvertert, még a Calibre működik legjobban, de Mobipocket Creator vagy Sigil eléggé harmatos.
Pl csináltam egy sorkizárt szöveget, rtf-ben importálom Calibréba, onnan felküldöm Kindle-ra, Calibre felkonvertálja, feltölti, sorkizárás volt nincs, szöveg balra igazított, a szövegbe szúrt 1-2 kép összevissza elcsúszva...Lehet a Word formáz nem szabványosan, amiben az rtf készült?

Na most az epub3 ban van html öt, és az ipad meg támogatja is mint referencia implementáció ha jól gondolom. Akkor most miben vezet a kf8?

@Uzi: "jön egy kis napfény":-D persze, ha pedig rálöttyen egy liter gázolaj, akkor is baj van. na neeeee. simán hülyeség csak e-könyv olvasót annyiért venni, amennyibe a rengeteg mindent tudó (amúgy ugyanakkora) gépek kerülnek.

@acel: a kf8-ban is van html5, és az ipad meg támogatja mint kindle app.

Ugyanaz a helyet, mint a mobi vs. sima epubnál - az Amazon hamarabb lépett, és így a saját formátumával hódította meg a piac jelentős részét.

Lehet, hogy az epub3 jobb, tisztább, szárazabb érzés lesz, de addigra már ott lesz X magazin, mesekönyv, stb a kétszáz dolláros Fireon.

@Plumper_: van, akinek fontos, hogy ne mindent, hanem csak egy dolgot tudjon, de azt jól.

Például lehessen rajta szöveget olvasni, akár órákon át, miközben kint ülsz egy parkban.

Szerencsére senki sem kényszerít rá, hogy neked kelljen ekönyvolvasót venni.

@Komavary: ha mindenre lenne egy külön gépünk, 10 év alatt belefulladnánk az elektronikai szemétbe (a jelentős többletkiadásokról nem is beszélve). már így is belefulladunk. NEM NEKEM kell e-könyvolvasót venni, nem rólam van szó! nem kell senkinek venni, de a fogyasztói társadalmat súlyosan etetik olyan dolgokkal, amikre valójában nincs is szükségük. Az e-könyv olvasóknak egyetlen előnyük van: kevesebb fát vágnak ki a papírspórolás miatt; elvileg, aztán ki tudja...

Ilyen megközelítéssel nem csak a könyvolvasó, de a tablet, okostelefon stb. is hülyeség.
Hiszen egy Leatherman multitool mennyivel több mindenre használható.

@Komavary:
Azt akartam mondani hogy Epub3 már _van_ nem lesz: "October 10, 2011" -óta, pár héttel hamarabb jelent meg mint a kf8 első bejelentése, Az IBook - reader azóta támogatja.
Tartalmat még nem ellenőriztem hozzá.
Szóval most a amazon csak felzárkózozzott a epubhoz technológiailag.

@acel: Az a baj az epub3-al, ami az epub-bal, es a html-el, es az osszes olyan formatummal, ami mogott nem all eros hatter ami kikenyszeritene egy egyseges ertelmezest:
minden implemantacio mast ertelmez belole, maskep nez ki rajta, es optimalizalhatsz 1000-el, akkor sem lesz jo mindenhol.
lasd html esetben az ACID teszteket, a szejjelganyolt css-eket (eleg csak a webkit es a mozilla direktivakat nezni), meg a javascripteket...

Az animációk megjelenítése az e-ink-es kijelzőkön nem megoldott. Másra készültek. Pont az az előnyük, hogy ritkán kell a képet frissíteni. Többek között ezért is bír ki egy hónapot egy feltöltéssel.
Aki animációkat, videókat akar nézni, ne e-book readert vegyen, hanem tablet-et.

Felteszek pár naiv kérdést, gondolom tudtok rá válaszolni: e-ink-es olvasó az ugye csak fekete fehér? Vagy az új formátummal az is színes lenne?
Az e-könyv olvasók (kindle) ismerik a sorkizárt formátumot? Mert eddig bárkinek a kezében láttam, csak balra zárt szövegek voltak... (ez esetben az is kérdés, hogy ha epub-ra konvertálok egy pdf-et, akkor az sorkizárt marad?)
Köszi!

@Plumper_: Ahol én lakom napi rendszerességgel megjelenik a nap :) Ráadásul a szabadban szeretek olvasni. Tableten már az ablak mellett is gond lehet. (Kindle3 és fire is van otthon, másra vannak). A legutóbbi nyaralásra csak a fire-t vittem, gondoltam majd az lesz a mindenes, de csak beltéren volt láható a képernyője.
Ezzel együtt sok felesleges kütyüm van, de ezeket pont nem tartom annak. (A 10 colos tabletem sokkal inkább)

Csak az a kerdesem, hogy mikor jon a kf8 a K3-ra?

@Kohn Troll (Altdel): "És vajon ez a formátum nyitott lesz-e? Vagy csak az Amazon olvasóival tudom elolvasni azt, amit ilyen formátumban tudok megszerezni?

Ha zárt, akkor eleve nem akarok hallani se róla."

Hogyan definiálod a zártságot? Ingyen gyártod a tartalmat (MPC, kindlegen, Calibre, online konverzió), és gyakorlatilag minden platformra van (lesz) olvasó app. Viszont nem szólhatsz bele a feature-listába, nem írhatod át a parsert. Nyitott, vagy zárt?

Szerintem nyitott, és pont az egységes appkészlet miatt messze rugalmasabb és konzisztensebb, mint az epub.

@penumbra1984: Szép prc gyártáshoz itt ez a poszt: ekonyvolvaso.blog.hu/2009/05/11/hogyan_csinaljunk_igenyes_mobipocket_publikaciot

plusz kell még bele Ignis ncx generátora.

@Dworkyll: "és gyakorlatilag minden platformra van (lesz) olvasó app" ...kivéve a konkurens ekönyvolvasókat.

Vagyis bevinni bármit bevihetsz az Amazon rendszerébe, kihozni macerásabb.

Ez szerintem zárt.

@Komavary: Igazán zárt formátum már nem nagyon van (olyan, amihez sehogy sem tudsz hozzányúlni, mert lekódolták, nem publikálják a specifikációt stb.) Ha a KF8 leírását tisztességesen publikálják, akkor semmi gond.

@Komavary: még valami, szerintem a konkurens könyvolvasókra azért nem lesz app, mert azok gyártói nem annyira szeretik az amazont ;)

Kipróbáltam, működik a dolog. Két epubot betoltam az új kindlegenbe és megnéztem a previewerben. Vannak vele gondok, de működik.
Első gond: a mobi sokkal nagyobb, mint az epub-é, még akkor is, ha maximális tömörítést használok. Több mint kétszeres.

Második gond: látszik, hogy a beépített betűkészletet használja, de olyan a megjelenés, mintha "lefotózta volna" az oldalakat és egy rossz minőségű képnézegetővel mutogatná. Csúnya. Remélem, ez csak a previewer hibája.

a méretezés egyelőre nem az erőssége. Az epub-ban gondosan belőtt méretű iniciálékat alaposan átalakította. Az eredetileg három sor magas betűk 5 sornyi helyet foglalnak, de csak 3 sor magasak.

A legnagyobb gond: a korábbi kindlegenek olyan mobi-t csináltak, amit ki lehetett bontani 7zippel. Ezt már nem lehet, akárcsak a prc-ket. Így nem tudom leellenőrizni, hogy mit is csinált az epubommal valójában.

Most vettem észre: a Kindle Previewer is megeszi az epubot, csak konvertálja röptében, elmenti és ez után mutatja meg. Az eredmény bitre azonos a kindlegennel előállítottal, azaz ez utóbbira nincs is szükség...

@pytta: Igen, az eInkes kijelzők monokrómok, gyakorlatilag 16 szürkeárnyalat amit tudnak. Az új formátumtól ez nem fog változni.

A Kindle egy "adaptív sorkizárást csinál, alapból sorkizárt, de ha túl nagy szóközöket generálna az algoritmus, mert hosszú szó az utolsó, akkor az így felhígult sort valamelyest balra zárja. A sok ér rövid szó van a szövegben, akkor teljesen zsír a sorkizárás. Plusz a margó gyárinál szűkebbre vétele segít picit a helyzeten, több térrel lehet gazdálkodni.

A pdf-> epub konverzió nagyon cinkes. A pdf oldalképet őriz, ezért nagyon munkás rendes folyószöveget húzni belőle.

@Dworkyll: Köszi. Jól értem, hogy ha nekem sok könyvem van pdf-ben, akkor nem érdemes Kindle-t vennem? Mit érdemes akkor? (vagy ha mondjuk pdf-ből át tudom rakni rendesen word-be, akkor már működhet a további konvertálás "e-köny-olvasó-kompatibilis-formátumba"?)

@SaGa: probald meg a
-c2: Kindle huffdic compression
opcioval hivogatni, hatha ki tudja bontani

elolvasva a Amazon Kindle Publishing Guidelines -t eleg zsirnak tunik az uj formatum, majd jatszok vele.

vannak benne erdekes reszek:
"The Kindle platform supports GIF, BMP, JPEG, non-transparent PNG and Scalable Vector Graphics (SVG) images in your content."
melyen hallgat, hogy hogyan kell pl egy svg-t belerantani

"Kindle Format 8 internally supports JPEG and GIF images of up to 127KB in size. This is double the previously-supported maximum of 63KB, and provides for richer nuances in images, particularly for large images, or content with gradient patterns. KindleGen will perform the necessary conversions automatically from the supported input formats so you should provide your images with the maximum resolution available and let KindleGen do the rest."
vagyis az svg-bol kapok egy gyenge jpg-t?

kozben a vegen:
"The following HTML tags are not supported in the Kindle Format:
...
Embed (Only SVG is supported for Kindle Fire)"
Mintha nativban tolna a Fire (a kf8) a SVG-t, es nem konvertalna.

NCX:
eleg erdekes a pelda, mert a "napint" elemben definialva van a class ami book|chapter|titlepage es azt mondja, hogy ekkor jo lesz a "bogyozas" is. De nem ir a lehetseges ertekekrol es a hasznalatukrol.

A legszomorubb, hogy nem ir semmit a periodical formatumrol. :(

@pytta: Pont az a gond, hogy pdf-ből semmibe sem tudod "rendesen átrakni". Igazából egyetlen jó - ám hosszadalmas - módszer van: át kell küldeni egy ocr programon, majd újraformázni és korrigálni az ocr hibákat, azaz el kell olvasni betűről-betűre.
Ha exportálod a pdf-ből txt-be, akkor megspórolod az ocr-hibák javítását, ellenben soronként össze kell fűznöd a széthullott bekezdéseket...

@Ignis_veneficus: Sajnos a 3 közül egyikkel sem lesz megnyitható a végeredmény, ellenben egy 1740kb méretű epub-ból lesz 4636kb (c0), 4012kb (c1), vagy 3687kb (c2) méretű mobi...

@pytta: Az a kérdés, hogy milyen a pdf-ed. Ha összetett a lapkép, sok a kép, akkor szó sincs konverzióról= iPad+Goodreader. Ha főleg szöveg, akkor nem lehetetlen, de munkás, viszont utána lehet bármin olvasni.

@Komavary: Nem kell bemenni az Amazon rendszerébe, anélkül is simán (kemény DRM nélkül) lehet árulni/generálni tartalmat Kindle platfromokra.

Zártnak zárt, de nem kötelező. Szóval? ;-)

@Dworkyll: Köszi a linket. Sajna ez eléggé macerásnak tűnik... Valami olyan eljárás nincs, amikor szövegszerkesztőben megformázom és csak exportálom a megfelelő formátumba direkt és nem kell még a html kódban túrni?

Kérdésem még mindig a következő: Amazonék mivel gyártják az e-könyveiket? Mi az iparági módszer a Kindle-re való "authoring"-nak?

Nem hinném, hogy Word meg Mobipocket Creator kombóval dolgoznak....

@SaGa: Acrobat Pro képes doc, docx formátumba exportálni, azzal lehet könnyebb.

@penumbra1984: Szia. Amazonék Kindlegennel gyártják a motyóikat, a hivatalos mondás az, hogy bármi mással csinálod, nincs rá garancia. A MPC igazából egy maradvány, cserébe emberbarát, amikor optimalizálni kell.

Merthogy konvertálni nagyon sokféleképpen lehet, egyszerűen is: elküldöd a docot mailben az olvasódra, és kész. Az optimalizálás, na az a kaland. Hogy pl. hogyan lesz fizikai ÉS logikai tartalomjegyzék. Ezt pl, Kindlegenben nem nagyon látom, hacsak nem egy szénné polírozott, megfelelően tagelt xml-t küldenek bele. Aminél az MPC azért egyszerűbb.

@penumbra1984: Lehet ra gyartosorokat irni:
az odt egy bezippelt xml, leteznek xml->xml (xhtml) atalakitok (xsl), a kindlegen meg mukodik parancssorbol.
en mar irtam egy ilyet rendszert: megfelelo doc-bol, rtf-bol csinal epub-ot vagy mobi-t

@penumbra1984: van indesign export/generalo toolja is az amazonnak, igaz meg csak beta, de lehet, hogy mukodik..
www.amazon.com/gp/feature.html/ref=amb_link_357613502_3?ie=UTF8&docId=1000765271&pf_rd_m=ATVPDKIKX0DER&pf_rd_s=right-4&pf_rd_r=01Y6KWWW250QQ195NMXS&pf_rd_t=1401&pf_rd_p=1343256942&pf_rd_i=1000729511

@Ignis_veneficus: Ezzel már én is szemeztem, le is töltöttem, de előtte InDesign-t kéne megtanulni korrekten használni... :)

@penumbra1984: Na ahhoz kell pilótavizsga ;-), Kezdve azzal, hogy az is lapképre akar optimalizálni, és pl. a könyvek tagolása eszetlen bonyolult.

@penumbra1984: Az acrobat pro az doc-ból, docx-ből pdf-et gyárt és nem egy már kész pdf-ből doc-ot. Vagy rosszul tudom? Én még ott tartok, hogy az acrobattal is csak akkor lehet rendesen javítgatni a pdf-eket, ha birtokában vagy a forrásnak valami egyéb formátumban, mert az acrobat csak egy pdf generátor igazából. De lehet, hogy lemaradtam...

@Dworkyll: az epubban ott van (már ha beletetted) a fizikai és a logikai tartalomjegyzék is. Ezt az mbp creator és a kindlegen egyaránt megeszi és beépíti a kimenetbe.

Hát, nekem most az jött le, hogy kib*szottul nem éri meg most e-könyv olvasót venni, nagyon nem áll még úgy a technológia (meg a tartalom sem...). Én majd akkor visszanézek, ha pdf-et is tudnak eink-re vinni... :)

@SaGa: Igen, de visszafelé is tud, persze nem tökéletesen visszakapni eredeti Word dokumentumot, formázások ott is képesek összekavarodni, de mégse plain text-et kapsz vissza.

Közvetlenül nem tudsz Acrobattal beleírni a pdf szövegébe, mint egy szövegszerkesztővel, hiszen az Acrobat nem szövegszerkesztő. De ha van Acrobat Pro-d (az X Pro egész biztos tudja, de szerintem a 9-es, 8-as is) akkor nyiss meg egy szöveges pdf-et, majd menj a File, Save As menüpontba és ott kell lennie olyan lehetőségnek, hogy rtf, txt, dox, docx, xls, xlsx, stb. Az acro képes kiexportálni ezekbe a formátumokba a pdf-et.

Apropó, hol találom a billenytűzeten a kötőjelet és hol a gondolatjelet?

@pytta: Sajnálom, ha ez jött le, mert piszokul nem így van. A pdf nem e-könyv, nem arra való, nem úgy viselkedik. De erről lesz nagy poszt hamarosan.

@Dworkyll: tegyük fel megvan egy könyv txt-ben, vagy negyisten doc-ban. Akkor nekem még mindig át kell konvertálnom valami MÁS-ba, az meg ki tudja, kezeli-e a karakterkészletet, a kódolást, meg mit tudom én még mennyi kompatibilitási probléma előjöhet... Akkor érdemes legalább 30k-t költeni valamire, ami ki tudja mennyire időtálló lesz? Emlékszik még valaki a mini-disc (MD) formátumra? Még valamivel az mp3 előtt jött ki, egy ideig párhuzamosan futottak, egy lejátszó anno kb 50ezerbe került. Én most pont ezt érzem az e-könyvnél is. Lehet, hogy kevesebb papír, de egy könyvet akármikor elő tudok venni, ha már megvan, 50 év múlva is, ezeket meg nem biztos, hogy fogom tudni olvasni...

@beavereater: @Dworkyll:

Kinek jó a kf8?

Hosszú távon egyvalakinek: az Amazonnak. (lásd még en.wikipedia.org/wiki/Vendor_lock-in )

Én nem nagyon látom, mitől tudna többet a kf8 az epub3-nál. (pontosabban: a kf8-specifikus DRM-en kívül).

Lényegében ez egy az egyben ugyanaz, mint az "ezt a weboldalt csak IE X vagy frissebb böngészővel lehet használni".

Nem jó a tartalomszolgáltatónak, mert ugyanazt a tartalmat már megint két eltérő formátumban kell megcsinálnia. (Megintcsak: vö. böngészőkompatibilitás.)

Nem jó az olvasónak, mert DRM ide vagy oda, nem tudja könnyedén másik céghez vinni a megvett tartalmat. Pláne nem jó akkor, hogyha (ahogy már a mobi esetében is sokszor előfordul) a tartalomszolgáltató azt mondja, hogy márpedig elég macerás volt a formátum előállítása, elég az amazonos formátum, úgyis mindenki ott vásárol.

Persze simán lehet, hogy az Amazon X év múlva is a világ legangyalibb cége lesz (pláne, ha X évnyi vásárlásaink ott lebegnek kipiszkálhatatlanul a felhőben.)

Ahogy az is biztos, hogy (mivel annyira hasonló formátumokról van szó) meglesznek a törő- konvertálóprogramok, és egy kattintás lesz epub3-at varázsolni a kf8 fájlokból.

Ettől függetlenül nem dőlt volna össze a világ, ha az amazon kindlegenen és szigorú stílusútmutatón keresztül azt mondja, hogy az új formátum az amazonos epub3, vagyis ezt meg ezt meg ezt lehet vele csinálni, így és így, a többit pedig jelenleg nem, ja, és minden viszi, ami a szabványos epub3-at olvassa.

@penumbra1984: jobb oldali shift meletti gomb a kötőjel. Gondolatjel nincs "kivezetve"...

@penumbra1984: Majd elfeledtem: a magyar billentyűzeten.
Egyébként a plain text is jobb, mint az összekeveredett formázások. Szerintem.

@pytta: "Akkor érdemes legalább 30k-t költeni valamire, ami ki tudja mennyire időtálló lesz?"

Az a jó, hogy a Kindle for PC/MAC, az Adobe Digital Editions, a Calibre és társai ingyenesek.

Letöltöd őket, megnézed, hogy egy kattintásos konvertálással számodra elfogadható eredményt ad-e txtből, docsból. Ha elégedett vagy, és úgy érzed, olvasnál eleget az eszközön, érdemes rá költened. Ha még szöszölni kell a szöveggel, és ezzel együtt bevállalod, akkor is.

Ha az eredmény borzasztó, és te mindenáron azokat a txt és pdf könyveket akarod ezután is olvasni, ami eddig megvan neked, akkor semmi értelme ekönyvolvasót venni.

@SaGa: És akkor gondolatjelet, hogyan írok billenytűzeten? Vmi Alt+akármi kombináció?

Próba szerencse kérdése, nekem sikerült pdf-ből kivarázsolni úgy xls táblázatot, hogy simán kijelölés után tudtam tovább másolni adatsorokat másik alkalmazásba, lehet sikerül majdnem tökéletes docot kihámozni pdf-ből...

@pytta: rosszul allsz hozza
az e- vs papirkonyvekrol folyamatosan van/volt szo (ervek/ellenervek).
Az mp3 nem jo pelda, mert az is kihalhat, ha pl elterjed valami mas.
Az ekonyveket meg valami szabvanyba kell rakni, vagy ha magat a konyvet nem is tudod (pl a mobi nem szabvany), akkor a forrasmuvet.
es igen, konvertalni kell MAS-ba.
de ha azt nezed, hogy 50 ev mulva mit tudsz hasznalni, akkit mit veszel meg?
konyvet? (papirt) - igen, hasznalhato 50 ev mulva.
audio CD? - kihaltak az LP-k, a kazettak, es is megszunoben
audio mp3? - min tarolod? az 5.25"-s floppy megszunt, pedig olyan fiatal volt meg. lassan megszunik a ATA interface is a winyoknal.
film DVD? - emlexel a videomagnora? most a streaming fut fel.
film divx? - ua mint a mp3..
akarhogy nezzuk, vagy kozepkori eszkozeid lehetnek, vagy amit meg tudsz csinalni film/zene ugyen azt nem akarod tudni a konyvekkel (formatumkovetes, arhivalas stb)

@penumbra1984: Beállítod a szerkesztődben, hogy a -- karaktersort (két kötőjel) cserélje gondolatjelre...

@Komavary: en inkabb azt mondanam, hogy a kf8 kb pdf, mig az epub3 kb html (lehet, hogy rossz az osszehasonlitas)
a pdf-et az adobe tartotta karban, es tudtad, hogy ahogy nalad kinez, az mindenhol ugyanugy fog kinezni. ezzel szembe a HTML eseten remenykedhettel, hogy eleg jol fog hasonlitani egymashoz az IE-n, az FF-en, es a tobbi bongeszon.
en meg mindig azon az velemyen vagyok, hogy van egy sajat xml formatumom, es abbol azt generalok amit akarok: epub,(epub3),mobi, kf8, pdf, akarmi.
kompromisszumok nelkul.

@SaGa: Na ezt sem tudtam...
Azért kérdezem, mert amit Dworkyll olvtárs belinkelt epub hegesztős oldalt, azon felhívták figyelmet, hogy nem mindegy melyik van szövegben a konverzió miatt.

@penumbra1984: wikipedia segit megtalalni a megfelelo utf kodot, uatana lehet alt+akarmizni, de a windowsban van "karaktertabla" alkalmazas, onnet tudsz copyzni is.

@Ignis_veneficus: @Komavary: ezek szerint esély sincs arra szerintetek, hogy egy e-könyv olvasó emberi formátumot (doc/pdf) is kezeljen ? Mert én úgy látom, hogy a .doc pl. elég időtálló. Nekem az mp3 meg az avi is az, meg a jpg. Amíg én élek, ezeket le fogom tudni játszani, mert mindig lesz olyan eszközöm, amin menni fognak / tárolni tudom őket (mondjátok, hogy naív vagyok, de akkor is így gondolom). Ellenben az e-könyves szabványokat, formátumokat nem látom ennyire kiforrottnak - közel sem...
Lehet tényleg, hogy összegyűjtöm mennyi könyvem van, meg egy estét rászánok, hogy megnézzem, hogy megy a konvertálás, és akkor már csak 1-2 évet kell várni jó esetben, hogy 10k körüli árra lemenjenek az olvasók (ha valóban elterjednek, és van értelmük, akkor lemegy az áruk...)

@pytta: doc/pdf:
a doc zart formatum, nem tudom, hogy az MS mennyire nyitotta med, de tele van olyan "szemettel" ami egy olvasas soran nem kell.
Amugy en egy olyan rendszert tartanek elfogadhatonak (amazon megy eziranyba), hogy minden eszkozon tudjam ugyanazt olvasni. Olvason/Pc-n/tableten/mobilon stb...
es lehetoleg ugy tudjak valtogatni a kutyuk kozott, hogy ugyanott tudjam folytatni.

amugy az epub (altalaban) nem mast, mint html fileok halmaza ami metaadatokkal egyutt van osszecsomagolva.
aztan merthogy a html tul.keppen tagelt txt, igy beleferhet az mp3/avi/jpg kategoriaba.

@pytta: A Kindle megjeleníti a pdf-et, Calibre szoftverrel pedig szinte bármit bármilyen e-könyv formátumra tudsz konvertálni.

Csak van egy nagy különbség a pdf meg az ekönyv formátumok között és ez nem azért van, mert szemét gyártók el akarnak mindent adni, haenm mert pdf nyomdai célokra lett kifejlesztve, ekönyv formátumok meg nem.

A pdf non-reflowable vagyis adott fix oldalelrendezést őriz, nem tördelhető újra, épp az a lényeg, hogy elrendezést őrizze. Hasonlóképp mint a doc, bár az már könnyebben gyúrható.

Ekönyv olvasóknál ez nem jó, ott reflowable kell legyen a text, hiszen sokféle kijelzőméreten kell megjelennie ugyanannak a szövegnek.

A probléma ott van, hogy a non-reflowable formátumból kell átmenni a flowable formátumra. Egy nyomtatott könyv beszkennelve, képként elmentve nem tördelhető. Karakterfelismerést kell futtatni, ami messze nem olyan precíz, át kell nézni a szöveget, kijavítani, megformázni, stb. Maga a szűken értelmezett konvertálás csak ezután jöhet és nem ez a nehéz.

Szóval ha egy egész könyvtárat szeretnél ekönyv formátumra digitalizálni az nagyon nagy munka.

A sima szkennelés, pdfbe mentés archiválásnak jó, de az úgy tárolt szövegben nem tudsz keresni, mert a számítógép számára az nem szöveg hanem kép. Érted már?

@pytta: nagyon összetett a kérdés. 1. a doc nem publikációs formátum, mások a funkciói. Pl. nincs platform, ami ott folytatná, ahol abbahagytad. Viszont szerkesztheted.

Nagy kérdés, hogyan olvasol és mit. Főleg szakcucc és száguldozni kell, vagy rekreáció van és elmélyülés, vagy épp tömegközlekedés közben. Mert mindegyikre más az optimális.

És azért félrevezető a negatív attitűdöd, mert nagyon sok "civil" kezébe segítettem már olvasót, akiknek teljesen bejött a cucc, abszolút megtalálták a helyét az életükben. Kényelmes, komfortos. Használható. Nemcsak kockák által

Pénzügyileg meg lehet számolni mindenféle megtérülési modellel, pl. kötelező olvasányok a MEKről, stb. Hidd el, pillanatokon belül pénzednél vagy, ha sokat olvasol.

@penumbra1984: nagyjából értem... de pdf-ben keresni pl ugyanúgy tudok, mint doc-ban. Vagy nem ugyanarról beszélek. De azt felfogtam, hogy a tördelést nem lehet átalakítani (már ha ezt akartad írni). Én csak azt nem értem, hogy erre hogy nincs program, mert szöveget tudok kimásolni pdf-ből, nem képként menti ki nekem a cuccot ugyebár. Persze annyira nem értek hozzá, hogy mit miért NEM lehet, de igazából ezek a korlátok zavarnak engem NAGYON.

@Dworkyll: sokat olvasok, nem szakcuccot, hanem szabadidős tevékenységként (buszon-metrón is). És szerintem nincs negatív attitűdöm :), én SZERETNÉK ilyen eszközöket használni. De iszonyú macera, ahogy most látom. Nem mellesleg ha vennék, azért tenném, hogy pénzt spóroljak, de jelenleg könyvekre 30k-t kb 2 év alatt költök el. Ha feltételezem, hogy az általam olvasni kívánt könyvek 2/3 megvan digitális formában ingyen hozzáférhetően - és ez egy nagyon optimista becslés, valljuk meg őszintén - , akkor kb 5-6 év alatt térül meg a befektetés. Addigra meg a ki-tudja-milyen-technológia lesz már, és dobhatom ki az eszközömet, mert már ciki vele utcára menni. Értitek? :)

@pytta: pdf:
sona csinaljak azt, hogy a bescannelt konyvet, laponkent, kepkent rakjak bele a pdf-be, aztan olvasd.
ebben az esetben nem tudsz benne keresni, kimenteni, stb.
(onnet ismered meg, hogy egy normal pdf regeny jelemzoen par mega, addig egy kepekbol osszerakott tobb tiz, tobb szaz mega)

kimasolas:
A pdf megengedi, hogy tetszolegese szoveget helyezz el benne tetszoleges helyen, es nem fogja kovetni a fizikai file-ban levo helyet. pl:
a file-ban az oldal 1. sora, 10. sora, 15. sora, 2. sora , stb sorrendben is lehet.
szabadon definialt font-ot es fontkeszletet is hasznalhatsz, tehat amit te "A"-nak latsz az lehet a fileban a "B" helyen, innentol a copy-pasta gazos, es nem garantalt.
lattam olyan (szoveg, vagyis nem kepekbol osszerakott) PDF-et, amit keptelenseg volt copy-paste modszerekkel visszanyerni, mert annyira gaz volt belul (de jol lehetett olvasni)
egy pelda: ugyebar tudjuk, hogy a normalis fontokban megvan afont dolt, felkover, es dolt-felkover formatumban is, es normalis szerkeszto nem a "normal" fontbol csinal doltet, hanem fogja a dolt varianst. igy a pdf-ben a dolt es a nem dolt kozott csak a font tesz kulonbseget. es lehet izgulni, hogy a copy-paste tud-e vinnie ezt az informaciot, vagy sem, es mit kezd vele a fogado oldal.

penumbra1984: Én saját használatú mobi/prc gyártásra a következő útvonalat használom:
1: Atlantis szövegszerkesztőben a doc/rtf állományt formázom, a fejezetcímeket beállítom a megfelelő Heading 1,2,... stílusra (ebből lesz a tartalomjegyzék), karaktertípusnak pedig beállítok valami olyat, amiben a magyar ékezetes betűk is rendesen benne vannak (pl. Gentium Book Basic).
2. Még mindig az Atlantisban a kész művet exportálom epub formátumba.
3. Az epub-ot betöltöm a Calibre-be, a metaadat szerkesztőben adok hozzá borítót/fülszöveget/stb.
4. Végül jöhet egy epub->mobi konverzió.

A végeredmény egy borítóval ellátott, tagolt, fizikai és logikai tartalomjegyzékkel egyaránt rendelkező mobi állomány lesz.

@pytta: Jól látod, de kicsit túlpörgöd. Vettem nyáron Kindle-t. Feltelepítettem Calibre nevű ingyenes szoftvert, ez kezeli kindle formátumot, hozzáteszem kindle is kezel sok mindent.
Kindle etetése: netről lehet eleve ingyenesen letölteni megformázott ekönyveket, neked csak fel kell tölteni és olvasni.
Ha ez nincs, akkor meg kell szerezni doc-ban vagy rtf-ben, Calibrébe importálni, majd azzal felküldeni, ez automatikusan megfelelő formátumra alakítja.
Létezik olyan firefox kiegészítő, ami egy gombnyomásra átalakítja a kérdéses honlapot kindle formátumra és ráküldi az olvasódra! ez úgy megy, hogy kindle-t regisztrálni kell amazonnál, kapsz egy @kindle.com-os emailcímet, ezt kell megadni a kiegészítésnek és bekapcsolod wifit, és pár percen belül megérkezik a könyv az olvasóra, ingyen!
Vagy egyszerűen a @kindle.com-os emilcímre elküldöd az átalakítandó fájlt, amazon átalakítja és elküldi az olvasóra.
Fenti módszereknél lehet, hogy nem lesz tökéletes a formázás, nem lesz "szép" a könyv, de olvasható lesz.

A macera a papíralapú könyvek digitalizálásával van, de arról nem az ekönyv technika tehet, ott nem lehet megkerülni az OCR-t, és az a gyenge láncszem. Ha már megvan mégis valahogy a szöveg digitális formátumban, akármilyen formátumban (nem képként!), kisebb kerülőkkel már rá lehet könnyen küldeni az olvasóra, legfeljebb nem lesz tökéletesen igényesen formázott, de olvasható marad.

A legtöbb fáradságot és szakértelmet az igényli, hogy szép, ízléses tördelésű, pofás ekönyvet gyártsunk. De ez megint nem csak az ekönyvek problémája egyedül, hiszen egy papírkönyv kiadását is kiadványszerkesztés előz meg és az is külön szakma.

Szóval egyáltalán nem macera ez, csak némi engedményt kell tenni a külalakot illetően (de nem sokat) és akkor aki egy kicsit is leleményes az tudja etetni az olvasóját.

@penumbra1984: persze, meg kell ezt is tanulni, mint a facebook-ot (igen, én 25 évesen már az a generáció vagyok, akinek tanulni kellett :)) ). Csak reméltem, hogy egyszerűbb, de majd egyszer rászánom magam, aztán meglátom mi lesz belőle.

@pytta: szégyelld magad, én 28 leszek :D

@pytta: csal a matekod. 30 k az kábé 10 új könyv. Két év alatt az kb két és fél hónap per könyv, Ezért tényleg nem érdemes villanyolvasót venni.

Mondjuk ha többet akarsz olvasni, és nem kökteni rá többet, akkor viszont mindenképpen. Csak nem pdf-et eszik főképpen, ez tény.

Mégegyszer, nagyon sok nem e-könyv fanatikus vett és használ azóta is boldogan Kindle-t. Ami nem véletlen. Lehet, hogy te nem illesz bele a mintába, de akkor kisebbség vagy ;-)

@Dworkyll: én kb 1000-2000 forintos könyveket szoktam venni (használtan is), van könyvtárjegyem, tehát amit nem nem merek elsőre megvenni azt onnan olvasom, és hébe-hóba ajándékba is szoktam könyvet kapni, plusz szüleim könyvespolcai még mindig tartogatnak meglepetéseket :). Szóval ne ebből vond le, mennyi könyvet olvasok évente (kb 20 és 30 között egyébként).

@Mike76: Na valami ilyesmit keresek, hogy egyszer kelljen megformázni egy szövegszerkesztőben és onnantól könnyedén generálhassam a könyvet. Mi ez az Atlantis? Rákeresek...

@pytta: Peace :-) Nem személyeskedni akartam, hanem rámutatni, hogy többet olvasol, és többet költesz. Az évi tizenöt ropi még mindig nagyon kevésnek tűnik, de te tudod. Ez 10 mozijegy, vagy 3 színházjegy, vagy 1 koncertjegy, csak hogy szigorúan a kultúránál maradjunk. Mivel te felbukkantál itt, sőt értelmesen hozzá is szóltál, abból nekem az jött lem, hogy költesz kultúrára.

Ezekhez a számokhoz mérve+plusz a fogyasztással összevetve szerintem simán értelmes befektetés egy olvasó.

@penumbra1984: www.atlantiswordprocessor.com/en/ benne save as epub funkció

Találtam egy ilyet is: www.aspose.com/blogs/blogs/blogs/?p=2757

@Dworkyll: hát... az a baj, hogy én ezt elsősorban nem kulturális kiadásnak tekintem (mármint pénzkiadás, érted). Ezért még magasnak tartom az e-könyv olvasó árát. Barátkozni kell vele, nem sietem el semmiképpen mert most a 'várólistámon' legalább félévre való "papírkönyv" van, amik már tulajdonomban vannak, tehát majd ha azokat elolvastam, akkor gondolkodom ilyesmin :)

@penumbra1984: Filléres cucc, ezer dolcsiról indul: www.aspose.com/categories/.net-components/aspose.words-for-.net/default.aspx ;-)

@Dworkyll: Ja azt nem vettem észre. :) Amúgy is okosítottam egy Atlantist, most abban próbálkozom. Az csak 70 dolcsi (lenne). ;)

Ez jó:
www.aspose.com/community/files/69/free-utilities/aspose.words-express/category1319.aspx

Docx-ből (tartalomjegyzékkel) epub.
Calibre-be betöltve, metaadatok kitöltve, konvertálva mobi-ba.
Egész jó.
Tartalomjegyzék van, ncx van.

Bár a profik biztos azt mondják tele van "szemetelve" meg hasonlók... :) De első ránézésre a Kindle-n, nem rossz.

Még mindig keresem a mobi/prc gyártás legegyszerűbb, de jó ereményt adó formáját:)

@guti.haz14: @Mike76: Én a MS Word->szűrt html->Calibre konverziót szoktam használni, de ingyenesnek jól használható a Libre/Open Office->ODT->Calibre is.

@Gukker: nekem a végjegyzeteket is hozzáadta a tartalomjegyzékhez (szűrt html-ből).
Lehet vmit állítani a Calibre-ben, hogy ne adja hozzá?

@guti.haz14: A Wordben az egyes tartalomjegyzékszinteket (címsorokat/fejezetcímeket) formázd címsor1-2-3 stb.-re szintnek megfelelően. A Calibre-ben konvertáláskor a Tartalomjegyzéknél a "Tartalomjegyzék x. szintje" mellett a varázspálcára kattintva a legördülő listából válaszd ki a h1-et. Ez ugye=heading1=címsor1. Ekkor a //h:h1 kifejezés jelenik meg. A többi szintre dettó.
Ezt alapértelmezetté tudod tenni a beállítások gomb/konvertálás/közös beállítások/tartalomjegyzék alatt!
Érdemes még a struktúra felismerés oldalt megnézni a konvertálásnál. a //*[name()='h1' or name()='h2'] kifejezés esetén a h1 és h2 stílusú bekezdések elé beszúr egy oldaltörést. Ez fejezetcímeknél jól jöhet, de ha nem kell pl. a második szintnél, akkor töröld a ráutaló részt.
Érdemes böngészgetni a beállításokat nagyon szépen finoman be lehet hangolni a Calibre-t, ha értesz hozzá.

@guti.haz14: Ja és a szűrt html azért is jó, mert a lábjegyzeteket automatikusan végjegyzetekké alakítja. A trükkje az, hogy elmented pl. a word docot szűrt html-re, kilépsz és újra megnyitod. Ha nem lépsz ki, akkor nem látod, hogy megcsinálta volna, hiába mentesz.

@Gukker:
Köszi. Így már azért jobban használható a Calibre.

@Ignis_veneficus: Ez érdekelne. A megfelelő doc/rtf alatt mit értesz?

@ehran: Adott nevesitett stilusokkal van jelolve, pl: Meta.Cim nevu stilussal van jelolve a konyv cime, Meta.Iro nevuvel az iro, stb..
Hasonloan van egy stilushalmaz a konyvstruktura kezelesehez.
Ebbol egy standardizalt xml lesz, ami az IVB projecthez hasonloan atkonvertalodik epub/mobi formatumba.

@penumbra1984: szia, épp olvasom a kommentet, és mivel én is rengeteget szenvedtem evvel a problémával írom is a tapasztalataimat ( lehet, hogy a továbbiakban már megválaszolta valaki okosabban, de azért ideírom): megformázom a doc/rtf anyagot - címsorozás, behúzások, stb - aztán weblapként mentem el. Ezt rakom be a Mobipocketbe - itt borító, tartalomjegyzék, metaadatok stb - majd a kész prc-t nyomhatod is fel az olvasódra. Nekem így minden esetben megmaradt a word-formázás (weblap-mentésként és NEM szűrt weblapként) Nekem így tűnt a legegyszerűbbnek...És mivel a Calibre-vel katalogizálom az e-bookjaimat, ezert általában erről küldöm fel az olvasóra. Ha érdekel esetleg átküldhetek egy általam összerakott könyvet, hadd lásd, hogy mi az eredmény.

@urielz29: De jó, neked sikerült működésre bírni mobipocket creatort? Én elekadok ott, hogy beimportálom a dokumentumot doc-ból vagy html-ből. Tartalomjegyzék hozzáadása... na ott áll meg a tudomány, mit írjak azokba a rubrikákba? Valami HTML kódot kér oda gondolom (h1, h2, h3 meg társai, amik jelzik a fejezetcímeket), de én ahhoz nem sokat értek.
innatetalent@gmail.com -ra jöhet. :)

@urielz29: Ha használod a Calibre-t, minek a MPC? Az mivel tud többet, mint a Calibre?

@Gukker:
Nekem az MPC sokkal egyszerűbbnek tűnik mint a Calibre....Publikációt MPC-vel rakok össze, Calibre-t csak katalogizálásra( meg esetleg metaadatok pótlására) használok. Ha csatlakoztatom az eszközt, akkor szépen megmondja hogy mi van fent az olvasón és mi nincs....többszáz könyv esetében meglehetősen hasznos tud lenni; és én személy szerint villámgyorsan be tudok tölteni adattal minden üres helyet, legyen az olvasó, pc....("horror vacui"??? :-) lehetséges...)

"felugró ablakok"?! Te jó ég!!

@naxa: Lábjegyzet, pl. Nem akkora kaland. Különben is: szines könyv volt már Gutenberg előtt is, sőt. Oszt ma mégis van élet egy biten is, (plusz címlap). Az új lehetőségek lehetőségek, nem kötelezőek. Amihez nem kell, nem használjuk.

@Dworkyll: mekkora otlet(popup labjegyzet)! ki is fogom probalni.

@Dworkyll: Csak az a gaz, hogy a pop-up-rol csak egy mondatot talaltam:
"Children's picture books come to life with brilliant images, fixed layouts and Kindle Text Pop Up."
ezt is a "demo" oldalon, kozben meg a "Publishing on Kindle: Guidelines for Publishers" -ban semmi "pop" stringget, helyette "Region Magnification" -rol beszel, ami meg nem a alapertelmezett "pop-up"

@SaGa: Betoltam egy szuz(nem epubos) konyvet a kindlegen-be:
1. tapasztalat: nagy, nagyon nagy lett a kimenet (kb 2.9M-s bemenetbol 4.8-as kimenet ugy, hogy 50%-os tomorites)
2: valszeg megmagyarazza az elozot: a log szerint 2* kerult bele a dokumentum:
---------kindlegen kimenet-------
Info(prcgen):I1017: Building PRC file, record count: 0000377
Info(prcgen):I1039: Final stats - text compressed to (in % of original size): 062.56%
Info(prcgen):I1040: The document identifier is: "xxxxxxxxxxxx"
Info(prcgen):I1041: The file format version is V6
Info(prcgen):I1031: Saving PRC file
Info(prcgen):I1033: PRC built with WARNINGS!
Info(prcgen):I1016: Building enhanced PRC file
Info(prcgen):I1007: Resolving mediaidlinks
Info(prcgen):I1011: Writing mediaidlinks
Info(prcgen):I1009: Resolving guide items
Info(prcgen):I1017: Building PRC file, record count: 0000540
Info(prcgen):I1039: Final stats - text compressed to (in % of original size): 053.87%
Info(prcgen):I1041: The file format version is V8
Info(prcgen):I1032: PRC built successfully
Info(prcgen):I1037: Mobi file built with WARNINGS!

en meg azt hittem, hogy kiesik a vegen belole egy .mobi _es_ egy .kf8 file

@Ignis_veneficus: "en meg azt hittem, hogy kiesik a vegen belole egy .mobi _es_ egy .kf8 file"

Jó hercegem, te még hiszel a mesékben?

A viccet félretéve, szerintem az Amazon weboldala egyértelműbb nem is lehetne:

Highlights of KindleGen functionality
* Support for all KF8 functionality
* Generates (!!!!)a single file(!!!!) supporting both KF8 and Mobi format
* Support for multiple source formats including HTML, XHTML and EPUB

@elminster: pont atsikolottam azon a soron..

Lassan ideje lenne már az e-könyveket is szabványosítani és egy szabványt fejleszteni, mert már nemcsak az olvasó eszközöknél van kavar, henem a formátumoknál is és ezt az olvasó nem szereti. Én, ha olvasó vagyok, akkor azt szeretem, ha nem kell gondolkodni, nekem mi a jó, s pláne nem kell konvertálgatni semmit semmivé. Megint egy formátum, ami megint nem mindenkinek lesz megfelelő. Legyen már egy blueray-e-book-mp3 meg mit tudom én mi egységes szabvány és csináljunk arra könyveket, aztán még talán kedvet is kapnak az emberek a vásárláshoz.

@ff48bp: A KF8 csak annyira nem jó valakinek, mint amennyire mobi/prc. Jelenleg ugyanis az történik, hogy a KF8 előállításakor a publikációban létre jön a mobi/prc verzió is. Így a régebbi Kindle olvasó eszközöknek elég egy frissítés, hogy felismerjék a KF8 formátumot és kitúrják belőle a nekik megfelelő mobit. Az, hogy mennyire lesz optimalizált ennek a mellékesen létrejött mobi fájlnak a kinézete, az már a tartalom előállító gondja-baja lesz. A felhasználó remélhetőleg nem fog ebből érzékelni semmit.

Én most épp arra vagyok kíváncsi amire Ignis is. Vajon kompatibilis lesz-e az okosabb html5+css3-as formátummal az einkes Kindle, és ha igen, akkor mikortól és melyik generációtól felfelé (van ugye négy + a DX-ek).

@ff48bp: Van szabvany, ugy hivjak, hogy epub (tobb verzio) ua a problemaja, mint a HTML-nek: mindenki maskep ertelmezi, jeleniti meg.
es van a masik ami nem szabvany, de az amazon 139$-ert utanaddobja az olvasojat, ez a kindle es a mobipocket, mint formatum, ebbol jelent meg a kov verzio. Ez meg kb ua mint az MS Word, es a .Doc mint formatum. nem szabvanyos de mindenki ezt hasznalja, es minden estben ugyanugy jelenik meg (ooo.. a word eseten nem teljesen igaz, de tok mindegy) es mintha abbol jelenne meg egy uj formatum, mondjuk a docx.

@Ignis_veneficus: Még egy oka van annak, hogy ilyen szép nagy: hiába adtam meg a legnagyobb tömörítést, bezipelve jó 35%-kal kisebb lett a mobi. Azaz a kindlegen több lépcsős tömörítője sem éri el egy zip teljesítményét.

Szerintem egy olvasónak már az sem jó, ha kétféle verzió van. Az olvasó azt szereti, ha úgy vásárol e-könyvet, ahogy a papírkönyvet: tetszik neki a tartalma és megveszi. Miért nem lehet egyféle szabvány? Én mindenképpen az egységesítés mellett lennék. Aztán az lehet kf8 vagy akármi, ez lényegtelen, csak olvasni lehessen mindenféle hozzáértés nélkül egy egyszerű programmal, vagy egy egyszerű olvasóval.

@ff48bp: Mert egyfele szabvany van.
Es van egy zart konyv formatum.
Es van eszkoz, ami tamogatja a szabvanyt, es van eszkoz, ami meg nem.
A "mezei" olvaso a vilag boldogabbik fele vesz egy olvasot, amit eppen a kedvenc konyvarusa (amazon, B&N, stb) arul, vagy valami hasonlot (iPad) es automatikusan kap melle egy boltot tele mindennel ami szep es jo (most mar filmmel, zenevel magazinokkal is tele)
egy "mezei" olvaso nem is tudja, hogy milyen formatumot olvas a gepe, mert a beepitett boltbol vasarol.

@SaGa: Szerintem a Palm korszakbol maradt adatbazisstruktura miatt akkora, amekkora

@Ignis_veneficus: Talán térjünk vissza a gyakorlati életbe és nézzük az itthoni helyzetet, s akkor már nem ilyen szép kép. Vagy szerinted igen? Te is tudod, hogy eddig sem volt egyféle szabvány itthon. Ok, megint olyanról beszélünk, ami már régen lerágott csont, szóval nem szólok, csak halkan mondom, hogy kellene az a szabvány, egyféle típusra, mert nincs.

@ff48bp: Nem igazán értem miféle szabványt vársz? De facto szabványnak ott a mobi és az epub. De jure szabványt pedig hiába vársz. Egy ilyen dolgot leszabályozni csak a piac tud, más nem. Emlékezz pl. a VHS-Beta párharcra. Hiába volt a Beta szinte mindenben jobb, mint a VHS, mégis az utóbbi győzött a jobb árazás miatt.
Visíthatsz szabvány után, de ezt úgyis a piac fogja eldönteni. Vagy csinálj magadnak egy szabványt, azt reménykedj, hogy valaki komolyan vesz.

Jaj pajtások, ne durvázzatok már :-) Amúgy én is az "alulról jövő", a többség által elfogadott és használható "szabványokban" hiszek. A pdf papíron nem az, valójában mégis. Stb.

Annyi analógia van az utóbbi pár évtized techikatörténelmében: VHS vs Betamax, a GSM, az mp3plus vs ogg/flac, a minidisk vs CD, stb.

Evvel a logikával szerintem a mobi/prc szabvány, mert gyakorlatilag mindenen el lehet olvasni, könnyű előállítani, és konzisztensen fog viselkedni. Hasonlóan a pdf-hez.
És ezért nem szeretem az epubot, mert bár a lehetőségei bővebbek, piszokul szór a viselkedése annak függvényében, hogy min próbálom nézni.

@Gukker:
Olyat nem lehet véletlenül beállítani a Calibre-ben, hogy az oldaltöréseket békén hagyja? Tehát ne vegye ki, és ne is tegyen be automatikusan.

@guti.haz14: A Calibre (hacsak nem állítottál kézzel valamit) alapból csak berak oldaltörést. A konvertálás struktúra felismerés részében van oldalrörés beszúrása. Alapértelmezetten a következő kivejezésre: //*[name()='h1' or name()='h2'] ez a címsor1 (h1) és címsor2 (h2) formázott bekezdések elé rak oldaltörést. Ezt persze ki lehet törölni.
Ez persze akkor igaz, ha html a forrás. Pl. pdf-nél ugye ez teljesen kiszámíthatatlan.
De részletezd a problémát nyugodtan, hátha tudok segíteni.

@Gukker: Word-ből mentett szürt html a forrás.
Az volt a problémám, hogy a rész címét (Címsor 1), az alcímet (Címsor 2), illetve egy egymondatos összefoglalást egy oldalon szerettem volna szerepeltetni. Oldaltörés volt utána, így a szöveg a következő oldalon kezdődött (a Word-ben).
Néhány résznél ugyanez volt a felépítés, csak az oldaltörések után voltak fejezetcímek is (Címsor 3).

A konverzió során 3 résznél benne maradt az oldaltörés, 3 résznél nem.
Nem tudom mi alapján tartotta meg, vagy vette ki, mivel a Wordben minden egyforma volt.

Végül minden oldaltörést kitöröltem, és kézzel újra beszúrtam. Az eredeti dokumentumban az oldaltörések a pdf-doc konverzió során kerültek be automatikusan. Úgy látszik ezeket nem tudta megfelelően/egységesen értemezni a Calibre.

@guti.haz14: Amit az első bekezdésben írtál, arra jó az, amit írtam az előző postban.
A második probléma meg a wordből adódik szerintem. Nézd meg a kérdéses dokumentum htm forráskódját. Lehet, hogy mégis másféle kódokat használ oldaltörésre, de a word dokumentumban ezt nem veszed észre.
Egyébként sem kell kézzel cserélgetni. Erre van a word keresés/csere funkciója. A házi könyvkészítők legjobb barátja!
A pdf mint mondtam más tészta. Ott semmit nem tudsz kiszámítani. De ez nem a Calibre hibája. Minden attól függ, mennyire rendesen lett elkészítve a forrásdokumentum. Pdf-nél érdemesebb ocr programot használni, különben a bekezdésvégekkel óriási problémák lehetnek.

@Gukker: Nem kézzel szoktam cserélgetni, de ebben az esetben mindössze 6 oldaltörést kellett kicserélni, pontosan meghatározott helyeken.

A pdf-word konverziót nem a Calibre-vel csináltam, hanem egy ocr programmal. Ezt találtam még a legelfogadhatóbbnak. A bekezdéseket általában helyesen értelmezi, egyedül az oldaltöréseknél van probléma, főleg akkor, ha oldalszámot is tartalmaz a pdf. Ilyenkor kereséssel megtalálja a word (pl. bármely számjegy, bekezdésjel, szakasztörés), de nem cseréli. Gyanítom mert valamiféle mezőként szerepel az oldalszám.

Nincs valaminek egy Fire eszkoze? kuldenek ra tartalmat, es kivancsi lennek a velemenyere, es arra hogy mennyiben ter el a megjelenitett cucc a kindle preview-tol..

kosz