ePub2 dovrebbe supportare il formato grafico svg, un formato XML con il quale si può disegnare sullo schermo. Il vantaggio del formato svg è che è un formato vettoriale, si è indipendenti dalle dimensioni dello schermo del lettore e soprattutto dalla sua risoluzione, ovvero dai ppi. Se abbiamo una immagine bitmap, ad esempio un jpeg o un png, e la stiamo gestendo con valori percentuali, questa verrà stirata o ristretta per adattarsi alle dimensioni dello schermo in cui è. Se invece la utilizzamo usando la grandezza naturale dei suoi pixel, rischierà di uscire fuori dallo schermo (ad esempio una immagine di 1000 pixel di larghezza su una device che ha solo 600 pixel di schermo), oppure – all’opposto – si trasformerà in un piccolo francobollo se la densità di pixel è troppo alta (ad esempio uno schema a 300 pixel letto su un Kobo Aura a 1000 e passa pixel).
Gli svg vettoriali non hanno questo problema: non contengono immagini, ma ordini. Il disegno viene fatto sul momento, ed è possibile fare in modo che sia composto in relazione alla dimensione della pagina.
Tutto bene allora? Dopo diversi giorni di test nel laboratorio estivo di Quintadicopertina, posso dire che lavorare ePub con svg e camminare in un campo minato sono attività concettualmente non troppo dissimili (in una delle due però si soffre notevolmente di meno).
Faccio un riassunto delle prove di questi giorni: Adobe digital edition 1.7 supporta gli svg, ma non quelli complessi, non mostra immagini bitmap embeddate nel testo e ha difficoltà ad allineare scritte; Adobe digital edition 2 si comporta molto meglio, ha una buona gestione del formato e – dando come larghezza dell’svg il 100% dello schermo e non indicando una altezza in pixel – l’altezza viene gestita in proporzione rispetto alla larghezza (tanto di cappello, è l’unico a farlo. Gli altri richiedono per l’altezza valori in pixel che vincolano poi l’espansione in orizzontale del width); Ibooks su iPad fa cadere le braccia: dando il 100% di larghezza senza indicare la larghezza Ibooks attribuisce arbitrariamente un 100% di altezza, ovvero il body dell’intero documento: l’immagine quindi viene messa in una pagina da sola con spazio bianco sopra e sotto e spezzando il flusso del testo. Non pago di questo Ibooks mostra una pregevole esemplificazione di codice scritto in vino veritas: variando il font del testo, eventuali scritte presenti nell’svg collassano le une sopra le altre; variando ancora la dimensione del font, tornano normali; variandolo ancora collassano e così via, con regolarità pari/dispari; anche Readium e Calibre vedono gli svg e anche loro, se è specificata solo la larghezza al 100% e non ci sono valori per l’altezza, la prendono malissimo: l’immagine appare un po’ nello schermo, un po’ nel nulla che attornia le pagine digitali (dove il pac man andava a riposarsi, tanto per capirci); convertendolo per Kindle si vede su Kindle recenti in kf8 (con le stesse limitazioni della larghezza/altezza viste in Ibooks), non si vede in Kindle mobi, si vede in Kindle fire, non si vede in Kindle per iPad. Vedo e non ti vedo.
Insomma: un ginepraio, complicato dal fatto che la validazione ePub non ammette che negli svg ci siano istruzioni superiori alla versione svg 1.1, mentre molti programmi di disegno svg (come Inkscape) salvano in svg 1.2

La mia impressione è che è chiaro il perché svg non lo utilizzi nessuno. Ed è un peccato perché un formato vettoriale diventa oggi essenziale, nel momento in cui utilizzino grafici che debbono essere visti su device le cui caratteristiche tecniche variano in maniera sempre più macroscopica.
E questo senza toccare il tema dell’accessibilità. Lasciar perdere allora? Forse, o forse potrebbe essere il momento di affiancare ad un ePub in bitmap una versione vettoriale e far vedere l’effetto che fa. Perché, imho, gli svg sono bellissimi.

Advertisements