Már többször le akartam írni az alábbiakat, de mindig visszaléptem, hogy ne ronsam el senki üzletét. Látom, már nem csak az én szememet szúrja, így összefoglalom:

Nagyom sajnálom, hogy anno itt felhívtam az e-pub gyártók figyelmét az Atlantisra. Akkor jó ötletnek tűnt, de hosszú távon nem vált be. Kereskedelmi szoftver, amit egy jó ideje egyáltalán nem fejlesztenek, és amit előállít az nagyon gányolt cucc. Hasonlít az e-pubra, de nem az. Saját, otthoni, civil használatra is csak addig volt jó, míg meg nem jelent a már használható writer2epub kiegészítő a LibreOffice-hoz. Azóta az én példányomat uninstalláltam, pedig anno ki is fizettem.

Az Atlantis által előállított e-pub szerűségből a Sigil (vagy a notepad) segítségével elő lehet ugyan állítani pár óra alatt egy ténylegesen e-pub szerkezetű, jó minőségű munkát, de a tapasztalatom az, hogy még a hivatásszerűen ezzel foglalkozók sem veszik a fáradságot erre. Nem törlik a felesleges, duplázott formátumokat, nem állítják be rendesen azok tartalmát, nem törlik a felesleges belső formázásokat (amikor pl egy gondolatjel vagy őű betű miatt befejez egy class-t, majd újranyitja, lezárja és ismét újranyitja), és a könyvtárszerkezetet sem javítják ki szabványosra. Már pedig ez még otthonra is gáz, pénzért árusított e-pubnál meg bűn, a vásárlók átverése. Tudom, az ilyen e-pubot is megmutatja az ADE jól, az átlag olvasó nem veszi észre, hogy belül mi van, de ettől még nem lesz jó.

Mivel nem mindenki xml guru (én sem), nem tud xsl-ekkel operálni, szükség van valami alap xhtml előállítóra. Erre jelenleg a legalkalmasabb a writer2epub. Ez ugyan nem ágyazza be a felhasznált fontokat, mint az Atlantis, de az utóbbi átal elkövetett beágyazást is javítani kell a sigilben, így nem veszítünk vele semmit. Ezt is végig kell nézni és kézzel javítgatni a formátum osztályokat (a tartalmukat, mert az eredeti, A4-A5 formátumhoz igazítja a méretezést, ami a tipikus olvasóknál aránytalanul nagy lesz), de ebben legalább nincsenek duplázott osztályok, nem csinál felesleges "class" használatot, nem szemeteli tele a forrást.
A Sigil a legalkalmasabb az e-pub "kézi" előállítására jelenleg. Alapjában véve egy olyan "notepad", ami figyel arra, hogy a tag-ek lezárása rendben legyen, az xhtml szabványnak megfeleljen az egész és képes megmutatni, hogy kb hogy is fog kinézni az oldal, amikor megváltoztatom valamelyik bejegyzést a css-ben. Elő lehet vele állítani txt-ből is e-pubot, ha valakinek ilyen forrása van.

Igen, ha valóban szépet akarok, akkor ez 1-2-9 órányi kézi munka, nyersanyag minőségtől és a könyv formátumának összetettségétől függően. Nem fogja automatikusan beméretezni a beágyazott, körülfolyatott képeket, a táblázatokat, iniciálékat, ezt mind kézzel kell megtenni és minden változtatást ellenőrizni legalább két olvasó programmal/eszközzel. Néha még a toc.ncx-be és a content.opf-be is kézzel kell belenyúlni, de az eredmény miatt megéri és aki üzletszerűen árusít e-pubot, annak kötelező!
Lenne.

@kIára: Megnézném egy ezer oldalas könyv tagről tagre való átnézését :)
Egy tipográfus meg nem programozó általában. és pont az a baj, hogy az ekönyv készítése környékén teljesen tipográfiai analfabéták tünnek fel, akik a te elved szerint akarnak könyvet csinálni, de nem tudják mit jelent a behúzás, a sortávolság és a többi (beszéltem több ilyennel). Szerinted az amazonnál is 10000 kódoló ül?

@SaGa:
Végre, lassan kiderül, hogy amit jónéhányan egymástól függetlenül gagyogunk nem csupán Vox clamantis in deserto.
Amúgy ismerem, olykor használom a writer2epub kiterjesztést, szerintem is jelenleg a felhasználók számára legalkalmasabb megoldás, az xhtml exportja pedig majdnem kifogástalan.

@_iMaginer_:
A tipográfus–kódoló ellentétről vallott tapasztalatod sajnos csak megerősíteni tudom (talán egyedüli kivételt képeznek a Tex/LaTex-et használók).
Amúgy külön tisztelet illeti ezt a blogot, amiért a howto/tech-rovatok-, posztokban az alapvető tipográfiai ismeretekre is felhívja a figyelmet – talán két ilyen irányú agytágító kommentemet az adminok ki is emelték.

Mindenesetre ez már nagyon off-topic.
Hajrá, DeltaVision – a gyerekbetegségeken át kell esni –, száz e-könyvet, ezeret!

@kIára: @SaGa: Nem megkérdőjelezve a minőség és az elvek iránti elkötelezettségeteket, a writer2epub-sigil-kézimunka vonal egyszerűen irreális.

A jellemző eladott példányszám/cím most nagy jóindulattal pár tucat. A vállalt konverziós költségvetés párezer forint/cím. Az elvárt konverziós sebesség meg sok cím/nap.

Ezek együtt persze egymásnak is ellentmondanak. Ebbe piszok nehezen fog beleférni egy ideális állapotú epub legyártása ideális áron.

Az atlantison meg bizony fejlesztettek, meg fejlesztenek folyamatosan, igaz mehetne gyorsabban is, (pl. a fölösleges classolás sincs már benne nagyon régóta). A mocskos kapitalisták meg sajnos költséghatékonyan akarnak dolgoztatni, az általatok vázolt útvonal egyszerűen nem fér bele. Szerintem. Komolyan kérdezve, ti mennyiért tolnátok keresztül mondjuk egy rtf-et egy writer2epub-sigil-ellenőrzés gépsoron?

Arról nem beszélve, hogy láttam már így készült anyagokat, és gondolom pont a módszer komplexitása miatt nem is sikerültek túl jól.

Ezért is mondom, hogy nem csak az olvasásra, de az előállításra is kell valami egységes robusztus alkalmazás, ne nyolcféléből kelljen összeszkriptelni, kattintgatni. Vagy legalább egy validátor.

@Dworkyll: És még egy. 10 vásárlóból 8 nem az epubot használja, hanem a mobit/prc-t. Ezért sem érdemes "belehalni a szépségbe" epub fronton.

Ezzel együtt nem akartok egy gyártós cikket írni a writer2epub-sigil útvonalról? Mert szerintem is kellene.

@Dworkyll:
Már jeleztem, hogy ez már off-topic, szerintem ebben a kommentfolyamban a DeltaVisionról kellene dumálni.

Azért nem állom meg, hogy legalább erre ne válaszoljak:
       „Az elvárt konverziós sebesség meg sok cím/nap.” -- írod.
Miért is? René Guénon szerint a mennyiség uralma a végidők jele
Ha egy kiadó egyetlen egy papírkönyvre akár két-három hónapot, néha félévet, olykor éveket rászán, akkor annak az elektronikus variánsára miért elég 10 percnél alig több/kevesebb idő?
Alig látszó fogyasztói réteg, piac mellett?

Vegyük pl. a kiadó új fordítású Pratchett-sorozatát. Az első (Fegyvertársak) 2009-ben jelent meg, azóta további 15 kötet. Három év tizenhat könyv. Papírban ez iszonyú sebesség ([{sajnos néha a fordítások minőségében meg is látszik}]), mégis ízlelgessük: 3 év 16 könyv. Majd hasonlítsuk össze ezzel: „sok cím/nap”.
Most vonjak gasztronómiai párhuzamot egy eredetvédett és a tecsós akciós sonka között, vagy anélkül is érthető?

       „Ezért is mondom, hogy nem csak az olvasásra, de az előállításra is kell valami egységes robusztus alkalmazás, ne nyolcféléből kelljen összeszkriptelni, kattintgatni.” – teljesen felesleges, csupán a szabványt és parsereket ismerő szakemberek kellenek. Az ilyen atlantis, writer2epub, calibre maradjon a civilek amatőrök otthoni játékszere.
       „Vagy legalább egy validátor.” – ebből kettő is van. Az egyik maga az IDPF validatora, a másik meg az olvasó/vásárló/fogyasztó. :P

@Dworkyll:
Ezt már ezerszer elmagyarázták, sőt maga az Amazon (a formátumtulajdonos) is kitér erre a Publishing Guideline-ban. Minek maszatolni? MOBI=EPUB, csak Huffman tömörítéssel és néhány apró eltéréssel az opf/ncx-ben.

       „Ezzel együtt nem akartok egy gyártós cikket írni a writer2epub-sigil útvonalról? Mert szerintem is kellene.” – nem tudom, hogy miért lettünk többes számban megszólítva, valóban ismerem a writer2epub–sigil „útvonalat” de ez is csak egy újabb felhasználókat, civileket érintő tutorial lenne amivel tele van a világháló.
(Röviden: „ha OOo-t vagy LO-t használsz, telepítsd a writer2epub kiterjesztést, azzal generálj epubot, majd a Sigilben nevelgesd tovább”.)

@kIára: " teljesen felesleges, csupán a szabványt és parsereket ismerő szakemberek kellenek"

Szerintem ez kevés, mert bár notepad++-al és pkzippel is lehet epubot gyártani, de lassú és drága. Hát ezért kellene egy kézreálló kreátor. Mert addig maradnak a barkácsolások.

Re: gyártós cikk. Nem te vagy az egyetlen, pl. SaGa is ezt a vonalat proponálta, és valamiért nem ti vagytok az egyetlenek. És egy csomó civil olvassa ezt a blogot, (pl. én ;-) na nekik, nekünk lenne ez érdekes. Én pl. nagyon szenvedtem a sigillel, amit sokkal rosszabbul kezelhetőnek tartok, mint akár az atlantist. Sigilben összerakott epubokban is kellett már hibát keresnem, és nem voltam tőle boldog. Hiába szipi-szupi-szabványos.

@kIára: Én például nagyon örülnék egy hülyéknek szóló tutorialra (ami megint végigmegy azon, hogy pontosan hogy nézzen ki a szöveg oOO/LOban, mi az, amit mindenképpen kell piszkálni a Sigilben, és hogyan (pl. illusztrációk).

@Komavary: mármint illusztrációk alatt nem azt értem, hogy kép arról, hova kell kattintani a tálcán, hogy elinduljon a LO, hanem hogy milyen formátumban, minőségben és hogyanérdemes beletenni pl. egy ff, egy színes képet a könyvbe.

@Dworkyll:

Borzasztóan offtopicolunk, de te vagy az admin…
      „mert bár notepad++-al és pkzippel is lehet epubot gyártani, de lassú és drága” – so what? Így KELL gyártani.

Kezdem érteni az érvelésed (talán még pontosabban az érvelési pozíciód) ezért inkább magamnak válaszolok. Soha nem fogunk egyetérteni – hál’ istennek, nem is kell. Te deklaráltan véghasználói szempontból közelíted meg nemcsak a fogyasztást, hanem a termelést ist.
Sajnos valóban így alakult, évekig magunknak kellett (és sajnos még sokáig magunknak kell) legyártani saját (egyre jobbá váló és többet tudó) kütyüjeinkre a kívánt, elfogyasztandó tartalomból a formátumot. Az egyre szebben gyarapodó közkincsekből, legális és kalóz tartalmakból, az egyre népszerűbb open, free vagy libre ideológiát képviselő szoftverfejlesztők által készített alkalmazásokkal immár elvileg bárki képes magának saját fogyasztásra alkalmas tartalmat előállítani. Ez jó szép üdvös. 8–10 perc, olykor csupán pár másodperc és kész a saját tartalmam (ez esetben olvasandó szöveg).
Ha azonban kiadónak dogozom akkor a gyártott
– a mobit minden egyes alkalommal ellenőrzöm: a K. Previewerben, a K. for Pc-n, a K. CloudReaderben és KÉT (!) különböző Kindle-n. (Ez az egyszerűbb eset, mert zárt kör.)
– az epubot ellenőrzöm: Nook, Sony, és DPS 750 olvasókon, három androidos alkalmazáson, egy GPS készüléken (!) továbbá ADE-n, Coolreader, FbReader, Lucidor, CalibreViewer, NookFor Pc-n, Kobo Desktop Readeren, Firefox és Opera kiegészítőn.

Ahhoz pedig, hogy a fent felsorolt alkalmazás- és eszközkörön a látott és elvárt élmény a lehető legegységesebb legyen, az atlantis, writer2epub, calibre stb. édeskevés. Ez bizony source editor és zip meló.
_____

Másképpen fogalmazva: ha Steve Jobs-féle i…-t akarunk „adni” az júzereknek, akkor a háttérben a Donald Knuth-féle emberekre bízzuk a melót.

( Egyszer, ha lesz egy szabad félórád, ajánlom figyelmedbe: river-valley.tv/media/conferences/tug-2010/Don-Knuth/ )

@kIára: Csak megjegyezném: a Sigil-t kapcsold át könyv nézetről forrás nézetre és kapsz egy olyan notepad++-t, ami menet közben ellenőrzi, hogy az xhtml szintaxisnak megfelelnek-e a tag-ek és azok paraméterei, lezártad-e őket ahogy kell, illetve pontosan tudja, hogy milyen könyvtárszerkezetben kell elhelyezni a fájlokat, melyik betűtípus lesz jó és melyik nem, és azt is tudja, hogy a kész e-pubba melyik fájlt kell elsőként becsomagolni, hogy a szabványnak megfeleljen.
Az már csak hab a tortán, hogy - ellentétben a notepad++-szal, amit egyébként én is használok ott, ahova az kell - ez létezik 64 bites és linux verziókban is.

@Komavary: Nem bonyolult. Az, hogy mi hogyan nézzen ki, rajtad áll, illetve az eredeti kötettől függ. Mivel az olvasók tipikusan 6"-osak, a kinézetet vagy A6-os, vagy ha pontosabb akarsz lenni, 256x340 pt méretű, minimális (1-2pt) margóval rendelkező oldalhoz állítod be.

Szükséges a LibreOffice vagy OpenOffice. Ehhez kell a writer2epub kiegészítő, illetve ha akarsz ligaturákat és egyéb szedői finomságokat, érdemes a lighproof kieget is felrakni.

A bekezdésformátumokat a címsorok (Címsor 1 ... Címsor x) kivételével át kell nevezni "w2e_" karaktersorral kezdődőekre.
A Writer2epub beállításainél NE! jelöld be az "index" létrehozását, attól el szokott szállni. A fontbeágyazással sem érdemes vesződni, mert nem azt az eredményt adja, amit szeretnél.

A kész e-pubot told be a sigilbe. Itt add hozzá a fontokat, képeket, állítsd be, hogy melyik fájl lesz a borító, a tartalomjegyzék, a kolofón, a névmutató, stb. Ezeket a content.opf-ben én le szoktam fordítani magyarra. Nem a tag-et, hanem a tartalmát, amit megjelenít az olvasó.
A styles.css-hez is add hozzá a fontokat, a megfelelő bekezdésstílusokhoz is. Magyarul: megnyitod szerkesztésre és kézzel beleírod ahogy kell és ahova kell.
A ligaturákat is kézzel kell létrehozni, ahogy a képek pontos beállítását is.

A képeket én akkorára szoktam méretezni, hogy 166 dpi-ben 600x800-as oldalt veszek alapul, ehhez arányítva eleve beállítom a méretet. Vagy ha arra számítok, hogy nagyobb kijelzőn is használni fogják, mindkét irányan megduplázom. Akkor ebben a méretben sem lesz csúnya, meg nagyobban sem.

Ha mobi-t is akarsz, a kész epub-ot betolod a kindlegenbe. Ha van táblázat is benne, azt ellenőrizni kell, mert a Kindle ezeket még mindig nem túl megbízhtóan kezeli, lehet, hogy a cellaméretekkel kicsit trükközni kell.

@kIára: Mennyi idő ez a folyamat egy kb. 500 oldalas könyvnél? Ez engem a hőskorra emlékeztet, amikor a fényszedőgépekhez programozószerű ismeret kellett.

@SaGa: Csak én vagyok értetlen, hogy elvárnám egy ekkora piac láttán, hogy az adobe vagy más miért nem tud kijönni egy profi szoftverrel? Szerintem ez egyszerűbb kell legyen mint egy InDesign vagy Quark. Tőlem sem várja el senki hogy az indesign-t vagy a pdf-et sorrol sorra ellenőrizzem bbedittel. Szerintem az olvasók 99.9%-a nem nézi az ekönyv forrását hogy milyen szép és letisztult, hanem hogy jó-e a könyv és ne legyen tele helyesírási hibákkal.

@Dworkyll: Több kérdés is előkerült.

Az Atlantison jó rég nem fejlesztettek semmit, de ezen nem fogunk összeveszni. Illetve látom, hogy kijött valamikor az 1.6.5.9, amiben a "fejlesztés" a címoldalra illesztendő kép méretezésének és elhelyezésének javítása. Bocs, ez vicces, amikor sokkal fontosabb lenne pl az e-pub belső könyvtárszerkezetének gányolt volta, vagy az ő-ű betűk kezelése körüli szemetelés felszámolása.

Szóval a kérdések:
Ár: Már gondolkodtam rajta, hogy mennyit is kérnék egy könyvért, ha ebből kellene megélnem. Amennyiben a forrás egy szerkesztett és formázott rtf vagy doc, vagy odt, vagy bármi (azaz nem nekem kell elvégeznem azt, amit a tipográfusnak, szerkesztőnek és korrektornak kellene), akkor az egész folyamat a LO-ba beolvasástól a kész epub-ig eltelik, egy egyszerű kötetnél 1-2 óra, egy bonyolult, sok beágyazott képet, esetleg táblázatokat, ligaturáket is tartalmazó kötetnél 4-6 óra tud lenni. Abből kifolyólag egy egyszerűbb kötetért 8-10, egy összetettebbért 20-30 ezer Ft-ot tartanék normálisnak. Ezért a pénzért kapsz egy epub, egy pdf, egy mobi és egy prc fájlt. Ráadásul a pdf és odt-ben arra is figyelni szoktam, hogy egy oldal ne álljon 3 sornál kevesebből pl a fejezetek végén.
Ha sok időm van és a könyv tartalma/szerkezete igényli, még az elvélasztásokkal is el szoktam játszani, hogy ne legyen túl sok egymás után, figyelek a "csatornákra", stb. Ezekre pl az epub esetén nem kell, így ebben az időben és árban nincs is benne.

Ehhez persze az is kell, hogy a szükséges betűfájlok is rendelkezésre álljanak. Nekem gyakorta egy-két nap is rámegy arra, hogy a könyben található betűkhöz leginkább hasonló, szabad felhasználású fontokat megkeressem, és ha kell, létrehozzam bennük a hiányzó ékezetes karaktereket és ligaturákat. Van olyan e-könyvem, amihez iniciálékat készítettem. Azaz egy olyan font fájlt, amiben a könyben látható fejezetkezdő rajzocskákat ápítettem be, mert ha képként emelem be őket a könyvbe és az olvasó betűméretet állít, ezek nem változnak vele együtt - így aránytalanná vélnak -, míg ha betűként vannak beillesztve, igen. Ez persze a prc-be már nem tud átmenni sajnos, de a mobiba igen. Ez nincs benne a fenti árban természetesen és kiadói "dolgozóként" nem is tenném meg, csak külön szerződéssel.

Idő: ahogy írtam 1-2 órától 1-2 munkanapig, mérettől és bonyolultságtól függően. Egy albumszerű kiadvánnyal sok meló van, egy csak szövegeket tartalmazóval kevesebb.

Az, hogy némely ezzel s "gépsorral" készült e-pub nem sikerült jól, nem a komplexitás, hanem a készítő tapasztalatlansága vagy igénytelensége miatt van. Azt látatlanban merem állítani, hogy az Atlantisból kijött és azt tisztítás, szabványosítás nélkül kereskedelmi forgalomba hozott e-pubnál egyik sem lehet rosszabb, ha legalább a címsorok ki vannak emelve címsorként és van tartalomjegyzéke.
A Sigil nem egy wysiwyg editor, bár vannak ilyen kvalitásai is (gyengék, részben a QT-nek betudhatóan, pl nem tud egy oldalon belül vastag és dőlt betűket megjeleníteni, de nem is ezért használjuk), hanem egy nagyon jól összerakott xhtml forrás javító eszköz, ami ismeri az e-őpub belső szerkezetét és képes annak megfelelő eredményt összerakni a forrásfájlokból. Nem méretezi helyetted a képeket, táblázatokat, ezeket neked kell tudni, hogyan és "kézzel" bevinni, de ezzel azt is biztosítja, hogy a végeredény az lesz, amit elvársz, nem az, amit egy programozó valahol megálmodott.

@_iMaginer_: Ebben igazad van, az olvasó nem fog szembesülni azzal, hogy amit vett, nem egy igényesen összerakott, szabványos fájl, hanem egy olan valami, ami egy e-pub olvasón úgy ahogy kinéz, mindaddig, míg ezt az olvasót használja. Ha valami mást, akkor meg dühöng. Pl az Atlantis azon hülyeségét, amit írtam (őű betűk és gondolatjelek körül megszakítja, újra nyitja, megszakítja és újranyitja a formázásokat) úgy vettem észre, hogy a telefonomon használt e-pub olvasó a lezárt tag-ek után mindig betett egy szóközt. Ett ő l egy dőlt vgy vastag "Ettől" a mondat elején láthatóan nézett ki.
A kiadó mindenesetre nem engedheti meg magának - a saját jó hírneve miatt -, hogy az amatőrök által saját használatra összerakott e-pub igényesebben legyen elkészítve, mint az, amit pénzért árul. Akkor sem, ha az olvasók 99%-a ezt nem veszi észre.

Egyébként a folyamat időtartama nem az oldalak számától, hanem a könyv tipográfiai, tördelési összetettségétől függ. Ha nincs benne ligatura, sok különböző méretű kép, táblázat, akkor a méret mindegy. Ha ezekből van jó sok, pártíz oldallal is el lehet mókolni napokat.

A profi szotverrel az lesz a baj, hogy minden szerkesztő program, amivel kiadványokat készítünk a könyv szerkezetéhez igazodik, azaz oldalorientált. Az egész szakma ilyen. Egy e-book ellenben folyamatos szöveg, amit a fejezetek vagy a kiemelt bekezdések tördelnek és nem az oldalak.
A mostani kiadványszerkesztő/tördelő programok nem képesek "tekercsként" kezelni a szöveget, pedig ide ez kellene. Ehhez teljesen új alapokra kell helyezni a dolgot. A Sigil pl emiatt is jó. Egy fejezet egy fájl és nincs oldalakra szaggatva. Akkorára állítod magadnak a ablakot, amekkoréra akarod, és azt látod benne, amit majd az olvasón fogsz (nagyjából). Az oldalméretezést használó szerkesztőn nem. Ahhoz, hgoy ilyen "tekercs" jellegű legyen a szerkesztő, gyakorlatilag a programtervezők teljes gondolkodását át kell állítani előbb, mert ami működik az egyikben, nem biztos, hogy átemelhető a másikba.

@SaGa: A quark már elindult ebbe az irányba: youtu.be/RqiJL_zcPbA
A folyamattal és a technikákkal teljesen tisztában vagyok (szerintem itt én vagyok a legrégebben a szakmában – ólomtól az indesign 6-ig). ekönyveket is csináltam, és pont ezért furcsállom a nagyok hozzáállását.

@_iMaginer_: annak idején még postcript nyelvben írtuk meg, hogy a címsornak legyen árnyéka. most ugyanez van az ekönyvvel. szerintem nem ez a jövő :)

@SaGa: Köll nekem ennyit írni, már be is csúszik valami marhaság.
Természetesen nem a ligaturákat kell kézzel létrehozni a sigilben, azokat már a LO/OOo-ban megcsináltad a lightproof támogatásával. Az iniciálékat kell beálíltani, azt nem tudja a writer2epub rendesen átemelni.

Még valami: ha a végeredmény prc (is) lesz, akkor a folyamat kiegészül: az e-pubot átkonvertálja a kindlegen jó, majd a mobi-t szét kell szedni valami kicsomagolóval (én a calibre pluginját használom). A kibontott K7 formátumot meg lehet etetni a mobipocket creatorral, az fogja a legjobb eredményt adni, csak előbb a html-ben át kell alakítani az iniciálékat és a ligaturákat, ha vannak, és az esetleges kiskapitálisokat. Meg a táblázatokat is le kell ellenőrizni, mert sajna a különböző prc olvasók különbözőképp jelenítik meg ugyanazt. Még a Kindle különböző verziói is. Prc-ben a legjobb, ha minden cellaszélesség meg van adva fixen, vagy %-osan (az adott kijelző szlpességéből számolja vissza és összességében max 100% legyen), de néha így is túlnyúlik a képernyő szélén.

@_iMaginer_: Ólommal sosem foglalkoztam, de a kiadványszerkesztgetést még a DOS-os Venturával kezdtem úgy '89-ben. A diplomamunkámat is azzal készítettem lézernyomtatóval, csorgott is a nyála az értékelőknek rendesen tőle a sok írógéppel meg mátrixnyomtatóval készített cucc mellett. Aztán sok év kimaradt, majd pár éve elkezdtem az e-könyv gyártogatást magamnak. Folyamatosan tanulom most is, napról napra több jön vissza a régi tapasztalatokból, illetve tanulok az itt-ott felszedett megjegyzésekből is.

Anno ismerkedtem a Quark-kal, PageMakerrel, FrameMakerrel is. A Ventura ott kezdett elromlani, mikor Corel Ventura lett belőle. Egy nyomdász ismerőst még bevezettem a program kezelésének rejtelmeibe, aztán abbahagytam a kiadványokkal való foglalkozást.

@SaGa:
Ez egyértelmű, (a Sigil WYSWG nézete talán a fő hiba a programban :D)
Amúgy forráskódszerkesztéshez én szinte mindig az abszolút fapados Meditet vagy QuantaPlust használom.

@_iMaginer_:
Szerintem kevés. A bármi -> xhtml konverziót és a kép-/illusztráció optimalizációt is beleértve akkor is max. 40–45 perc. A terjedelem irreleváns. Sokkal több időt vesz el egy bonyolult toc/ncx (mondjuk 5 szintes) és/vagy egy 300–500 lábjegyzetből álló tanulmánykötet. De ez sem bonyolult.

@_iMaginer_:
Amiért a W3C, a TEI, és szinte semelyik, leíró-, program-, parancs-, vagy tudományos nyelvet koordináló, vagy ajánlást tevő konzorcium, alapítvány sem jön ki egy saját editorral. Sőt még az Amazon is csupán annyit tesz, hogy kiadja a legfrissebb Publishing Guideline-t és hozzá egy parancssoros alkalmazást.
A leíró nyelven alapuló tartalmak már csak ilyenek. Feltételezik a hozzáértő emberek meglétét.

De ez valamilyen formában igaz a DTP ipar egyéb szoftvereire is. Végső soron tök mindegy, hogy InDesign, Quark, Scribus, vagy Photoshop, Gimp akármit használsz, ha nem érted az alapokat, vagy a végtermék mibenlétét – megmaradsz az ipar Pistikéjének. Láttunk már ezer InDesignnal készült (tehát mondhatjuk „profi”) kiadványt, amelyekről lerí, hogy Pistikénknek látható módon halvány segédfogalma sincs arról, hogy mit miért csinál. Ha pedig szóvá teszed, akkor csak bámul ki a fejéből és nem érti miről beszélsz, jobb esetben meg sem hallgat, hiszen ő „profi” és már több szász terméket letett az asztalra.

@kIára: Nagyon el vagy tévedve. Pont azt mondtam, hogy régen, a fényszedés idejében volt ez a hozzáállás (vagy 30 éve), hogy parancssorosan volt szerkesztve az oldal. De csak túlléptünk rajta pár év alatt. A Venturát meg a Quarkot használókat is egy darabig lenézték a nagy fényszedős stúdiók aztán eltüntek nyomtalanul. Én mint „profi” nem akarok a forrásban turkálni. A bios átirogatása meg a configsys is a múlté. Jobb lenne ha az ekönyvet is profi tipográfusok csinálhatnák, mert most úgy látom (személyes tapasztalat), hogy több az informatikus, ami nem tesz jót a minőségnek (bár lehet hogy van aki a könyv forrásától elélvez)

@_iMaginer_:
Nem látok ellentmondást. Az e-könyves jelen: NINCS ún. profi alkalmazás, csak ipari szabványleírás. Tetszik, nem tetszik ez van. A jövőben (és reméljük nem 30 év alatt) bizonyára lesz.

Amit meg a DTP programokról és Pistikéről írtam, az az érzésem, hogy félreértetted. Az általam említett Pistike nem tudja, hogy mi a fattyúsor, mi a ligatúra, mik a nemzeti nyelvek idézési szabályai, a kerningről pedig azt gondolja, hogy egy népszerű színészünk ruházata. Az ilyen „profi” hiába használja a legjobb program legfrissebb verzióját, munkája valószínűleg olcsó lesz és ehhez mérten kaka.

     „Jobb lenne ha az ekönyvet is profi tipográfusok csinálhatnák, mert most úgy látom (személyes tapasztalat), hogy több az informatikus, ami nem tesz jót a minőségnek (bár lehet hogy van aki a könyv forrásától elélvez)”
Ez a kedvenc vesszőparipám, amint Horváth Iván nyomán „digitális barbárságnak” hívok. Sajnos a mai világban még mindig tényleg ez a helyzet. Ha egy informatikusra bízzuk egy e-könyv elkészítését, az valószínűleg „belül” kifogástalan lesz, de isten mentsen a külcsíntől, formától, tartalomtól, pontosságtól, helyességtől. Ő az egyik digitális barbár, aki tönkreteszi a művet/tartalmat. Ha a dwo mester és általam is olyigen nagyra becsült „bölcsészre”, lelkes irodalomkedvelőre bízzuk a feladatot, akkor abban biztos nem lesz helyesírási hiba, stiláris egyenetlenség, tartalmi tévedés, de minden esélyünk megvan arra hogy a „belül” található szeméthalom miatt meg sem tudjuk nyitni az állományt. Ő a másik digitális barbár, aki ugyanúgy tönkreteszi az elektronikus művet/tartalmat.

Topichoz illő példát kérsz? Idézet az Amazon Publishing Guidline-ból:
    1. „The Kindle file format 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.”
    2. „Kindle books must have a cover image. The preferred format for the cover is a JPEG
image of 600x800 pixels. Covers with less than 500 pixels on the smaller side are
rejected.
” (v. 1.6. p. 12)

Néhány hozzászólással fentebb írja @bbandi: „a nagy kép pedig 600kB körüli: 595x860, 24 bit, jpeg quality: 98.”
– Jean-Luc Picard facepalmja vagyok, és magamban digitális barbározok.

     „bár lehet hogy van aki a könyv forrásától elélvez”
Igen, ilyen is van, de nem ez a lényeg. Én például míg nem láttam saját szememmel, hogy a Nook hogyan NEM jelenít meg valamit a hanyagságom miatt, vagy azt, hogy az adott esetben egy ilyen leszarom-apróság mint a <br> vagy <br /> mekkora kárt tud okozni, addig én sem vettem komolyan.

    „Jobb lenne ha az ekönyvet is profi tipográfusok csinálhatnák…”
Persze, így lenne ideális, hogy az aki tördelte a könyvet, az is készítse el az ebookot is. Amennyiben hajlandó azt (is) rendesen megtanulni (adott esetben a kiadó költségén).

@_iMaginer_: @kIára:

Amúgy itt is érezni vélem, hogy miért beszélünk el egymás mellett, de mégis mondjuk és mondjuk a magunkét :D
Te például kitértél kétszer is a könyv terjedelmére. Mert való igaz, évtizedes szakmai tapasztalatunk, hogy a méret igenis számít, nem mindegy ha egy 3 íves, vagy egy 30 íves szöveget kell kiszedni. Az ekönyvnél a terjedelem/hossz mondhatni mellékes tényező, a munkaidő másra megy el.
Új paradigma, hogy az ekönyvet nem te tördeled, hiszen maga a kütyü/parser „tördel”, választ el stb. az általad megadott paraméterek függvényében.
Új dolog, hogy tartalomelőállító létünkre fogalmunk sincs, hogy ki min és hogyan olvas. Csak „belőni” tudjuk; egy ekönyvgyártó (különösen az epub esetén) a piacon található eszközök és a felhasználói preferenciák felét sem ismeri. Például nem tudjuk, hogy ma Magyarországon hányan olvasnak GPS-en.
Ekönyvnél elég nehéz eszközről eszközre optimalizálni, ezért a kütyük (a piaci résztvevők száma közben n+1) közösen támogatott tulajdonságait kell állandóan figyelni. Puritanizmusra nevel, nem vitás.
Szinte senki nem foglalkozik a _már létező_ ajánlásokkal, amit _még egyetlen gyártó sem_ támogat. Lesz, nem lesz, szánjak-e rá +20 másodpercet most, vagy +20 percet másfél év múlva?

@SaGa: Imádlak benneteket :-) Tényleg. Mindent kifiléztetek. Két pici dolgot pontosítanék csak.

Az atlantis ékezetkezelő span-mániájára ezer éve van orvosság, kattanjunk már le róla. Win95-öt sem használ senki.

"Az, hogy némely ezzel s "gépsorral" készült e-pub nem sikerült jól, nem a komplexitás, hanem a készítő tapasztalatlansága vagy igénytelensége miatt van. Azt látatlanban merem állítani, hogy az Atlantisból kijött és azt tisztítás, szabványosítás nélkül kereskedelmi forgalomba hozott e-pubnál egyik sem lehet rosszabb, ..."

Őőő, de. Konkrétan nem nyílt meg bizonyos platformokon. Sima atlantis export ugye ilyet nem csinál. Mert ez a processz összetett annyira, hogy ne feltétlenül vegyél észre benne lyukakat, aztán ott a meglepetés. És visszajutottunk oda, amit kIára már feszegetett, hogy egy raklap platformon le kell ellenőrizni a végterméket, és a gyanútlan kiadóknak _erről_ még fogalma sincs.

@Dworkyll: Kedves Dworkyll.

Csak úgy kiváncsiságból letöltöttem az általad is itt reklámozott Szinkron.epub-ot. Meg sem kellett néznem a fájlok fejlécét, elég volt megnyitni a fájlt, hogy lássam: ez bizony Atlantissal készült (könyvtárszerkezet).
Tartalmaz egy sehol sem használt windigs és egy szintén sehol sem használt Book Antiqua fontkészletet (jócskán növelve a fájl méretét). Pontosabban a sehol sem használt nem teljesen igaz. Az Windingset tartalmazó stílust egy képhez társítja, egyetlen karakter sincs benne, teljesen felesleges, míg a Book antiqua-t egy &nbsp; tartalmú sorhoz, aminek már magának is ciki a létezése (és minden fejezetben van 4-5 belőle pl egy-egy rögtön az alcímsor előtt és után), nem csak a felesleges betűfájl. Ahogy a sorzáró "&nbsp; " (igen, nem törhető szóköz után sszóköz, mindez egy sor végén) karaktersor. Ezt úgy 40 másodperc alatt találtam a notepad++-szal... Ahogy találtam gondolatjel helyett kötőjelet is.

Ezeket mind pár perc alatt ki lehet irtani a sigillel, vagy a notepad++-szal.

Igazad van, elfuserált őű valóban nincs benne...

Az igaz, hogy a kötet ingyenes, de ettől még egy kiadónál van a polcon, nem egy amatörnél vagy valahol egy letöltő oldalon a szürkezónában.

Részemről az atlantissal előállított e-pubokról és a kiadók igényességéről folytatott beszélgetés ezennel véget is ért...

@SaGa: ne szomoríts el. Most tényleg a nemtörhető szóközök zavarnak? Igen, vannak benne ilyen üres sorok. A kindle parser sajnos ezt szereti, ártani meg olyan nagyon nem árt.

A Book Antiqua valóban fölösleges, egész pontosan 155 k a tömörítetlen mérete, kihagyható, de rajtad kívül kit zavar?

Viszont wingdings karakterek vannak benne, több is, elválasztójelként.

