[DISPLAY_ULTIMATE_SOCIAL_ICONS]

Formattare la poesia con le media query

Liz Castro

15 Gennaio 2012

[Tempo di lettura: 7 minuti]

Che matassa aggrovigliata che è la rete! Amazon vuole continuare a supportare i suoi vecchi e-reader. Tutti noi vogliamo supportare e-reader con differenti formati e caratteristiche (iPad, Kindle, telefoni Android ecc.), ma nessuno supporta il codice allo stesso modo. Che cosa fare? Una soluzione è quella di usare le media query, come sto cercando di spiegare da mesi.

Una media query permette di creare diverse serie di CSS, o “Cascading Style Sheets ” (esattamente ciò che vogliamo fare, giusto?) e di caricare il CSS ottimizzato per il tipo di lettore che apre quel determinato ebook. In questo modo, in un singolo file ebook ci saranno più file CSS, uno adatto per i vecchi Kindle, un altro per il Kindle Fire, un altro ancora per schermi piccoli come quelli degli iPhone e ancora uno per l’iPad dell’ultima generazione. L’ebook si adatterà a un determinato ambiente, permettendo a tutti gli utenti di usufruire della miglior esperienza possibile.

Questa, perlomeno, è la teoria.

Ovviamente dovremo avere qualche accortezza. Le media query riguardano il CSS ma non l’HTML, il che limita i cambiamenti al CSS per quei dispositivi che supportano malamente il CSS (sì, sto parlando del vecchio e goffo “mobi”). Non tutti i dispositivi supportano il CSS allo stesso modo pur avendo uno schermo della stessa dimensione. Gli ebook designer, come i web designer prima di loro, continueranno a creare versioni multiple dello stesso ebook fino a quando il codice non sarà standardizzato (e non ci si aspetti che i produttori di e-reader aderiscano spontaneamente a questi standard).

Comunque sia, le media query aiutano. Vediamo come funzionano.

Supponiamo che si voglia formattare una poesia per farne un ebook. La poesia è complicata perché la lunghezza di ogni riga va in qualche modo rispettata, anche in una schermata che non si adatta a quella lunghezza. La soluzione ricorrente è quella di dividere ogni riga della poesia in molteplici righe con la seconda e le successive righe rientrate rispetto alla prima. Il lettore sarà comunque in grado di identificare ogni riga della poesia come un’unità, indipendentemente dalla larghezza dello schermo.

Diamo un’occhiata a “O Captain! My Captain” di Whitman sull’applicazione Kindle per iPad con l’iPad disposto in orizzontale. (Le schermate che seguono sono del Kindle Previewer, così non devo copiarle da un sacco di altri dispositivi). Notate ogni riga della poesia, indipendentemente dalla lunghezza, è disposta su una riga. La poesia non perde il suo fluire. È difficile rendersene conto guardando questa prima schermata, ma notate che Kindle rientra automaticamente le righe del testo 40 pixel per Kindle e nell’applicazione per iPad/iPhone, ma non per Kindle Fire.

Se giriamo l’iPad di lato, portandolo il orizzontale, o se ingrandiamo il testo o eseguiamo tutte e due le azioni, le righe improvvisamente non entreranno più nella schermata. Non solo, ma il rientro automatico della prima riga che Amazon ha aggiunto renderà la poesia davvero brutta da vedersi. Comincia a diventare difficile definire quale sia la seconda parte di una riga lunga e quale sia una riga singola più corta.

Ecco come appare sui vecchi Kindle (o il “vecchio mobi”, come lo chiamo io).

Non molto carino.

Ed ecco come appare su Kindle Fire. Ricordatevi che Kindle Fire non ha un rientro paragrafo automatico per quanto riguarda la prima riga.

La combinazione di giustificazione automatica, nessun rientro per la prima riga e nessun aggiustamento per le righe della poesia ha una pessima resa sul Kindle Fire. Ne vien fuori solo un marea di testo.

Qual è la soluzione? La convenzione per formattare la poesia è di far rientrare la parte di riga che non entra. Ciò che gli impaginatori chiamano capoverso rientrato.

Con il CSS è facile farlo. Si aggiunga un margine sinistro di diciamo, 2 em (unità di misura relativa utilizzata in tipografia digitale), il che sposterà l’intero paragrafo e poi si aggiunga un rientro di testo negativo di 2 em, in modo che la prima riga cominci dal margine sinistro come sempre e le altre righe abbiano un capoverso. In questo modo ogni riga della poesia comincerà dal margine sinistro ma ogni parte della riga che supera il limite verrà rientrata nelle righe successive. Ecco il codice CSS:

p {line-height: 1;padding:0;margin:0}
p.firstline {margin-top:2em; margin-left:2em; text-indent: -2em;}
p.line {margin-left:2em; text-indent: -2em;}

Ed ecco come appare sul Kindle Fire:

Sicuramente dovrò regolare un po’ la formattazione generale, ma adesso almeno le righe delle poesie sono a posto.

Ma se lo apriamo con i vecchi Kindle, viene fuori qualcosa di non molto carino:

E anche con l’applicazione Kindle per iPad. Non ci siamo:

Cosa sta succedendo? A quanto pare il vecchio mobi gestisce i valori per text-indent in un modo davvero strano. Se non s’imposta un valore text-indent, il vecchio mobi rientra automaticamente di 40 pixel. Se si imposta un text-indent positivo utilizzerà invece quello (si possono utilizzare pixel o em, ma con gli em funzioneranno solo i numeri interi). Ma se s’imposta un text-indent negativo, si creerà un capoverso alla prima riga e le righe successive avranno un rientro pari al valore del text-indent. Provate a immaginare. È una cosa strana e inaspettata, ma se si imposta il margine sinistro tutto insieme, ne viene fuori una cosa molto disordinata e i dettagli sono troppo noiosi da spiegare. Fidatevi, non avreste proprio voglia di apprendere i particolari.

Per creare un capoverso su un vecchio mobi, si usa un semplice text-indent negativo, ma senza alcun margine. Non dovrebbe funzionare ma funziona.

h1 {text-align: left} 
p {line-height: 1} 
p.firstline {margin-top:20px;text-indent:-40px} 
p.line {text-indent:-40px}

Ed ecco cosa otteniamo su un vecchio Kindle:

Non male, ma date un’occhiata a cosa succede sul Kindle Fire:

A causa di questi rientri negativi e della mancanza di un margine sinistro automatico, o di qualsiasi altra cosa usassero i vecchi mobi, adesso il nostro testo è tagliato. Inaccettabile.

Dunque Kindle Fire e gli altri e-reader di formato ePub abbastanza buoni da supportare il CSS, come iBooks, vogliono un margine sinistro e un rientro negativo, ma i vecchi mobi non supportano questa combinazione, in quanto sono un grado di utilizzare solo un rientro negativo.

La soluzione sta nel fornire diversi CSS adatti ai differenti e-reader, tramite le media query. Vi mostrerò come farlo in un foglio di stile interno all’ebook con gli stessi principi che si userebbero per un foglio di stile esterno.

Per prima cosa create un foglio di stile normale, privo cioè di attributi relativi ai media, che contenga gli stili che dovrebbero essere applicati a tutte le versioni degli ebook.

<style type=”text/css”>
 h1 {text-align: left}
 p {line-height: 1;padding:0;margin:0}
</style>

Poi create un secondo foglio di stile con media=”not amzn-mobi” nel tag di apertura style. Il foglio di stile dovrebbe includere tutti gli stili che si applicano agli e-reader tranne i vecchi Kindle. Amazon dice che si dovrebbe usare media=”kf8″ ma questo perché loro pensano che tutto il mondo usi solo i vecchi Kindle e Kindle Fire. Diciamo solo che il mondo è più vasto di quanto pensi Amazon.

<style type=”text/css” media=”not amzn-mobi”>
 p.firstline {margin-top:2em; margin-left:2em; text-indent: -2em;}
 p.line {margin-left:2em; text-indent: -2em;}
</style>

Alla fine create un foglio di stile per i vecchi Kindle semplicemente aggiungendo media=”amzn-mobi” al tag di apertura style.

<style type=”text/css” media=”amzn-mobi”>
 p.firstline {margin-top:20px;text-indent:-40px}
 p.line {text-indent:-40px}
</style>

Ecco come si presenta sul Kindle Fire :

Ed ecco com’è lo stesso identico file sui vecchi Kindle:

Vittoria!

Nel caso vi stiate preoccupando, ecco come l’ePub appare su iBooks per iPad:

Ovviamente, è perfetto, in quanto iBooks supporta il CSS molto bene.

Una nota tecnica. C’erano alcune problematiche riguardanti l’inserimento di paragrafi rientrati per il Kindle Fire e i vecchi Kindle, in quanto il codice di quest’ultimo utilizza l’attributo width (in un modo molto strano) in HTML e non nel CSS. Ma la tecnica spiegata qui sopra funziona perché il KindleGen converte il CSS di un buon ePub in uno strano, vecchio e goffo codice mobi – completo di tag width – che i vecchi Kindle adorano, ma crea il codice “KF8” per il nuovo Kindle Fire, il quale, come ho mostrato, è praticamente lo stesso dell’originale ePub. E i lettori ePub avranno il file buono originale. Così saranno contenti tutti.

A parte i designer che avranno da fare il doppio del lavoro. Pensate che gli standard non siano importanti? Ripensateci.

Un’ultima nota. Ripeto spesso che i file KF8 che KindleGen genera dall’ePub originale è praticamente identico a quello dell’ePub. Questo vale solo per i CSS che supportano i KF8. Non li ho provati in maniera estesa, ma credo che KindleGen semplicemente ignori il fatto che il CSS non lo supporta. E soprattutto devo ancora determinare (né l’ho visto fare da altri) fino a che punto Kindle Fire supporti CSS. Ho bisogno di un altro paio di giorni!

da Pigs, Gourds, and Wikis | 15 gennaio 2012

Traduzione di Angelo Gaudino, laureando SSML Carlo Bo – sede di Bologna

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *