Non è facile fare un ebook

C'è un articolo da leggere oggi in rete per chi si interessa di ebook, è quello di infogridPacific in cui si ragiona sul fallimento di EPUB3 e in cui si cerca di lanciare un nuovo formato chiamato E0. L'articolo è da leggere, non solo per le riflessioni sulle problematiche del formato EPUB, ma anche per la narrazione dei poteri che stanno dietro a IDPF. Molte delle critiche di Richard Pipe sono molto sensate e condivisibili, anzi, potrebbero essere elevate a potenza. Altre no, e anche alcune visioni del libro digitale mi paiono piuttosto riduttive. Il lancio del formato E0, infine, mi sembra più una boutade polemica che una reale possibilità di sviluppo.

Ma la cosa che fa riflettere è che ancora oggi, in pieno 2013, non è affatto chiaro cosa possa o debba essere un ebook. È palpabile leggendo il pezzo di Pipe, come la visione del testo digitale sia ancora strattonata: da una parte dal libro, dall'altra parte dal web.

Anche io penso che la scelta di EPUB3 di abbracciare un subset di HTML5, un subset di CSS2 e CSS3 con una spruzzata di Javascript (ma non troppo) e di attributi proprietari, sia una scelta a corto respiro e ad ampio rischio di side effect.

In primo luogo perché agli editori non frega niente. Intendo quelli tradizionali. Gli editori tradizionali stanno continuando a fare libri di carta, anche per il digitale e non hanno intenzione di andare ad investire capitali per fare cose strane che non abbiano una immediata redditività.

In secondo luogo perché le stesse specifiche di HTML5 e CSS3 non sono ancora definitive. E sono enormi. Voglio dire: con HTML5, CSS3 e Javascript si può fare di tutto, in termini di interattività e di creazione di cose digitali. Il supporto da parte degli ebook reader, nei prossimi anni, sarà quanto mai parcellizzato. Sarà un bagno di sangue e una corsa al minimo comun denominatore, ovvero si andrà a velocità di progettazione ridotta per poter stare su tutto il parco macchine. Non è un caso che sempre più editori, a questo punto, pensino di usare HTML5, CSS3 e Javascript, sì, ma attraverso Web-app o altri sistemi di lettura on-line, senza i vincoli dell'IDPF e dei vari produttori di hardware.

In terzo luogo, con EPUB3 (come con il suo fratello scemo KF8) si continuano ad utilizzare strumenti che nascono per il web e non, non, non per fare ebook. Non è possibile parlare di impaginazione digitale di ebook quando non posso nemmeno mettere una immagine centrata verticalmente nella pagina. E non è l'esempio più drammatico.

E qui ritorniamo al cuore del discorso: ma cosa è un ebook, cosa deve fare?

Bella domanda.

Ad oggi - in genere - un ebook vive questa contraddizione:

  • • è un libro di carta, nel senso che nel 99% dei casi l'editore fa il libro di carta e poi fa anche l'ebook;
  • • è un libro di carta, ma impaginato come se fosse un sito web;
  • • è impaginato come un sito web, ma si deve sfogliare tutto.

Questo crea dei mostriciattoli, gli ebook oggi sono un po' gli hobbit dell'editoria, non hanno la forza per essere nani e non sono abbastanza leggiadri per folleggiare nei boschi degli elfi.

La cosa che penso io, e non solo io grazie al cielo, è che l'ebook non sia un libro. Non abbia niente a che vedere con il libro di carta. Quando mi chiedono se gli ebook amazzeranno i libri di carta, io penso che spero di no, nel senso che secondo me gli ebook sono un prodotto infinitamente superiore al libro di carta, e profondamente diverso.

Ho bestemmiato, ho detto che l'ebook è infinitamente superiore al libro di carta. Mi spiego meglio. Penso che potremmo parlare di ebook, in senso pieno e completo del termine, di rivoluzione digitale, quando saranno i libri ad essere dei derivati degli ebook e non il contrario. Perché gli ebook non sono solo la rappresentazione di dati, di narrazioni, di informazioni, ma sono quei dati. Un vero libro digitale è una raccolta di informazioni, relazioni, interrogazioni.

La cosa che non mi convince dell'E0, tra le altre, è la filosofia per la quale bisogna fare in modo che per gli editori sia facile fare ebook. Questo è un grosso fraintendimento: fare book è più difficile che fare libri di carta, perché gli ebook non stanno fermi un attimo. Non devono stare fermi un attimo. Bisogna pungerli, ad esempio con le Api.

Non le ho ancora studiate in tutti i loro aspetti, ma le Api del laboratorio di Alese sono un esempio abbastanza chiaro ed esemplificativo di quello che sto dicendo. In questo caso abbiamo un ePub2 e una serie di strumenti che, dall'esterno, interrogano l'ePub e ne traggono informazioni che vengono viste in tempo reale dal lettore. È più chiaro adesso: un ebook è un database delle informazioni che contiene e nello stesso tempo è la rappresenzione delle informazioni stesse.

(per la cronaca, questo è il metodo con cui con quintadicopertina interroghiamo gli ebook per farne indici e percorsi interattivi via XQuery, che poi inglobiamo all'interno dell'ebook stesso. È il digitale bellezza).