Kiadónal a polcon. Senki nem kapott érte pénzt. Ingyenes, szerintem vállalható. Ennyi férjen már bele. Tudod, ajándék rakéta, meg az ő kipufogója :-(

Hol vannak a kommentjeim?

No, lássuk így.

@Dworkyll:
Dwo, kissé arrogánsnak látszó válaszod kényszerített arra, hogy beszálljak a savazásba. SaGa felét sem mondta el. Bocsáss meg érte, ettől még Klára szeret téged.

Azzal remélem tisztában vagy, hogy ezzel a hozzászólással és hozzáállással sokat rontasz az ekönyvek megítélésén.

Csak néhány screenshot-részlet erejéig veszek egy másik kereskedelmi forgalomban lévő ekönyvet (mivel eszem ágában sincs reklámozni, a releváns adatokat satíroztam).

Lássuk a Guide-ot:

    Szinkron: Cover
    Példánk: Borító, Címlap, Impresszum, Könyv kezdete, Tartalom, Kolofon (magyarul!)

Lássuk a Jogokat, Metaadokat:

    Szinkron: Cím, Szerző (vezetéknév feleslegen, vesszővel ellátva), Nyelv, Kiadó, Dátum, Egyedi azonosító (ami nem UUID, hanem ISBN!!)
    Példánk: Cím, Szerző-, Grafikus- (cov), Szerkesztő-, Korrektor- (crr), BKP-, Felelős kiadó neve (pbd), Kiadó, Jogok (angolul és magyarul), Leírás/Fülszöveg, Mű keletkezésének ideje, Elektronikus kiadás dátuma, Nyelv, Egyedi azonosító (UUID), Kiadványazonosító (ISBN).

Lássuk a struktúrát:

    Szinkron: a képek és fontok kivételével, minden belehányva az OPS-be
    Példánk: a konzorciumi ajánlásnak megfelelően az OEBPS-ben külön tartalmi mappákban a képek, fontok, stílusok, szövegek, és egyéb tartalmak, gyökérben csak az opf és ncx.

Lássuk a betűkészletet:
    Szinkron: az ipari szabvánnyal és az Adobe ajánlással ellentétben: ttf.
    Példánk: az ipari szabványnak és az Adobe ajánlásnak megfelelően: otf.

Lássuk Misc mappa tartalmát:

    Szinkron: nincs is ilyen.
    Példánk: tartalmazza a könyvben felhasznált fontok licencét, annak alkotóit, és a szerzői jogokat. Hm…

Lássuk a szöveget:
    Szinkron: sok apró darabkára szabdalt html-ek tömkelege (összesen: 25 db).
    Példánk: a tech spec-ben leírt 300kb-os maximális méretet nem meghaladó xhtml-ek (összesen 6 db)

A Szinkron forrásról lásd SaGa panaszát + néhány apróság:
Értelmezhetetlen, felesleges üres sor a fejezet végén (pl. 008.htm) [<p class="p11">&nbsp;</p>] csak hogy szépen dobjon nekünk egy üres oldalt. Ez bizony zavaró lesz, sőt hiba.
Értelmezhetetlen, felesleges <span>-nel terhelt üres sor (pl. 018.html) [<p class="p8"><span class="t8">&nbsp;</span></p>] – senkit sem zavar, de akkor is.

Címsorok következetes és egyszerű H(n) megoldása helyett P(osztály) SPAN(osztály). Ennek megfelelően az NCX-ben természetesen fájl referencia van, az id referencia helyett (!!)

Gyönyörködjünk: <p class="p7"><span class="t10"><i><img src="images/img2.png" alt="img2.png"/></i></span><span class="t10"><i><img src="images/img2.png" alt="img2.png"/></i></span><span class="t10"><i><img src="images/img2.png" alt="img2.png"/></i></span></p>
Könyörgök: mit keres itt ez a sok <i> és <span>?

Dőlt betűs bekezdések: <p class="valami"> helyett <p><i>szöveg</i></p> megoldással. (Uraim, elegancia…)

üres [<i> </i>] folyószövegben, tényleg senkit nem zavar, csak szimplán ciki. Egyszer-kétszer talán elmegy, de fájlonként több helyen már nem. Ez szemét, a jövőben meglesz a böjtje.
Erről [<b>.</b>] nem is beszélve. PONT! :D

Esztétikum, hagyomány ilyesmi…
   – Ó, egy csak egy olyan magyar nyelven kiadott könyvet mutassatok, ahol a lábjegyzethivatkozások kapcsos zárójelben vannak. Most komolyan, irodalmi műben egy ilyen {8} forma bizony erőszak.
   Ordibálunk, ordibálunk? (rövid tájékoztató: hu.wikipedia.org/wiki/Verzál ) Jahogy ez ekönyvben melós? Istenem…
   Hogy is állunk az formázott szöveg–írásjel kombinációval? Lapozzuk csak fel az ekönyvolvasó blog, vonatkozó bejegyzését. ( ekonyvolvaso.blog.hu/2011/02/01/igy_szerkeszd_a_novelladat) Ó…kké…

Mint látható, csupán 4 forrástisztaságra tettem megjegyzést SaGát kiegészítendő. A többi… nos a többi…
Mindegy, ne foglalkozzunk ilyen apróságokkal, megnyitottam, az ADE szuperül viszi. Szuper, meló letudva.

@kIára:
Sajnálom, a screenshotok hivatkozásaival nem ment át a komment; az eredeti szöveg az adminok jóindulatára van bízva :D

Hopsz.
Ha nincs http, akkor a komment lazán megy.
Namégegyszerutoljára.

Lássuk a Guide-ot:
img254.imageshack.us/img254/2324/pl1a.png
img819.imageshack.us/img819/3267/pl1b.png

Lássuk a Jogokat, Metaadokat:
img716.imageshack.us/img716/7407/pl2a.png
img19.imageshack.us/img19/9151/pl2b.png

Lássuk a struktúrát:
img141.imageshack.us/img141/8945/pl3.png

Lássuk Misc mappa tartalmát:
img812.imageshack.us/img812/7430/pl4t.png

@Dworkyll:

„Kiadónal a polcon. Senki nem kapott érte pénzt. Ingyenes, szerintem vállalható. Ennyi férjen már bele. Tudod, ajándék rakéta, meg az ő kipufogója :-(”

Nem, nem és nem.
Ilyen hozzáállással soha de soha nem lesz magyar e-könyv. Születésében megölöd.
Ez már nem „falura jó lesz” hozzáállás, hanem „nesztek bammeg ingyé’ kúttúra”.

@kIára: Nem értünk egyet.

Igazatok van abban, hogy lehetne szabvány-komformabb, szebb, jobb, autentikusabb. Lehetne polírozni sokáig.

Ott nem értünk ebben egyet, hogy ennek a kiegészítő polírozásnak mekkora a határhaszna. Szerintem kicsi, szerintetek meg nem.

SaGa érve az, hogy a polírozás szerinte kevés munka lenne, ha jól dekódoltam a mondandóját, a tied meg az, hogy végtelenül tökéletesnek kell lennie.

Azt mondod így ölöm meg az e-könyvet. Szerintem meg az a veszélyes, ha a nulladik másodpercben fölrakod a lécet három méterre, a kiskrampó nem viszi át, és akkor inkább nem is próbálkozik.

Ma még nincsenek profik. Senki sem az. Az amatőrök tudják a legtöbbet, és a legtöbb amit kapnak, amit kaphatnak, hogy kompenzálják a szabadidejüket. Ez nem profizmus. Ez max civil kurázsi.

Csináljátok jobban, szebben, autentikusabban. Én lennék a legboldogabb, ha csak válogatnom kellene a tökéltesre desztillált e-címek között az e-boltban.

De nem tartunk itt.

Savazni meg könnyű, tanítani nehezebb, ezt te nálam ezerszer jobban tudod. Még mindig áll, hogy írjatok egy jó kis guide-ot, na csak mondogassunk ilyen bölcseket, hogy "gugli a barátod", meg "fönt van a neten".

Had gyarapodjon a kollektív tudás. Én tanulni szeretnék. Komolyan.

kindlevarazs.wordpress.com/2012/10/11/online-konyvszerkeszto-tanfolyam/

@Dworkyll:
Tényleg nem értünk egyet. Szerencsére nem is fogunk.

Egy, a kiadó honlapján is elérhető ingyenes ekönyv (amelyet a nemzet vezető tematikus blogja is népszerűsít) szerintem a következőkről (is) szól (ha magáról a műről egy picit elvonatkoztatunk):
    1. Az olvasóink, felhasználóink felé: Mi. Ilyeneket. Készítünk. (Pöpec, semmi gond vele, bárhol, bármin, gond, baj és nyűg nélkül olvasható, esztétikai/olvasási élményt zavaró hiba nincs benne. Nézd meg, olvasd el, az összes könyvünk ezt a minőséget nyújtja.)
    2. A piaci szereplők, esetleges vetély… izé versenytársaink felé: Mi. Ilyeneket. Készítünk. („Akkor fogtok labdába rúgni barátocskáim, ha legalább ezt a szintet megütitek; alább nem adjuk”.)
    3. Az összes többi, hivatásos vagy amatőr BKP felé: Mi. Ilyeneket. Készítünk. (Aranybogaram, ez a szint, a léc, a mérce. Így kell kinézzen egy minőségi e-tartalom. Ha ezt elérni, vagy meglépni nem tudod, semmi keresnivalód a piacon, vagy goto RTFM).
    4. „Ne tömjénezze magát. Szerénység. Ha én valamit szeretek magamban, az a szerénység.” :P

@kIára: :D

" a nemzet vezető tematikus blogja" B+. Ne süllyedjünk már a politikai blogok szintjére, ha kérhetem. Még a végén kénytelen lennék elhatárolódni tőled.

Itt, az elefántcsonttornyomban. A Digitális Barbár posztereim között.

:-P

@Dworkyll:

     „Igazatok van abban, hogy lehetne szabvány-komformabb, szebb, jobb, autentikusabb. Lehetne polírozni sokáig.”
– Nem. Eleve úgy kell nekiállni, elkészíteni, hogy ne legyen min vagy mit polírozni. Ennek egyik első feltétele, hogy nem népszerűsítünk sem a szakmának, sem az amatőröknek egy erre jobbára alkalmatlan export-alkalmazást.

Második pont, a fentiek értelmében cáfolásra sem érdemes.

     „SaGa érve az, hogy a polírozás szerinte kevés munka lenne, ha jól dekódoltam a mondandóját, a tied meg az, hogy végtelenül tökéletesnek kell lennie.”
– Nem. Önmagunk, megbízóink és felhasználóink és a könyvek tiszteletéről szól.

     „Azt mondod így ölöm meg az e-könyvet. Szerintem meg az a veszélyes, ha a nulladik másodpercben fölrakod a lécet három méterre, a kiskrampó nem viszi át, és akkor inkább nem is próbálkozik.”
– Első mondat állítását tartom. A kiskrampó elbátortalanítása is igaz. Történetesen két piaci szereplő által forgalomba hozott ekönyv siralmas állapota volt példa.

     „Ma még nincsenek profik. Senki sem az. Az amatőrök tudják a legtöbbet, és a legtöbb amit kapnak, amit kaphatnak, hogy kompenzálják a szabadidejüket. Ez nem profizmus. Ez max civil kurázsi.”
– Profi tudtommal az, aki teljes vagy résztudását felhasználva egy olyan tevékenységet végez, amiből megél. „Az amatőrök tudják a legtöbbet” – erre a gyönyörű oximoronra alszom egyet.

     „Csináljátok jobban, szebben, autentikusabban. Én lennék a legboldogabb, ha csak válogatnom kellene a tökéltesre desztillált e-címek között az e-boltban.”
– Próbálkozunk, próbálkozunk… Ugyanakkor én lennék a legboldogabb, ha csak válogatnom kellene a tökéletesre desztillált e-címek között az e-boltban.

     „De nem tartunk itt.”
– Hát nem.

     „Savazni meg könnyű, tanítani nehezebb, ezt te nálam ezerszer jobban tudod. Még mindig áll, hogy írjatok egy jó kis guide-ot, na csak mondogassunk ilyen bölcseket, hogy "gugli a barátod", meg "fönt van a neten".”
– Ma pont olyan napom volt, amikor savazni külön öröm volt számomra :D (A guide írásán gondolkodni fogok, bár lehet, értelmét nem látom).

@Dworkyll:
:D Egyszerűen nem tudtam kihagyni.

Itt, az elefántcsonttornyomban. A Digitális Előkelőség metszeteim között.

orratlan smiley

@Dworkyll: "Viszont wingdings karakterek vannak benne, több is, elválasztójelként."

Lehet, hogy te így gondolod, de az epubban sajna nem így van. A windings karaktert két class tartalmazza összesen.
Az egyiket már említettem (t11), egyetlen üres, pontosabban egyetlen nem törhető szóközt tartalmazó sorra érvényes. Megjegyezném: a nem törhető sorral tagolás a prc-ben is ciki, erre van a "height" stílus opció...

A másik stílus, amire a windings karakterset vonatkozik több helyen is előfordul (kizárólag a 018.html-ben, igaz ott ötször) és az alábbiakat tartalmazza:

[code]
<p class="p7"><span class="t10"><i><img src="images/img2.png" alt="img2.png"/></i></span><span class="t10"><i><img src="images/img2.png" alt="img2.png"/></i></span><span class="t10"><i><img src="images/img2.png" alt="img2.png"/></i></span><span class="t10"><i><img src="images/img2.png" alt="img2.png"/></i></span></p>
[/code]

Csak azért idéztem be, mert benne van mindaz, amiért az Atlantist nem szeretem. Gyakorlatilag egyetlen betű nincs benne, csak kép, ami egyébként eredetleg valóban a winndings fontkészletben találhat betű képe. Ezen kívül jól láthatóak a feleslegesen lezárt, majd újranyitott formázások, stb...

A formátumduplázás sem szűnt meg teljesen. Az alábbi három ugyan nem egyforma, de tulajdonképpen ugyanarra (a lábjegyzetekre mutató linkekre) alkalmazza az Atlantis:

[code]
.t9{font-size:.65em;line-height:150%;vertical-align:super}
.t13{font-size:.54em;line-height:150%;vertical-align:super}
.t15{font-size:.6em;line-height:150%;vertical-align:super}
[/code]

De tulajdonképpen mindegy, ahogy a dologról alkotott véleményedet olvasom.

Az "oktatást" már mellőzném. Felesleges. Amíg ez a fórum a lelkes amatőrök foruma volt, azoké, akik minél szebb, szabályosabb és több e-bookot akartak látni, addig érdemes volt leírogatni a tapasztalatokat, hogy másnak már ne kelljen vele megszenvedni. De látom, felesleges, mert az, aki már majdnem hivatásszerűen űzi az e-book gyártást azt mondja, felesleges fényezés, minek küzdjek vele. Ha a kiadók megengedik maguknak az ilyen hozzállást, akkor inkább felhagyok a "térítéssel", és mindenkire rábízom, hogy mi az elvárt minimum és mi a "fényezés". Mindenki megtapasztalja és eldönti maga, hogy mennyit akar rááldozni az idejéből a dologra.

Megjegyzem: ha lenne elegendő, olcsó, jóminőségű e-book, én sem foglalkoznék vele, megvenném azt is, ami papiron már megvan. Ellenben amíg ilyen a minőség, nem kell az sem, ami egyébként érdekelne. Egyszerűen zavar és nem bírnám ki, hogy ne javítsak bele, ami már törvénysértő is lenne. Akkor meg már egyszerűbb, ha az egészet magamnak csinálom, és olvasás közben jól szórakozom.

Viszont egyre kevésbé szórakoztat ennek a blognak az olvasása. Az a trollháború, ami ennek a hozzászólásfolyamnak az elején volt... Eddig ez a blog mentes volt ettől, de látom, elveszett az "aranykor"...

@kIára:
" – Ó, egy csak egy olyan magyar nyelven kiadott könyvet mutassatok, ahol a lábjegyzethivatkozások kapcsos zárójelben vannak. Most komolyan, irodalmi műben egy ilyen {8} forma bizony erőszak."

Ezzel az eggyel vitatkoznék. Nagyban függ a használ olvasó programtól, hogy a linkek "kattintása" mennyire eltalálható. Sokkal kényelmesebb egy karakter helyett (pl '8') legalább három karaktert ('[8]') megbökni.
A többivel nem vitatkoznék.

@SaGa: „Ellenben amíg ilyen a minőség, nem kell az sem, ami egyébként érdekelne. Egyszerűen zavar és nem bírnám ki, hogy ne javítsak bele, ami már törvénysértő is lenne.”
Gondolom, ha megveszed az új tévédet rögtön szétszeded, hogy minden forrasztás szép-e és a nyák is esztétikusan letisztult :)

@_iMaginer_: Természetesen nem, de ha zavaróan zizereg a kép, hívok egy szerelőt, hogy javítsa meg. A felsorolt hibák egy része olvasás közben is látható...

@kIára: @SaGa: @Dworkyll:
Kicsit tényleg kezd elharapódzni ez a vita az e-könyv készítésről. Nem jó ezt látni. Kicsit olyan érzésem van, mintha az oviban durcás kisgyereket látnék. Szerintem Dworkyll kérése, hogy írjatok egy cikket arról, hogyan lehet a kódolás oldaláról is szépen megcsinálni az e-könyveket jó felvetés volt, és igenis szükség lenne rá, hogy valaki – aki ért is hozzá – elkészítse.

Amúgy ha ő azzal a hozzáállással megöli a magyar e-könyveket, hogy segít a kiadóknak, íróknak összehozni az e-könyveiket. Ám teszi ezt pontatlanul, és hibás eszközökkel, akkor sajnos az sem sokkal jobb, aki tudna segíteni, mégsem teszi ezt.
Jelenleg pont ennek a leírásnak hiánya az, ami a még ezen a téren tapasztalatlan kiadókat a hanyagul elkészített e-könyvek kiadására sarkallják. Mivel fogalmuk sincs róla, hogy ezt lehet másképp is. Bár félek tőle, hogy ha még tudnának is róla, akkor sem lennének képesek minden címüket egy profira bízni, hiszen az átlag magyar e-könyv még a konverzió árát sem termeli vissza. Szóval vagy van sok belül kotvány struktúrájú e-könyv a polcon, vagy nincs semmi, esetleg néhány bestseller cím jól elkészítve. De azért az még kevés az üdvösséghez.

Viszont még nem jöttünk ki a hazai piac alakulási fázisból, most lehetne/kellene formálni a kiadók hozzáállását, hátha még a végén ők is költséghatékonyabbnak találják legalább a kiemelt címek minőségi elkészítését, hogy aztán ne pár év múlva kelljen nulláról újra elkészíteni őket, mert széthullnak az akkori parserek alatt az export e-könyveik.

Szóval a lényeg, hogy igenis érdemes lenne megcsinálnotok know-how-t az igényes publikációk készítéséhez. Valamikor el kell vetni azokat a csírákat, hogy szárba szökkenhessenek. Ha mondjuk már lenne egy ilyen, akkor most lehet, hogy nem is kéne erről beszélnünk, mert a pl. DeltaVision sem az Atlantis-t választotta volna.

Ha már annyiszor szóba került a civilkurázsi.
És az átlag felhasználói igényt kielégítő ekönyv minőség.
Íme egy 71 másodperces, vágatlan videotutorial:

www.youtube.com/watch?v=7nJ3OOOvexs

Just for the sake of argument.

@kIára:
Mint látható, az ötvenedik másodperc körül elkészült egy átlagfelhasználói igényt kielégítő e-könyv (maga a konverzió kb. 20 másodperc volt, az összes többi kapkodó bénázás).
Egy hatéves, csupán 1,88GHz, 4Gb ram, kétmagos subnotin (azaz ócskavason), powersave governor mellett, egy szálon futtatva.
A legnagyobb cpu-terhelés 19,8% volt.
Ez azt jelenti, hogy akár 4 párhuzamos process is futhatna a háttérben anélkül, hogy a normális géphasználatot alapvetően befolyásolná.

Matek.
Kb. 30 másodperc 4 könyv. 10 perc kb. 80 könyv. Egy óra kb. 480 könyv. (Inkább több, mint kevesebb)

    1. Mivel a MEK struktúrája egyszerű mint a faék (lásd: ftp://mek.oszk.hu/pub/mek2), a wget-et beállítani rá nem kerül semmibe.
    2. Mivel a MEK állomány egységes, egyedi, vagy sajátos igényt kielégítendő css-t csak egyet kell megírni, ami lefedi a prózát, lírát, drámát (ilyen több is van, de akár mehet a sajátjával is, nem annyira gáz).
    3. Mivel a MEK állomány egységes, a náluk barbármódra használt kötőjel (-) és idézőjelhasználatára ("") egy néhány soros sed-szkriptet kell írni, hogy (–) és („”) legyen ott ahol kell. (A processt max. 2–3 másodperccel hosszabbítja.)
    4. Mivel a MEK katalóguscédula szabványos, az OPF metaadatkonverzió és beszúrás 0–2 másodperc, hiszen kombináljuk a 3. folyamattal.
    5. Számoljunk csupán öt júzerrel és a fentinél alig jobb vagy rosszabb gépekkel.
    6. Osszuk fel a feladatot, MEK-id-től MEK-id-ig (vagy mappáktól mappákig).
    7. Számításaim szerint a jelenleg elérhető kb. 10000 dokumentum 80–90%-a maximum öt óra alatt legyártható.
    (8.) Mivel a DIA még szabványosabb, az állomány kevesebb (de értékesebb), a teljes folyamat és a TELJES DIA számításaim szerint max. két és fél óra.

Simplicity. Civilkurázsi. Tök amatőr szinten. Közkincset közmunkában.
De minek? Lenne értelme? Vegyük el a Kindlevarázs kenyerét?

@kIára: Őőő, szeretném kérni SaGa olvtárs minősítését is a végeredmény minőségét illetően ;-)

Az eredményt meg nem tudom hitelesíteni. Ez egy parancssoros konverternek látszó borotválkozógép volt, b+ ;-). Biztos jó, de ha nem osztod meg a forrást/forrásokat, akkor ugye süthetjük.

Egyébként meg ha én digitális barbár vagyok, meg az ekönyvek gyilkosa, akkor hogy aposztrofálnád ezt a kis performanszt? :D

Tényleg nem értelek. Ha lövök egy screencam-et egy kindlegen futásról az oktatóvideó?

@Dworkyll:
Szépen oda van írva, hogy kizárólag érvek alátámasztására készült.
Két programot használtam wget (cross platform) ebook-convert (cross platform – és mellesleg a calibre része), tehát operációs rendszertől függetlenül bárki által lejátszható móka.
Így van, ez egy barbár, „de falura jó lesz” néhány másodperces módszer. Az eredmény, ([{szerintem}]) nem múlja alul egyetlen civilműhely, vagy (mint példáink mutatják) a szárnypróbálgató kiadóknál található minőséget (lévén az elvárásszint, a megugrandó léc alacsony). Hiszen ugyanezt művelik, csak klikkelgetve, ugyanilyen konvertergagyikkal (ez csupán a leggyorsabb módszer a klip.me után :P ) Van benne, toc, ncx, beállított kezdet, a forráskód a MEKé (tehát olyan amilyen, de minek szőrözni?). Mi kell még? Borító. Istenkém, tudok nélküle is élni (de ha kell, generálok egyet logóval, gradienssel, csicsafontokkal).

Ehhez képest, ha valódi e-könyvet készítünk, akkor az bizony meló. Jó esetben egy óránál kevesebb, neccesebb helyzetben ennél lényegesen több.

A számolgatásos példámmal csupán azt akartam érzékeltetni, hogy a civilek által olyigen hiányolt választékot néhány óra alatt bőven lehet növelni. Igaz, húzónevek, művek nemnagyon lesznek – kivéve persze ha valaki pont a DIA szerzőire élvez, mert akkor kánaán.

@kIára:
Kedves KIara!

Bocsánat, hogy beledumálok:
Nyugodtan neki lehet allni, és összedobni 5 óra alatt a MEK anyagát, sokat segítene a magyar olvasóközönségen, a Kindlevarázs kenyerét nem tudnád elvenni, mert pontosan ugyanannyit kapnak érte, mint Te.
Viszont a többieknek mondanám, hogy az is benne van ebben a "minek írjunk tutorialt a többieknek, semmi értelme" dologban, hogy nehogy a többiek is egy tudják, amit én tudok. Nem gondolom, hogy szerencsés hozzáállás másokat hülyének nézni olyan alapon, hogy a lécet talán máshová teszi valaki.
Azt is érdemes figyelembe venni, hogy az az igényesség (amivel egyébként nincs bajom) amit elvársz, nem megfizethető valószínűleg a kiadók részéről. De megjegyzem, ez más szakmák szakértőinél is így van gyakran. Ha egy profi esküvői fotós az mondja, hogy az esküvőt 150-ért megcsinálom, gyakran találnak olyat, aki már 50-ért, sőt 30-ért is, esetleg nem azon a szinten, de még ez sem kizárt. Ha Te azt írod, fizessék meg a munkád - egyetértek, én is ezt gondolom. De ha mégsem fizetik meg, akkor Te is meg én is így jártunk, csak én nem állok neki egy könyv forráskódját olvasgatni, mert mezei olvasóként (ők vannak nagy nagy többségben) könyvet olvasok.
A vita helyett például gyorsan meg lehet cáfolni a butaságaimat, le lehet generálni a MEK-et meg a DIA-t 5 óra alatt, és közre lehet adni a tudást is, a'la civil kurázsilag. A többi csak szöveg, meg kötözködés.
Tisztelettel!

