{"id":245,"date":"2015-06-03T10:12:13","date_gmt":"2015-06-03T08:12:13","guid":{"rendered":"http:\/\/www.quintadicopertina.com\/fabriziovenerandi\/?p=245"},"modified":"2015-10-14T12:37:18","modified_gmt":"2015-10-14T10:37:18","slug":"245","status":"publish","type":"post","link":"https:\/\/www.quintadicopertina.com\/fabriziovenerandi\/?p=245","title":{"rendered":"Le pagine degli ebook rompono le scatolette"},"content":{"rendered":"
\"Schermata<\/a>\r\n
Cliccare sull’immagine per vedere il dettaglio<\/figcaption>\r\n<\/figure>\r\n

Ultimamente sulla mia scrivania transitano due file che si chiamano labo_2_ePub3<\/code> e labo_1_ePub3<\/code>. Si tratta \u2013 come il nome pu\u00f2 fare capire \u2013 di file in cui man mano testo<\/em> cosa si pu\u00f2 fare e cosa non si pu\u00f2 fare in EPUB3, che poi visiono con Adobe Digital Edition 4, Ibooks per Osx, Ibooks per Os, Gitden Reader, Readium e Azardi. Siccome \u2013\u00a0come ho ripetuto allo sfinimento dei corsisti all’ultimo bel laboratorio a Cologno Monzese \u2013 per fare ebook usiamo specifiche nate per fare tutt’altro<\/strong>, quello che potremmo<\/em> fare e quello che possiamo<\/em> fare deve passare sotto le forche caudine del supporto.<\/p>\r\n

Alcuni grossi limiti oggi di fare ebook sono ad esempio legati al fatto che tutte le specifiche ebook lavorano pensando DOM<\/acronym><\/strong>. DOM<\/acronym> \u00e8 il Document Object Model: \u00e8 una cosa buona, a suo modo. Banalizzando possiamo dire che ogni pagina Web \u00e8 concepita a scatolette<\/strong>. C’\u00e8 una grossa scatoletta che si chiama body<\/code>, che contiene tante scatolette piccole: titoli, immagini, paragrafi, video, etc. Ogni scatoletta pu\u00f2 contenere a sua volta scatolette pi\u00f9 piccole, ad esempio un paragrafo pu\u00f2 contenere del testo e delle scatolette che contengono titoli di libri, o una scatoletta tabella pu\u00f2 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<\/strong>, gli si dice cosa fare o come comportarsi con il loro contenuto. Per chi gli piacciono questo genere di cose \u00e8 anche divertente. A me diverte, se so come farlo.<\/p>\r\n

Anyway<\/em>. Qui nasce un problema per gli ebook. Ovvero che gli ebook sono paginati<\/strong>, sono divisi in pagine. Queste pagine non sono reali, sono virtuali, vivono in reflow. Cosa voglio dire che non esistono: voglio dire che \u2013 ad esempio \u2013 non ce ne \u00e8 traccia nella DOM<\/acronym>. Il fatto che non esistano nella DOM fa s\u00ec che tutte le regole che noi diamo alle scatolette, in genere, non possono essere relazionate alle pagine<\/strong>. Possiamo dire che una immagine \u00e8 alta il 50% della scatoletta che la contiene, ma non il 50% della pagina in cui viene visualizzata, perch\u00e9 la pagina non esiste.<\/p>\r\n

Non \u00e8 un problema solo di noi noiosi progettisti digitali, ma anche di chi deve adattare le specifiche nate per pagine web, affinch\u00e9 funzionino su documenti paged<\/em>. Si tratta di porsi problemi mai posti prima nella progettazione web:<\/p>\r\n