Állandó rovatok

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

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

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

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

Ha adakozni akarsz, itt megteheted:

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

GYIK - Szerszámosláda

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

Vannak még:

Válassz és rendelj Kindle-t innen

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

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

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

Sok Kindle trükk.

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

Eszközismertetők

Boltismertetők

 

Utolsó kommentek

Címkék

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

Linkek - források

A barátaim, innen onnan

Svájci bicska: XSLT

2011.01.10. 21:26 Ignis_veneficus

Ajánlás

eNeL makróidomítási okosságai után újabb technológiaközeli írással igyekszünk borzolni a kedélyeket. Fogadjátok sok szeretettel Ignis_veneficus barátunkat, az ipari szövegtranszformáció feketeöves mesterét, a TEI és az XML avatott kezű varázslóját. Az írás nagyon száraz, ezt előre mondom, de van, amikor ez kell. A prc fizikai tartalomjegyzékkel való kiegészítésének támogatásáért mindenesetre örökké hálásak leszünk neki (is).

Aki nem érti, ne pánikoljon, nem vele van a baj, a megfejtés ott a poszt végén egy hasonló dobozban :-)

Dworkyll

Intro

Az XSLT az XSL Transformation rövidítése, vagyis (pongyolán fogalmazva) XML transzformáció, amivel egy XML-ből másik XML-t lehet előállítani. Egy teljes programozási nyelv.

Mivel az e-könyv generálása során XHTML-t állítunk elő (mind az epub, mind a mobi generáló részére), és a hozzá tartozó egyéb leíró fileok (opf és ncx) szintén XML, adja magát, hogy az XSLT-t felhasználjuk ezek előállítására, és hasonló kis sriptek írhatóak benne szinte percek alatt.

A továbbiakban nagyon szakmai, programozói lesz.

Hozzávalók

  • Bemeneti XHTML
  • XSLT processor (ami futtatni tudja az XSLT-t), én a java-s xalan-t használom (gyors, egyszerű, parancssorból futtaható, és integrálható java programokba)
  • XML editor. (használható helyette egyszerű TXT editor is. pl notepad, Jedit, stb)

Példaprogram: mbp_toc -> ncx

A következő XSLT a előző postban vázolt problémára ad megoldást, vagyis, hogyan csináljunk a Mobipocket Creator által létrehozott tartalomjegyzékből ncx-et.

A kód

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

  <xsl:output method="XML" version="1.0" encoding="UTF-16" indent="yes" doctype-public="-//NISO//DTD ncx 2005-1//EN"
    doctype-system="http://www.daisy.org/z3986/2005/ncx-2005-1.dtd"/>

  <xsl:template match="/html">
  <ncx>  
    <head>
      <meta name="dtb:uid" content=""/>
      <meta name="dtb:depth">
        <xsl:attribute name="content">
          <xsl:call-template name="getDeep"/>
        </xsl:attribute>
      </meta>
      <meta name="dtb:totalPageCount" content="0"/>
      <meta name="dtb:maxPageNumber" content="0"/>
    </head>
    <navMap>
      <xsl:apply-templates select="body/ul"/>
    </navMap>
  </ncx>
  </xsl:template>
  
  <xsl:template match="ul">
    <xsl:apply-templates select="li"/>
  </xsl:template>
  
  <xsl:template match="li">
      <navPoint id="{generate-id(.)}">
        <xsl:attribute name="playOrder">
          <xsl:number level="any"/>
        </xsl:attribute>
        <navLabel>
          <text><xsl:apply-templates select="a"/></text>
        </navLabel>
        <content>
          <xsl:attribute name="src">
            <xsl:call-template name="getFileName">
              <xsl:with-param name="filename" select="a/@href"/>
            </xsl:call-template>
          </xsl:attribute>
        </content>
        <xsl:apply-templates select="following-sibling::*[position()=1 and local-name()='ul']"/>
      </navPoint> 
  </xsl:template>
   
  <xsl:template name="getDeep">
    <xsl:for-each select="//li">
      <xsl:sort select="count(ancestor::ul)" data-type="number"/>
      <xsl:if test="position()=last()">
        <xsl:value-of select="count(ancestor::ul)"/>
      </xsl:if>
    </xsl:for-each>  
  </xsl:template>
   
  <xsl:template name="getFileName">
    <xsl:param name="filename"/>
    <xsl:variable name="new">
    <xsl:choose>
      <xsl:when test="contains($filename,'%5C')">
        <xsl:value-of select="substring-after($filename,'%5C')"/>
      </xsl:when>
      <xsl:otherwise>
        <xsl:value-of select="substring-after($filename,'/')"/>
      </xsl:otherwise>
    </xsl:choose>
    </xsl:variable>
    <xsl:choose>
      <xsl:when test="$new and $new!=''">
        <xsl:call-template name="getFileName">
          <xsl:with-param name="filename" select="$new"/>
        </xsl:call-template>
      </xsl:when>
      <xsl:otherwise>
        <xsl:value-of select="$filename"/>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>
</xsl:stylesheet>

Az XML jól megkülönböztethető részekből áll:

  • Fejléc
  • XSLT definíció
  • Output definíció
  • "html" elem feldolgozása
  • "ul" elem feldolgozása
  • "li" elem feldolgozása
  • "getDeep" "függvény"
  • "getFileName" "függvény"

Fejléc és XSLT definíció

A fejléc és az XSLT definíció adott. Ez minden esetben szinte ugyanígy néz ki. Amiben eltérés lehet, az a alapértelmezett névtér a:

xmlns="http://www.daisy.org/z3986/2005/ncx/(névtér: egy XMl file több XML struktúrából is tartalmazhat elemet, és valahogy meg kell különböztetni egymástól, hogy melyik elem melyik struktúra része. A névtér egy előtagot definiál. A példánkba két névtér van, az alapértelmezett /ez jelenleg most az ncx-hez tartozik/ és egy xsl: kezdetű, ami az XSLT struktúra része)

Kimenet definíció

A kimeneti formátum definiálja a kimeneti XML header részét. Jelen esetben egy utf-16 karakterkódolást, és az NCX struktúrát, és így fog kinézni:

<?xml version="1.0" encoding="UTF-16"?>
<!DOCTYPE ncx PUBLIC "-//NISO//DTD ncx 2005-1//EN" "http://www.daisy.org/z3986/2005/ncx-2005-1.dtd">

Elemek feldolgozása

A következő három rész különböző elemek feldolgozását végzi el.

Az XSLT-ben egy elem feldolgozást a 

<xsl:template match="...">vezeti be. A match attributumban levő feltétel esetén fut le. Jelenleg három ilyen feltételt készítettünk:

  • /html: A gyökér HTML elem feldolgozása
  • ul: UL elem feldolgozása
  • li: LI elem feldolgozása

"ul" elem

Most felrúgva a kódban szereplő sorrendet, először a "ul" feldolgozását nézzük meg.

Egy sort tartalmaz:

<xsl:apply-templates select="li"/>Értelmezése: dolgozzon fel minden olyan "li" elemet ami közvetlenül az "ul" elemben található.

"html" elem

A gyökér HTML feldolgozása:

A feldolgozás során elkezdjük előállítani a kimeneti XML-t

(ezek azok a elemek, amelyek nem xsl:-lel kezdődnek) 

Az első lényeges dolog a

<xsl:attribute name="content">
  <xsl:call-template name="getDeep"/>
</xsl:attribute>
rész. Ez létrehoz egy attribútumot az előző elemhez (ami dtb:depth), a "content" névvel, és meghívunk egy "függvényt", melynek a neve "getDeep" (erről később, tulajdonképpen kiszámolja a tartalomjegyzék mélységét)

Ebben a részben még egy lényeges dolog van

<xsl:apply-templates select="body/ul"/>ami nem csinal mást, csak feldolgozza az összes "body" elemben lévő "ul" elemet (az elérés relatív, de ha a path előtt "/" van, lehet abszolút elérést is megadni)

"li" feldolgozása

Egyik leghúzósabb rész, a li feldolgozása következik. Ez készíti el a fejezet bejegyzéseket a tartalomjegyzékbe. Itt is a kimeneti XMLT-t állítjuk elő.

Első pontunk a 

<navPoint id="{generate-id(.)}">ami egy "navPoint" elemet hoz létre, egy "id" attribútummal. Az "id" értéke számított értéket tartalmaz (ezt mutatja benne a kapcsos-zárójel), mégpedig egy egyedi azonosító generálást az aktuális elemből. (generate-id() függvény)

A következő rész szintén egy attribútumot ad hozzá:

<xsl:attribute name="playOrder">
   <xsl:number level="any"/>
</xsl:attribute>
A "playOrder" attribútumot. Az értéke egy másik XSLT elem, amely a kérdéses elem ("li") sorszámát adja meg, mivel a "level" attribútum "any", a teljes dokumentumon belül.

Ezt követi a "content" elem "src" attribútumának beállítása:

<xsl:attribute name="src">
   <xsl:call-template name="getFileName">
     <xsl:with-param name="filename" select="a/@href"/>
   </xsl:call-template>
</xsl:attribute>
Ami szintén egy függvény hívás, de ennek már átadunk egy paramétert is: a "li" elemben lévő "a" elem "href" attribútumát. (a függvény megpróbálja az elérési útból a tényleges fájlnevet kiszedni)

<xsl:apply-templates select="following-sibling::*[position()=1 and local-name()='ul']"/>Itt meghívjuk feldolgozásra az "li" elemet közvetlenül követő "ul" elemet.

A "following-sibling::" definiálja, hogy a következő elemekkel foglalkozunk, a "*", hogy nem érdekel a típusuk (ha itt megadtuk volna hogy "ul", de akkor a pozicíótól függetlenül minden "ul" a listába került volna), de az első legyen és a típusa legyen ul

( a különbség:

following-sibling:ul[position()=1] : a következő ul elemek közül az első

following-sibling:*[position()=1 and local-name='ul'] a következő elemek közül az elsőt, ha ul a neve)

(a following-sibling:: szerkezet neve tengely, vagy axis)

 

Függvények

Ezek olyan részek, melyeket máshonnan lehet meghívni, mint egy függvényt.

getDeep

A kettő közül az egyszerűbb: megszámolja a tartalomjegyzék szintjeit.

    <xsl:for-each select="//li">
      <xsl:sort select="count(ancestor::ul)" data-type="number"/>
      <xsl:if test="position()=last()">
        <xsl:value-of select="count(ancestor::ul)"/>
      </xsl:if>
    </xsl:for-each> 
Végigmegy az összes "li" elemen (a "//" előtte azt jelenti, hogy az aktuális pozíciótól függetlenül, minden "li" elemre hajtsa végre)

<xsl:sort select="count(ancestor::ul)" data-type="number"/>Sor sorrendezi az elemeket (itt most az összes "li" elemet), mint számokat (ez a data-type), az a "select" attribútumban adjuk meg, hogy mi alapján.

Jelen estben egy összetett műveletet hajtunk végre. Megszámoltatjuk a felmenő "ul" elemeket.

(minden elemnek van egy szülő eleme, itt a szülő elem szülő elemet is vizsgáljuk egészen a kezdeti html elemig. az "ul" elemek száma meghatározza, hogy a tartalomjegyzék melyik szintjén található a vizsgált "li" elem)

 (Az "ancestor::" kifejezést tengelynek, axis-nak hívja a szakirodalom)

<xsl:if test="position()=last()">Egy másik programvezérlési utasítás: feltétel. Minden esetben a "test"-ben leírtak kerülnek kiértékelésre (else nincs, azt máshogy kell megoldani, látunk rá példát). Itt az adott elem pozícióját (sorszámát) hasonlítjuk össze az összesével (ez a last). Ezzel biztosítjuk, hogy azt az elemet vizsgáljuk, aki a tartalomjegyzék legalján áll.

<xsl:value-of select="count(ancestor::ul)"/>Szimpla érték kiolvasás. A felmenő "ul" elemek számát adjuk vissza

A függvény visszatérési értéke szimplán írunk a "kimeneti file"-ba

getFileName függvény

A függvény tipikus példája annak, hogy mire nem jó a XSLT: A file path-át kellene levágni. Ez tetszőleges programozási nyelven kb. 2 sor.

<xsl:param name="filename"/>Definiáljuk, hogy kaphatunk paramétert a filename név alatt.

<xsl:variable name="new">Létrehozunk egy új változót "new" néven. (az, hogy változó, kicsit meredek, mert csak egyszer kaphat értéket, később nem változhat.)

    <xsl:choose>
      <xsl:when test="">
Szerkezet a ellenőrzi a "when" "test"-ben definiált feltételt, és csak és kizárólag az első igaz értékűt hajtja végre.

Ez kiegészülhet egy "xsl:otherwise"-szal, ami a "minden más esetben". (egy when-otherwise-szal lehet megoldani egy if-else serkezetet)

<xsl:when test="contains($filename,'%5C')">Első feltétel, hogy a filename praméter tartalma-e "%5C" karaktersorozatot (html-es /jel kódolás)

amennyiben igen

<xsl:value-of select="substring-after($filename,'%5C')"/>Levágjuk ami utána következik (ez lesz a "new" változó értéke)

Az otherwise részben ugyanezt végezzük el, de itt már a rendes "/" karakterrel

Az értékadás után vizsgáljuk a változó értékét

<xsl:when test="$new and $new!=''">Ha van tartalma, akkor talált valamit a fenti két karakter(sorozat) után.

<xsl:call-template name="getFileName">
   <xsl:with-param name="filename" select="$new"/>
</xsl:call-template>
Meghívjuk önmagát, de itt más az új változóval, mint paraméter.

Mivel az XSLT-ben nincs hagyományos ciklus (for, while), ilyen problémákat csak rekurzióval lehet megoldani. (az meg gyorsan stack-owerflow hibát dobhat)

Amennyiben nincs adat az uj változóban:

<xsl:value-of select="$filename"/>Visszaadjuk a paramétert (ebben az esetben már csak a filenevet tartalmazza)

Verdikt

Az XSLT bizonyos feladatokat nagyon leegyszerűsít, és sok problémát levesz az egyszerű script-készítő válláról (nem kell a XML szabvánnyal foglalkozni, pl. karakterkódolás, space-kezelés, elemek végének keresése stb)

Nagyon egyszerűen lehet benne elemeket/attributumok megcímezni. Pl. az összes link url megfogása XSLT-ben egy kifejezés:

//a/@urlvagy pl: keressük az összes olyan elemet, ami három elemet tartalmaz, ebből az első "p" és az nem tartalmaz "i"-t:

//*[count(child::*)=3 and p[location()=1 and not(child::i)]]

És akkor mindenki elgondolkodhat, hogy a kedvenc script/programozási nyelvében hogyan tudná megoldani.

Mire használható

Minden olyan esetben, amikor az elemekkel történnek műveletek, áthelyezés, törlés, létrehozás, másolás stb. Amikor nem a text tartalommal kell dolgozni.

Mire nem használható

Minden olyan esetben amikor a elemek/attribútumok szöveges tartalmával kell dolgozni. pl Regexp-es find-replace-re nem ajánlott. 

Bináris adatokkal történő műveletre nem ajánlott.

(a fenti getFileName függvény majdnem határeset. A kód mennyiségéből is látszik (majdnem a leghosszabb rész), hogy egy viszonylag egyszerű feladatot milyen nehéz megoldani.

Két link

Két link, amelyből többet lehet megtudni:

  • XSLT leírás (XSLT elemek definíciója, használata, leírása)
  • Xpath leírás (Xpath az elemek címzése, axis-ok leírása, függvények definícóját tartalmazza)

 

 

Oké,
 
akkor aki magamfajta hályogkovács, és elméleti tudás nélkül csak használni akarja Ignis megoldását, kövesse az alábbi lépéseket:
 
  1. töltsd le a innen a xalan utolsó „binary release”-ét
  2. csomagold ki egy szívednek kedves helyre
  3. tedd melléjük az alábbi xalan.bat file-t (.bat-ra visszanevezve). Ez fogja majd az xsl file-t meghajtani az imént letöltött java futtatókörnyezeten
  4. tedd melléjük az alábbi xsl-t. Ez végzi a transzformációt magát. Ha akarod, ezen már bütykölhetsz magad is.
  5. Töltsd le ezt a toc_creator.bat file-t. Ezt, a belső, xalan.bat-ot és xsl-t elérő útvonalak pontosítása után (ezt elég egyszer megcsinálni, mert úgysem fogod a xalan készletet hurcolászni) mindig oda kell másolni a publikációs alkönyvtárakba, ahol az adott mbp_toc.html van. Ha ezt futtatod, ez fogja megcsinálni magát a toc.ncx-et.
  6. Ezt a vbscriptet eNeL anyagából vágtam, a kész toc.ncx hivatkozását ez szúrja be az opf-be. Ezt is mindig a publikációs könyvtárba kell bemásolni, a txt kiterjesztést meg idejekorán levágni.
  7. Ha az új opf alapján buildeled meg a publikációt, akkor abban már benne lesz a toc.ncx is. A Mobi desktop kijelzi a fejezetcímet, és Kindle tud fejezetenként lapozni. A legfölső szintű töréspontok meg ott lesznek a progress bar-on. 
  8. Gondolj hálás szívvel Ignisre és eNeLre :-)

Dworkyll

 

Update #1

A kindle féle változat, amelyben minden egy szinten van:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" xmlns="http://www.daisy.org/z3986/2005/ncx/">
  <xsl:output method="XML" version="1.0" encoding="UTF-16" indent="yes" doctype-public="-//NISO//DTD ncx 2005-1//EN"
    doctype-system="http://www.daisy.org/z3986/2005/ncx-2005-1.dtd"/>

  <xsl:template match="/html">
    <ncx>
      <head>
        <meta name="dtb:uid" content=""/>
        <meta name="dtb:depth" content="1"/>
        <meta name="dtb:totalPageCount" content="0"/>
        <meta name="dtb:maxPageNumber" content="0"/>
      </head>
      <docTitle>
        <text><xsl:apply-templates select="title"></xsl:apply-templates></text>
      </docTitle>
      <navMap>
        <xsl:apply-templates select="//li"/>
      </navMap>
    </ncx>
  </xsl:template>

  <xsl:template match="li">
    <navPoint id="{generate-id(.)}">
      <xsl:attribute name="playOrder">
        <xsl:number level="any"/>
      </xsl:attribute>
      <navLabel>
        <text><xsl:apply-templates select="a"/></text>
      </navLabel>
      <content>
        <xsl:attribute name="src">
          <xsl:call-template name="getFileName">
            <xsl:with-param name="filename" select="a/@href"/>
          </xsl:call-template>
        </xsl:attribute>
      </content>
    </navPoint>
  </xsl:template>

  <xsl:template name="getFileName">
    <xsl:param name="filename"/>
    <xsl:variable name="new">
      <xsl:choose>
        <xsl:when test="contains($filename,'%5C')">
          <xsl:value-of select="substring-after($filename,'%5C')"/>
        </xsl:when>
        <xsl:otherwise>
          <xsl:value-of select="substring-after($filename,'/')"/>
        </xsl:otherwise>
      </xsl:choose>
    </xsl:variable>
    <xsl:choose>
      <xsl:when test="$new and $new!=''">
        <xsl:call-template name="getFileName">
          <xsl:with-param name="filename" select="$new"/>
        </xsl:call-template>
      </xsl:when>
      <xsl:otherwise>
        <xsl:value-of select="$filename"/>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>
</xsl:stylesheet>

113 komment

Címkék: xml prc mobipocket gyakorlati kérdések epub

A bejegyzés trackback címe:

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

Kommentek:

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

Ignis_veneficus 2011.01.13. 06:51:22

@Dworkyll: keres helyet a metaadatoknak a html-ben es megirom a html->opf konvertert

SaGa 2011.01.13. 08:06:50

@Dworkyll: Semmi "bugyiráhúzás" nincs. A Kindlegen semmi egyebet nem csinál az epubbal, mint egy prc forrással. A content.opf tartalmát feldolgozza. Mivel az epub content.opf-jében benne vannak a fontok is, azt is beépíti.

Megoldás: fogod az epub-ot, kibontod, kiradírozod a content.opf-ből a fontokat és így küldöd be a kindlegenbe.
A kindle a styles.css-ből azokat a formázási utasításokat, amelyeket ért, használja, a többit meg nem veszi figyelembe. Ennyi.
Ha az epub-ban volt "rendes" tartalomjegyzék, akkor lesz egy full prc-d, tartalommal és ncx tartalommal. Kicsit ugyan puritánabb mint ugyanaz a kötet epub-ban, de még mindig többet mutat, mint ugyanaz a kötet natív mobi formátumra előkészített html-ből generálva.