@szakértőbb:
    „Nyugodtan neki lehet allni, és összedobni 5 óra alatt a MEK anyagát, sokat segítene a magyar olvasóközönségen, a Kindlevarázs kenyerét nem tudnád elvenni, mert pontosan ugyanannyit kapnak érte, mint Te.”
Én ugyan nem fogok nekiállni, mert fikarcnyi értelmét sem látom. Itt egy egyperces demo, és egy hétpontos feladatterv (kb. 20 perc agymunka még egy abszolút kezdőnek is). Te is megteheted. Bárki.

    „Viszont a többieknek mondanám, hogy az is benne van ebben a "minek írjunk tutorialt a többieknek, semmi értelme" dologban, hogy nehogy a többiek is egy tudják, amit én tudok.”
([{Míg oktatói pályán is mozogtam, utána még két évig ingyen oktattam ugyanazon az egyetemen, csak azért meg kedveltem azt a nyavalyás tanszéket, és minimálisan oktatásra érdemesnek tartottam az adott tantárgyakat. Mellesleg van egy szakmám, ami elég jól fizet, mert ritka /köze nincs a könyvekhez/. Évek óta fiatalabbakat képzek ki rá, és már 6 nagyon profi riválisom van akik elhappolják előlem a munkát. Büszke vagyok rájuk.}]) Az inszinuációt kérlek fejezd be.

    „Nem gondolom, hogy szerencsés hozzáállás másokat hülyének nézni olyan alapon, hogy a lécet talán máshová teszi valaki.”
Nem néztem hülyének senkit. Dwo-val (és még néhány hozzászólóval) kedélyesen elcsevegünk erről-arról, hidd el, ugyanolyan kedélyesen fogok legközelebb is kocsmázni vele, sőt talán még durvább hangnemet is megengedünk egymásnak.

De tudod mit? A következő kommentemben (amint ezt befejeztem) átmegyek igazi trollba, és engedelmeddel, bemutatom, hogy szerintem milyen egy igazi hülyének nézés.

    „Azt is érdemes figyelembe venni, hogy az az igényesség (amivel egyébként nincs bajom) amit elvársz, nem megfizethető valószínűleg a kiadók részéről.”
Ha egy kiadó képes jogokat, (fordítót,) szerkesztőt, korrektort, grafikust, royaltyt, tördelőt, nyomdát, raktározást, honlapot, reklámot, könyvbemutatóhoz terembért, reklámot/hirdetést, stb., stb. fizetni, nehogymá’ pont erre ne legyen fél fityingje sem.
    „esküvői fotós 150 –> 30 példád”
A világ szerencsétlen állásáról való eszmefuttatásoddal egyetértek. Tetszettünk volna egy jobb világba születni.

    „csak én nem állok neki egy könyv forráskódját olvasgatni, mert mezei olvasóként (ők vannak nagy nagy többségben) könyvet olvasok.”
1.) Nem voltál figyelmes. Különösen a Szinkron kapcsán. A forráskódba alig kötöttem bele és akkor is inkább a vicces bakikra hívtam fel a figyelmet (a durvákra SaGa). Ellenben felhívtam a figyelmet a hiányzó metaadokra, a nem létező vezérlőkre, az esztétikai-formai igénytelenségre, a téves azonosítóra. Továbbá a font és egyéb licencek meglétének hiányára, ami kereskedelmi forgalomba hozott termék kapcsán meglehetősen veszélyes. (Kifejtsem?). És ami a legfontosabb: felhívtam a figyelmet arra, hogy pont ebben a blogban van egy útmutató, irányelv (amúgy több is) amit pont a vesézett e-könyv nem tart be. Felfedezni véltem a vízprédikálás esetét (érdekes módon nemcsak én).
2.) Én az olvasókkal vagyok. Bocs, de önmagam idézem: „Önmagunk, megbízóink és felhasználóink és a könyvek tiszteletéről szól.” Most komolyan, mi baj van ezzel? Végig erről beszéltem, beszélek. A példáim lehetnének jobbak, a stílusom lehetne csiszoltabb, elismerem. Ettől még ugyanezt mondom.

    „A vita helyett például gyorsan meg lehet cáfolni a butaságaimat, le lehet generálni a MEK-et meg a DIA-t 5 óra alatt, és közre lehet adni a tudást is, a'la civil kurázsilag.”
1.) Nincs semmilyen vita. Szempontokat egyeztetünk, érveket ütköztetünk és mindannyian azon vagyunk, hogy az e-könyvek által is menjen a világ elébb. Te is, én is, a blog is, a hozzászólók és a szotyizók – mindenki.
2.) Ismétlem: személyesen semmi értelmét nem látom. Remélem valamelyik itteni olvasónak már felcsillant a szeme, és már negyedével kész is van. (Hétfőre várom a pakk-linket :D).

@kIára:
Köszönöm a választ!

@kIára: a diás oldalszámozással mit csinálsz?

(még soha sem írtam se csst, s sed-szriptet, ezek szerint átlag alatti felhasználó vagyok :p )

A zárójeles mondathoz kapcsolódva: mivel ezekhez nem értek, annyit tudnék csinálni, hogy lelkesen támogatnék egy közösségileg finanszírozott projektetk, aminek az eredménye MEK (és DIA?) ekönyvben, plusz két css, amivel lehet tovább dolgozni.

@Komavary:

A DIA xhtml-ekben az oldalszámozás mindenhol ugyanaz.
Így néz ki
<a name="DIAPage20" shape="rect"/><span class="oldaltores">20</span>
vagy
<a name="DIAPage345" shape="rect"/>
<span class="oldaltores">345</span>
Tehát vagy egy vagy két sorban.

Ha soha nem használtál sed-et, akkor jobb nem kínlódni vele, egyszerűbb bármilyen Reguláris kifejezéseket kezelő editorban megnyitni és két cserét elvégezni:
<a name="DIAPage\d{1,4}" shape="rect"/>\n<span class="oldaltores">\d{1,4}</span> csere semmire.
<a name="DIAPage\d{1,4}" shape="rect"/><span class="oldaltores">\d{1,4}</span> csere semmire.

Mivel feltételezhetjük hogy a DIÁn nincs 9999 oldalt meghaladó mű, a \d{1,4} annyit tesz, hogy az 1–4 számjegyből álló kifejezéseket keressen. Kész.

(Adott esetben érdemes megnézni, hogy az editor milyen reg.expr-et használ.)

Sed:
sed -e :a -e N -e 's/<a name=\"DIAPage[0-9]*\" shape=\"rect\"\/>\n//' -e 's/<span class=\"oldaltores\">[0-9]*<\/span>//' -e 's/<a name=\"DIAPage[0-9]*\" shape=\"rect\"\/>//' < dia_be.xml > dia_ki.xml

egy mappába mentett összes dia xml-re egy példa:
for dia in *.xml; do sed -e :a -e N -e 's/<a name=\"DIAPage[0-9]*\" shape=\"rect\"\/>\n//' -e 's/<span class=\"oldaltores\">[0-9]*<\/span>//' -e 's/<a name=\"DIAPage[0-9]*\" shape=\"rect\"\/>//' < $dia > $dia.uj.xhtml; done;
– lehetne szebb, fájintosabb elismerem. Sőt, fejlesztésre érdemesnek tartom.

@kIára: Köszönöm, megpróbálok barbárkodni vele.

@Komavary:

Mivel egy link többet ér ezer szónál:
data.hu/get/5685377/Hatar_Gyozo_DIA_ebook.zip

Egyik kedvenc íróm – Határ Győző –, összes műve (34 könyv).

Folyamat elindítva: óra 24 perckor.
Folyamat befejezve: óra 53 perckor.
Tehát 34 e-könyv egy szálon 29 perc alatt készült el.
Ha 4 szálon futtattam volna: kb. 10 perc.
Az összes xhtml mérete: 34.8Mb;
Legnagyobb xhtml: mérete 3.8Mb;
Legkisebb xhtml mérete: 33kb;

imageshack.us/a/img341/2272/hgydiademo.png

Megjelöltem a legkisebb és a legnagyobb elkészülési időpontokat.

A fájlokhoz egyáltalán nem nyúltam. Csak egy folyamatot használtam, a zavaró oldalszámjelölést végül Xpath segítségével töröltem.

<KÓD>

ls *.xhtml | xargs -I DIA ebook-convert DIA DIA.mobi --authors 'Határ Győző' --book-producer 'Tibiné Klára' -vv --language hu --level1-toc '//*[@class="cim"]' --level2-toc '//*[@class="alcim"]' --toc-title "Tartalom" --sr1-search '<span class="oldaltores">\d{1,4}</span>' --sr1-replace '' --sr2-search '<span class="oldaltores">.* kötet \d{1,4}</span>' --sr2-replace '' --extra-css dia_all.css --page-breaks-before '//*[@class="cim" or @class="copyright" or @class="mu"]'

</KÓD>
= listázd ki a mappában található összes xhtml-t és végezd el rajtuk a konverziót a következő módon: a szerző neve mindenhol legyen Határ Győző, a BKP Tibiné Klára, használd fel a kinézethez a dia_all.css-t, a „cim” és „alcim” osztályú div-eket rakd be a tartalomjegyzékbe Tartalom címmel, töröld az oldaltöréseket jelző izéket, a „cim” „copyright” „mu” divek elé tegyél oldaltöréseket.

Hogy miért használtam a for helyett xargs-ot? Hirtelen felindulásból ;)
A fájlok lementésére, átnevezésére elment kb. 3 perc, a fenti parancs megírására (gondolkodással együtt) kb. 12 perc (ezentúl 0).

A kódon lehetne bővíteni (pl. szedje ki a szövegek végén található js-t, vagy a tartalomkezelés legyen okosabb, a kinézet, pedig csinosabb, bonyolultabb, akármilyenebb, vagy legyen egy Szerző, Cím, DIA-logót tartalmazó egyszerű borító).

Előnézetek:
Kindle for PC:
img198.imageshack.us/img198/6055/kfpc.png

Kindle Previewer:
img163.imageshack.us/img163/2778/kprev.png

Calibre Viewer:
img853.imageshack.us/img853/1088/calibreviewer.png

FBReader:
img846.imageshack.us/img846/6126/fbreader.png

CoolReader:
img267.imageshack.us/img267/9789/coolreader.png

Jó olvasást, különösen azoknak akik HGy rajongók.

@kIára:
„töröld az oldaltöréseket jelző izéket”
helyesen „töröld az oldalszámokat jelző izéket”

cdn.memegenerator.net/instances/400x/28400930.jpg

@kIára: Köszönöm szépen!

Ugyan a data.hu majdnem kifogott rajtam (nem szereti a külfölid címet), de most csak ámulok és bámulok (és epubot eszkábálok).

@kIára: elkerhetem a dia_all.css-t? kuldtem emailt.

Kozben elkezdtem dolgozni egy altalanosabb dia2ebook scripten, meg nagyon minimal, de mar mukodik:

github.com/KTamas/dia2ebook

es ha az ember kiadja azt a parancsot, hogy:

./dia2mobi.rb -a "Csukás István" -w "Süsü, a sárkány"

akkor ott lesz egy tmp.mobi kis ido mulva. meg hardkodolva van minden a sajat gepemre, de igyekszek egy altalanosabb verziot csinalni, meg valami jobb UI-t.

@kIára: elkerhetem a dia_all.css-t? kuldtem emailt.

Kozben elkezdtem dolgozni egy altalanosabb dia2ebook scripten, meg nagyon minimal, de mar mukodik:

github.com/KTamas/dia2ebook

es ha az ember kiadja azt a parancsot, hogy:

./dia2mobi.rb -a "Csukás István" -w "Süsü, a sárkány"

akkor ott lesz egy tmp.mobi kis ido mulva. meg hardkodolva van minden a sajat gepemre, de igyekszek egy altalanosabb verziot csinalni, meg valami jobb UI-t.

@Komavary: (es csak a te kedvedert, lesz epub opcio is, termeszetesen)

@KTamas: :keres pompomot, hogy szurkolhasson:

@KTamas:

A css a lehető legegyszerűbb, nem is akartam túlcicomázni, hiszen csak demonstrációs célból készült.

