Non sono stato un entusiasta della prima ora di ePub3: avrei preferito la nascita di uno vero standard nato per fare ebook. Invece, come già ePub2, questo formato prende una serie di strumenti già noti, ma che non sono stati ideati per fare ebook bensì pagine web. Nello specifico html5 e Javascript.

Il mio sospetto era che si trattasse di una scelta “comoda” per beneficiare, non tanto gli ebook reader, quanto i tablet. Il mio timore era poi che specifiche così ampie e non strutturate portassero a implementazioni parziali a macchia di leopardo.

Detto questo, buona parte del mio tempo non-libero è impegnato da tempo a studiare html5, css3, javascript e le specifiche ePub3 per capire come questo formato possa dare nuove possibilità per la creazione di “libri elettronici”, al di là delle facili inclusioni di video o animazioni nel testo.

Da questo punto di vista una delle cose più importanti di html5 e javascript è l’introduzione del web-storage, ovvero la possibilità di utilizzare e registrare sul lettore variabili di stato, che permangono anche quando l’ebook viene chiuso. In pratica un ebook diventa un database di dati manipolabili dall’utente che possono essere utilizzati anche in sessioni diverse di lettura.

{A livello progettuale questo è un giro di boa incredibile per la costruzione di testi elettronici. È l’equivalente informatico dell’ampio gesto che si fa in cucina con la padella per rivoltare per aria una frittata e ritrovarsela con il lato ancora da cuocere aderente al metallo: l’attimo in cui si smette di scaldare un piatto precotto e si inizia a fare sul serio, con tutti i rischi del caso}

Bene; stavo lavorando per la prima volta ad un ePub3 in cui si faceva un massivo utilizzo di web-storage. Una volta strutturata la pagina inizio a testarla sugli unici due motori “certi” di lettura ePub3, Readium e Ibooks. Su Readium funziona tutto alla perfezione, su Ibooks no. Nulla. Controllo il mio codice, rifaccio partire i test, faccio piccole modifiche, finché parlando con alcuni programmatori oltreoceano mi viene confermato che sì, Apple ha recentemente inibito lo webstorage su Ibooks.

Perché? Perché sì.

In pratica, una delle più determinanti innovazioni di html5 che fa fare un grosso passo avanti nella costruzione di testi digitali in ePub3, è spenta da Apple.

Mi viene da pensare, leggendo anche altre specifiche ePub3 in cui si annuncia che no, non è possibile includere in un ePub3 aggiornamenti provenienti dalla rete, mi viene da pensare, dicevo, che gli stessi creatori del formato per fare ebook non sappiano bene come gestirlo. Nel momento in cui inizia a differire troppo da un libro statico (o con qualche animazione in mezzo), per assumere una propria autonomia procedurale, allora si corre ai ripari. Si castrano strumenti che sono propri del linguaggio, si inibiscono soluzioni che non c’è motivo di inibire.

In fondo è solo un ePub, non una applicazione.

Non è la prima volta. Già in ePub2 avevamo con Quintadicopertina creato ePub, validati, che si connettevano con il server di Pingtheworld per aggiornare sezioni dell’ebook che informavano su avvenimenti ancora in corso. Tutto utilizzando le specifiche di XML. Ma anche in quel caso alcuni lettori (i maggiori) avevano chiuso le porte per impedire la visualizzazione di contenuti on-line.

Non c’è nessun motivo tecnico e nessun limite informatico, è semplicemente una scelta di comodo. È più facile per distributori e seller gestire un mercato di ebook debilitati, che siano una copia più o meno rassicurante del libro di carta. Un po’ come gli mp3.

Chiudo questo piccolo angolo dell’amarezza: questo atteggiamento credo induca gli editori a non investire risorse in innovazione e sperimentazione. Perché dovrei impegnare mesi per scrivere codice e tag che rischierebbero di non funzionare su questa o quella device, quando posso impacchettare i Promessi Sposi e venderli a .99?

Non è questo che i lettori vogliono leggere?

Advertisements