Professzore · http://ekonyvolvaso.blog.hu 2011.01.13. 08:11:43

Nem lehetne végre ezt a konferenciát moderált körülmények között összehozni? Többre mennénk vele szerintem.

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.13. 09:38:32

@SaGa: Éppen ez a baj. A fontokat a prc parser nem tudja értelmezni/másképp értelmezi. Akkor a kindlegen miért viszi át?

Meg ott vannak azok a dolgok, amiket másképp értelmez az epub és a mobi parser. Alapértelmezett sortávok és behúzások pl.
Azoknál érdekes ez, amik valami mobi specifikus formázást csinálnak, és ezért véletlenül sincsenek benne az epubban, pl a monospaces kiemelések.

Arra jó egy epub, hogy gyorsan mobit húzzak le belőle, pl. azért mert a mobit jól lehet korrektúrázni, az epubot meg kevésbé, de az optimumhoz szerintem a forrást magát kell kioptimalizálni.

Vagy kéne egy "stílus- vagy tagmapper" ami a kindlegen konverziónál definiálja, hogy az epub egyes dolgait hogy fordítsa mobira.

kIára 2011.01.13. 10:26:04

@Dworkyll: Az tetszik a Kindlegen-ben amit @SaGa: is mondott.
Az OEBPS szabványhoz való igazodási szándék, az xhtml és a css utasítások pontosabb követése.
A kindlegen még csak az 1.1 verziónál tart, de gyakorlatilag már most egy más tömörítéssel készült epubot generál.
Az, hogy megőrzi az epub publikációs fájlok beépített fontjait, számomra azt jelenti, hogy vagy a következő generációs kindle, vagy egy jövőbeni hivatalos K3 firmware update is tudni fogja (előregondolokodás).
Lesz/van egy más drm, és más tömörítés, de epubnak epub az eredmény.

Engem egyáltalán nem zavar a metaadatok, az ncx, a toc _jelenleg_ fapadosnak tűnő készítése.
A kindlegen elsősorban kiadóknak e-tipográfusoknak készült (vagyis szakembereknek) és szerintem szándékosan puritán. Kicsit olyannak látom mint a LaTeX-et. Mindkét esetben forrás- állománybütykölés van, a könyvet meg feldolgozza a platform. Lehet szeretni vagy nem szeretni, de jó kezekben kezesbárány, és úgy érzem, hogy még mindig kevesebb kézimunka van vele, mint egy papírkönyv előállítása során szükséges DTP meló esetén. (Az lenne irritáló ha lenne egy iTex vagy iKindle csilivili, klikkelgetős „ne kérdezz semmit, ne tudj semmit, bízz bennem” publikációs rendszer.)

Amúgy kíváncsi lennék, egy olyan versenyre, amely során ugyanabból az rtf-ből mennyi idő alatt készít el egy-egy InDesign, LaTeX, QuarkXPress, Epub és Mobi guru a maga formátumában minden téren profinak minősülő kész könyvet. (Tippem a megosztott első helyre: epub/mobi, utolsó hely: LaTeX)

Ignis_veneficus 2011.01.13. 10:48:28

@Dworkyll: "Vagy kéne egy "stílus- vagy tagmapper" ami a kindlegen konverziónál definiálja, hogy az epub egyes dolgait hogy fordítsa mobira."
megoldhato: definialsz egy mapping xml-t (stilus), kicsomagolod az epub-ot, lecsereled a css-t, rakuldod a konvertert, ami 1 vagy 2 lepesben lecsereleli a stilusokat a megfelelolekre. aztan mehet a kindlegen

kIára 2011.01.13. 10:48:36

@Dworkyll:
»Azoknál érdekes ez, amik valami mobi specifikus formázást csinálnak, [és ezért véletlenül sincsenek benne az epubban, pl a monospaces kiemelések.]«
Amióta ismerem és használom a mobit, pont ezek a „specifikus formázásuk” irritáltak. Elfogadtam, használtam (mert kellett), de idegesített. Nekem azt tanították, hogy ha valamit készítek, akkor a receptet kövessem, és ne a tortaformára vagy a majdan felszolgálásra kerülő tányérra gondoljak, hanem a hozzávalókra. Nem készítek vaníliás muffint fahéjból.
Magánvélemény, de számomra a Mobipocket Industry régen és ma olyannak tűnik mint a Microsoft. Saját, önfejű, enyhén erőszakos kikényszerítése olyan dolgoknak, amik ellentmondanak a szabványoknak, de az erőfölény miatt a saját dolgaik szabványnak minősülnek.
(Mikor webdizájnnal foglalkoztam, soha de soha nem optimalizáltam IE6-ra. Mert nem.) Most, hogy végre van egy használható kindle, többé nem fogok „mobi specifikus formázást” használni. Temettem.

kIára 2011.01.13. 10:57:16

@Dworkyll: @kIára:
Persze az én gépemen is elég sok prc és publikációs fájl csücsül, ami miatt kicsit fáj a fejem. De szerencsére jelentős részüket nem akarom a közeljövőben újraolvasni, úgyhogy jelenleg nem is foglalkozom ezek kindleoptimalizációjával.
Neked meg gondolom sokkal több van, és nem kicsit fáj a fejed. De már van mbp_toc -> ncx varázslatod :)

SaGa 2011.01.13. 11:21:07

@Dworkyll: Van ilyen "tagmapperem". Ennek elkészítése pofon egyszerű, ha magad dolgozod fel a forrást.
Ha már elkészült epub-ból kell dolgozni (pláne, ha Atlantis által berheltből), akkor kötetenként kell újra elkészíteni.
A sokat emlegetett scriptjeim jelen formában úgy működnek, hogy a megfelelően formázott *.odt-ből kibontott content.xml-ből egyszerű regexp keres-cserél algoritmussal előállítja a prc forrásául szolgáló, kizárólag mobi formázásokat tartalmazó fájlt és az epub forrásául szolgáló másikat. Ez utóbbiban az epub formázások vannak benne. Aki kéri annak szívesen elküldöm és ki-ki alakítsa át ahogy neki tetszik. Be nem másolom ide, mert több száz sornyi és mg messze nem kész... Ha majd jobban megy a powershell, megpróbálom arra átírni. A VB scriptektől lábrázást kapok, arra nem vállalkozom...

A kindlegent azért nem lehet ilyen tagmapperrel ellátni, mert a forrás epubban a class-ok bárhogy kinézhetnek, ráadásul lehet köztük rengeteg felesleges is. Lásd Atlantis.
Emiatt a Kindlegen maximum annyit tudna tenni, hogy a font fájlokra vonatkozó bejegyzéseket eliminálja a content.opf-ből, mielőtt elkezdi feldolgozni a tartalmát, hogy ne maradjon benne fölöslegesen. A formázási osztályokat nem tudja átalakítani, mert miről-mire? Melyik Kindle verzió képességeihez igazodjon?

Dworkyll · http://ekonyvolvaso.blog.hu/ 2011.01.13. 11:23:30

@kIára: Finoman vitatkoznék. Még ha epub felé konvergálódónak látszik is az amazon, szerintem arra kínosan ügyelni fognak, nehogy más vason is olvasni lehessen, csak úgy. Leginkább azért, mert ők adnak egy raklap plusz szolgáltatást, leginkább az annotációt, meg az értelmes metaadat-kezelést.

A másik, hogy épp a specifikumok okán a többiek előtt jártak, már évekkel ezelőtt. Volt annotáció, volt működő DRM, volt fehér ember által használható konverter. Ha temeted a specifikumokat, ami persze szived joga, akkor lemondasz a platformon elérhető maximumról, és maradsz a "közös nevező" által kijelölt lehetőségtérben. Aminek csak akkor van előnye, ha egyszerre több platformon mozogsz. Szerintem.

Off: egyszer nézd meg, hogyan készülnek egy szakácsversenyre. Pl. amikor tükrön tálalják a hidegtálat. Megdöbbennél :-)

kIára 2011.01.13. 12:22:00

@Dworkyll:
Kicsit másról beszélünk.
Több mobi megközelítés van.
Eddig uralkodott a Mobipocket Industry prc-je. Ehhez van (szűkös) leírás, builder, olvasó.
Most pozíciócsere történik az Amazon azw-vel. Ehhez is van leírás, builder, olvasó.
Csak annyit akartam mondtani, hogy nekem a Mobipocket irány soha nem tetszett, az Amazoné meg (egyelőre) tetszik.
És szerintem prc-mobi és az azw-mobi egymástól távolodnak. Persze sokáig (vagy talán mindig) kölcsönösen támogatni fogják egymás olvasószoftvereit és -kütyüit, de belül egyre nagyobbak lesznek az eltérések.

Off: a szakácsversenyen a szakácsművész készít egy egyszeri, csodálatos, lenyűgöző és megismételhetetlen muffin jellegű muffint. Recept alapján meg készítesz egy muffint ami valóban muffin.

kIára 2011.01.13. 12:41:15

@Dworkyll:
    »Ha temeted a specifikumokat, ami persze szived joga, akkor lemondasz a platformon elérhető maximumról, és maradsz a "közös nevező" által kijelölt lehetőségtérben. Aminek csak akkor van előnye, ha egyszerre több platformon mozogsz. Szerintem.«

Mondok egy egyszerű példát. Ahhoz hogy a Mobipocket Creatorral normális behúzást érjünk el, a <p> tageket agyon kellett szemetelni a teljesen irracionális, nevetséges, a szabványt magasról lehugyozó attribútumokkal. Most meg van a normális, logikus szabálykövetés a Kindlegen részéről. Ez az ami tetszik.
Nem beszélve arról, hogy ennek hála lehet végre EGY forrásállományról beszélni (ahogy te is észrevetted). A falat kaparnám, ha két e-könyvért (epub & mobi) kétszer kellene forráskódot bütykölni.

Ignis_veneficus 2011.01.13. 13:01:37

@SaGa: "megfelelően formázott *.odt-ből kibontott content.xml-ből egyszerű regexp keres-cserél algoritmussal előállítja a prc forrásául szolgáló, kizárólag mobi formázásokat tartalmazó fájlt és az epub forrásául szolgáló másikat."
Pl erre lenne jo egy xslt. kevesebb sor, robosztusabb, egyszerubb.

