[1] durante l’ultimo laboratorio di creazione ebook sono stato ripreso perché parlo troppo di EPUB3. È vero, dopo aver stigmatizzato in lungo e in largo l’EPUB3, ho iniziato a parlarne e fare vedere le cose che si possono fare. Non che sia cambiato il mio giudizio sul formato o sul supporto in sé, che rimane sostanzialmente negativo, ma ePub2 è un formato riguardo al quale si è già detto tutto quello che si poteva dire e – lato amazon – kf8 ha più buchi che pregi. EPUB3 è comunque l’unica direzione di sviluppo di editoria digitale nella quale non ci sia il rischio di trovarsi in un vicolo cieco o – più facilmente – accecato.
[2] quando scrivo che di ePub2 si è detto tutto quello che si poteva dire, mento. Di ePub2 si è detto poco, pochissimo. Alcune sue caratteristiche non sono mai state utilizzate decentemente da nessun ebook reader e quindi sono rimaste lettera morta. Mi sono già dilungato in passato per il supporto indegno del linear="no", ma molto altro potrebbe essere scritto. Sapevate – ad esempio – che è possibile embeddare in un ePub2 un intero PDF? O che, per citare un altro illustre sconosciuto, è possibile creare un’isoletta xml nel mezzo dell’ePub2? Negli scuri meandri dei laboratori di Quintadicopertina abbiamo anche fatto un ePub2 interamente in TEI, e su alcune device (inaspettatamente: Ibooks) si leggeva anche.
[3] per unica direzione di sviluppo, intendo dire che se EPUB3 affondasse, magari sotto i tiri correttivi del W3C, il codice è una zattera universale che si può portare in qualunque ambiente di sviluppo si andrà delineando in futuro. Una delle maggiori competenze in ambito di editoria digitale – IMHO – non è solo conoscere le specifiche, ma sognarsi di notte i fallback per ogni singola azione che si va a fare.
[4] EPUB3 non significa necessariamente tablet. Principalmente tablet, certo, ma non necessariamente. Abbiamo installato un EPUB3 reader su un Onyx T68 e ci siamo divertiti a vedere cosa succede ad un libro testuale animato da javascript. Si possono fare tante cose interessanti, anche senza scomodare multimedialità e compagnia cantante. Senza parlare di media overlay, che già ora funziona molto bene in e-ink.
[5] è facile smettere di aver paura del multimediale, se sai come farlo. Il multimediale non è un video infilato in mezzo al testo, ma fa parte di un amalgama omogeneo tra contenuti coerenti fra di loro. È video, canvas, svg e tanto javascript. È una risorsa che va ripensata e utilizzata in un contesto nuovo, diverso sia dal libro che dal web.
[6] al corso abbiamo anche parlato del fixed layout. Il fixed layout non è il male, però ci somiglia. È una impostazione che tende a riprodurre il vecchio concetto del libro di carta, aggiungendo multimedialità e interazione, ma andando a corrompere qualunque discorso di sviluppo interamente digitale. Il solo concetto di un ebook in cui ogni pagina è un file separato dagli altri, dovrebbe far riflettere su quello che si sta andando a creare, alla sua futura manipolazione e alla sua longevità.
[7] non ho davvero un settimo punto, solo una notizia di ordine logistico. Un po’ come alla fine della messa il prete inizia a dire gli appuntamenti del mese, ecco. Questo blog è a fine corsa. Tra poco si sposterà altrove, assieme ad altri blog, quindi tenete caldi i vostri preferiti. Buon coding.
salvo esaurimento scorte 
[1] Gli editori (presenti esclusi) non sono culturalmente (tecnologicamente) preparati. Spesso nemmeno chi li rappresenta in sede IDPF. (Imbarazzante.)
[2] Problema dell’uovo e della gallina: gli implementatori di reading systems implementano solo le funzioni che generano un ritorno economico (o che vengono gratis dalle primitive che usano, tipo i rendering engines). Di conseguenza, senza mercato non sono incentivati ad implementare funzioni esotiche. E gli editori che magari sarebbero contenti di usarle, sono costretti a mettere una fila interminabile di asterischi che dicono: nell’app X questo ebook ha le funzioni A, B, C; su Y funziona A e D; ecc.
[3] Premesso che credo che ben pochi in questo ambiente si siano mai letti le specifiche, concordo sull’idea del master code, da cui derivare N formati di output. Tuttavia il discorso dei fallback va precisato. I fallback dovrebbero esistere solo per le parti opzionali delle specifiche, che dovrebbero essere poche e ben modularizzate e separate dalla parte principale “a supporto obbligatorio”. Non reputo molto onorevole doversi sognare di notte ennemila fallback perche’ i vari reading systems hanno ciascuno un proprio insieme di idiosincrasie (su funzioni base).
[4] [5] Concordo, eccetto su una questione molto importante: starei molto attento a uscire da un modello documentale dichiarativo rispetto a uno “comportamentale” implicato da e.g. dall’uso di JS. Non postulo l’inferiorita’ di questo secondo rispetto al primo, solo bisogna stare molto attenti al fatto che i due modelli coprono esigenze diverse e implicano vantaggi/svantaggi ben diversi.
[6] Le implicazioni del discorso che fai sul FXL (su cui concordo), specialmente circa la “longevita’” (= riutilizzabilita’) di una rappresentazione non dichiarativa di un documento, sono applicabili anche all’uso di JS, come detto al punto precedente.
[7] Una volta provato un compilatore statico (e.g., Jekyll), non si torna indietro.
[2] amen; [3] in questo caso sono stato poco chiaro: non mi riferivo ad un fallback informatico, ma strutturale. L’editoria digitale è talmente mobile da necessitare un percorso di lavoro che preveda un “fallback” concettuale continuo. Niente è fermo, nessuna regola è davvero una regola. [4] [5] [6] assolutamente. La mia è una osservazione cinica: certe cose in “modello documentale dichiarativo” non le avremo mai, dove per “mai” si intenda un tempo sufficientemente lungo da renderle inimplementabili. Vedi XLink. Se una cosa si può fare “facilmente” in Javascript, si implementa bene solo quella. Guarda il banale esempio, nel web non in ebook, delle entità esterne. Firefox e Chrome non supportano una cosa documentale e semplice come le entità esterne. Perché implementarle se esiste già httpRequest (che fa anche altro, va bene)? Insomma, sono d’accordo anche io che javascript non è – in assoluto – la strada giusta per fare una cosa, ma temo che per molte cose sia l’unica obbligata. Peraltro, correggimi se sbaglio, con HTML5 in maniera ancora più codificata (penso alle canvas che possono essere disegnate e animate solo con javascript se non erro).