La conclusione: sarà un percorso lungo per riuscire ad avere la maturazione di questo qualcosa che è il libro digitale. Ci sono le sirene della multimedialità, quelle delle applicazioni, quelle delle web-app, quelle del libro di carta, qua è là ci sono ancora le secche del PDF di stampa e dei DRM. Ma chi fa ebook, davvero ebook si rende sempre più conto che l'editoria digitale è una cosa troppo importante per lasciarla andare avanti per forza di inerzia, delegando lo sviluppo agli algoritmi di acquisto di Amazon o alle scelte di mercato di altri grossi attori della distribuzione e produzione di beni elettronici.

 

Fabrizio Venerandi

Commenti  

 
+3 #5 Fabrizio Venerandi 2013-07-23 22:03
Izzy, tecnicamente un ebook ha molte più similitudini con un sito web che con un libro tradizionale. Credo poi che un editore non debba essere interessato a pubblicare libri, ma a sviluppare narrazioni, portare informazione, sapere. Il libro è uno dei "media" utilizzato per farlo. Se cambiano i mezzi di trasmissione del sapere, cambiano anche le narrazioni e le modalità con cui queste narrazioni possono essere trasmesse. Gli scrittori non scrivono *libri*, scrivono *storie* e le portano dove possono essere realizzate: libri, teatri, piazze, concerti, installazioni, film, videogiochi...Il sito-app *non* è l'evoluzione del libro, ma è un altro luogo in cui sviluppare ambienti di lettura.
Citazione
 
 
+2 #4 Izzy 2013-07-23 19:42
E io continuo a non capire. Se volete una cosa interattiva in html, css, e js, allora volete un sito-app, non un libro. L'ebook ha quella parola lì, book, che qualcosa dovrebbe significare. Pensare che l'evoluzione del libro sia diventare un sito-app mi sembra assurdo. L'ebook è nato per gli ereader, con lo scopo di rendere digitali i libri. Della serie: esistono i libri di carta, ora li portiamo in digitale. Devono offrire quello che offre un libro. Altrimenti non sono ebook, ma qualcos'altro. Infatti il “libro digitale” di cui parli esiste già: si chiama sito, o altre volte app. E come tale la gente lo conosce. Quindi di cosa parliamo? Del perché una pera non è una mela? E del perché mai chi vuole mangiare una pera non si compra le mele? Del perché chi produce pere (scrive libri) non crea qualcosa che sembra una mela (una app)? O del perché il fruttivendolo (l'editore) non ti trasforma le pere in mele?

Gli ebook sono ebook perché chi scrive libri scrive, guarda un po', libri, non siti app. E chi legge libri vuole leggere, difficile crederci, libri. Non è che agli editori non frega niente. Diciamo che se gli dai in mano un libro lo trattano come tale. Se da un libro ci fanno un videogame, beh, la gente lo chiamerà con il suo nome, non certo ebook.
Citazione
 
 
+1 #3 Marco Esposito 2013-07-19 10:13
Concordo pienamente con l'analisi di Fabrizio.

Con Nuova Cultura, casa editrice attiva soprattutto nel settore della ricerca scientifica, stiamo sviluppando dei prototipi basati su ePub/ePub3 e ci siamo più volte scontrati con le problematiche descritte. In particolare: la codifica delle formule matematiche, la gestione di box interattivi e diversi livelli di contenuto.

La proposta di Dave Cramer su EPUB Zero è interessante soprattutto per questo: "Interactivity. What can be done on the web can be done in the book."

Aggiungerei che anche i produttori di dispositivi hanno delle responsabilità in merito e, piuttosto che delegare a loro ricerca e sviluppo, gli editori più illuminati debbano cercare di investire il più possibile in questo settore.

Nel nostro piccolo, è quello che anche noi cerchiamo di fare. ;-)
Citazione
 
 
0 #2 Gabriele 2013-07-17 08:43
Credo che si sottovaluti un aspetto secondo me non banale, che spiega almeno parzialmente la macchinosità delle specifiche epub: un documento così rigidamente costruito è passibile di validazione, e poter validare i documenti rende più semplice il lavoro di chi deve progettare sistemi di lettura per tali documenti, sistemi che – almeno ai tempi di introduzione delle specifiche – erano con ogni probabilità destinati in particolare a dispositivi privi di potenza di calcolo sufficiente a gestire un motore di rendering "tollerante" come quello di un browser moderno. Potremmo pensare che al giorno d'oggi, con le vendite di reader basati su eink e l'ascesa dei tablet, questo requisito sia superfluo; ricordiamo però che la validità dei documenti epub è stato un fattore non trascurabile nella progettazione dei workflow dei publisher, e l'impossibilità di caricare epub non validi sulle piattaforme di distribuzione ha evitato che i consumatori venissero sommersi di prodotti che sarebbero stati non solo difettosi ma del tutto impossibili da leggere.
Citazione
 
 
+2 #1 Teo Balocco 2013-07-16 13:36
Epub e Mobi sono da sempre l'ufficio complicazioni affari semplici.
Il formato hpub di Baker Framework è MOLTO più sensato.
In effetti tutto ciò che serve è semplicemente un wrapper compresso, poi tutto il resto è già previsto e risolvibile con html5,css,js e microformats.
Non resco a darmi nessuna spiegazione sensata (se non la creazione di walled garden) per l'attuale scenario.
Citazione
 

Aggiungi commento


Codice di sicurezza
Aggiorna

joomla template