@kIára:
"Nem beszélve arról, hogy ennek hála lehet végre EGY forrásállományról beszélni (ahogy te is észrevetted). A falat kaparnám, ha két e-könyvért (epub & mobi) kétszer kellene forráskódot bütykölni."
Erre nekem az a megoldasom, hogy egy XML forrasom, es annyi "konverterem" ahany kimenetet akarok.
- egy forrast kell butykolni, ami fuggetlen a formazastol
- egy-egy konvertert kell butykolni, (de az jo az osszes forrasra), es nincsenek kompromisszumok, hogy az egyikben a blockqouta lenne jo (kindle), a masikba pedig a margin-left (epub). vagy az egyikbe bele kell rakni a fontot (css, opf, stb), a masikba pedig nem.

Wierra 2011.01.13. 14:08:32

Végre megjött a dec. 5-én rendelt K3 wifi!

Van örö' és bódottá'! :D

Atyaman 2011.01.13. 14:29:07

Lenne egy kérdésem.
Win XP 32-biten hibátlanul lefutott az ncx generátor, de Win 7 64-biten már nem sikerült neki. Arra lennék kíváncsi ennek mi lehet az oka?
(Egy ötlet: a xalan.bat fájlnál a run as administrator checkboxa nem pipálható ki, így lehet, hogy nem kapta meg a rendszergazdai jogokat.)

Ignis_veneficus 2011.01.13. 15:00:29

@Atyaman: mekem win7 64-en fut..
hibatlanul
mi a hibauzenet?

Atyaman 2011.01.13. 15:06:40

@Ignis_veneficus: nincs ;)
Megjelenik a futási ablak, de mielőtt bármit is csinálhatna be is zárul.

Ignis_veneficus 2011.01.13. 15:36:48

probald elosz a run-ban a "cmd" -t inditani, megkapod a command promtot, es ott inditod (a megfeleo alkonyvtarbol)
ha total commandered dav, akkor a kerdeses alkonyvtarba allva beirod: cmd
majd az elozo parancsot Cpoy es a command ablakban Paste.
Ott latni fogod a hibauzenetet is

Atyaman 2011.01.13. 15:57:30

@Ignis_veneficus: ezt írja: 'java' is not recognized as an internal or external command, operable program or batch file.

És tényleg. Most látom, hogy 32-bites java van fenn.
Mentségemre szóljon nem én raktam fel (legalábbis nem közvetlenül :D)
Újra telepítem egy 64-es verzióval. Avval már sztem menni fog.

Köszi a helpet ;)

Ignis_veneficus 2011.01.13. 16:19:19

@Atyaman: nem kell telepiteni
a batch-ba nem a java-ra hivatkozz, hanem add meg a teljes eleresi utat.
nem talalta a path-ba a java-t

Atyaman 2011.01.13. 16:23:02

Nem sikerült megtalálnom a 64-bites JRE-t letöltésre úgyhogy az alap JRE 6 (23)-at raktam fel. Szerintem a 32-esnek is mennie kéne. Kipróbáltam egy java-s progit az megy gond nélkül.
Ennek ellenére a hibaüzenet maradt ugyanaz. Furi.

Ignis_veneficus 2011.01.13. 16:51:06

@Atyaman: az a problema, hogy amikor beirod, hogy ÁjavaÁ a win nem tuydja mit kellene csinalnia.

keresd meg azt a bat file-t amiben a java-ra hivatkozik (valszeg a xalan.bat) es a "java"-t ird at arra, ahova raktad: pl:
"c:\progam file\java\bin\java.exe"

Karma17 2011.01.13. 16:57:16

Pontosabban ha 32 bites a Java a 64 bites OS-en: "c:\progam files (x86)\java\bin\java.exe"

Atyaman 2011.01.13. 17:14:25

@Ignis_veneficus: nem nagyon tudom mit kéne átírni, mert a xalan.bat-ban átírtam a java-t az elérési útvonalra (C:\Program Files (x86)\Java\jre6\bin\java.exe). De a hibaüzenet csak annyit változott, hogy most 'java' helyett 'C:\Program'-ot ír.

Atyaman 2011.01.13. 17:17:23

Az előző két hozzászólsom úgy született, hogy már több mint fél órája meg volt nyitva a böngésző ablak és nem láttam azokat a hozzászólásokat, amik akkor születtek. (csak hogy ne tünjek teljesen hülyének a válaszaimmal, elég az is, hogy a xalanhoz és az xsl-hez nem értek)

Atyaman 2011.01.13. 17:19:41

Lehagytam az aposztrófokat az elérési útvonal elejéről és végéről. Most már megy. THX Ignis és Karma17!

SaGa 2011.01.13. 17:39:56

@Ignis_veneficus: Igazad van, csak az xslt-hez (még) nem értek, a shellscripteket meg már legalább ugatom valamelyest...

hcpeter1 2011.01.15. 18:26:12

Sziasztok!

Egy kérdésem lenne konvertálás témakörben. Mindent a leírtak szerint csináltam, de sajnos a konvertált prc nem olyan lesz mint amire számítottam. Pdf-ből konvertáltam htmlbe, megcsináltam az opf-et kindle 3 formátumra. A következő a probléma: a kindle nem látja a fejezetes ugrópontokat (szóval a fejezetek között nem tudok lapozni), illetve valahogy összefolyik az egész. Tehát a fejezetek nem kezdődnek külön oldalon. Tartalomjegyzéket is generáltam, preview-ben egész jól nézett ki böngészőben, de az is eléggé szét van csúszva.
A html-ben kell valamit szerkesztenem?
Ja, még egy bosszantó probléma: a hossú ő előtt mindig van egy space...

Köszi a segítséget!

Atyaman 2011.01.15. 21:26:15

@hcpeter1: Hasznos lenne ha picit részletesebb leírnád a folyamatot. Pl. milyen programokat használtál pdf-html konvertre, prc készítésre stb. Egyelőre feltételezem, hogy Mobipocket Creatort.

1-2 ötlet: Ha egy konverter készítette html-t a pdf-ből ott sok hiba előjöhet, esélyes hogy itt került be az ő-k elé a szóköz. Érdemes utána nekiesni a html-nek egy szövegszerkesztővel. De méginkább egy hagyományos szöveges fájlt kéne konvertálni (rtf, doc, docx) és azt gyúrni amíg jó nem lesz, majd menteni (szűrt) htm(l)-ként.

A fejezetek alapból nem kezdődnek új oldalon. Azt vagy szövegszerkesztőben állítod be: stílust választasz hozzájuk (Címsor 1,2,3,4...) és a stílusra vonatkozó beállításoknál kiválasztod, hogy előtte legyen oldaltörés. Vagy a html-nél megkeresed a stílus leírását és ott írod be/át ezt: "page-break-before:always;".

Ha tartalomjegyzék címei nagyon hosszúak, akkor kicsit kuszán tud kinézni a kindle-ön, hiszen csak nem akkora a felbontása, mint egy full hd monitornak.

NCX: először nézd meg az XSLT-vel készített ncx-et pl. egy jegyzettömben. Úgy néz-e ki ahogy ki kell neki. [Referencia: www.cjs-easy-as-pie.com/p/create-ncx-file-by-araby-greene.html ]. A fura az, hogy ha beépítetted az opf-be (pl. Dworkyll vbs scriptjével), akkor elvileg jónak kéne lennie, különben hibát dobna a prc összerakásánál.

gh14 2011.01.17. 17:53:12

Atyaman-hoz hasonoló a problémám (szintén Win 7 x64), de nekem miután átírtam a java elérési útját ez a hibaüzenet:
"A fájlnév, a könyvtárnév vagy a kötetcímke szintaxtisa nem megfelelő."

Ez mit jelent?

Karma17 2011.01.17. 20:06:44

Elképzelhető, hogy lefelejtetted az idézőjelet?

gh14 2011.01.17. 21:08:40

Valóban, aposztrófot ' tettem. Köszi.

xtraktor 2011.01.25. 20:53:27

Sziasztok.
Ha wordban (2003) megcsinálom a TOC-ot akkor elméletileg a MobipocketCreator is létre kellene hozza. Ez mégsem történik meg. Mi az oka ?

Atyaman 2011.01.25. 21:14:08

@xtraktor: egy kicsit bővebben írd már le, hogy milyen módon hozod létre a TOC-ot a wordben. Ennyi leírásból nehéz kiindulni.

xtraktor 2011.01.25. 21:18:55

insert/reference/index and tables/table of contents/OK
Így automatikusan létrejön a belinkelt tartalomjegyzék.
Mit kellene még tegyek, hogy a Mobipocket is felismerje ?

Atyaman 2011.01.25. 21:35:58

@xtraktor: hmmm... Ezt így konkrétan nem tudom, nem evvel szoktam létrehozni. Az a kérdés, hogy ez a TOC-ot a Heading-ekből (hun: Címsor) generálja-e.

Ha igen, akkor a mobipocketben importálás után bal oldalt kattints a Table of Contents-re, Add... A Tag name legyen h1, h2, h3... attól függően, hogy melyikekből akarsz TOC-ot generálni, majd nyomj az Update-re!

Ezek után még érdemes megnézni, hogy hogyan sikerült. A Publication Files-ban jelöld ki a TOC-ot és baloldalt felül kattints a Preview with Web Browserre!

xtraktor 2011.01.25. 21:54:30

@Atyaman: A Tagek elenevezése után simán létrejött a tartalomjegyzék (TOC).
Most csak az a baj, hogy megmaradt (ezen kívül, így már kettő is van) az eredeti wordos tartalomjegyzék is :)
Már csak az kell kiötöljem, azt hogyan pusztítsam el.

Atyaman 2011.01.25. 21:59:12

@xtraktor: Én a helyedben az eredeti dokumentumban törölném a TOC-ot majd menteném egy másik néven vagy máshová. A lényeg, hogy a heading formázások megmaradjanak az adott címszavakon (fejezet címeken). És az így TOC talanított dokumentummal etetném a Mobi Creatort.

xtraktor 2011.01.25. 22:01:57

