Le pagine degli ebook rompono le scatolette
Ultimamente sulla mia scrivania transitano due file che si chiamano labo_2_ePub3 e labo_1_ePub3. Si tratta – come il nome può fare capire – di file in cui man mano testo cosa si può fare e cosa non si può fare in EPUB3, che poi visiono con Adobe Digital Edition 4, Ibooks per Osx, Ibooks per Os, Gitden Reader, Readium e Azardi. Siccome – come ho ripetuto allo sfinimento dei corsisti all’ultimo bel laboratorio a Cologno Monzese – per fare ebook usiamo specifiche nate per fare tutt’altro, quello che potremmo fare e quello che possiamo fare deve passare sotto le forche caudine del supporto.
Alcuni grossi limiti oggi di fare ebook sono ad esempio legati al fatto che tutte le specifiche ebook lavorano pensando DOM. DOM è il Document Object Model: è una cosa buona, a suo modo. Banalizzando possiamo dire che ogni pagina Web è concepita a scatolette. C’è una grossa scatoletta che si chiama body, che contiene tante scatolette piccole: titoli, immagini, paragrafi, video, etc. Ogni scatoletta può contenere a sua volta scatolette più piccole, ad esempio un paragrafo può contenere del testo e delle scatolette che contengono titoli di libri, o una scatoletta tabella può contenere scatolette righe che a loro volta contengono scatolette celle che contengono testo. Quando si deve parlare con una pagina web si parla con queste scatolette, gli si dice cosa fare o come comportarsi con il loro contenuto. Per chi gli piacciono questo genere di cose è anche divertente. A me diverte, se so come farlo.
Anyway. Qui nasce un problema per gli ebook. Ovvero che gli ebook sono paginati, sono divisi in pagine. Queste pagine non sono reali, sono virtuali, vivono in reflow. Cosa voglio dire che non esistono: voglio dire che – ad esempio – non ce ne è traccia nella DOM. Il fatto che non esistano nella DOM fa sì che tutte le regole che noi diamo alle scatolette, in genere, non possono essere relazionate alle pagine. Possiamo dire che una immagine è alta il 50% della scatoletta che la contiene, ma non il 50% della pagina in cui viene visualizzata, perché la pagina non esiste.
Non è un problema solo di noi noiosi progettisti digitali, ma anche di chi deve adattare le specifiche nate per pagine web, affinché funzionino su documenti paged. Si tratta di porsi problemi mai posti prima nella progettazione web:
- cosa devo fare se una pagina di un ebook mi finisce proprio a metà di una immagine?
- come devo comportarmi se ho paragrafi a due colonne e questi esondano dalla pagina in cui sono e finiscono in quella dopo?
- che faccio se elementi javascript aggiungono scatolette in una pagina e quindi aumenta la foliazione di un capitolo di cui ho già stabilito il numero di pagine all’apertura?
- come gestisco i form di inserimento dati in ebook destinati a device che non dovrebbero avere tastiera?
- cosa faccio se ho un’immagine con testo che la contorna e l’immagine finisce nella pagina dopo perché è troppo grossa, ma il testo che la dovrebbe contornare trova invece spazio nella pagina precedente?
- (continua a lungo)
Non di tratta di problemi dalla facile soluzione e che – facilmente – rischiano di non trovare soluzione o di trovare soluzioni diverse a seconda delle decisioni degli sviluppatori. Il che significa che poi noi, i tipografi digitali, non potremo usare quelle soluzioni perché troppo poco omogenee da device a device. È già successo in passato con i linear="no" o con le XML island.
C’è da dire che non è che nessuno non ci abbia ancora pensato. Faccio un esempio: quando si parla delle note a piè di pagina in un ebook si dice che non esistono perché non esiste la pagina
. Non esistendo più in concetto di pagina non esistono nemmeno le note a piè di pagina. È una frase molto bella perché è chiara e fa capire subito come il digitale sia diverso dal cartaceo. Però è falsa. Non ci sono le note a piè di pagina perché usiamo specifiche fatte per pagine web, dove lì sì, non esiste il concetto di foliazione, ma quello di scroll.
Non c’è nessun motivo per il quale un ebook reader non possa gestire le note a piè di pagina in maniera dinamica, reimpaginandole in reflow. Ci sono anche le istruzioni per farlo. È il settore dei paged mediaVedi anche: http://www.w3.org/TR/css-gcpm-3/#creating-footnotes, ma anche http://www.smashingmagazine.com/2015/01/07/designing-for-print-with-css/, che si occupano proprio di andare a gestire quella strana cosa fisica che è la pagina e che non ha nessun senso logico di essere lì se non per il fatto che c’è. Ed è lì, e devi tenerne conto.
Per convincervi che non sto parlando di fantascienza o di specifiche così recenti che se le tocchi ti sporchi le mani di vernice fresca, sappiate che alcune cose dei paged media già si usano abitualmente negli ebook, come il @page per la gestione dei margini, o i vari page-break-inside, after, before.
Ps: e se pensate che prima della annotazione qui sopra che inizia con Vedi anche:
manchi uno spazio, guardate cosa succede se stampo questa pagina con Prince (quel Prince, non questo).