Risposte nei forum create
-
AutoreRisposte
-
::
I documenti SVG possono essere inclusi in un EPUB gia’ dalla v2.0 dello standard. In particolare, essi possono essere “spine level content documents” (ossia costituire gli elementi dell’ordine lineare di lettura della pubblicazione, generalmente capitoli, come avviene piu’ comunemente per i file XHTML) oppure inclusi come isole (e.g., immagini) dentro i file XHTML.
Il problema con SVG, comune ad altri aspetti “avanzati” della specifica EPUB, e’ che non tutti i reading systems ne supportano il rendering, specialmente le app/device piu’ datati, ad esempio quelli che si appoggiano ad Adobe RMSDK (in pratica, qualunque cosa supporti Adobe DRM). Ma questa e’ una limitazione dei sistemi di lettura, non del formato in se’.Sottolineo qui un aspetto forse poco noto di EPUB: la specifica prevede la possibilita’ di includere dentro al medesimo “contenitore fisico” (ossia il contenitore ZIP che costituisce un file EPUB) varie presentazioni del medesimo documento. Ad esempio, piu’ file PDF a varie dimensioni di pagina logica e in parallelo avere la piu’ comune versione “liquida” basata su XHTML. In questo modo, il reading system e/o l’utente finale possono scegliere la versione “piu’ adatta” e.g. alle dimensioni dello schermo o al fatto che si sta usando uno screen reader per fruire la pubblicazione. Di nuovo, probabilmente nessuno di voi ha mai visto queste cose, perche’ i sistemi di lettura non li supportano (ancora).
Mi pare significativo che al momento vari editori scientifici come Elsevier o Wiley e grandi aziende come IBM stiano investendo pesantemente su EPUB (3), sia come formato di trasporto sia come formato di output finale. E cio’ mi pare ragionevole: e’ proprio su testi complessi (manuali tecnici, articoli scientifici, ecc.) che la possibilita’ di manipolazione indotta dall’utilizzo di tecnologie (derivate dal) Web si manifesta meglio, con funzioni come la filtrabilita’ semantica dei contenuti, la visualizzazione di dati grezzi, dizionari e indici integrati nella pubblicazione, ecc.
Giusto per chiarezza: io non sono certo un fan di EPUB di per se’; anzi, ho spesso criticato pubblicamente sia la specifica stessa sia il modus operandi di IDPF e dei suoi membri.
Puo’ essere che in futuro prendera’ piede un formato per ebook piu’ simile a EPUB-Zero/E0/HPub/Baker oppure HTML5-OWA/HTML5-AppCache che non EPUB (3), ma il nocciolo della questione rimarra’ il medesimo: se voglio avere un unico file fisico per documento, che sia decentemente godibile su qualsiasi schermo dallo smartphone al phablet al tablet al PC, devo avere almeno una delle due:
1. piu’ versioni pre-rendered dentro il medesimo contenitore fisico
2. un formato “impaginabile” al volo dal reading system a seconda delle dimensioni del viewport utenteInfine, concordo pienamente sul fatto che gli attuali sistemi di produzione di EPUB, specie da *TeX, siano a dir poco rudimentali se prendiamo un input mediamente complesso.
::
Credo anch’io che il tema *TeX => Web/XML sia importante, anche se non necessariamente fondamentale per la sopravvivenza/rilevanza di TeX & friends, e che esso meriterebbe un po’ piu’ di indagine e sforzi, vista la pervasivita’ e le possibilita’ offerte dall’Open Web Platform.Al di la’ delle questioni “filosofiche” (e.g., “che cosa e’ un libro? Il suo contenuto (= un modo di “impacchettare” dati)? O contenuto+manifestazione (e.g., la sua tipografia)? L’utente deve/puo’ essere in grado di modificarne l’aspetto e/o i contenuti?” ecc.), dal punto di vista tecnico e pratico due sono i grandi problemi degli ebook attuali:
1. i sistemi di lettura con la loro mancanza di coerenza e funzioni realmente utili; e
2. i sistemi di authoring, che generalmente non agevolano gli autori a produrre un buon markup, focalizzandosi troppo sull’aspetto presentazionale (“word processing junkies”, ricordate la citazione?)Personalmente credo che se esistesse un buon strumento per esportare un sorgente *TeX in X(HT)ML sufficientemente espressivo (= supporto di macro e pacchetti comuni), allora avremmo una parziale copertura del punto 2, almeno per gli ambiti tecnici dove *TeX e’ gia’ diffuso. Potenzialmente potrebbe addirittura “colonizzare” nuove nicchie, specie se vi fossero sviluppi dal lato “interfacce utente”.
Come dicevo prima, latexml mi pare stia andando nella giusta direzione ed essendo attivamente sviluppato dal NIST, ha buone chances: v. http://latexml.mathweb.org/editor (esempi in basso a sinistra)
=== === ===
BTW, grazie per l’invito a inviare un contributo sul tema.
Ho svariato materiale da parte e ci pensero’ seriamente, anche se non sono certo di essere in Italia ad ottobre. (Purtroppo ReadBeyond ha chiuso i battenti, e io sono in giro per l’Europa a fare colloquii…)
::
Dai miei test, non produce risultati particolarmente impressionanti.In realta’ il nocciolo del problema e’ la “conversione” .tex => .xhtml. Su questo fronte, il progetto LaTeXML e’ molto attivo e sempre piu’ pacchetti/costrutti sono supportati: https://github.com/brucemiller/LaTeXML
Un altro progetto simile con buone potenzialita’ (ma meno attivo) e’ plasTeX : https://github.com/tiarno/plastex
::
Velocemente (e scusere se un po’ apoditticamente):– “ebook” e’ commercialmente usato dagli editori/piattaforme di distribuzione anche per i PDF. Ai lettori piace meno, perche’ a volte non e’ chiaro se stanno comprando un PDF o un EPUB.
– Editor MathML: se parti da LaTeX, prova latexml o Blahtexml. LibreOffice Math esporta in MathML. Vari CAS/MAS (tipo Mathematica) esportano MathML. Mi pare esista anche un plugin per MS Office che esporta MathML dalle equazioni Equation Editor (o come si chiama adesso).
– Premesso che allo stato dell’arte effettivamente PDF e’ praticamente l’unico modo di trasferire un documento con molta matematica, vorrei far notare che online MathJax fa gia’ ora cose egregie — effettuando un rendering “al volo” di MathML o LaTeX. Basta dare un’occhiata a Mathematics StackExchange http://math.stackexchange.com/ . Gia’ ora Readium e un paio di app per leggere EPUB integrano MathJax e fanno il rendering “al volo” all’interno dell’ebook reflow. Anche iBooks lo supporta, mettendo il JS dentro all’EPUB stesso.
– Il “problema” del PDF e’ che e’ un formato prettamente presentazionale — e’ sufficiente per certi scopi, ma per altri e’ carente. Ad esempio, non mi pare fantascienza pretendere di poter fare copia-e-incolla di formule matematiche da un eBook o di poter “interagire” con la notazione matematica contenuta in un eBook (magari “a la Bret Victor”: http://vimeo.com/66085662 ), tutte cose che si possono fare solo se quella notazione e’ espressa “semanticamente” — e.g. con MathML. Infine, MathML & C. abilitano gli screen reader per i non vedenti.
::
(Secoli che non mi loggavo piu’ qua dentro.)Rispetto a quanto scrivevo/dicevo nel 2011 (BTW: l’URL aggiornato e’: http://www.albertopettarin.it/pubb/misc/PettarinEbookcamp11.pdf ) — quando era appena uscita la specifica EPUB 3 — sono successe alcune cosette:
1) EPUB 3 sta iniziando ad avere trazione solo ora;
2) ufficialmente, EPUB 3 prevede l’uso di MathML per descrivere notazione matematica — ma visto che il rendering nativo di MathML e’ gia’ scarseggiante nei browser, i pochi esempi di matematica resa dichiarativamente (ossia NON con immagini raster) sono A) SVG o B) MathML/LaTeX immerso “as is” nella pagina XHTML e renderizzato da MathJax.
In parole povere: lo scenario e’ a dir poco sconfortante. Pochissimi reading systems per EPUB 3 sono capaci di visualizzare MathML/LaTeX, e quasi tutti lo fanno via MathJax, embedded nell’EPUB 3 stesso o embedded come libreria nel reading system stesso. Ergo: niente manipolazioni dinamiche, niente copia-e-incolla, ecc.
A suo tempo mi ero ripromesso di studiare un flusso (La)TeX => EPUB diretto, ma per varie vicende professionali/personali non ho mai approfondito seriamente il discorso. IMHO, attualmente la via migliore continua ad essere l’output della notazione matematica in MathML, e da li’ l’embedding dentro l’EPUB.
In questo momento non posso scendere in dettagli oltre, ma mi faccio un appunto per ritornare a scriverne in un secondo tempo.
::
Non posso investigare il tuo problema ora. Pandoc funziona benino ma non supporta molte macro. Finora ho ottenuto risultati migliori con plasTeX: http://plastex.sourceforge.net/
::Marco87″ post=65327Ciao AlPe,
per prima cosa ti faccio i miei complimenti per la presentazione che hai fatto (curiosità, hai per caso letto Presentation Zen, di Garr Reynolds?).
Io ho un file .tex di solo testo, senza formule matematiche quindi. Vorrei provare ad ottenere un file epub a partire da questo. Se ho capito bene dalla tua presentazione, devo per prima cosa convertirlo in (X)HTML. Poi, usando calibre e sigil dovrei passare dall'(X)HTML al formato epub. Ho capito bene? Riusciresti a esplicitare i vari passaggi che mi portano da .tex al .epub?
In ogni caso, grazie e buon proseguimento,
Marco.Si’ e’ corretto. Puoi dare un’occhiata a queste due pagine:
http://www.dei.unipd.it/~pettarin/fsfs2.html
http://www.dei.unipd.it/~pettarin/faif2.htmlper avere un’idea piu’ precisa del flusso.
(Scusa il ritardo, non avevo visto il messaggio!)
::
Al recente eBookCamp 2011 (Loreto, 23/10/2011) ho presentato “LaTeX to EPUB: a poor man’s guide to publishing math ebooks” .
La presentazione (ovviamente prodotta con beamer :P) e’ disponibile a questo URL (7 MB)In estrema sintesi: se il sorgente LaTeX e’:
1) ben scritto,
2) con poche macro complicate,
3) senza matematica (ad esempio, un romanzo o un saggio),con uno dei compilatori LaTeX -> (X)HTML piu’ recenti (TeX4ht, pandoc, plasTeX, LaTeXML) si ottengono risultati eccellenti. In cascata, si possono usare calibre+sigil per produrre EPUB/MOBI decenti.
-
AutoreRisposte