@Atyaman: Kissé nyakatekert, de rájöttem:
1. Létrehozom a fent leírt módon wordban a TOC-ot
2. Miután ez megvan törlöm a teljes wordos tartalomjegyzéket
3. Elnevezem a Tageket a Mobipicketben(h1,h2,h3)
4. Kész a mű, ezúttal egyetlen tartalomjegyzékkel :)
Köszönöm a segítséget.

Atyaman 2011.01.25. 22:16:45

@xtraktor: Szívesen!

Amúgy a word nem a már heading stílusúra formázott részekből csinálja a TOC-ot? Mert ha igen, akkor felesleges létrehozni a wordben a TOC-ot imho.

xtraktor 2011.01.25. 22:21:06

@Atyaman: Teljesen igazad van :)
Csak el kellett volna neveznem a tageket (ezt nem tudtam eddig) és simán meglesz word formázás nélkül is.
Na, ennyivel is többet tudok.
Thx.

bns 2011.02.12. 00:20:15

OSX-en egyszerűbb:
- Forrásfájl Pagesben, megcsinálni a TOC-ot
- Pagesben e-pub export
- Calibre ebubból mobi, és van a Kindleben TOC
Mondjuk azt nem tudom, hogy az így készített fájl mennyire sallangmentes, de az egész folyamat nagyon egyszerű.

xtraktor 2011.02.13. 19:48:36

Sziasztok.
Megint kérdésem lenne:
Megoldható-e, hogy mobipockettel vagy calibreval készített prc, mobi anyag a borítóval nyíljon meg az olvasóban és ne tartalomjegyzékkel vagy a könyv elejével ?

szakértőbb 2011.02.13. 20:19:52

Egy nemhivatalos (=profiknak nem tetszo, de mukodo) megoldas: a dokumentumban/konyvben az elso oldalra teszed a borito kepet.

Pátyer 2011.02.25. 22:54:36

Sziasztok!

A segítségeteket kérem. Megpróbálkoztam a tartalomjegyzék hályogkovácsolásával, de a következő hibaüzenetet kaptam a képembe:

Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/xalan/xslt/Process
Caused by: java.lang.ClassNotFoundException: org.apache.xalan.xslt.Process
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Could not find the main class: org.apache.xalan.xslt.Process. Program will exit.

Ebből körülbelül az utolsó mondatot értettem. Áruljátok el legyetek szívesek, mit bénázhattam el.

Köszönöm!

Ignis_veneficus 2011.02.25. 23:52:56

@Pátyer: Elirtad a classpath-t.
A java hivas nem volt megfelelo, es nem talalta a xalan.jar-t.
a xalan.bat-ot a xalan konyvtarba kell rakni, es at kell oda hivni, vagy onnet inditani.
Le tudod irni, hogy hol, mi van es hogyan probalkoztal?
kosz

Pátyer 2011.02.26. 15:30:53

@Ignis_veneficus:
Amit elkövettem: C meghajtón egy "Egyebek" nevű könyvtárban hoztam létre a Xalan könyvtárat, ide tömörítettem ki a programot, a saját, xalan-j_2_7_1 nevű alkönyvtárába. Az alkönyvtár mellé pakoltam a xalan.bat-ot és a toc2ncx_localpath.xsl-t.
A c:\...\My Publications-ben, a konvertálandó könyv Mobipocket Creator által gyártott alkönyvtárába tettem a ncx_creator.bat-ot (meg eNeL scriptjét).
Az ncx_creator.bat-ot a következőre írtam át:
c:\Egyebek\Xalan\xalan.bat -IN mbp_toc.html -XSL c:\Egyebek\Xalan\toc2ncx_localpath.xsl -OUT toc.ncx
Máshoz nem nyúltam, parancssorból indítottam a ncx_creator-t, és akkor kaptam a hibaüzenetet.

Ignis_veneficus 2011.02.26. 21:18:41

@Pátyer: ott a hiba, hogy a xalan.bat-ot a xalan-j_2_7_1 nevu alkonyvtarba kell rakni a tobbi xalan cucc melle. (az XSL maradhat ahol van), igy az ncx_creator.bat-ban igy fog kinezni:
c:\Egyebek\Xalan\xalan-j_2_7_1\xalan.bat -IN mbp_toc.html -XSL c:\Egyebek\Xalan\toc2ncx_localpath.xsl -OUT toc.ncx

Pátyer 2011.02.26. 23:10:58

@Ignis_veneficus:
Hála, köszönet és kalaplengetés: működik!

xtraktor 2011.03.03. 21:11:48

Olyan problémába ütköztem, hogy nagyon gyakran az elkészült ncx fájl szóközök (vagy sortörés) helyett négyzeteket jelenít meg.
Tehát ha ncx nézetet választok a KindlePrevieweren vagy MobipocketReaderen hibásan jeleníti meg, viszont a tartalomjegyzék minden esetben jó.
A TOC hibátlan, ott jók a karakterek, viszont az ncx-ben már nem.
Találkozott valaki már ezzel ?
És mi lenne a megoldás ?

xtraktor 2011.03.03. 23:17:38

Belenéztem az ncx fájlba és ott a gond, hogy egy az egyben másolja a TOC-ot, így ahol <text>...</text> sortörés van ott az ncx nézetben mindenhol négyzet jelenik meg.
Nem lehetne egy olyan parancsot beleírni, hogy a szöveg mindehol egy sorban legyen az ncx-ben ?

kIára 2011.03.25. 13:16:15

A többi bejegyzéshez írt hozzászólásokban egy kis zavart éreztem az NCX–TOC kapcsán, úgy gondoltam, hogy nem ártana az ide tévedő laikusok, magáncélú otthoni ekönyvkészítők számára tisztázni néhány alapvető dolgot.

Szóval. Ha valaki bkp (book producer) vagy mrk (markup editor), és elkezd egy kész szövegből ekönyvet gyártani, akkor a következőt kell átgondolja:
        akárcsak a papírkönyvek esetén, mindig el kell dönteni, hogy mi a MŰ, mi a „könyv” és mi a PUBLIKÁCIÓ (kiadvány) része.

Miről van szó? Nagyon kevés kivételtől eltekintve a betűtípus, a tördelés, a szennyoldal, vagy maga a papír nem a „mű” része. Ezek az adott kiadvány részei, ha úgy tetszik „hordozzák” a művet.

TOC
A hagyományos tartalomjegyzék a mű egységeiről és azoknak a kiadványban található helyéről (általában oldalszám) ad információt. Lényeges mozzanat, hogy szinte mindig _a szerző írja_ a tartalomjegyzéket, és vagy egy absztrakt jelzésrendszert használ (pl. „Harmadik fejezet”) vagy a mű stílusában írt tömör összefoglalót, jelzésrendszert alkalmaz (pl. „Helyben vagyunk”, „A szanatóriumban feltűnés nélkül meghal a főhercegnő”, „A Pequod találkozik a Rózsabimbóval” stb.).
Tehát amikor az epubunkban vagy a mobinkban elkészítjük a toc.xhtml-t vagy tartalom.xhtml-t akkor ebbe _csakis a mű_ egységeit vehetjük fel.
A dolog például akkor lesz nehéz, ha a mű szerkesztője láb-/végjegyzetekkel segíti a megértést (pl. „Háború és béke”) és nem tudjuk eldönteni, hogy ilyenkor a jegyzetek.xhtml-re legyen hivatkozás toc.xhtml-ben vagy sem. Ugyanakkor az olyan jellegű művek esetén, mint pl. a Korongvilág-regények, a Jegyzetek a mű részei.
Még lehetne bonyolítani (szerzői lábjegyzet, szerkesztői végjegyzet, társzerzői széljegyzet egy műben), de itt abbahagyom. Még csak annyit, hogy ha a mű egy egységes szövegfolyam (pl. „Táncórák időseknek és haladóknak”), akkor azt tartalomjegyzékkel megerőszakolni barbárság (láttam már ilyet, azért írom).

A kiadvány persze nemcsak a műből áll. Van neki borítója, címlapja, impresszuma, kolofonja stb. és ezek segítségével lesz végül a _műből könyv_. Ezek, illetve a mű elemeinek sorrendjét az opf-ben a <spine> adja. Azonosításuk a <guide>-referenciákkal történik.

Tehát már elvileg elkészült a(z e)könyvünk is, amiből elektronikus publikáció lesz.
Ebből úgy lesz elektronikus kiadvány, ha minden további alkotóelemet (fontok, azok licencdíját, stílusokat, adott esetben grafikai elemeket) definiálunk, valamint elkészítjük a publikációhoz kapcsolódó összes metaadatot (alkotók, készítők, dátumok, azonosítók, stb).

És jön a kérdés: akkor most mi is az az ncx? Ez a kimondottan ekönyvekre jellemző XML elsősorban a kiadványunk struktúrájának gépi (és persze humán) feldolgozásában segít.
Véleményem szerint tartalmaznia kell a toc.elemeit (bár nem biztos, hogy annak minden elemét kell) és az opf <guide> elemeit is. Tehát a _mű_ és a _könyv_ egységeit egyaránt.
Valamint tartalmazHAT _egyéb strukturáló elemeket_, pontokat.
      Például a „Táncórák időseknek és haladóknak” esetén az ekönyv készítője (a bkp) úgy dönthet, hogy öt egyenlő hosszúságú egységre tagolja a művet, hogy ezzel a virtuális tartalomjegyzékkel segítsen a türelmetlen olvasóknak („most kb. itt tartasz”).
      Vagy másik példa: az e-könyv vagy e-kötet _szerkesztője_, szólhat a _gyártónak_, hogy a mű bizonyos, a szerző által nem jelölt gondolati egységeit jelölje és strukturálja.
      Olyat is megtehetünk, hogy egy vegyes műfajú könyvben az epikus részt megszakító lírai betéteket kigyűjtjük.

Tehát: Mű—struktúra –» Könyv—struktúra –» Publikáció—struktúra

Ezzel csak azt akartam elmondani, hogy az ncx-nek nem az az elsődleges célja hogy „bigyókat szórjunk el a progressbaron”

szakértőbb 2011.03.25. 14:21:31

Kedves KIára!