p { margin:0; text-indent: 1.5em; }
.cim { text-align:center; margin:1.2em; text-indent:0; font-style: italic; font-size:1.4em; }
.alcim { text-align:center; margin:1.2em; text-indent:0; font-style: italic; font-size:1.2em; }
.szerzo { text-align:center; margin-top: 3em; margin-bottom:1em; font-size: 1.4em; }
.konyvcim { text-align:center; margin:1em; text-indent:0; font-style: italic; font-size:1.2em; }

A versekhez, illetve a drámákhoz kellene/lehetne még valami.

Próbálkoztam az összes dia css-t egybefűzni, de az eredmény nem valami biztató, sokat kell mazsolázni.
dia.jadox.pim.hu/base.css
dia.jadox.pim.hu/check.css
dia.jadox.pim.hu/dia.css
dia.jadox.pim.hu/korrektor.css
dia.jadox.pim.hu/overwriteDIA.css
dia.jadox.pim.hu/presentation-base.css
dia.jadox.pim.hu/structure.css

A base.css és dia.css gyakorlatilag tartalmazza az összes osztályt.

@kIára: koszi!

igen, a versekre-dramakra ki kell valamit talalni. Illetve mivel a windowsos commandline hirbol is csak reszben ismeri az UTF-8at, asszem fogom magam es atirom meg most az egesz kocerajt egy calibre pluginnak.

@Dworkyll:
Pontosítok. Az téves, hogy már csak e-könyv joggal adnak papírjogot. A helyzet az, hogy már adnak e-könyv jogot a papírral, de még nem mindenki. A többi állítás (gyakori DRM-kötelezettség, időnként túl magas árrésigény) helytálló.

Az is téves, hogy ha a "szürke" fogy e-könyvben, akkor más is.
Papírkönyvre sem igaz, miért lenne igaz az elektronikus változatra. Van, ami fogy, van, ami nem. Az olvasók néha kifürkészhetetlenek.:)

@KTamas: nagyon csöndesen és szerényen jegyzem meg, hogy Csukás István művei védettek. ;)

@Konyvmolyolo: milyen szempontbol? mas szabaly vonatkozik rajuk mint a tobbi DIA-s cuccra?

@Konyvmolyolo: Nagyon csöndesen és szerényen jegyzem meg, hogy a művekért olyan összeget kapnak évente az örökösök, amikről az ekönyves piac csak álmodni merne.

@KTamas:
Mindegyik DIA-s konyv vedett, a szerzo halala utan 70 évig:-P

@Komavary: Lásd előző hozzászólásom. Ettől még kínálhatnák őket ekönyv-formátumban - de nem teszik. AZ, hoyg mennyit kapnak érte, a jogvédettséget sajnos nem befolyásolja:-(

@szakértőbb: ez pontosan így van, ahogy a két kommentedben írod. Nincs is mit hozzáfűznöm.:)

Talán még csak annyit, hogy várhatóak Csukás István könyvei e-könyvben. Pontos dátumot ne kérdezzetek, több mindentől függ még - legelőször is a fentebb tárgyalt profi és megfizethető digitalizálás megoldásától.
De rajta vagyunk.:)

@szakértőbb: @Konyvmolyolo: A DIA-s anyagok felhasznalasa magancelra szabad. A magancelu felhasznalasba beleesik az is, ha az ember fogja, es egyszeruen lementi maganak az adott HTML oldalt a sajat gepen (sot, amugyis ott van mar a winchesteren a cacheben) -- ezt teszi a script is. Utana az ember azt konvertal meg mondosit rajta *sajat maganak* amit akar -- peldaul csinalhat belole ekonyvet, mint azt a script teszi --, amig nem terjeszti tovabb a modositott fajlt (ez esetben az elkeszult ekonyvet), addig nem sert meg semmifele jogot ezzel.

Ezert is van az, hogy a script direkt ugy keszul, hogy a felhasznalo gepen fut, ott tolti le a fajlt, es ott keszi el az ekonyvet belole. Ha mondjuk egy internetes szolgaltatast csinalnek belole, vagy legeneralnam az osszes ekonyvet es kitennem az internetre, az mar nem lenne legalis. De amig mindenki maganak csinalja, a sajat gepen, az teljesen oke.

@KTamas:
Szerencsére nem vagyok jogász:-) De:

A szabad felhasználás esetei

35
(2) Teljes könyv, továbbá a folyóirat vagy a napilap egésze magáncélra is csak kézírással vagy írógéppel másolható.

(3) Nem minősül szabad felhasználásnak - függetlenül attól, hogy magáncélra történik-e -, ha a műről számítógéppel, illetve elektronikus adathordozóra mással készíttetnek másolatot.

Szóval a script nyilvánosságra hozatala ezt minimum sérti, már ha kötözködni akarnánk...

@Konyvmolyolo:

>Talán még csak annyit, hogy várhatóak Csukás István könyvei e->könyvben. Pontos dátumot ne kérdezzetek, több mindentől függ >még - legelőször is a fentebb tárgyalt profi és megfizethető >digitalizálás megoldásától.
>De rajta vagyunk.:)

Dátumot nem kérdezek, de a profi és megfizethető digitalizálásból mi hiányzik? :-) A szöveg ugye lektoráltan ott a DIA-ban... Dworkyll leírta, hogyan kell e-book-ot csinálni, KIára (vagy bárki más) gondolom szívesen megcsinálja profin:-)

:) ajánljak fel blogpizzát annak, aki megmondja, melyik feltételt nem soroltad fel a teljesültek között? :)

@Konyvmolyolo:
Ha nincs pénzed, miért nem azt mondod? :-P
Ha ezen múlna a kiadás, szerintem a civilszféra profi szerkesztői sorban állnának a feladatért:-)

@Konyvmolyolo: Nem kötözködéképpen kérdezem, de mit jelent az hogy védett, egy olyan esetben, ahol legális és publikus verzió érhető el? Mit nem szabad csinálnom, és miért?

A PIM honlapján leírt felhasználási feltételek hagynak némi játérkteret, a magáncélú olvasást és nyomtatást megengedik, a kereskedelmi célú többszörözést meg tiltják.

Ide szerintem befér, hogy pl. magáncélra egy virtuális pdf printerbe nyomtatok, vagy hogy etetek egy ekönyvet "nyomtató" szkriptet.

Ugyanezért viszonylag gyengén megalapozottnak érzem, hogy valaki kereskedelmi kiadványt akarna csinálni belőle.

1. mert a forrást, ha nagyon szigorúan vesszük, közpénzből állították elő, (azaz az adófizetők már kifizették), másrészt a szerzőt bőségesen kompenzálták (lehet persze más forrás is, de az olyan autentikus lesz, mint a kritikai minőségű PIM verzió?)

2. az ingyenes (és jó minőségű) változat ott marad legálisan és publikusan (ugye?)

Azaz csak arra lehet a bizniszt alapozni, aki lusta megkeresni a a legálisan ingyenes alternatívákat, és megcsinálni magának a konverzót, ha offline akarná élvezni ("nyomtatás").

Szóval?

@Dworkyll:
azt jelenti, amit szakértőbb az előbb beidézett, a másolás (többszörözés) erős korlátozását.

Pl.Legálisan és publikusan elérheted a papírkönyvet is egy könyvtárban, mégsem másolhatod le pl. fénymásolóval még saját célra sem.

Az, hogy közpénzből állították elő és hogy kompenzálták a szerzőt, igazából indifferens.
Különösen a felhasználói jogok (átmeneti) birtokosai (pl. kiadók) szempontjából.
Hiszen a védettségtől függ pl., hogy megtérül-e az az összeg, amelyet a felhasználási jogokért fizetett. És ez az összeg teljes mértékben független attól, mennyi pénzt kapott egy szerző a DIA-ban való szereplésért. Ez egy piaci ár, melyet alakít, hogy a jog még védett.
De a szerző nem fog kevesebbet kérni amiatt, mert a DIA-tól már kapott jogdíjat.

Vagyis arra lehet ezt a megtérülést alapozni, "aki lusta megkeresni..." és/vagy tudja, hogy nem másolhatja le és nem is teszi.:)

@szakértőbb:
:) mert ha mondom, adsz? ;)

Jócskán múlik rajta, komolyan.
És a kiadók zöme még csak most kezd rádöbbenni, hogy ez nem is olyan egyszerű.
Vállalható minőségű, az olvasók érdekeit messzemenően figyelembe vevő ipari szabványt kialakítani és tartósan annak megfelelően gyártani úgy, hogy ne növelje a veszteséget, ha újabb és újabb könyveket vonunk be a portfólióba.

És ne feledjük! A kiadók zöme még mindig nem tudja biztosan - sőt, legyünk pontosak: BIZTOSAN senki sem tudja -, hogy nálunk is olyan hatása lesz-e az e-könyveknek, mint az USÁ-ban. Van rá esély, de ki merne fogadni rá?

Boldogan működünk együtt minden civil vagy nem civil szakértővel, aki megbízhatóan hozza a minőséget, és a gyártás költsége ad rá lehetőséget, hogy megtérüljön.
Amennyiben ez egy jó, szabványosítható automatizmus+némi emberi munka, akkor is.
Sőt, leginkább ez érdekel. Egy használható, gazdaságosan működtethető logika, mely pl. kiegészíthető egyetemisták munkájával.

Ha ez megoldható, mi az idén legalább 100 könyvvel jövünk.
(Könyvmolyképző)
Aki tehát érez rá indíttatást, előmozdíthatja jócskán. Ráadásul kurrens címek.

De bevallom, én inkább azonnal jó megoldást szeretnék hozni, minthogy egy-két címmel próbálkozzak.
Azt szeretném, hogy már a színre lépésünkkor biztos lehessen benne minden olvasó, hogy a megvásárolt e-könyv az ÖVÉ.
Bármin, bárhol, bármikor olvashatja.

@Dworkyll: Dwo, ezt most komolyan kérdezted??? Attól, hogy a DIA-n kinn van, ugyanúgy védett, mint bármely más könyv...

@Konyvmolyolo:

Szia!

pár dolgot itt kérdőjelesnek érzek:

>a gyártás költsége ad rá lehetőséget, hogy megtérüljön.
a megterulés nem a gyartas koltségén fog mulni, hanem hogy megveszik-e.

>Bármin, bárhol, bármikor olvashatja.

És persze jo lenne mindez ingyen... Valakinek a kockázatot is be kell vállalni, nem? :-)

@Konyvmolyolo: @szakértőbb: Bocs, az a bajom az érvelésetekkel, hogynem veszi figyelembe a paradigmaváltást. Most komolyan, kézírással meg írógéppel másolás... A beatles is rég feloszlott már.

Elvileg ugye nem lehetne fénymásolni nemhogy könyvtári, de semmilyen könyvet sem, ezzel szemben a valóság az, hogy bizony azok a fénymásolók dolgoznak szépen.

Az egy dolog, hogy az írott jog mindig is lemaradásban van a gyakorlathoz képest, de szerintem nem túl üdvös kapaszkodni valamibe, ami se praktikusan se morálisan nem igazán tartható.

Gondolatkísérlet: jön a mezei, és jogkövető felhasználó, megtalálja a PIM-et, egyrészt büszkén düllleszt, lám lám az én adóforintjaimból mi kulturális érték jött itt létre, majd elolvassa a T&C-t és szépen odakészíti magának a cuccot offline, nevezzük ezt a lépést printnek. Ezek után szerintem fel lesz háborodva, ha utána valahol valaki pénzt akarna kérni ugyanezért. Az egyetlen, legalább morálisan védhető érv az az lehet, hogy a _minőségi konverziót_ fizeti ki, hiszen a forrás már praktikusan köztulajdon, a köz fizetett érte, és a köz használhatja.

És utána ugyanez a mezei és jogkövető felhasználó kicsit haragudni fog a kiadóra, hogy mi a viharért kellett már megint egy ezer helyről elérhető anyagot újra kiadnia, miért nem jön inkább valami igazán újjal, eredetivel?

És mert empata, belátja, hogy a kiadó nyilván kockázatminimalizál. Csak éppen ebből nem lesz progresszió, és emberünk elszomorodik.

Tényleg ezt akarjuk?

@szakértőbb:
Pontosabban azon fog múlni, hányan veszik meg.
A megtérülés a gyártás költségén IS múlik.
Ez egy tétel a ráfordítások között. És miután nagyon kevés példányt vásárolnak még az olvasók, fillérek folynak be az e-könyvekből.
Ha nem akarjuk drágán adni a könyveket, átlag 15 e Ft fog befolyni könyvenként. Ez nem sok mindenre elég.

A kockázatot mindenképp a kiadó vállalja.
Egyrészt azzal, hogy tönkreteszi-e a piacot a nyitással.
Másrészt azzal, hogy kiszolgálja az olvasóit, kínál e-könyveket, méghozzá nem is akármilyen minőségben.

A feladat ezt a kockázatot racionalizálni, hogy ne kelljen leragadni néhány könyvnél, és csak próbálkozni, hanem rendes kínálatot lehessen nyújtani.

@Dworkyll: Nézd, Dwo, én ebbe nem mennék bele.
Hiszen ez oda vezet, hogy meg kell szüntetni a szerzői jogot mint olyat. Mert a van rajta sapka (fenn van a DIÁ-n) nem máködik.

Én biztosan tudnék úgy is élni - az egy más helyzet volna, amihez kell alkalmazkodni.
Ha nem sikerül, legfeljebb kihalnék, mint a dinók.:)

Ma azonban még van szerzői jogi törvény, és az a fentit írja elő.
És a szerződéseinket is annak tudatában kötjük, hogy van.

Ezeket a dolgokat nem lehet csúsztatgatni, hogy ha akarom vemhes, ha akarom nem.

Akkor odaállhatnék Csukás Pista bátyánk (vagy bárki más) elé, és mondhatnám:
bocs, igaz, hogy ezt írtuk alá, de hát paradigmaváltás van, inkább mégsem fizetném ki, amit megígértem.

@Konyvmolyolo:

>Pontosabban azon fog múlni, hányan veszik meg.
>A megtérülés a gyártás költségén IS múlik.
>Ha nem akarjuk drágán adni a könyveket, átlag 15 e Ft fog >befolyni könyvenként. Ez nem sok mindenre elég.

:-) Akkor a rendelkezésre álló takaró hosszáig célszerű a nyújtózkodást kivitelezni.

>Egyrészt azzal, hogy tönkreteszi-e a piacot a nyitással.

Milyen piacot? :-)) E-könyvek vannak, ha a kiadók nem is adnak ki... De erről már sok szó esett, úgyhogy ezt nem érdemes firtatni.

:) egyetértünk.

Persze, hogy vannak e-könyvek. De mennyire?
A mostani helyzet nem írható le a logikai igen/nem-mel, nem fekete-fehér.

Ha valami matematikai apparátust kellene használni, sokkal inkább a valami fuzzy rendszerre szavaznék, ahol olvasótípusonként, könyvtípusonként, sőt, konkrét könyvenként más értéket vesz föl ez a "létfüggvény", és ha a piacra való hatását akarnánk elemezni, még az eredmény előjele sem könnyen megjósolható az egyes pontokon.

Valami szürke sok-sok árnyalata, több dimenzióban.:)

@szakértőbb:

Itt nem a szabad felhasználás számít, hanem az, amit a DIA szab feltételnek:

"Minden további nélkül olvashatja és magáncélra kinyomtathatja a honlapon közölt szövegeket, változtatások nélkül és a forrásra való megfelelő hivatkozással. Azonban nem áll jogában azoknak vagy azok bármely részletének kereskedelmi jellegű, elektronikus vagy nyomtatott formában történő felhasználása, módosítása, másolása, többszörözése, terjesztése, továbbítása, megjelenítése, előadása, reprodukálása, közzététele. Ezek a cselekmények a fent említett jogszabályba ütköznek, és az abban megfogalmazott jogkövetkezményekkel járnak."

A szkript az elsőt csinálja.

Az összes többi - kereskedelmi célra - tilos.

De ha csak a technikai oldalát nézzük: azzal, hogy egy adott szöveget megnyitok a dián - erre van kitalálva az oldal - egy másolat már ott lesz a gépemen. Hogy ezt milyen böngészővel (Firefox, Safari, IE, vagy éppen ekönyvolvasó alkalmazás), milyen gépen (PC vagy mobiltelefon, ekönyvolvasó), milyen méretben, fonttal stb. teszem meg, az természetesen a magánügyem. Ahogy az is, hogy a szöveget "online" (élő internetkapcsolattal" vagy "offline" olvasom, digitálisan vagy papírra nyomtatom stb.

Vagyis a fenti feltételeknél előrángatni a szabad felhasználást olyan, mintha azt mondanád, hogy egy CC licensz alatti mű nem másolható, mert az sérti a szabad felhasználást.

@Dworkyll: Semmi baj azzal, hogyha a kiadó pénzért adja az ekönyvet. Az a dolga. Akinek így kell, az úgyis így fogja megvenni.

(Baj inkább azzal van, amikor ott a kész digitális szöveg, és mégis ("véletlenül") évek telnek el, amíg egy papírkiadást (ami mostanában már szerencsére sokszor együtt jár az ekönyvkiadással) követ a DIÁs változat. )

@Komavary: Ha ez nem így lenne, ahogy Komavary írja, akkor az egész DIA-nak nem sok értelme lenne szerintem.

@cxm: Mennyi mindennek nincs még értelme ezen kívül is, amire pénzt adnak ki... :)

@Konyvmolyolo:
Idén 100 e-könyv címmel?
Nincs szükségetek segítségre helyben? :)

Egyébként minden kollégától kérdem:
Ha már szóba került, hogy ipari (ha úgy tetszik profi, bár jelenleg azt hiszem ezen a területen ilyen nem létezik) megoldások kellenének, miért kerülnek elő folyton a konvertáló csodák és wyswyg szerkesztők?
Hiszen a kiadóknál a forrás jellemzően tördelőprogramokban van meg (indesign, esetleg quark). Onnan meg az út - ahogyan én látom - nem visszafele (szövegszerkesztők irányába) kellene vezessen, hanem egy jól felhasználható köztes alapanyaghoz (xml, xhtml), amelyből kívánság szerint lehet előállítani epubot, mobit (akármit).

A másik, hogy Klára például nagyszerűen megoldja sed scriptekkel amit szeretne, de miért nem például xsl (ha már eljut oda a folyamat, hogy xhtml/xml van)? Nem személyesen neki szól, úgy általában kérdem hogy miért nem platformfüggetlen, akár szerver oldalon is használható megoldást kerestek?

Harmadik, hogy valóban lehet szép, jól mutató dolgokat készíteni egyik vagy másik formátumban (iniciálék, miegymás) ám eddigi tapasztalataim alapján hamar előkerül az a probléma, amely már régóta jelen van a weben is: ahány megjelenítő, annyi módon jelennek meg ezek a varázslások.
Részemről arra jutottam: "ipari" szempontból elsődleges a kompatibilitás.

(Kissé szétszóródott a téma, de úgy tűnik itt kicsit nagyobb a forgalom, ezért ide írtam.)

@Polemius: :) beszéljünk.

Küldtem üzenetet az indával, de nem tudom megkaptad-e.
Amennyiben nem, kérlek küldj egy címet a polemius kukac gmail pont com címre.
Ha mégis megkaptad, a választ is írhatod ide. :)

A projektem egyelore jegelem. Leginkabb a megkopott lelkesedes (meg kisebb reszben a vegtelenul elavult szerzoi jogi torvenyek) miatt, es mert ahhoz, hogy egyaltalan rendesen mukodne windowson, ujra kene irni calibre-pluginkent. a github repot levettem, aztan majd ha eldontom h egyszer mi lesz ennek a sorsa, akkor majd...lesz valami.

@Polemius: Ezügyben az elmúlt két évben páran már értetlenkedtünk néhány kört. anno azt hiszem én voltam az első és heteken-hónapokon át talán az egyetlen, aki ragaszkodott ahhoz, hogy a konverzió csupán shellscriptek kérdése kellene legyen. Készítettem is ilyeneket, néhányat. Működnek, Viszont kiadóközeli olvtársak felvilágosítottak, hogy a tipikus magyar kiadónak ha van egyáltalán valamilyen elektronikusan tárol példánya a könyveiből, az vagy pdf, vagy (jobb esetben) valamelyik tördelőprogram kimenete. ezek meg - a programok készítőinek jóvoltából - továbbfeldolgozásra, konverzióra alkalmatlanok. Direkt.
Azt is megtárgyaltuk mát több körben és néhányan bele is fogtunk, hogy kidolgozzunk egy xml alapú tárolási mechanizmust, amiből aztán a megfelelő xsl használatával olyan formátum generálható, amilyet csak akarsz. Úgy tűnik a kiadók ebben nem érdekeltek (illetve nem tudják, hogy azok). Nehogymár legyen egy közös szabvány, ami olcsóvá és gond nélkül ide-oda konvertálhatóvá teszi a tárolást. Az a jó üzlet, ha mindenki külön megszenved a saját rendszerének kidolgozásával sok pénzért és lehet mutogatni, hogy emiatt kell drága legyen az e-book.
Ahhoz, hogy xml legyen a vegyes forrásokból, előbb a szomszédos posztban leírt "gépsorhoz" hasonló folyamatokat kell használni, aztán lehet továbbgondolni.
Abban meg nem értünk teljesen egyet, hogy "ipari szempontból elsődleges a kompatibilitás". Nem tudsz minden olvasóval kompatibilis lenni ugyanazzal az e-pubbal. Illetve de: ha nem tud többet, mint az fb2. Az meg eléggé fapados, igaz xml.
Ipari szempontból elsődleges kell legyen, hogy a tárolt forrásban legyen benne minden, ami beletehető. Tehát iniciálé, táblázat, ligatura, minden, ami a könyvet a txt-nél többé teszi. Eztán a konverziónál elő lehet belőle állítani az egyszerűbb formákat. Egy bonyolult felépítésű forrást egyszerűsíteni scriptekkel könnyen megoldható, míg egy txt-ből semmilyen scripttel nem fogsz szépen kivitelezett e-pub-ot csináni.
Azt kellene elfogadni, hogy egy igazán sokoldalú e-book boltban nem csak arra kérdez rá az eladó, hogy milyen formátumot akarsz (e-pub, prc, fb2), hanem arra is: ha e-pub, akkor milyen olvasót fogsz használni. És az ahhoz igazított e-pub-ot adod el a vevőnek.
Ez már tényleg csak scriptek kérdése, ha a "full service" e-pub, vagy az annak megfelelő xml rendelkezésedre áll. Egy ilyen script elkészítése pár nap (ha tudom, hogy a célberendezés az e-pub szabvány mely részeit ignorálja), utána a használata meg pár másodperc. Ehhez meg a kiadónak, vagy a könyves műhelynek be kell szereznie a lehető legtöbb olvasót, és pár hetet rááldozni a kiismerésükre.
Ne a tárolandó példány lebutítása legyen a cél.

@SaGa:
"Tehát iniciálé, táblázat, ligatura, minden"

Azért én egy e-könyvben nem erőltetném a ligatúrákat. Sok értelme nincs, ráadásul a szótárazást, keresést, felolvasást (ami egyik fő előnye az e-könyveknek) kapásból ki is zárhatnád.

@SaGa: Én azért bízom benne, hogy csak odafigyelnek a kommentjeidre a kiadók (tudtommal nem egy piaci szereplő olvassa a blogot), és lesz belőle valami, mert vásárlói szempontból logikusnak és igen barátságosnak tűnik amit írsz, ezek hosszútávon biztos elvárások lesznek.

@SaGa: Bizonyára félreérthetően fogalmaztam. A kompatibilitás maximalizálását a végeredményre értettem: az e-könyvekre.
Egy tökéletes világban bizonyára működne, hogy minden készülékre külön szerelődne össze az e-könyv (sőt, szabványosan működnének :) ). Addig is persze érdemes minél teljesebben megőrizni a formázásokat akár xml akár más formátumban a folyamat során.
Ám a jelenlegi lehetőségeket felmérve én erre jutottam. Így is legalább két különböző változatot (epub és mobi) kell készíteni.

Eddigi saját tapasztalatom alapján azt kell mondjam: a kiadói források (kiadványszerkesztő formátumok) nem használhatatlanok. Ha nem áll rendelkezésre ilyen (csak pdf, netán print könyv) akkor persze ez nem működik, de azt kell mondjam, hogy ha már egyszer készen van egy tördelőprogram->ekönyv eljárás, akkor ezeket az egyéb forrásokat is vissza lehet vezetni erre. Hiszen például Indesignban elég hatékony eszközök állnak rendelkezésünkre a szövegek feldolgozására.
Az újonnan kiadott címek esetén pedig már eleve elő lehet készíteni az állományokat e-könyv konverzióra.