Érdeklődéssel és nagy figyelemmel olvastam tisztázó soraidat. Be kell valljam, többször is nekifutottam, mire felfogtam:-(

Pár megjegyzés:

1. miert ne lenne resze a tartalomjegyzeknek a műhöz fűzött jegyzetek?
2. >Véleményem szerint tartalmaznia kell a toc.elemeit (bár >nem biztos, hogy annak minden elemét kell) és az opf ><guide> elemeit is.

Mi a szerepe itt a "velemenyem szerint" kitetelnek? Te most itt a TOX.NCX file-rol beszelsz, vagy az NCX tartalomjegyzekrol?

3. >a virtuális tartalomjegyzékkel segítsen a türelmetlen >olvasóknak („most kb. itt tartasz”).

ezt komolytalannak talalom. A turelmetlen olvaso az oldalszambol vagy a Locations-bol is lathatja, hol tart, nem? Vagy mi az a virtualis tartalomjegyzek?

4. >Ezzel csak azt akartam elmondani, hogy az ncx-nek nem az >az elsődleges célja hogy „bigyókat szórjunk el a >progressbaron”

az elozovel (ui: turelmetlen olvaso segitse) nem eppen ezt mondtad? vagyis ugy segitesuk, hogy bigyokat szorunk oda?

Elnezest az ertetlenkedesemert!

kIára 2011.03.25. 21:35:40

@szakértőbb:
Elismerem, kissé kapkodva írtam, elnézést ha néhol zavaros a mondanivalóm.

          »1. miert ne lenne resze a tartalomjegyzeknek a műhöz fűzött jegyzetek?«
Az elején írtam, hogy az ekönyv legyártójának folyamatosan döntenie kell. Mérlegelni.
Ha a „Háború és béke” példájánál maradunk, akkor az abban található jegyzetek célja a mű értelmezésének elősegítése. Ezt valaki írta, jóval a mű keletkezése után. Korábbi, vagy későbbi kiadásokból ez teljesen kimaradhat, illetve a más nyelvekre fordított verziókban teljesen más jegyzetek is lehetnek (gondoljunk a francia kiadásra).
Tehát dönteni kell. Én az ilyen esetek kapcsán hajlok arra, hogy az ilyen típusú jegyzetek nem a mű, hanem a könyv részei.
Pratchett műveinek esetében a jegyzetek egyértelműen a mű részei, de kérdés, hogy a néhány fordítói-szerkesztői jegyzet már az-e. Én pl. a szerkesztői magyarázó jegyzeteket teljesen másképpen szedném és jelölném.
Persze ezt lehet vitatni.

          »2. Mi a szerepe itt a "velemenyem szerint" kitetelnek? Te most itt a TOX.NCX file-rol beszelsz, vagy az NCX tartalomjegyzekrol?«
Az NCX fájlról beszélek, amit sok esetben a mű tartalomjegyzékéből generálnak (ami lehet a toc.xhtm vagy tartalom.htm fájl, vagy bármi más).
Véleményem szerint _bizonyos könyvek kapcsán_ az NCX-nek nem kell hűségesen követni, lemásolni a mű tartalomjegyzékét, különösen akkor, ha annak nagyon sok szintje van (Rész -> Fejezet -> Alfejezet -> al alfejezet -> al al al… alfejezet stb.). Ezek fontos gondolati, tartalmi egységek a _műben_, de a _publikáció struktúrájához_ nem adnak lényegi többletet, sőt feleslegesen terhelik azt.
Ennek az egyik következménye, hogy az NCX tartalmazhatja (sőt szinte mindig tartalmazza is) a mű tartalomjegyzékét.

          »3. ezt komolytalannak talalom. A turelmetlen olvaso az oldalszambol vagy a Locations-bol is lathatja, hol tart, nem? Vagy mi az a virtualis tartalomjegyzek?«
Igaz. Én sem tartom nagyon fontosnak. Kicsit olyan mint a pusztavarcsi „Magyarország földrajzi középpontja”. Egyszerűen csak megkeresem a szöveg középpontját (negyedét, harmadát stb.) és ezt jelölöm. Persze a locations-ból is tudhatom ezt, vagy ha volt papírváltozat, akkor az oldalszámok is közelítő értéket adnak. Van aki számára ez fontos; egyáltalán nem kötelező, egyszerűen egy _döntési lehetőség_. Nagy terjedelmű művek esetén általában darabolni is szokták a szöveget, ha ezt arányosan tesszük, miért ne jelöljük?
A „virtuális tartalomjegyzék” persze más is lehet. Pl. Esterházy műveiben készíthetek a vendégszövegek helyéről egyet, és azokat felveszem az NCX-be. Vagy egy más könyvről készítek egy hálózati elemzést, és azok csomópontját jelölöm. Vagy egy önéletrajzi ihletésű fikciós műről készíthetek egy fikciós NCX-sort és egy biografikus NCX-sort. Sorolhatnék még példákat, hogy az NCX hogyan épülhet fel, a lényeg, hogy a kiadványokban rejlő struktúrák száma akár végtelen is lehet, míg a mű tartalomjegyzéke csak egy lehet vagy 0.

          »4. az elozovel (ui: turelmetlen olvaso segitse) nem eppen ezt mondtad? vagyis ugy segitesuk, hogy bigyokat szorunk oda?«
Ezt egy kissé poénnak szántam. Ez csak egy lehetőség, ami ebben a blogban mintha céllá változott volna. Ha jól olvastam a bejegyzésekhez írt hozzászólásokat, néha erre ment ki a játék („már tudok pontokat elhelyezni a progressbar-on”). Csakhogy nem egy kütyü vagy szoftver/parser létezik, illetve minden publikáció más és más, és úgy éreztem, hogy ha nem tudatosítjuk ezeket, akkor a Kindle-dominancia miatt elsikkadhatnak az NCX-ben rejlő egyéb lehetőségek.

szakértőbb 2011.03.25. 22:00:29

@kIára:
Koszonom a felvilagositast, majd reagalok. Most csak egyetlen megjegyzes: az NCX azert lehet "alap", mert az Amazon ezt irja elo az ott publikalt konyveknel.

A tobbirol kesobb.
Es koszonom a valaszt!

kIára 2011.03.26. 00:20:45

@szakértőbb:
       »az NCX azert lehet "alap", mert az Amazon ezt irja elo az ott publikalt konyveknel«
Na itt lesz igazán érdekes.
Ugye az IDPF (International Digital Publishing Forum) ajánlást tett ill. kialakította az OEB nyílt ekönyv struktúrát, majd a még szabadabb OPS nyílt publikációs struktúrát majd az OPF csomagformátumot és OCF konténerformátumot. Ezeknek többé-kevésbé meg is felel az epub és a mobi ekönyv-formátum. Amik aztán szépen beemelték és/vagy támogatni kezdték az NCX-et ami a DTB-hez készült (és eredetileg vakok és gyengénlátók számára kialakított navigációs kontroll-fájl) és egy teljesen más konzorcium, a Daisy tart fenn és adja az ajánlást.

Követhető, igaz? :D

Erre jönnek a hatalmas szoftver- és kereskedőóriások (Adobe, Amazon és társai) meglehetősen önkényesen figyelmen kívül hagynak valamit az ajánlásokból, vagy hozzátesznek valami hasznosat és/vagy indokolatlant, majd a piaci fölénnyel visszaélve a szabványt szabállyá merevítik. „Így megy ez” a digitális korszak vágóhídjain.

szakértőbb 2011.03.26. 07:37:49

@kIára:
EZt tudtam kovetni:-)
ENn csak kvazi indokoltam miert forditanak egyesek figyelmet az NCX-re:-) Engem a felsorolt (ien izgalmasnak latszo) dolgok hidegen hagynak, van mas eleg szeles e vilagon:-)
AZ Amazon pedig azt ir elo a sajat konyveire, amit csak akar, ha zavar, majd nem foglalkozom vele. Amig nem zavar, addig meg akar be is tarthatom. Valljuk be, a nem-amerikaiak hatranyos megkulonboztetese sokkal jobban zavar (mondjuk a 30-70%).

megvakarom 2011.03.26. 13:30:02

@kIára: nekem most tisztult a kép, köszönöm!
tehát pl. a kolofont beteszem az nxc-be, mint könyvészetileg érdekes helyét a kiadványnak, de nem teszem bele a tartalom.xhtml-be, hiszen a nyomtatott könyvek tartalomjegyzékében sem szokás ezt jelölni.
Jól sejtem?

kIára 2011.03.26. 14:00:07

@megvakarom:
Pontosan.

Ha nagyon pontos akarok lenni, akkor a kolofon _mindig_ bekerül a <guide>-ba:
<reference type="colophon" title="Kolofon" href="Text/kolofon.xhtml"/>

és érdemes és hasznos beletenni az NCX-be is (nem kötelező).

kIára 2011.03.26. 15:50:14

Nade egy kép többet mond ezer szónál.
Ncx lehetőségek, és azok hogyan jelennek (ADE, Kindle, stb.):

img809.imageshack.us/img809/605/ncxlehetosegek.png

Ignis_veneficus 2011.03.26. 20:15:26

@kIára: Ez mind szep es jo, csak ket megjegyzes (kindle iranybol)

1, a Kindle jelenlegi parsere nagy ivben tesz a NCX-ra (kiveve a sokat emlegetett bogyozast, de azt is csak az elso szinten)
2, ezenkivul ha jol tudom akkor az ADE-t is hidegen hagyja a guide, es a kindle is csak 2-3 elemet hasznal belole (cover, toc, text)

A fentiekbol kovetkezik, hogy az ember megprobal mindent belerakni, mind a toc-ba, mind az ncx-be.

kIára 2011.03.26. 20:51:47

@Ignis_veneficus:
Én csak tisztázni akartam a különbséget.

1. _jelenlegi_ (és például csak emiatt az első szintre hozni mindent: badarság).
2. Emiatt nem elkészíteni rendesen a Guide-ot szerintem hanyagság, a saját munkánk semmibevétele, balkáni leszaromozás. Már elnézést. Így készülnek az e-bookok Daciái is. Úgy néz ki mintha, csak éppen kihagytak belőle ezt-azt.

»A fentiekbol kovetkezik, hogy az ember megprobal mindent belerakni, mind a toc-ba, mind az ncx-be.«
Ez meg hiba. Hogyhogy mindent berakni a toc-ba?? Azt is ami nem oda való?

kIára 2011.03.26. 20:58:27

Amúgy már rég szólni akartam, csak mindig elfelejtem. Bár lehet hogy tudod.

Az OOo új forkja a LibreOffice beemelte a gyönyörűszép Open Document Text mentést, és többé már nem kell belemászni az odt-kbe.
Érdemes váltani már csak emiatt is.

szakértőbb 2011.03.26. 21:03:33

@kIára:
Kicsit maskepp latom. Ha keszitek egy e-book-ot a Kindle3-ra, akkor a jelenlegi tudasat probalom kihasznalni. Megtehetnem, hogy beleteszek olyasmiket, amik kesobb jol jonnnek, DE: azt akar mindenki megteheti sajat maganak, masreszt eleg sok feleslegesnek latszo (?) munka lenne. Tovabba a kulonfele parserek miatt ugy lenne celszeru, ha mindenen "menne" ugyebar tokeletesen az adott formatumu konyv. Ez jelenleg szerintem tul nagy es felesleges energia befektetesnek tunik (szamomra).
Mindezzel nem mondtam, hogy szandekosan sz@rul csinalom a Guide-ot, de azt sem, hogy maximalista lennek. Nekem eppenseggel a txt is jo lenne, mert olvasas kozben nem azt nezegetem, hogy az elso sor jol van-e behuzva, vagy a sorkoz 6 vagy 7 pont.

Tetszett a belinkelt kep, de olyan szintu dolgokat meg magamnak se csinalnek (10,20,30% a konyvben - mar mondtam, hogy nevetseges; ki hol mikor halt meg benne es hasonlok - ezt meg jegyzetelje ki, akit erdekel, de mit keres az NCX-ben? stb.) Tehat ezek kreativ felhasznalasnak elmennek, de azert mastol meg ne vard el:-)

kIára 2011.03.26. 21:41:09

@szakértőbb:
     »azt akar mindenki megteheti sajat maganak, masreszt eleg sok feleslegesnek latszo (?) munka lenne. […] Ez jelenleg szerintem tul nagy es felesleges energia befektetesnek tunik«
Külön kell választani a saját, magáncélú, egyszeri felhasználásra készült ekönyvkészítést a kiadói, vagy hosszú távú célból készült publikálástól. Ha egy kiadónak dolgozom, fájhat a fejem rendesen, ha mondjuk száz könyvet már legyártottam és a hanyagságom miatt újból neki kell állnom az összesnek. Dworkyll egyszer írt is egy hasonló problémáról amibe belefutott és szívott is rendesen. (Amúgy a fenti mintát kb. 15 perc alatt készítettem el, úgyhogy annyira nem nagy munka).
     »Nekem eppenseggel a txt is jo lenne, mert olvasas kozben nem azt nezegetem, hogy az elso sor jol van-e behuzva, vagy a sorkoz 6 vagy 7 pont.«
Ezzel ugyanígy vagyok, a netről egyszeri olvasásra letöltött könyvekkel én sem szöszölök.
     »Tetszett a belinkelt kep […] Tehat ezek kreativ felhasznalasnak elmennek, de azert mastol meg ne vard el:-)«
Köszi. A példámat szándékosan vicceltem el, hogy érzékeltessem az ncx—toc különbséget. Ilyesfajta igényességet, vagy alaposságot csak a kereskedelmi forgalomban található ekönyvektől várok el.

szakértőbb 2011.03.26. 21:53:22

@kIára:
Ezt a halalozasok, versreszletek, helyszinek az ncx-ben dolgot? En pedig ezt elkepzelhetetlennek tartom. Ehhez olyan szinten kell(ene) minden konyvet ismerni, ami nem hogy az 500 Ft-os, de 5000 Ft-is konyvarba sem ferne bele. Te lattal mar ilyen konyvet egyebkent? Es mennyi ido alatt "dolgozol fel" ilyen szinten egy konyvet?

kIára 2011.03.26. 22:18:07

@szakértőbb:
Ja neem :) Csak magát az ncx-et. Ha létező könyről lenne szó, akkor az ilyen típusú feldolgozás 3-4 szakértő feladata lenne egy évnél hosszabb időtartamra :D

Amúgy igen. Láttam ilyet. Kritikai kiadásnak hívják. Akár tizenöt évig is eltarthat egy életmű (hiányos) feldolgozása.

Ismétlem: a példán csak ábrázolni akartam az ncx-ben rejlő lehetőséget, ami túlmutat a toc-on.

xtraktor 2011.03.30. 20:52:41

Sziasztok.
Egy olyan kérdésem/kérésem lenne, hogy van-e rá mód úgy átalakítani az ncx generátort, hogy az mbp_toc.html leképzése elé belefűzze a címlapot és a tartalomjegyzéket, így a könyv borítójához és tartalmához is lehetne ugrálni, nemcsak a fejezetekhez.
Talán Ignis_veneficus tudna rá válaszolni, de bárkinek az ötletét/szkripjét szívesen látnám :)

Ignis_veneficus 2011.03.30. 22:32:43

@xtraktor: a kerdes, hogy a borito es a toc fix neven fut-e vagy valahonet ki kellene olvasni?

xtraktor 2011.03.31. 06:48:00

@Ignis_veneficus: Mivel én általában MPC-t használok, az készít egy saját mappát ahova beteszi az összes prc-hez szükséges alkotóelemet:
1.html (maga a könyv)
2.opf (a készítési recept) - itt van megadva a sorrend, hogy borítót és TOC-ot is fűzzön bele (ncx-et az injektorral fűzöm a végére)
3.mbp_toc.html (ebből készül az ncx)
4.borítókép
5.build parameters xml-ben (mappában)
6.a már elkészített prc fájl

Ignis_veneficus 2011.03.31. 09:28:02

@xtraktor: A toc fix nevu, de a borito is? az XLT csak egy xml-bol tud dolgozni (jelenleg a toc), ami nincs benne azt ki kell "talalni" es nem tudja a vinyorol felolvasni. Tehat vagy fix nevu (pl "cover.png" vagy a megadott adatokbol kitalalhato
Amugy kindle eseten nincs ra szukseg, mert mindkettot el lehet erni, menubol, es a bogyok is feleslegesek neki

xtraktor 2011.03.31. 18:48:26

@Ignis_veneficus: Köszönöm a választ.
Sajnos tényleg nehéz így megoldani, mivel minden borítónak más a neve és persze nem volna elég egyetlen fájlt (toc_mbp.html) elemezni, hanem a többit is kellene.
Így tényleg nehezen kivitelezhetőnek tűnik :(
Talán az egyetlen járható út az lenne, hogy a könyv.html-ből legyen elkészítve az opf, toc, ncx - egyszerre.
Viszont valóban nem olyan fontos, hisz elérhető a menüből is, csak jobb ötletnek tűnt, ha menübe lépés nélkül is oda tudok ugrálni :)

szakértőbb 2011.03.31. 19:04:58

@xtraktor: ne viccelj mar, a boritokat nevezheted mindig cover.jpg-nek es ennyi.

szakértőbb 2011.03.31. 19:07:05

@Ignis_veneficus:
>Amugy kindle eseten nincs ra szukseg, mert mindkettot el lehet >erni, menubol, es a bogyok is feleslegesek neki

elnezest, nem ertem. Mit lehet elerni menubol? Milyen bogyok feleslegesek?

Ignis_veneficus 2011.03.31. 21:06:17

@szakértőbb: Mind a boritot, mind a TOC-ot el lehet erni a kindle menubol a "go to.." ponttal. Van neki ket gomb: Cover es TOC.
(Igaz, rendes guide kell hozza az opf-ben)
Es ugy erzem a lenti statuszsorban nincs szukseg a jelolesre sem a cover sem a toc eseten.

szakértőbb 2011.03.31. 21:45:59

@Ignis_veneficus:
Ja, mar kezdem kapisgalni:-)
De a toc.ncx-nek a cover is es a toc is resze, fuggetlenul attol, mit gondolunk rola:-) Ha jol emlekszem, az Amazon igy keri/varja a konyveket.
Ha ezt igy nezzuk, hogy "szerintem nem fontos", akkor nem nagoyn kene foglalkoznunk a konyvek szerkesztgetesevel, mert szerintem nem fontos a sortavolsagokat meg a behuzasokat maceralni:-) A tobbi felesleges dologrol nem is szolva..
De szerintem felreertelek.

xtraktor 2011.03.31. 22:33:53

Újabb kérdés:
Guide-al be tudom állítani, hogy a könyv elejétől, tartalomjegyzéktől vagy bármilyen más helyről nyíljon meg, kivétel a borító ...
Ezt hogyan tudnám megoldani ?
Persze betehetném előre a borítót a html-be, de akkor vagy két borító lesz könyvben vagy nem lesz a goto-ban cover (ha nem teszek külön covert).

Ignis_veneficus 2011.03.31. 23:27:38

@szakértőbb: Szoval.
Az amazon keri a TOC-ot es keri a covert.
A covert a OPF-be kell rakni. (van is neki hely a meta-k kozott)
Tudomasom szerint nem keri a ncx-ben sem a toc-ot, sem a covert (legalabis a kindlegen nem akad ki rajta pedig az eleg valogatos ezen a teren: kepes a kicsi cimlapert is rinyalni)
Ezenkivul van harom parhuzamos tartalomjegyzek feleseg, amit eleg erdekesen kezel a Kindle:
- opf/guide -> csak dedikalt elemet hasznal fel belole (begin, toc)
- ncx -> csak a bogyozasra hasznalja + jobb, bal gombokra.
- toc -> ezt adja a usernek mint tartalomjegyzek.
a borito egyikben sincs benne.
A kerdes, hogy a boritonak kell bogyo? szerintem nem.
Masik kerdes, a TOC-nak kell bogyo? lehet, hogy nem artana, igy a user tudja mikor er veget az utolso fejezet.

xtraktor 2011.04.05. 21:24:04

@Ignis_veneficus:
Szia.
Ha már gondolkodol a TOC bogyózásán, nem tudnád átírni úgy, hogy az is bekerüljön az ncx-be ?
Köszi :bow:

szakértőbb 2011.04.05. 22:06:24

@Ignis_veneficus:
Szia!

>opf/guide -> csak dedikalt elemet hasznal fel belole (begin, toc)
azt hiszem, ez teves. Mintha lattam volna olyat, hogy a Menu gombra 2 sornyi gom jelenik meg alul a menuben. Majd kiprobalom.

>A kerdes, hogy a boritonak kell bogyo? szerintem nem.

szerintem sem.

>Masik kerdes, a TOC-nak kell bogyo? lehet, hogy nem artana, >igy a user tudja mikor er veget az utolso fejezet.

Tartalomjegyzek kell az NCX-be. :-)

Ignis_veneficus 2011.04.05. 22:21:59

@xtraktor: @szakértőbb: Toc az NCX-ben: most frissitettem a postot, ott a vegen a megoldas

2 sornyi gombsor:
Az uj firmware tudja, de a kov cimkekkel:
TOC: a regi toc (guide->toc)
Beginning: ami eddig volt (guide->begin)
Page: a lapszamozassal van osszefuggesben
Cover: borito
End: az utolso oldal vege
Location: ami eddig volt

xtraktor 2011.04.06. 09:35:56

@Ignis_veneficus:
Csak én nem látom a frissítést ?
Update#1 csak az egyszintű ncx van, mely betűről-betűre azonos a korábbi hozzászólásban találhatóval.

Ignis_veneficus 2011.04.06. 10:28:09

@xtraktor: Akkor a net lenyelte a frissitest.. :(
este bepotlom

xtraktor 2011.04.09. 08:36:00

@Ignis_veneficus: Szia! Még mindig szívesen kipróbálnám, a bővített verziót ncx verziót is :)

Dragon Z. · http://www.dragonweb.hu 2011.04.10. 15:23:42

Sziasztok, egy újabb ncx-es kérdés:

Az Amazon kiadta az új kindlegen-t (1.2), ami már be tudja tenni az oldalszámokat is (amit ugye az új Kindle szoftver már kezel). Ehhez azonban a Guide (s3.amazonaws.com/kindlegen/AmazonKindlePublishingGuidelines.pdf) szerint vagy pageList kell ncx-ben, vagy page-map xml-ben. Tudtok arra módot, hogy a toc-megoldáshoz hasonlóan ilyesmi elkészíthető legyen? Elnézést, ha ez off-topic, csak mivel erről még nem volt szó, így jobb híján ide pötyögtem be.

Atyaman 2011.04.10. 16:18:07

@Dragon Z.: A fenti link nekem nem működött. Itt sikerült elérnem a doksit:
kindlegen.s3.amazonaws.com/AmazonKindlePublishingGuidelines.pdf

Leginkább a page-map.xml-es megoldás tetszik. Furcsa lenne az oldalszámokat is bepaszírozni a toc.ncx-be, a könyv melletti .apnx fájl (amit ott alkalmaznak, ahol nem akarták az egész könyvet újra konvertálni) pedig felesleges hiba lehetőség, ha már egyszer be is lehet építeni a publikációba az oldalszámokat.

Ha jól veszem le a leírásból, akkor magába a szöveg kódjába kell elhelyezni az oldalszámok azonosítóit. Ezt max. akkor tudod automatizálni, ha megvan az eredeti könyv scanje benne az oldalszámokkal a pontos helyükön (gyakorlatilag ocr-ezett foto/scan). És nem az ilyen formátumú könyvek vannak túlsúlyban a neten. Másik lehetőség ha megvan a fizikai példánya a könyvnek, akkor még neki lehet állni kézzel bevinni az oldaszámokat, de az meg szerintem időben nem éri meg (és akkor még finoman fogalmaztam).

Remélem az okosoknak több és jobb ötletük lesz :-S

szakértőbb 2011.04.10. 18:43:25

@Atyaman: A multkor nem abba maradtunk, hogy nem gond, rabszolgak megcsinaljak? : -DDD

Atyaman 2011.04.11. 08:46:16

@szakértőbb: Nem teljesen. Ráadásul ott az Amazon megoldásáról volt szó (legalábbis mikor a rabszolgákat felhoztad). Itt pedig a polgári megoldás volt a kérdés. A pontosság kedvéért:

szakértőbb:
>>En csupan ezert firtattam, mi lehet a megoldas, hogyan csinaljak ezt az Amazonok?!<<

Atyaman:
>>Most megint foglaljam össze, hogy mire jutottunk? Rendben van:
Szerintem az Amazonnak végig kell mennie a könyveken kézzel és úgy készítik. Ez alól egy kivétel lehet, ha a kiadótól megkapják a könyvet valami olyan formátumban amiben a nyomdába küldenék, azaz amiben már megvannak az oldaltörések és az oldalszámozás, erre már lehet írni valami algoritmust. Talán újra scannelik a könyveket, és abból ollózzák ki algoritmussal. Bármelyik verzió elképzelhető, sok okos ember dolgozik ott.<<

Szóba kerültek a polgári automatizált megoldások is. A Calibre (ami a 7.45-ös verziótól már támogatja az apnx generálást) és goaspy apnx generátora, előbbi maga számolja ki algoritmussal, hogy hány oldalas legyen a könyv, utóbbiban te adhatod meg mennyit szeretnél. Ezek hátránya ugye, hogy a fizikai könyvekkel nem megegyező oldalszámozást tesznek lehetővé. De azt legalább gyorsan :)

szakértőbb 2011.04.11. 09:00:30

@Atyaman:
Jaj, ne kezdjuk ezt a vitat ujra, nem latod a rohogos smiley-t?

Leirod feljebb, hogy nincs jo megoldas, aztan sorolod a konnyu es sz@r megoldasokat. Vicces.

Ja, az okosok tobb es jobb olete: el lehet felejteni a papirkonyvek papir szamozasat/oldalszamat Kindle-n. Ennyire egyszeru.

Atyaman 2011.04.11. 09:09:50

@szakértőbb:
>>Jaj, ne kezdjuk ezt a vitat ujra<<

Na ebben az egy dologban egyetértünk ;)

Dragon Z. · http://www.dragonweb.hu 2011.04.16. 10:06:56

@szakértőbb: igen, én is elfelejteném nagyon szívesen, és legtöbb esetben az égadta egy világon semmi értelme nincs, viszont pl. tudományos szövegek esetén a hivatkozást megkönnyíti. Nem azt mondom, hogy ne lehetne végre áttérni vmi más hivatkozási rendre (vagy netán megszokni, hogy pl. a Kindle kereső funkciójával gyönyörűen visszakövethető bármilyen idézet), de ez a szektor sajnos nagyon lassan mozdul új megoldások irányába. Szóval ilyen esetben jól jöhet az oldalszámosdi. Szerintem.

szakértőbb 2011.04.16. 10:26:52

@Dragon Z.:
AZ az oldalszamosdi nem! A tudomanyos szovegek a valodi oldalszamot kovetelik meg, nem az ilyen kamu ("jo lesz nektek ez a sz@r is") tipusut. Tehat vagy hasznalod a valodi oldalszamot, vagy akar a Locations-t is hasznalhatod. Vagy megoldjak, hogy a tenyleges oldalszamot mutassa a Kindle...

Dragon Z. · http://www.dragonweb.hu 2011.04.16. 10:30:44

@szakértőbb: persze, persze, bocs, én azonnal arra gondoltam, hogy egy eleve e-könyvként kiadott könyv esetén lehet ez is egyfajta megoldás (egyébként én is inkább Loc. vagy egyszerűen a webes forrásoknál használt módszert favorizálnám - fogom is, szerintem, valakinek el kell kezdenie...!). Egyébként persze, hogy nem, nem és nem! Ebben tökéletesen egyetértek! :D

megvakarom 2011.10.02. 08:10:59

Én is találtam egy megoldást a toc.html és toc.ncx együttes meglétére.
Atlantis szövegszerkesztőben elkészül a szöveg, h1 stb. a címeknek, tompa bekezdés, kurziválás (ha netán eltűnt volna vmi miatt) innen lehet epub exportot csinálni. Ez az epub tartalmazza a toc mindkét formáját magától, ADE és FBreader szépen viszi. De ha kitömörítem, content.opf kindlegen, akkor csak az ncx marad meg. Tehát az epubot Sigilben kinyitom, és ott is elkészítem a tartalomjegyzéket, mert valamiért a címek h1 tagját újra fel kell venni, de egyszerre lehet cserélni minden html-alkatrészben. Save, kitömörítés.
A friss content.opf be be kell szúrni ezt:
<guide> <reference type="toc" title="Table of Contents" href="toc.html"/> </guide>
(az Amazon-féle publishing guideline-ből vettem)
A toc.ncx magától is működik.
És kindlegen, és mehet.
És ebben a folyamatban születik epub és prc is, eddigi kevés tesztem szerint jól. Igaz, néhány szoftverben meg kell fordulnunk, de talán civilbarátabb, mint a scriptek.
Ádám

SaGa 2011.10.03. 09:53:56

@megvakarom: Az Atlantis-ban készítesz egy tartalomjegyzéket (Insert TOC). Vigyázat, a kötet elejére kell, mert a program csak az adott pont utáni fejezeteket veszi fel.
Elmozgatod a kötet végére (vagy ott hagyod az elején, ahogy jólesik). A kiexportált epub-ot betolod a Sigilbe és ott beállítod, arra a html-re, amiben a tartalomjegyzéked van, a Table of Contents címkét, majd ismét kimented az epubot. Nem kell a Sigilben toc-ot készíteni külön.

Ez után érdemes még a következő lépéseket megcsinálni:
kicsomagolod (könyvtárakkal együtt) az epubot, a content.opf-ből és a styles.css-ből törlöd a fontokra vonatkozó bejegyzéseket, stílusokat, és a content.opf-et betolod a kindlegen-be (vagy akár a mobipocket creatorba).

Megjegyezném: a Sigil sajnálatos módon az italic (dőlt) szövegekhez külön "sgc-x" stílust készít minden htm-lbe külön, ami feleslegesen bonyolítja az epubot és az ebből faragott prc-t is, így én az Atlantis és a Sigil közé még be szoktam illeszteni egy kibontást és editálást, amikoris az összes <i> </i> tag-et kicserélem <em> </em>-re. Ezt nem rontja el a Sigil.
Eközben az Atlantis által elrontott, bármiféle formázást (dőlt, vastag, egyéb speciális formátum) hordozüó őű betűket és gondolatjeleket is rendbe teszem.

megvakarom 2011.10.03. 10:43:27

@SaGa: köszönöm, megszívlelem. Mint friss Kindle-tulaj, lesz alkalmam gyakorolni, míg a rengeteg epubot a telefonról átfordítom
süti beállítások módosítása