La Fattoria Dolcemiele

Ciao!

Mi riaffaccio da queste parti dopo un periodo di assenza forzata, costretto da impegni imprevisti su fronti editoriali più ‘tradizionali’.

Rientro ‘col botto’ perché ho appena pubblicato un nuovo ePub interattivo e questa mi sembra l’occasione migliore per parlartene.

Il titolo è La Fattoria Dolcemiele, Sviluppato sulle tavole (e con il prezioso supporto) di Valeria Branca l’epub si compone di dieci pagine zeppe di interattivà, animazioni e commenti sonori.

Le pagine sono ambientate in una simpatica e coloratissima fattoria e il piccolo lettore dovrà accompagnare Greta e gli altri personaggi nelle loro faccende quotidiane.

Il sistema di help è pratico, funzionale e sempre a portata di ‘dito’.

Dal punto di vista tecnico il libro è assolutamente in linea con lo standard ePub 3.0. Le animazioni sono in puro CSS3 e l’interattività è pilotata da javascript. L’esperienza di lettura e di gioco è fluida e piacevole.

Allego la copertina animata che sta strappando moltissimo consenso, ma non lasciarti ingannare: le altre pagine sono molto meglio 🙂

Su iBooksStore a 3,99 euro 0,99 euro nell’occasione dell’imminente lancio della versione in inglese. Per iPad e Mac (con Yosemite)

Condivisioni e un po’ di promozione da parte tua saranno assolutamente graditi.

E per qualsiasi critica o commento puoi scrivere qui sotto come sempre; ti aspetto.

Ciao!

Fixed layout 2 – Facciamolo dondolare …

ROBERT DOISNEAU – La-dent, Paris 1956

… proseguo da dove eravamo rimasti.

Ora che l’elemento è nella corretta posizione e isolato dal resto del contesto, possiamo animarlo.

L’idea era quella di mettere in moto la catena in modo che al tocco di un  dito effettuasse una semplice oscillazione.

Separiamo l’argomento in due momenti distinti:  il primo che chiama in causa CSS3 (è l’animazione pura dell’attore) mentre il secondo necessita di qualche riga di codice (javascript) che avvii l’animazione solo al momento del tocco.

1. Animazione

nel post precedente avevamo definito il posizionamento dell’attore-catena tramite qualche riga di CSS:

#i11b {
z-index:1;
top: 681px;
left: 1082px;
position: absolute;
}

Queste espressioni, come sappiamo, si chiamano stili perché ‘spiegano’ con quale ‘stile’ l’oggetto si disporrà sulla scena. Ma, grazie a CSS3, possiamo definire anche il modo con cui si muoverà sulla scena arricchendo lo stile di informazioni dinamiche.

Mi spiego prima con le parole:

voglio che la catena oscilli con una determinata velocità, ruotando di un certo numero di gradi attorno ad un punto ben preciso.

Non vi tedio con la trattazione completa di sintassi e parametri, reperibile ovunque sul web, vi basti sapere che:

la rotazione attorno ad un punto implica (ma è ovvio no?) la definizione di un punto attorno al quale deve svilupparsi la trasformazione:

Qusto punto è detto centro o origine della trasformazione e si esprime in questo modo

-webkit-transform-origin: X% Y%;

dove X% e Y% rappresentano la posizione (valore percentuale) lungo X e lungo Y del centro della trasformazione

riprendiamo la nostra catena e individuiamo visivamente questo centro:

Quantificando quello che l’occhio vede (non è indispensabile una precisione assoluta) e ricordando che il sistema di riferimento ha origine in alto a sinistra, possiamo dire che le coordinate del centro della trasformazione sono quelle di un punto che si trova al 50% della dimensione dell’oggetto lungo X e al 3% lungo Y.

l’espressione del centro della trasformazione darà dunque:

-webkit-transform-origin: 50% 3%;

Bene. Ma di quale trasformazione si tratta? Dobbiamo ancora dichiarare che vogliamo che sia una rotazione. Questa la sintassi corretta:

-webkit-transform: rotate(0deg);

Questa riga oltre a definire il tipo di trasformazione ‘fissa’ praticamente la condizione di rotazione dell’oggetto (0 gradi) nel momento in cui la pagina viene caricata. Ragionando in termini temporali, rappresenta l’istante ‘zero’

Supponiamo di volere che la nostra oscillazione completi una fase nel tempo di 3 secondi prima di ricominciare da capo in un ciclo infinito.

Dobbiamo definire  gli  ‘istanti significativi’ che avvengono nell’arco di questi 3 secondi.

Decidiamo che ad un quarto (25%) della durata della trasformazione la nostra catena debba arrivare ad un estremo della rotazione corrispondente a -3 gradi.

Dopo un altro quarto (50%) vogliamo che la catena si rimetta in posizione verticale (0 gradi) per poi raggiungere dopo l’ultimo quarto (75%) la rotazione di 3 gradi.

Etichettiamo l’insieme di queste fasi con un nome per esempio ‘oscillacatena‘

La sintassi per esprimere le fasi appena viste è la seguente:

@-webkit-keyframes oscillacatena {
25% { -webkit-transform: rotate(-3deg);}
50% { -webkit-transform: rotate(0deg);}
75% { -webkit-transform: rotate(3deg);}
}

Scriviamo la riga che ‘indica’ qual è la trasformazione da eseguire, quali gli istanti significativi e quale il modo con cui la trasformazione deve essere condotta:

-webkit-animation: oscillacatena linear 3s infinite;

leggiamola per chiarezza: la trasformazione deve avvenire in modo lineare secondo gli istanti significativi espressi nelle righe ‘oscillacatena’, deve durare 3 secondi e poi ripartire in un ciclo infinito.

Rimettendo tutto assieme, otteniamo lo stile completo per il nostro attore catena:

#i11b {
z-index:1;
top: 681px;
left: 1082px;
position: absolute;
-webkit-animation: oscillacatena linear 3s infinite;
-webkit-transform-origin: 50% 3%;
-webkit-transform: rotate(0deg); 
}

@-webkit-keyframes oscillacatena {
25% { -webkit-transform: rotate(-3deg);}
50% { -webkit-transform: rotate(0deg);}
75% { -webkit-transform: rotate(3deg);}
}

da questa pagina potete vedere qualche esempio di comportamento al variare di alcuni parametri

Bene. Abbiamo completato un nuovo passo. Adesso il nostro attore è in posizione corretta, su un livello a se stante e in movimento.

Nel prossimo post vedremo come attivare il movimento sl tocco di un dito: l’interattività.

Advercomics! il Fumetto nella Comunicazione Commerciale

La copertina della guida

Il lavoro puntuale e dettagliato sugli Advercomics – condiviso nel tempo da DaZa (aka Davide Zamberlan 🙂 ) sul suo blog è stato curato, ampliato e riorganizzato dall’autore. Ne è nata una preziosa guida per … introdurre e promuovere le potenzialità del Fumetto nella comunicazione commerciale e promozionale, dallo spazio pubblicitario al gadget realizzato appositamente, dalla documentazione tecnica del prodotto alle applicazioni nei nuovi scenari del web 2.0.

Questa la presentazione ufficiale presa dal sito di DaZa:

Il Fumetto, diversamente a quanto si può pensare, è particolarmente adatto a veicolare comunicazioni promozionali. Le qualità intrinseche del connubio parola/disegno e della sequenzialità
temporale – immediatezza, appeal, capacità di raccontare e persuadere – lo rendono uno strumento efficace e versatile.

L’ Advercomic (advertising + comic) è in grado di attirare l’attenzione dei clienti e di raggiungere un ampio pubblico. Attiva un processo comunicativo coinvolgente, veicolando valori e filosofia dell’azienda con simpatia e creatività. Più economico e semplice da realizzare di uno spot o un’animazione, produce le stesse emozioni, racconta storie e può facilmente diventare virale e muoversi su tablet, smartphone, web e di lì tornare su carta. La grande varietà di stili grafici che può abbracciare, inoltre, gli consente di sposare i più diversi contesti.

“Advercomics! Guida al Fumetto nella Comunicazione Commerciale” vuole essere un piccolo manuale per autori, agenzie grafiche e aziende per conoscere e sfruttare le potenzialità di questo mezzo.

Il titolo è disponibile sia in versione PDF che in versione ePub 3.0 nell’edizione curata da ePubPublishing per iPad (o Readium).
Entrambe le versioni sono disponibili al solo costo di un tweet o di un post su FB dai links indicati di seguito.

Specifiche  tecniche
L’ePub è in formato fixed layout.
L’effetto di apertura/chiusura delle tavole illustrate è attenuta tramite CSS3 appoggiato a javascript.
Gli elementi grafici che identificano gli inizi dei vari capitoli e l’indicazione numerica delle didascalie sono espressi esclusivamente tramite SVG.

Questi i link ufficiali:

• Versione ePub:

• 

• Versione pdf

• 

_____

Chiudo con la graditissima dedica ricevuta da DaZa alla chiusura del lavoro.

Brucare libri

Laboratorio di Tecnologie Audiovisive

di Roberto Maragliano

“<No, io leggo solo su carta. Vuoi mettere il profumo dei libri?>: questo è quello che mi dice l’80% di quelli con cui parlo di ebook. Io ero (cioè, in parte lo sono ancora) una capra: le mie letture andavano a stagioni e variavano in funzione della mia vicinanza a una libreria. Adesso (post Kindle) sto diventando una lettrice vorace anche se un po’ disordinata. Mi viene da domandarmi se gli ebook siano un sostituito dei libri di carta o se in realtà servano a incoraggiare le capre (come me) alla lettura”.

Questa frase m’è capitata sotto gli occhi, grazie al motore di ricerca. L’ha messa su Facebook quasi due anni fa Rossella Cenini, alla quale ho chiesto, assieme all’amicizia, l’autorizzazione a riportarla qui, come ulteriore tassello di un discorso sulle metamorfosi in atto della forma libro.
Perché, quelli che ci seguono lo sanno, questo blog si…

View original post 518 altre parole

Immagini e licenze… grazie Creative Commons!

Grazie Sara! Concordo: non è solo questione di legalità. Bisogna recuperare un’attenzione oggi troppo facilmente ‘dimenticabile’ e non solo in ambito didattico.

Quello che mi APpare

Lo sai che se trovi un’immagine in internet questo non significa che tu possa usarla come vuoi?

Il fatto di pubblicare una tua opera in rete non significa che stai cedendo i tuoi diritti, anzi. Se su una fotografia non trovi scritto @Copyright o altro, questo non significa che hai il diritto di usarla come vuoi. Anzi. Se non ci sono indicazioni precise il diritto rimane IN CAPO ALL’AUTORE.

Sono molto grata a chi scatta immagini originali e straordinariee le mette a disposizione su Flickr o altre piattaforme con una licenza Creative Commons. Questo mi ha consentito spesso di inserire, nelle mie presentazioni o su siti e blog, immagini specifiche per veicolare concetti che difficilmente sarebbero stati compresi altrettanto bene.

Se trovo immagini con licenze Creative Commons, però, vado a leggere la licenza… e la rispetto. E anche se poi scaricare l’immagine e mettere i credits è più…

View original post 184 altre parole

Anya e il suo fantasma

Condivido! Ho trovato originale anch’io il meccanismo di immedesimazione di chi legge :-).

Libringioco

Ciao a tutti, nel fine settimana ho letto Anya e il suo fantasma (Anya’s Ghost) una graphic novel scritta e illustrata da Vera Brosgol, pubblicata dalla casa editrice Bao nel 2013 nella traduzione di Caterina Marietti. L’autrice vanta la collaborazione allo storyboard dell’animazione di Coraline di Neil Gaiman che, da parte sua, ha definito Anya e il suo fantasma un capolavoro. Non mi fido dei giudizi iperbolici. E’ vero comunque che lo storytelling intrattiene e incanta e che, graficamente, lo stile cartoon adottato da Vera è gradevole per i lettori di tutte le età. Senza dubbio vincente è stata inoltre la scelta di utilizzare il bianco, il nero e tutta la scala dei grigi, colori azzeccatissimi per una ghost story. Pronti alla spoilerata?

View original post 707 altre parole

Limeriz – Limericks all’italiana

Ciao!

con questo nuovo post ti presento un altro interessante ePub che ho sviluppato sui disegni e sui testi del grande Riz (Rino Zanchetta): I Limeriz

L’idea iniziale ha preso ispirazione dal Limerick … che è (cito wikipedia) un breve componimento in poesia, tipico della lingua inglese, dalle ferree regole (nonostante le infinite eccezioni), di contenuto nonsense, umoristico o scapigliato, che ha generalmente il proposito di far ridere o quantomeno sorridere.

Riz ne ha inventato qualcuno e, come dice bene nella presentazione del libro, si è divertito ad immaginarli, a scriverne i testi e a disegnarli.

Nella fase successiva le tavole sono state ‘lavorate’ da me con l’aggiunta di un effetto parallasse che, in un simpatico gioco di fusione tra cartaceo e digitale, ha reso piacevolissima la lettura.

Muovendo il mouse sullo schermo del computer oppure inclinando il tablet le tavole si animano e prendono magicamente vita.

Il libro è scritto secondo standard ePub 3.0 (con codice html5 e animazioni CSS3 pilotate da Javascript).

È un ePub a layout fisso (*) ed è disponibile gratuitamente su iBooksStore per iPad e per iBooks su Mac (sistemi operativi Mavericks o Yosemite).

È in lavorazione la versione App (anche per sistemi Android).

Ti invito caldamente a scaricarlo e sopratutto e fare una recensione scritta con l’aggiunta di qualche stellina di gradimento.

Nella colonna di destra i links per il download.

Fammi sapere se ti è piaciuto.

Ciao!

A presto

JP

[(*) spero che i ‘polemici’ poco corretti di questi giorni non si attacchino anche qui: non sta scritto da nessuna parte che tutto può (e deve) essere fatto esclusivamente in reflowable! Orticelli da coltivare?]

 

 

Da piccolo farò lo scienziato …

Raramente ospito sulle mie pagine lanci di esperienze editoriali. Per paradosso (e a maggior ragione), non lo faccio neanche quando intravedo possa trattarsi di un’esperienza interessante, perché credo poco che una buona idea abbia bisogno di spinte volutamente forzate per farsi conoscere. Con tutti i mezzi ‘social’ disponibili oggi, se un’idea è buona prima o poi emerge alla grande da sola.

Ma nel caso di PLaNCK! ho deciso di fare un’eccezione. Per vari motivi:

Perchè si tratta di un progetto unico nel suo genere perlomeno in Italia.

Perchè idealmente ma in modo magistrale, collega il mondo universitario ad una platea giovanissima (9-11 anni). Aprendo infatti le porte dei laboratori e raccontando l’attività scientifica che vi si  svolge  all’interno, tenta di compiere di fatto la ‘terza mission’ dell’Università, cioè la costituzione di un ‘patrimonio sociale’ di conoscenza mediante la condivisione della cultura scientifica.

Per il metodo utilizzato dallo staff che unisce il rigore scientifico al divertimento, avvicinando di fatto i più piccoli non più all’Università come ad un qualcosa di lontano e misterioso, quanto piuttosto ad un luogo accessibile, appassionante e assolutamente ‘reale’.

E infine per la scelta di pubblicare la rivista bifronte in due lingue: utile sia per gli studenti di lingua non italiana, sia per permettere l’ampliamento delle conoscenze tecnico-linguistiche del bambino.

Tutto questo è la rivista PLaNCK! , frutto dell’intuizione di Agnese Sonato e Marta Carli, due dottorande dell’Università di Padova e realizzato da uno staff di una decina di persone col sostegno dei Dipartimenti di Fisica e di Chimica.

Dopo la pubblicazione di un numero pilota (scaricabile gratuitamente da questo pagina), verificato dal vivo con i bambini in classe è prevista per il prossimo gennaio l’uscita del numero uno sul tema La Luce e l’Ottica. Proprio in preparazione all’uscita del numero uno, la redazione ha organizzato un evento parallelo che avrà luogo venerdì 13 dicembre a partire dalle 15:00 presso il Dipartimento di Fisica e Astronomia.

I dettagli completi direttamente sul sito di PLaNCK!

Suggerisco di seguire il progetto perché merita veramente…

Links e contatti:

Homepage

Abbonamenti 2014

redazione@planck-magazine.it

facebook

Fixed Layout 3 – Tocchi interattivi

ROBERT DOISNEAU – Les tabliers de la rue de Rivoli, Paris, 1978

[… continua]

Già, adesso il nostro attore è in movimento, ma noi vogliamo che si muova solo a comando, o meglio ‘a tocco’.

Questo vuol dire innanzitutto che nella condizione iniziale, nel cosiddetto momento ‘0’ il nostro oggetto deve trovarsi fermo.

Per questo scopo introduciamo una nuova istruzione con il compito di definire lo stato dell’animazione.

-webkit-animation-play-state: paused;

Può assumere i valori paused e running ad indicare banalmente se l’animazione è in pausa o attiva:

Ricompletiamo lo stile:

#i11b {
 z-index:1;
 top: 681px;
 left: 1082px;
 position: absolute;
 -webkit-animation: oscillacatena linear 3s infinite;
 -webkit-transform-origin: 50% 3%;
 -webkit-transform: rotate(0deg); 
 -webkit-animation-play-state: paused;
}

@-webkit-keyframes oscillacatena {
 25% { -webkit-transform: rotate(-3deg);}
 50% { -webkit-transform: rotate(0deg);}
 75% { -webkit-transform: rotate(3deg);}
}

Nell’istruzione appena vista, l’animazione pur contenendo tutta la potenzialità dinamica, è di fatto ferma e congelata all’istante ‘0’ in attesa di un nostro intervento.

Esatto; il nostro intervento.

O meglio l’interattività

Perché il nostro ‘dito’ possa interagire con l’attore, bisogna innanzitutto che l’attore stesso sia ‘disposto’ a recepire il nostro tocco e in secondo luogo che all’interno del codice ci sia qualche riga che dia il via alla trasformazione espressa nello stile.

Per il primo punto dobbiamo semplicemente rendere ‘sensibile’ all’input la nostra catena. Uno dei metodi per ottenere questo scopo è modificare la riga di dichiarazione

<img id="i11b” src=“../immagini/img11/i11catena.png"

alt=“la catena si scatena"/>

Trasformandola in sorgente di input:

<input type="image" id="i11b” src="../immagini/img11/i11catena.png"

onclick=“dondola();” alt="la catena si scatena"/>

Le due parti importanti sono sottolineate: quando l’immagine definita con id = “i11b” viene toccata verrà avviata la funzione “dondola()”

Cosa conterrà la funzione dondola()? Ovviamente l’istruzione per fare partire l’animazione “oscillacatena”

La scrivo e poi la spiego:

document.getElementById("i11b”).style.webkitAnimationPlayState = 'running';

Da destra a sinistra diventa abbastanza leggibile: rendiamo attivo lo stato dell’animazione definita nello stile dell’elemento i11b del documento

Praticamente viene espressa una modifica di stile  da paused a running allo stato dell’animazione legata all’oggetto avente id = “i11b”

La riga deve essere inserita all’interno della funzione dondola() secondo la sintassi canonica:

dondola() {
document.getElementById("i11b”).style.webkitAnimationPlayState = 'running';
}

Da questa pagina un esempio. Facendo click sulla catena inizia l’oscillazione.

Streghette Combinaguai – Il promo

Utilizzando ritagli, schizzi e note messi da parte durante la lavorazione della versione ePub di Streghette Combinaguai è nato, quasi senza volerlo,  un simpatico filmato promozionale che condivido con voi.

Il filmato in questi giorni sta facendo da ‘spalla’ ai  lavori che  Elisa ed io abbiamo iscritto al contest Bit Bum Bam.

Fateci un giro e  se siete iscritti a FB, magari ‘schiacciate’ anche un ‘mi piace’ di sostegno. I voti non sono discriminanti per l’esito finale, ma aiutano eccome. Anche perché è possibile votare una volta al giorno,

Fixed layout 1 – Lezioni di geometria …

ROBERT DOISNEAU – L’ information scolaire – Paris-1956

Come promesso inizio a pubblicare alcuni post sulle tecniche utilizzate in ‘Streghette Combianaguai’

Partirò dal semplice posizionamento di un elemento in una pagina di un Fixed Layout, e in una serie di step in sequenza arriverò, alla sua animazione CSS. L’idea come mio solito non è quella di proporre la soluzione migliore, quanto un metodo soddisfacente per affrontare le varie problematiche. Ricordo che conoscere i procedimenti e i metodi per fare le cose a mano  è la cosa migliore per avere veramente in mano l’argomento. Solo a questo punto ci si può permettere di utilizzare soluzioni automatizzate. Mai il contrario

1) Creazione dell’elemento da animare e posizionamento tramite CSS

Sarebbe un’ottima cosa se il lavoro nascesse con gli attori già impostati e isolati ciascuno sul proprio livello e con le immagini di fondo già in formato viewport, ma questo è possibile solo nell’ipotesi di partire da zero con i disegni e ovviamente presuppone uno studio a priori del formato e di tutte le caratteristiche animate del futuro libro. Ma non sempre si parte da zero.

Nel lavoro delle Streghette ho dovuto effettuare il porting da una versione esistente in PDF (versione piana e statica su carta).

Le esigenze principali erano quelle di uniformare le dimensioni delle immagini di fondo a quelle scelte per la viewport e in seconda istanza di staccare gli attori da tutto il resto e posizionarli su un diverso livello.

Normalizzazione delle dimensioni delle immagini di fondo

Supponiamo di avere stabilito per il nostro Layout una viewport di 1600 x 1200 pixel.

L’immagine di background dovrà avere quelle dimensioni. La prima operazione sarà dunque quella di uniformare il formato dell’immagine alle dimensioni stabilite. Qualche taglio di zone ininfluenti ai bordi (e se occorre anche qualche leggerissimo ridimensionamento non proporzionale) ci portano facilmente alle proporzioni dovute. Salviamo in jpg (senza profili colore).

Isolamento delle parti da rendere attive

Utilizzando un editor di immagini (per gli esempi di questo post utilizzo Graphic Converter della tedesca Lemke Software) si procede selezionando l’area rettangolare che contiene l’oggetto da rendere attivo.

Copiamo e incolliamo su un nuovo livello e uilizzando gli strumenti di ritocco forniti dell’editor, eliminiamo dall’immagine di fondo l’attore ricucendo lo strappo generato sul fondo e dall’area sul nuovo livello la parte di fondo che inevitabilmente ci siamo portati dietro.

Operata la pulizia (senza dimenticare eventuali buchi) si seleziona l’attore con un’area rettangolare appena sufficiente per contenerlo tutto e si prende nota delle coordinate della selezione. Se abbiamo lavorato secondo le specifiche di dimensioni di viewport decise per l’epub, queste coordinate sono esattamente quelle da inserire nel CSS come valori di posizionamento del nostro attore.

Copia e incolla in un documento nuovo, ecco creato il file che rappresenta il nostro oggetto da rendere animato. Salviamo in png per mantenere la trasparenza prestando attenzione a non incorporare profili che non servono e anzi, aumentano il peso dell’immagine.

Risalviamo in jpeg l’immagine di fondo aggiornata.

Un quadernaccio su cui annotare al volo coordinate, eventuali note, modifiche, cancellazioni, spunti e appunti vari è l’invenzione più utile e da tenere cara per future e molto probabili revisioni.

Procedendo così abbiamo ottenuto due immagini: fondo e attore.

Supponendo che vadano entrambi sulla pagina 11 avremo avuto cura di salvarli con nomi appropriati e di dichiararli nel file .opf

Sull’attribuzione dei nomi avevo già scritto qualcosina in questo post ne consiglio una veloce rilettura.

Supponiamo di avere scelto questi nomi:  i11fondo.jpg    e    i11catena.png.

All’interno della struttura dell’epub creiamo una cartella immagini e al suo interno una cartella che chiamiamo per esempio img11 e nella quale depositiamo i due contributi.

Dichiarazione all’interno del file .opf

La dichiarazione è banale. Raccomando di operare una scelta opportuna degli id e di prestare attenzione ad avere ordine nella nomenclatura perché libri di questo tipo si riempiono presto di tantissimi elementi e la pulizia aiuta nella stesura presente e soprattutto nella revisione per future riedizioni.

 <!–images–>

<item id=”i11a” href=“immagini/img11/i11fondo.jpg” media-type=”image/jpeg” />

<item id=“i11b” href=”immagini/img11/i11catena.png” media-type=”image/png” />

…

Inserimento sulla pagina e posizionamento tramite CSS

Ci siamo. Possiamo inserire l’attore ‘i11catena.png’ sulla pagina.

Non insegno niente a nessuno perché l’inserimento segue le specifiche HTML nude e crude.

<img id=”i11b” src=“../immagini/img11/i11catena.png” alt=“la catena si scatena”/>

Idem per la definizione CSS

#i11b {

z-index:1;

top: 681px;

left: 1082px;

position: absolute;

}

Fatto! Adesso il nostro attore-catena è presente sulla pagina, si trova nella corretta posizione e su un livello a se stante rispetto all’immagine di fondo.

[continua …]

Curiose, dispettose, disubbidienti e indisponenti …

Streghette Combinaguai – La cover

… ma anche terribilmente simpatiche.

Si sono fatte desiderare ma alla fine eccole qua: Le Streghette Combinaguai.

Il nuovo lavoro di Elisa, nella versione interattiva curata da me è finalmente disponibile su iBookstore.

Quattro piccole streghe pasticcione stanno per mettersi nei guai! Non hanno molta voglia di studiare ma moltissima di combinare disastri. E quando si mettono in testa di cercare nella stanze della scuola di stregoneria il libro con gli incantesimi stregosi incominciano a farne di tutti i colori.

Pur essendo destinato ad un pubblico di giovani lettori, questo libro contiene tutti gli ingredienti utili per chi vuole conoscere tecniche, metodi e regole per la scrittura di un ePub di questo tipo mantenendosi nei binari dello standard 3.0.

Questo il link per scaricare la versione per iPad (assolutamente gratuita).

A breve inizierò a postare una serie di contenuti sulle principali tecniche utilizzate.

A voi commenti, contributi e … condivisione!

iBookstore aggiornamento importante

A stack of books_by antony ruggiero (dreegez)

Con il recentissimo aggiornamento dell’iBooks Asset Guide alla revisione 2 della versione 5.1, Apple ha fatto chiarezza su alcuni punti che potevano essere fraintesi in fase di caricamento delle componenti dell’epub con iTunes Producer e ha introdotto di fatto qualche interessanti novità.

Vediamole punto per punto:

Interattività Javascript.

Come avevo accennato in questo post di lancio, a partire dalla versione 10.9 (Mavericks) del Sistema Operativo OS X, Apple introdurrà l’app iBooks anche su computer. Per chi ‘crea’ epub l’utilizzo di gestori di eventi ‘touch’ non sarà più sufficiente per poter rendere fruibili i propri libri sia in versione ‘mobile’ che in versione ‘desktop’; si dovranno prevedere anche gli eventi legati al mouse. A seconda del ‘device’ su cui il libro si apre verranno ‘ascoltati’ solo gli eventi interessati. In un prossimo post entrerò nel dettaglio tecnico.

Sempre rispetto al’’interattività, ricordo un’attenzione particolare al ‘peso’ degli script. Troppa interattività riduce drasticamente le performances e la fruizione ne risulta danneggiata. Vale sempre il consiglio principe di utilizzare il più possibile animazioni CSS3 e usare il codice Javascript solo per attivarle o temporizzarle.

Aggiornamento della versione di un eBook: un’attenzione particolare.

Apple raccomanda un’attenzione particolare quando si genera e pubblica un aggiornamento di un libro: è importante mantenere gli stessi ‘legami’ tra id  e le relative pagine xhtml utilizzate nella prima versione pubblicata, anche se si aggiungono capitoli o se ne modifica l’ordine sequenziale.

Faccio un esempio perché sembra una cosa ovvia, ma ha creato a molte persone (anche editori importanti) non pochi problemi:

Nelle riga seguente si vede la dichiarazione di una pagina nel file .opf.

…

<item id=”p02″ href=”pages/p0203.xhtml” media-type=”application/xhtml+xml” />

….

L’id “p02” fa riferimento alle pagine denominate “p0203.xhtml”

Supponiamo che un utente legga proprio  quelle pagine e vi faccia qualche annotazione personale.

Se in una versione successiva, magari un ampliamento del libro con l’aggiunta di capitoli, viene ‘rotto’ questo collegamento tra l’id “p02” e la pagina “p0203.xhtml” il lettore, dopo aver scaricato l’aggiornamento si troverà le proprie annotazioni in un altro capitolo del libro.

Titoli in lingua Giapponese o Cinese per i flowing books (a chiarimento)

Lo scroll del testo in queste due lingue avviene orizzontalmente al contrario di tutte le altre lingue.

Adesso è possibile gestire questa cosa direttamente nel file .opf utilizzando la proprietà “ibooks:scroll-axis” i cui possibili valori sono ‘vertical’, ‘horizontal’ e ‘default’

Utilizzo di fonts in lingua Giapponese (a chiarimento)

I seguenti 5 fonts sono disponibili al sistema e quindi utilizzabili

• Hiragino Kaku ProN
• Hiragino Mincho ProN
• Hiragino Maru Gothic ProN
• YuGothic
• YuMincho

ma mentre i primi due sono pre-caricati (e quindi consigliati), gli altri tre devono ogni volta essere scaricati dal lettore prima di essere disponibili

Copertina per lo Store (a chiarimento)

È la copertina che viene caricata durante l’upload dell’asset del libro e non quella contenuta all’interno del libro (per assurdo potrebbe addirittura avere un’altro contenuto).

È il primo strumento di marketing che abbiamo e quindi molto importante.

Le caratteristiche richieste sono:

Modo colore: RGB;

Dimensione lato corto: almeno 1400 pixel;

Per ottenere migliori risultati viene suggerita una risoluzione minima di 300 dpi.

Screenshots per lo Store (a chiarimento)

Sono le immagini che vengono caricate durante l’upload dell’asset del libro e non quelle realmente contenute all’interno del libro. Anche queste sono molto importanti per la promozione del nostro libro. Il chiarimento ‘ufficiale’ serve a spiegare meglio la possibilità che nei nostri screenshots sia presente o meno la ‘status bar’.

Queste le dimensioni ufficiali:

1024 x 768: (iPad1 e iPad2 con orientamento orizzontale)

1024 x 748: (iPad1 e iPad2 con orientamento orizzontale ed eliminazione della barra di stato )

768 x 1024: (iPad1 e iPad2 con orientamento verticale)

768 x 1004: (iPad1 e iPad2 con orientamento verticale ed eliminazione della barra di stato )

2048 x 1536: (iPad3 con orientamento orizzontale)

2048 x 1496: (iPad3 con orientamento orizzontale ed eliminazione della barra di stato )

1536 x 2048: (iPad3 con orientamento verticale)

1536 x 2008: (iPad3 con orientamento verticale ed eliminazione della barra di stato )

Immagini contenute nel libro (a chiarimento)

Per tutte le immagini interne al libro (copertina compresa) è adesso accettato per le dimensioni il limite superiore di 3.2 milioni di pixel. L’incremento rispetto al precedente limite (2,0 milioni di pixel) è notevole.

Ricordo che per verificare il limite basta moltiplicare le dimensioni in pixel della base per quelle dell’altezza.

iBooks arriva anche su Mac: cosa cambia?

Mavericks, il nuovo sistema operativo per Mac annunciato da Apple e atteso a breve, includerà tra le altre anche la novità di incorporare una versione di iBooks.

La cosa è interessante  dal punto di vista dell’utente che potrà  leggere i libri anche su computer (la versione sarà sincronizzata con tutte le altre librerie presenti sui propri iPad, iPhone e iPod touch)

Ma si tratta di una novità significativa anche per noi sviluppatori. specialmente per quel che riguarda i libri con funzionalità interattive magari  supportate da Javascript. Un utente infatti potrà accedere ai propri libri sia su periferiche iOS che su computer con OS X. Ma mentre su periferiche iOS l’interattività avviene tramite ‘tocco’, su macchine con OS X  avviene tramite eventi del mouse.

Va da se che chi produce dovrà  prevedere e supportare contemporaneamente entrambe le possibilità.

Nei prossimi giorni descriverò alcuni spunti sull’argomento.

Letture estive

Ancora gli ultimi giorni di ferie in attesa di settembre. La ripresa sarà ricca di post tecnici e vedrà la pubblicazione di un nuovo ePub interattivo basato su un altro libro per bambini illustrato da Elisa Favi assieme ad altre sorprese rivolte sempre ai piccoli lettori.
In attesa di queste novità condivido con voi una serie di guest-post proposti dagli amici di eBookReader Italia
Buona lettura

Condivisione digitale tra biblioteche.

Ogni tanto arriva qualche buona notizia!

Ne avevo già parlato precedentemente e approfitto volentieri dell’articolo pubblicato oggi da Alessia Rastelli su EHI BOOK per rilanciare la notizia e ri-condividere il suo articolo.

Il servizio di prestito digitale per l’utente finale è già in funzione dal 2011, ma acquisisce nuove opportunità:

a partire da Ottobre entra in funzione il servizio di prestito interbibliotecario per i contenuti digitali. Il sistema è messo a punto da MediaLibraryOnline (MIOL) e le biblioteche pubbliche aderenti al circuito sono attualmente circa 3ooo. Spiega Giulio Blasi, amministratore delegato della società che ha ideato MediaLibrary (Horizons Unlimited,). «La biblioteca riceve online la richiesta dell’utente, se non possiede l’ebook lo ordina, lo ottiene istantaneamente da un’altra biblioteca e può darlo in prestito. Per i lettori vuol dire un’offerta molto più ampia e immediata».

Qui l’articolo originale di Alessia

Principessa 2.0. Riflessioni a ruota libera

È stato appena rilasciato un importante aggiornamento per La Principessa Azzurra e il Drago Golosone. La richiesta di aggiornamento ricevuta da più parti e il successo di download, in numero ben più ampio rispetto alle più rosee aspettative, ha portato alla revisione e all’ampliamento delle parti animate e interattive. Il codice è stato limato e sono state eliminate quasi tutte le gif in favore di animazioni CSS3 più snelle e fluide. La struttura portante ovviamente è rimasta la stessa

Il successo di questo ePub, guardando oltre lo stupendo stile di Elisa o la squisita realizzazione tecnica, è dovuto ad una azzeccata miscela di diverse componenti. Le accenno sinteticamente come spunto, ma secondo me esprimono con chiarezza un ‘diverso modo’ con cui è possibile affrontare lavori di questo tipo e la cosa più interessante è che si tratta di una modalità alla portata di tutti.

Lo spunto iniziale e la sinergia tra me e l’autrice
Un concetto discutibile quanto volete, ma a me molto caro: tenere sempre presente l’intuizione iniziale, quella che ha fatto scattare la molla e ci ha fatto dire: ‘potremmo realizzarne un ePub’. In quel preciso momento prendono forma idee, spunti, immaginazioni su come ‘avremmo voluto’ che fosse quel libro. Tenere presente questo aiuta a mantenersi ancorati all’idea portante senza lasciarsi distrarre dalle ‘cose’ tecniche che inevitabilmente tendono a prendere il sopravvento. Altrimenti si perde di vista l’obiettivo finale e si genera un prodotto ‘distante’ da chi lo dovrà utilizzare. Il target di questo libro era un pubblico giovanissimo. Complicare certe situazioni o renderle troppo ‘automatizzate’ avrebbe tolto parecchio spazio alla fantasia del bambino/lettore. Eppure ho rischiato più di una volta di cascare nell’errore. Il richiamo alla molla iniziale e qualche benevola puntualizzazione da parte di Elisa hanno riportato il lavoro sul binario giusto.
Proprio questa sinergia diretta tra Elisa – autrice dei contenuti – e me – autore del contenitore epub – ha permesso una libertà estrema durante il lavoro e un’efficacia altrimenti impossibile:
I tempi di sviluppo sono risultati relativamente brevi: nessun obbligo di tempi di consegna imposti dall’editore (ma era banalmente evidente che prima avessimo finito prima avremmo pubblicato e quindi la celerità è venuta naturale).
Nessuna forzatura esterna: nessuna idea di terzi da calare nel documento, nessuna imposizione editoriale sui diritti dell’opera o comunque nessun suggerimento ‘affettuoso’ a cui essere ‘costretti’ a rispondere, ma un dialogo su cosa fare e su come farlo, accomunati semplicemente dall’obiettivo finale.

Certo, il lavoro pecca di gioventù; non avevamo un mega staff alle spalle, sicuramente la realizzazione ottenuta poteva essere più matura e adulta. Sta di fatto che ne è uscito comunque un piccolo gioiello. E i social hanno fatto il resto con il risultato che Azzurra si è posizionata ai primi posti nelle classifiche di download.

___
Proprio in questi giorni Azzurra è stata ospitata in due articoli tecnici:
il primo è apparso su eBookReaderItalia.com Il blog che dal 2009 ci racconta di ebookreaders, e di eBooks. Lo fa in maniera organica e puntuale affrontando il tema dal punto di vista tecnico ma anche da quello che definirei più ‘culturale’ sulle trasformazioni che questi strumenti si portano dietro.

Il secondo è stato presentato su COMX DOME, magazine digitale solo per iPad (almeno per ora).
Presenta argomenti di primo piano e contributi di altissimo livello uniti ad una deliziosa fruizione in lettura.

Quando le principesse vanno in cerca dei draghi…

Ho recentemente pubblicato su iBookstore la versione ePub del libretto La Principessa Azzurra e il Drago Golosone di Elisa Favi.

Lo scopo, d’accordo con l’autrice, era quello di inserire contenuti avanzati e interattivi alla base già esistente su carta e racchiudere il tutto in un ePub pienamente compatibile con lo standard 3.0 per dimostrare come CSS3 e HTML5 possano generare epubs avanzati senza essere costretti a inventarsi programmatori e scomodare le apps. Non volevamo saturare il libro con troppo animazioni ed effetti interattivi; il libro esisteva già e non volevamo snaturarlo troppo.
Ci bastava sostanzialmente condurre un esperimento per comprendere assieme, attraverso pochi ma efficaci esempi, cosa e come si potesse fare e fino a dove ci si potesse spingere.
Dopo avere verificato con Elisa file e formati, si trattava di individuare le parti sensibili e introdurre le varie componenti. Elisa si è occupata della parte grafica e io della sua implementazione nell’ePub.
Come prime componenti animate sono state introdotte alcune banalissime gif. Nessuno si scandalizzi, la cosa è voluta proprio per mostrare la banalità, come si vede nelle pagine successive, di fare la stessa cosa sfruttando le potenzialità di CSS3.

Una banalissima gif (140 Kb) o meglio un elegante CSS3 (8Kb)?

A seguire in un crescendo sempre più intenso sono state inserite componenti di animazione HTML5 con CSS3, Javascript fino a toccare a fondo l’argomento ‘canvas’.

Canvas e animazione su path

Ancora canvas con javascript

Chiaro quindi come ce ne sia per tutti i gusti e come siano ampie le possibilità offerte per chiunque desideri imparare tecniche e modi di utilizzo all’interno di un ePub.
A breve pubblicherò alcuni articoli tematici su principali argomenti affrontati nello sviluppo di questo libro.

Restate in zona!

La Principessa Azzurra e il Drago Golosone è disponibile gratuitamente su iBookstore. A breve anche in versione Inglese.

 

iBookstore nuovo aggiornamento: introdotta la specifica di libro con contenuti espliciti.

No Lifeguard On Duty sign – Toadsith’s – 8-Ago-2006 – United States

Apple ha rilasciato la versione 2.9 di iTunes Producer, il tools per pubblicare su iBookstore.
Da un punto di vista tecnico si tratta di un aggiornamento minore; le modifiche riguardano sostanzialmente la descrizione e gli attributi dei contenuti.

Queste le novità:

Inclusa la possibilità di specificare se il libro contiene o meno contenuti sessuali espliciti.
Selezionando questo flag il libro viene distribuito con un warning sui contenuti. L’account iTunes che presenti le restrizioni al download di contenuti espliciti non sarà in grado di effettuarne il download.
Inibita per questi utenti anche la visione dell’immagine di copertina e la lettura della descrizione del libro.
A tutela dei lettori, se si pubblica un libro con questa modalità e si cambia idea dopo la sua pubblicazione, l’unico modo per modificarne l’impostazione è passare attraverso il supporto Apple.

Migliorata la gestione dell’indicazione della sequenza di un titolo facente parte di una serie.
Apple ha introdotto il nuovo parametro Store Display Number.
Con questo parametro posso etichettare e nominare il volume all’interno di una serie, indipendentemente da qualsiasi numero o espressione avessi usato in fase di upload.

Caricamento screenshots
È ora possibile trascinare screenshot multipli con un semplice drag n’drop anziché caricarli uno alla volta.

Specificare se il titolo è multi-touch.
È possibile specificare se il titolo che stiamo caricando sia o meno un libro multi-touch.
Questi ultimi sono progettati esplicitamente per iPad e non per iPhone o iPod touch. L’utilizzo di questo parametro salvaguarda gli utenti possessori di questi dispositivi da download di materiale che non potrebbero utilizzare.
Il parametro è disponibile solo per titoli nuovi e non per quelli precedentemente già caricati.

Skipcoder: una soluzione completa per pubblicazioni digitali

Desidero oggi condividere con voi un interessante articolo: la presentazione di Skipcoder, soluzione completa per la realizzazione di pubblicazioni digitali a partire dalle fasi iniziali sino alla distribuzione finale del prodotto. Attualmente in fase Beta sarà disponibile al pubblico nel corso del primo semestre del 2013.

Ce ne parla Paolo Albert (*) uno dei suoi ideatori, che ci racconta la genesi e lo sviluppo di un progetto di cui sentiremo sicuramente parlare.

Perché Skipcoder?

Volevamo realizzare un libro per bambini. Lo volevamo fare animato, interattivo, multimediale. E volevamo che si potesse leggere e sfogliare su qualsiasi dispositivo elettronico, in qualsiasi lingua. Avevamo gli autori, la storia, i disegni, le voci, la musica. C’era l’idea – ce n’erano tante – ma ci mancava il programmatore.  Sì perché, per creare un applicazione, fino al 2011, era necessario programmare in codice nativo. Ovvero trasferire nelle mani di un tecnico (non di un illustratore, non di un grafico) la responsabilità di impaginare, animare, montare e confezionare l’opera. Questo non ci andava bene: volevamo avere un controllo maggiore, superare l’ostacolo del codice, oltrepassare l’aspetto tecnico e costruirci le app da noi. In autonomia.

Skipcoder è nato così, dall’esigenza di realizzare qualcosa per far giocare i nostri figli ed educarli attraverso la tecnologia. E dalla necessità di intervenire direttamente sulla nascita dell’opera digitale.

L’editoria e il futuro

Subito ci rendiamo conto che, intorno a noi, il mondo editoriale sta attraversando una fase di profondo cambiamento. Si tratta di una rivoluzione digitale: il libro come l’abbiamo conosciuto fino a oggi non sarà più lo stesso. A fianco della carta si sta aprendo un mondo fatto di pixel, di inchiostro elettronico, di schermi in retina, di interazioni, di ebook reader e di tablet di ogni forma, prezzo e dimensione. Insomma, il caos. E l’editore tradizionale, cioè chi ha il potere di distribuire la nostra opera, non sa più che pesci prendere, circondato dai nuovi protagonisti dell’editoria digitale – Amazon, Apple – che sono anche produttori dei dispositivi su cui si legge il nuovo libro.

Come si realizza un nuovo prodotto digitale? Di quali professionalità ho bisogno? Perché devo passare da uno sviluppatore per confezionare la mia app interattiva o il mio ebook? In quale formato lo distribuisco e attraverso quali canali? Domande, queste, che non hanno avuto interamente una risposta, perché l’editoria digitale sta cambiando, tutto si muove in gran fretta.

Skipcoder prende vita da un’idea piccola – un libro per bambini – ma diventa il mezzo per rispondere a problemi più grandi: uno strumento di authoring per il mondo editoriale, un software desktop a disposizione di autori ed editori per creare e pubblicare libri digitali multipiattaforma e multilingua, superando il dilemma del formato e della distribuzione.

Con un solo programma impagino, creo le animazioni, confeziono il libro scegliendo il formato tra quelli disponibili sul mercato.

Cos’è e come funziona

La genesi di Skipcoder parte dallo studio del processo di creazione: la prima release si presentava come un plug-in di Adobe InDesign, il software di impaginazione più utilizzato al mondo. Utilizzando un’interfaccia universalmente conosciuta, il grafico poteva creare tavola per tavola, importando le immagini, l’audio e i suoni e integrandoli tra loro per creare animazioni grazie a set predefiniti che sfruttavano le possibilità tecniche del dispositivo: drag, touch, pinch e così via.

La seconda release di Skipcoder si emancipa da InDesign e vive da sola. Le funzioni del programma sono molteplici:

• stabilire le caratteristiche del prodotto digitale (titoli, localizzazioni, menu di navigazione, indice, aiuti ecc)
• importare i file sorgenti (illustrazioni, disegni, testi) direttamente da InDesign
• sviluppare le interazioni sugli oggetti (animazioni, movimenti, suoni)
• simulare il funzionamento durante la realizzazione attraverso un sistema di test
• predisporre il prodotto finale per la submission ai canali di distribuzione e vendita

Il processo

Far nascere un libro digitale interattivo non è semplice. Le figure professionali coinvolte sono diverse, devono interagire tra loro e partecipare al processo di ideazione e verifica.

Tutto nasce da un concetto che diventa storyboard. Autore e illustratore agiscono in sinergia per creare la storia, visualizzarla e dotarla delle animazioni. Lo storyboard è legge: attraverso il documento che descrive le interazioni tra gli elementi, il grafico gestisce le immagini e i suoni e attraverso Skipcoder monta tavola per tavola. Alla prima versione del libro ne succedono altre, controllate dagli autori, attraverso gli strumenti di simulazione forniti dai diversi dispositivi. L’autore può così installarsi la versione provvisoria dell’app o dell’ebook per verificarne il funzionamento, e passare al grafico le modifiche. Parallelamente, i traduttori procedono a fornire la versioni in lingua, la cui integrazione è un’altra feature della piattaforma. Al termine del processo – sempre coordinato da un project manager che gestisce le risorse, i file sorgenti, le scadenze e garantisce il rispetto delle procedure condivise – il nostro libro digitale è pronto.

La nascita

Il processo di lavorazione è concluso. Il libro digitale è pronto nella sua forma grezza. L’ultimo passo è quello della finalizzazione: si sceglie il formato, a seconda del dispositivo che si vuole utilizzare, e si “chiude” il file.

Skipcoder non solo oltrepassa il codice: tra le sue innovazioni c’è anche la possibilità di salvare il libro digitale in qualsiasi formato disponibile per qualsiasi sistema operativo. Android, iOS, Windows, ePub, applicazioni. Basta scegliere.

Fatta la scelta e definite le lingue disponibili, l’editore o chi per lui può effettuare la submission sui canali di vendita e di distribuzione utilizzati dal formato e dal dispositivo scelto.

La distribuzione

La nostra idea non si esaurisce con l’impacchettamento di un prodotto digitale. Non vogliamo che sia il libro nel cassetto: vogliamo farlo conoscere, distribuirlo, farlo recensire, sapere cosa ne pensano i lettori.

Skipcoder sarà a disposizione di chiunque abbia voglia di provarci. Non ci sono costi per l’utilizzo del software: una volta creata l’app o l’ebook, si acquista una licenza di distribuzione che permette di distribuire il prodotto in rete. Che venga scaricato da 10 o da 1000 persone nulla cambia, la licenza ha sempre lo stesso prezzo.

Con Skipcoder paghi quando pubblichi, quello che pubblichi.

—

📝

(*) Paolo Albert è fondatore e amministratore di Conversa – agenzia IT nata a Torino nel 2001 – e tra gli ideatori del progetto Skipcoder. Scrive codice per ambienti web-based e per dispositivi mobili. Ha studiato Scienze Politiche e ha un Master in Political Theory alla London School of Economics di Londra. La sua formazione tecnica proviene dal campo e dal continuo aggiornamento e ricerca.

info@skipcoder.com

www.skipcoder.com

iBookstore; aggiornare la versione di un libro specificando la release

Seats – by Januszek – 31 Mar 2008 – Wadowice (Poland)

Apple ha recentemente rilasciato la versione 2.8 di iTunes Producer, il tool ‘passaggio obbligato’ per chiunque desideri preparare e caricare un titolo su iBookstore.
In questa nuova versione ha introdotto la possibilità, per gli ePub 3.0 e per i libri multi-touch, di definirne e identificarne la release.
Quando si pubblica una nuova versione di un libro esistente su iBookstore, il titolo aggiornato prende il posto del precedente e gli utenti in possesso della vecchia versione ricevono una notifica di aggiornamento.

L’utilizzo di questa nuova funzionalità è molto semplice:

Nell’elemento <package> del file .opf si deve includere il seguente prefisso:

prefix=”ibooks:http://vocabulary.itunes.apple.com/rdf/ibooks/vocabulary-extensions-1.0/&#8221;

il cui scopo è quello di introdurre il numero di release che verrà dichiarato, sempre all’interno dell’elemento <package>, in questo modo:

<meta property=”ibooks:version”>1.1</meta>

dove ‘1.1’ rappresenta appunto il numero di release.

In fase di ‘distribuzione’ con iTunes Producer, bisogna poi specificare nell’apposito box, le ‘Novità di questa versione’. Non è possibile lo skip di questo campo.

Questo è tutto.

Nell’immagine seguente la segnalazione, in iTunes Connect, che la versione 1.1 de ‘Le Illustrazioni di SteG’ appena caricata, è in fase di verifica in attesa di approvazione e pubblicazione.

Editoria Digitale: si muove finalmente qualcosa (di serio). Intervista agli ideatori di Smuuks

Diciamocelo francamente: l’editoria digitale è oggi in pieno tumulto.

Nuove soluzioni vengono proposte quotidianamente. Nascono come funghi nuove piattaforme che promettono miracoli.

Vengono sbandierati in modo selvaggio prezzi e prestazioni (giusto per stare al passo con l’agguerrita offerta proveniente dall’India !?!).

Ma raschiando, e neanche tanto, in profondità ci si accorge che ‘la polpa’ è veramente poca e che in realtà in tanti si sono buttati all’arrembaggio senza grande cognizione di causa, solo perché sorretti dal miraggio di questo ‘nuovo mercato miracoloso’.

È raro quindi incontrare nuove realtà che si presentano con idee innovative e che, forti di una grande preparazione tecnica, sono capaci perfino di generare impresa.

Questa è stata la piacevole sorpresa che ho ricevuto incontrando Edoardo Ferrini e Alberto Pettarin, i fondatori di Smuuks.

Condivido in questo post il dialogo avuto con loro.

Seguiamoli con attenzione perché hanno parecchio da dire e fanno terribilmente sul serio.

Qual è il modo migliore per descrivere Smuuks?

Siamo tipografi digitali a cui piace esplorare con metodo rigoroso le potenzialità offerte dai libri elettronici. Il nostro obiettivo consiste nell’ottimizzazione dell’esperienza di fruizione dei contenuti da parte del Lettore.

Come è nata l’idea di Smuuks? 

L’idea di fondare Smuuks è nata a Giugno 2012. Quando siamo entrati in contatto, abbiamo avvertito l’opportunità di costituire una squadra di lavoro per condividere le rispettive competenze. Abbiamo fondato Smuuks perché pensiamo di poter contribuire concretamente alla crescita del settore editoriale digitale italiano, soprattutto dal punto di vista tecnico. Questo proposito nasce anche dall’osservazione del deludente stato attuale degli eBook in Italia: le eccezioni, purtroppo, si contano sulle dita di una mano.

L’offerta di servizi avanzati per l’editoria digitale è oggi sempre più ampia. Perché dovrei preferire Smuuks? Quali sono i suoi punti di forza?

Smuuks vuole differenziarsi da analoghi servizi per l’editoria digitale principalmente per due aspetti. Innazitutto, avendo la qualità del “eBook finito” come obiettivo principale. Prima che addetti ai lavori, siamo noi stessi lettori e abbiamo più volte sperimentato la frustrazione di veder mortificata l’opera di un autore che amiamo da una scadente edizione digitale. Il nostro primo obiettivo è far sì che i Lettori dei nostri eBook non provino mai questa spiacevole esperienza, ma anzi apprezzino il “valore aggiunto” dato dall’edizione elettronica. Già questo concetto, che a noi pare naturale, sembra essere alieno a molti “produttori” di eBook che operano in Italia. In secondo luogo, siamo sperimentatori. Ci piace pensarci come “artigiani del libro digitale”. Usiamo il termine “artigiano” non nell’accezione di “amatoriale, dilettantistico” ma per sottolineare la volontà di sfruttare le nostre competenze tecniche per rendere il più efficiente e personale possibile il canale di comunicazione tra Autore e Lettore costuito dall’opera elettronica. Le nostre scelte tecniche e tipografiche non sono casuali, ma emergono da uno studio scientifico: dall’osservazione delle effettive modalità di fruizione degli eBook da parte dei Lettori, dalla conoscenza e dall’esplorazione delle possibilità tecniche dei vari dispositivi di lettura e dei vari formati.

Il settore editoriale digitale di questi tempi è un fiume in piena, ma offerta ampia non implica automaticamente alta qualità: tutti parlano di ePub, ma pochi probabilmente ci capiscono a fondo. Cosa, secondo voi potrebbe fare emergere realtà innovative, stimolare nuove idee e lanciare nuova impresa?

Hai colto nel segno: come dicevamo prima, abbiamo deciso di fondare Smuuks anche considerando il deludente panorama editoriale digitale italiano. Noi non tolleriamo che siano messi in commercio eBook non validati, eBook il cui testo contiene evidenti e numerosi errori da OCR, eBook illegibili su tablet o eReader per via dei fogli di stile pachidermici, eBook senza metadati, e via dicendo. Pensiamo che gran parte di questi problemi derivi da poca competenza/professionalità dei soggetti che quegli eBook li hanno prodotti, ma parte della colpa ricande anche sugli Editori che quegli eBook li pubblicano (forse per cercare di massimizzare il profitto immediato, a scapito del Lettore e della loro stessa reputazione?).

Non è un caso che siano sorte associazioni come l’eBook Club Italia con il dichiarato intento di spronare gli Editori a pubblicare libri digitali di qualità e a sensibilizzare gli Autori sul tema. Inutile aggiungere che Smuuks rifiuta logiche commerciali “a breve orizzonte temporale”, e crede che, passata questa prima fase di fermento, soltanto chi saprà realizzare opere tecnicamente eccellenti sarà in grado di sopravvivere.

Come giustamente sottolineavi, da queste problematiche nascono però molte possibilità. Innanzitutto, c’è lo spazio per gli Autori-Sperimentatori di nuove espressioni digitali, che hanno a disposizione un nuovo mezzo di comunicazione (il “libro digitale”), terreno essenzialmente vergine. A nostro avviso, i creatori di contenuti non hanno ancora esplorato fino in fondo e in maniera originale le funzionalità offerte da questo nuovo mezzo rispetto alle edizioni cartacee. Esiste poi l’opportunità per la nascita di nuovi soggetti imprenditoriali (come Smuuks) che aiutino, tramite il loro supporto tecnico, gli Autori ad esprimersi secondo questo nuovo “codice linguistico” e gli Editori a “traghettare” i loro cataloghi pregressi e a “ottimizzare” i nuovi titoli. Infine, ma non meno importanti, sono le opportunità date dall’editoria elettronica di qualità in campo scolastico e sulla società in generale — ma di questo punto, per noi importantissimo, parleremo dettagliatamente più avanti.

Uno dei fiori all’occhiello dichiarati di Smuuks è la competenza tecnica, garanzia di alta qualità negli eBooks. Allora, giusto per stuzzicarvi un pò, vi chiedo: se stiamo parlando di standard, che senso ha parlare di alta qualità? Nello standard non dovrebbe essere per definizione tutto di alta qualità?

Il rispetto degli standard è una pratica professionale non solo importante ma ormai necessaria, anche solo per mere questioni economiche e di immagine, senza scomodare l’etica professionale. Se l’eBook non è conforme, c’è il rischio che non sia fruibile da chi l’ha acquistato: costui non ha giustamente il diritto di ritenersi truffato? E di provare sfiducia verso il Distributore, l’Editore, o, peggio, l’Autore? O, ancor peggio, verso la lettura digitale? Purtroppo sul mercato italiano sono stati e sono ancor oggi messi in commercio titoli che non garantiscono nemmeno questo livello qualitativo minimo.

Fatta questa premessa, il rispetto degli standard non implica automaticamente “alta qualità”. Con una battuta potremmo dire che parlare la stessa lingua è solo un prerequisito per comunicare efficientemente ed efficacemente: rispettare uno standard di formato significa rispettarne la grammatica e la sintassi, ma non vuol automaticamente dire saperne sfruttare le peculiarità.

Ad esempio, lo standard EPUB prevede la possibilità di inserire metadati negli eBook, ma pochissimi eBook in commercio sono dotati di metadati non “obbligatori” (titolo, autore, lingua). Editori, sveglia! Se volete vendere i vostri eBook, devono essere “ricercabili”. E come fanno ad esserlo, senza metadati? Le ricerche full text non fanno miracoli, soprattuto in termini di qualità dei risultati!

Ancora: sono veramente pochi gli eBook pensati per essere realmente letti in maniera funzionale. Non è un caso che la maggior parte degli eBook in circolazione siano opere letterarie (soprattutto narrativa), proprio perché non richiedono particolari accorgimenti funzionali, visto che la loro lettura è essenzialmente lineare (dall’inizio alla fine). Ma per altri generi, ad esempio la saggistica o la manualistica, le cose cambiano:  note a piè di pagina del cartaceo spesso rese negli eBook con dei link in apice che puntano ad una pagina separata. Spesso in questa pagina non c’è il link per tornare al passaggio appropriato del testo principale. Questo non è un grosso problema se leggo l’eBook sul PC, dove tutti i programmi di lettura hanno la funzione “Indietro”; viceversa, molti eReader, specie i più economici o i più datati, non hanno un tasto fisico o una funzione software per tornare al passaggio precedente. Volendo raffinare ulteriormente l’esempio, Smuuks sceglie per le note lo stile “[1]” con altezza pari al corpo del testo, anziché in apice, perché così i link risultano più facili da “premere” sugli schermi sensibili al tocco.

Per “provare con mano”, invitiamo i Lettori a scaricare gratuitamente l’EPUB della Divina Commedia col commento di Isidoro Del Lungo e le illustrazioni di Gustave Dorè, da questo URL.

Tra gli obiettivi che elencate leggo: “conformità degli eBook agli standard e compatibilità con gli eReader sul mercato.” Visto lo stato dell’arte, le due affermazioni paiono un po’ in contraddizione. Come vedete gli sviluppi futuri? Stiamo realmente andando verso uno standard diffuso o continueremo a produrre a slalom tra le varie marche?

Effettivamente il tasto è dolente e i problemi, che gli addetti ai lavori conoscono fin troppo bene, nascono ovviamente dagli enormi interessi economici in gioco, che fanno sì che Amazon-Kindle usi un suo formato proprietario, Apple-iBooks pure, Adobe venda il suo macchinoso DRM un po’ a tutti gli altri, ma poi i diversi produttori di eReader implementino le proprie aggiunte proprietarie ad ADE, che nemmeno rispetta fino in fondo la specifica EPUB… insomma, stiamo vivendo un’altra “browser war”. La nostra speranza è che, così come iTunes ha eliminato il DRM dalla musica e i maggiori browser ormai supportano gran parte delle specifiche W3C in maniera omogenea, anche nel mondo degli eBook si arriverà a convergenza attorno ad un formato aperto, possibilmente tecnicamente migliore di EPUB3.

Ma non vogliamo svicolare dalla domanda. Smuuks predilige formati aperti (e lavora prevalentemente con software libero) e non impone DRM sui propri eBook, sconsigliandone l’adozione ai propri clienti. Per quanto riguarda la compatibilità inter-piattaforma, cerchiamo di produrre i nostri eBook scrivendo codice il più possibile essenziale e ordinato, usando costrutti supportati dal maggior numero di piattaforme, e riducendo al minimo l’uso degli stili. Facciamo anche ampio uso di fallback, proprio per minimizzare la perdita di qualità nella fruizione, nel caso un particolare artificio tecnico non possa essere reso appieno nell’ambiente di fruizione del Lettore. La nostra piattaforma di authoring, che abbiamo chiamato “raymond” in onore di Queneau, consente di personalizzare in maniera flessibile ed efficiente ogni singolo progetto, producendo eBook ottimizzati per dispositivi diversi. Infine, testiamo ogni formato di un eBook su uno o più eReader/tablet e software di lettura, per assicurarci che effettivamente siano resi come li abbiamo immaginati.

Chi è l’interlocutore di Smuuks oggi? E domani? dove vuole arrivare Smuuks?

La nostra attività mira ad offrire la miglior esperienza di lettura possibile al Lettore. Chiaramente dal punto di vista operativo offriamo i nostri servizi soprattutto ad Editori o altri Addetti ai Lavori dell’ecosistema editoriale, o agli Autori che desiderino autopubblicarsi, ma non scendiamo a compromessi in quanto a qualità del libro digitale finito, perché è il Lettore il nostro principale stakeholder. Per il momento abbiamo in cantiere un paio di progetti nell’ambito dell’autoistruzione musicale e alcune edizioni di critica letteraria, ma siamo assolutamente aperti a discutere progetti interessanti (secondo quanto detto sopra), a prescindere dalla loro natura editoriale, con chiunque voglia lavorare con noi. Quanto ad obiettivi a lungo termine, vorremmo riuscire ad imprimere una svolta radicale (verso la qualità e la competenza tecnica) all’intero mercato italiano, esplorando nuove strade tecnologiche e dialogando con gli altri attori interessati, sia economici sia accademici, culturali o sociali.

A proposito del titolo che avete scelto: Smuuks: smarter books (for a better society): il concetto sotteso è bellissimo, ma ci credete davvero? Secondo voi oggi, quanto vale ancora il legame diretto tra libri e società?

Crediamo ad ogni singola parola e ogni singola parola ha per noi un significato ben preciso. Innanzitutto parliamo di “books” e non di “eBooks”: la tecnologia è un mezzo, non un fine, e ha successo quando diventa ubiqua e permea la quotidianità delle persone senza che si noti. “Smarter” perché non basta prendere un testo e “convertirlo” dal cartaceo al digitale: sarebbe un peccato (se non addirittura controproducente) non sfruttare le peculiarità dei libri digitali. Infine, siamo convinti che il libro, inteso come unità di informazione organica e sufficientemente auto-sufficiente, manterrà certe caratteristiche che sono inevitabile conseguenza della fisiologia umana. Altre si evolveranno, così come si sta evolvendo quest’ultima sotto lo stimolo delle diverse tecnologie. I primi studi scientifici evidenziano come la lettura digitale possa essere più efficiente, nell’ambito dell’apprendimento superiore, rispetto alla lettura tradizionale. Ricerche di mercato hanno evidenziato come i Lettori digitali leggano più libri rispetto a prima dell’acquisto del proprio eReader e come gli eBook consentano di avvicinare gruppi di persone altrimenti difficilmente interessabili alla lettura.

Vediamo grandi opportunità di disseminazione della cultura: basti pensare alla maggiore accessibilità degli eBook (fatti bene) rispetto alle edizioni cartacee. La persona con difetti di vista non dovrà più scegliere cosa leggere in base al corpo del carattere di stampa, perché potrà sceglierlo in base alle proprie esigenze direttamente sul proprio lettore digitale. Allo stesso modo, chi soffre di dislessia può usare un carattere appositamente studiato. I non vedenti, potranno usare il TTS per fruire dell’eBook o di un convertitore Braille per “leggerlo tattilmente”. Qualcuno dirà: “tutte queste tecnologie ci sono già da anni”. è vero, ma ora sono finalmente adottabili da chiunque, sia consumatori sia produttori, in termini economicamente vantaggiosi, su larga scala e in mobilità.

Infine, permettici di sottolineare come queste tematiche costituiscano una perfetta testa di ponte per parlare di software libero, formati aperti, libertà digitali, digital citizenship, tutti temi a noi cari.

__

📝

http://www.smuuks.it

Email: info@smuuks.it
Google Chat: smuuks.it@gmail.com
Skype: smuuks (info@smuuks.it)
Twitter: @Smuuks (http://twitter.com/Smuuks)

Come non Detto.

Molto volentieri ospito oggi un guest post di lusso.

Marco Cetera (*) ci parla in modo affascinante del suo Come Non Detto. Un’opera ardita, a cavallo tra carta e digitale nella quale la vicenda del protagonista si snocciola in versi che sono in realtà parole o frasi di Altri.

Non aggiungo altro. Lascio che vi spieghi tutto lui per non guastare nulla.

Leggete perché merita veramente.

Lui: «C’avevo pensato anch’io.»

Io: «Come non detto».

di Marco Cetera

Versi che nascondono un archivio.

È da un po’ che si sente parlare di Clockss –Controlled Lots of Copies Keep Stuff Safe-, l’archivio elettronico internazionale nato per garantire la conservazione e la protezione delle pubblicazioni accademiche web-based. A mio avviso, uno degli aspetti più interessanti di Clockss è che si tratta di un prototipo di “dark archive”. Cioè un archivio nascosto, da usare nei momenti di emergenza. Ad esempio, l’uscita dal mercato di un editore, o il guasto tecnico di un server ma anche un evento catastrofico tipo tsunami. Insomma, qualsiasi evento capace di produrre danni irreversibili ai testi elettronici.

Ecco, nel suo piccolo, anche “Come non detto” può essere considerato un archivio nascosto da usare in caso di emergenza.

Come dichiara il sottotitolo, “Come non detto” è un “poema musivo ipertestuale”. Musivo, perché l’opera è composta dall’assemblaggio lineare di 2000 citazioni-tessere di altrettanti autori. Ipertestuale, perché a ognuna delle 2000 citazioni corrisponde un link che consente al lettore del sito di conoscere immediatamente la fonte bibliografica e di leggere la biografia dell’autore a cui quella frase (o parola) appartiene. I rinvii a Wikipedia (riordinati in ordine alfabetico  e tematico nelle rispettive pagine dell’indice) consentono di comporre la basilare costellazione di un sapere che spazia dalla letteratura alla fisica teorica, dai fumetti alla filosofia. Un’operazione che potrebbe essere definita di “enciclopedismo digitale”.

In questo modo, “Come non detto” ricrea in maniera “nascosta” la mappa di un archivio virtuale del sapere. Una mappa nata dall’esigenza – lo ammetto: un’esigenza molto personale – di far fronte alla mastodontica forza centrifuga di dissipazione culturale che agisce nella rete. Una piccola bussola, a disposizione di tutti, che galleggia sul mare magnum digitale.

La digitalizzazione è un fenomeno irreversibile.

Tuttavia, non sarebbe del tutto corretto considerare “Come non detto” esclusivamente come un’opera digitale. La sua natura “musiva”, infatti, è strettamente legata al mondo dei libri di carta. Non a caso i testi citati sono tutti tratti da volumi cartacei. Solo in un secondo momento sono stati trascritti su un supporto digitale e collegati in una rete ipertestuale. Si tratta di un “poema ibrido”, in grado di rappresentare emblematicamente la fase di “passaggio” che stiamo vivendo: la digitalizzazione del sapere.

Passaggio, appunto. Perché tra libro di carta e ebook non vedo alcuna frattura, ma solo continuità. La contrapposizione – totalmente inventata dai media – non nasce da finalità culturali, ma tutt’al più economiche. Forse l’editoria tradizionale ha paura. L’ostracismo e la diffidenza nascono soprattutto perché le case editrici sono ancora impreparate e temono, con ciò, di perdere opportunità economiche a vantaggio di case editrici digitali tecnologicamente più aggressive e competenti.

Una parentesi: il selfpublishing.

(Nella maggior parte dei casi, tutti gli argomenti usati contro il digitale sono paradossali e pretestuosi. Il selfpublishing, per esempio. O quella che in italiano si chiama “autoedizione”. Be’, è un fenomeno che esiste da quando esiste la stampa. Nel 1892, Italo Svevo pubblicò a proprie spese il suo primo romanzo, “Una vita”. Lo stesso vale per Nietzsche, il quale pubblicò a proprie spese alcune delle sue opere più belle: “La gaia scienza”, “Così parlò Zarathustra”, “Aldilà del bene e del male” e “Genealogia della morale”. E gli esempi, ovviamente, potrebbero continuare… A ciò si aggiunga un dato molto semplice [fonte]: le opere autopubblicate in formato cartaceo disponibili nel nostro Paese sono circa 38-40 mila, mentre gli ebook sono circa 6.500 (comprese le versioni pdf del libro cartaceo).

Il selfpublishing, insomma, non è un meccanismo congenito all’editoria digitale, ma fa parte del mondo librario tout court. Senza considerare che molti dei blog online da cui si levano gli strali contro il selfpublishing sono a loro volta selfpublished. Cos’altro è un blog se non una rivista che si autopubblica in rete?)

La tragicommedia della ripetizione.

In ogni caso, il mio obiettivo non era pubblicare, ma raccontare una storia.

Torniamo a “Come non detto” e alla sua trama.

Più o meno consapevolmente, Lui (pro-nome proprio del protagonista) si è macchiato di una grave colpa: l’elaborazione di un Nuovo Linguaggio.

Per questo, dopo un rocambolesco inseguimento, viene arrestato da due sbirri in borghese che lo conducono presso il palazzo del Supremo Consiglio Culturale. Qui, al cospetto del Giudice Supremo, Lui deve dimostrare la Novità della sua invenzione. Ma, messo ripetutamente alla prova, non riesce a tirar fuori nulla di davvero originale. «Tutto è stato già detto!»

Per aver tentato di contravvenire alla Prima Norma del Linguaggio Universale stabilita dal Consiglio Supremo («È impossibile dire qualcosa di nuovo»), Lui viene condannato alla deportazione forzata nella Penisola del Luogo Comune.

Fin qui, tutto chiaro, lineare.

La lettura di “Come non detto” si complica solo quando si inizia a considerare che i 2332 versi utilizzati dall’autore – cioè da me – per raccontare la vicenda di Lui sono in realtà parole o frasi di Altri.

L’ingranaggio letterario mette il lettore di fronte a questa paradossale forma di rifrazione: l’autore sembra essere condannato allo stesso destino assegnato al protagonista della storia che sta narrando. Quale destino? L’impossibilità di dire qualcosa che non sia già stata detta prima.

L’autore narra la vicenda di Lui ma, in modo indiretto, sta parlando di sé.

“Come non detto” è una “storia nella storia”, in cui la vicenda raccontata (livello basso) si ripete nell’aspetto fondamentale dell’atto narrativo che la incornicia (livello alto). Un gioco di specchi “mise en abyme” (“collocato nell’abisso”).

A questo punto il problema è: furto o paranoia?

Certo, da un lato l’autore si appropria consapevolmente delle parole Altrui, in un fraudolento processo di es-autor-azione, ma dall’altro, volendo approfondire o sprofondare nel senso del poema, sono proprio queste, le parole, che sembrano anticipare le intenzioni narrative dell’autore.

Guardarsi allo specchio così intensamente da non capire dove sta il riflesso e dove l’originale in carne e ossa: questo è l’effetto che volevo raggiungere.

Marco Cetera

—

📝

Come Non Detto può essere letto online oppure scaricato in formato ePub da questa pagina

Marco Cetera

(*) Pugliese, classe 1974. Prima copywriter, poi direttore creativo in alcune importanti agenzie pubblicitarie di Milano. Dal 2010, vive e lavora a Trieste.

Contatti: LinkedIn – Twitter: @ComeNonDetto

OLTRE L’eBOOK Guida definitiva alla Letteratura 2.0

To Imagine To Create To Learn Inspirational sign in the city of Derry in Northern Ireland – Jan 17, 2012 Nicolas Raymond (aka Somadjinn) – Montreal – Canada

Sonia Lombardo, Blogger e Web editor, gestisce dal 2010 Storiacontinua.com, sito indipendente rivolto al mondo della scrittura e della letteratura online.

Si tratta di uno spazio dedicato ai nuovi generi letterari nati su Internet, ai blog narrativi che stanno ridisegnando l’ordine delle classifiche di vendita, ai progetti di scrittura collettiva.

Il sito è portato avanti grazie ad un prezioso lavoro di raccolta e condivisione di strumenti e informazioni, utili per accompagnare gli autori nella scrittura e nella pubblicazione. Due anni di lavoro costante e capillare i cui frutti sono stati raccolti e organizzati da Sonia (aka Scrid) in un volume pubblicato presso Smashwords e oggi finalmente disponibile al pubblico: OLTRE L’eBOOK. Guida definitiva alla Letteratura 2.0

L’opera si snoda su molteplici piani nell’intento di addentrarsi in tutti gli aspetti riscontrabili nella stesura di un libro e offrire quindi all’autore un quadro complessivo con cui poter affrontare il proprio lavoro.

La lettura è sorretta dai racconti di alcuni scrittori digitali che completano la trattazione aggiungendo agli aspetti generali le peculiarità di un’esperienza personale.

La “Guida definitiva alla Letteratura 2.0″ può essere acquistata a partire da questa pagina, ma è possibile riceverla gratuitamente, iscrivendosi alla newsletter di Storiacontinua.com al solo costo di un tweet 🙂.

Formati disponibili: ePub, Mobi e Pdf.

Ne consiglio caldamente la lettura.

__

In chiusura, ricordo anche le altre pubblicazioni realizzate da Sonia per Storia Continua:

Self-publishing a confronto – i migliori servizi per scrivere e pubblicare il tuo ebook anche senza editore

Gli errori da evitare quando si scrive – manuale per l’editing dei tuoi romanzi

Scaricabili entrambe, nella versione gratuita, dal canale Scribd di Storia Continua

ePub 3.0 – Prove su strada

Detour – Christine Weddle – Colorado Spring – 7 Dic 2008

Come accennavo nel post precedente, per testare la compatibilità di ePUB 3.0 verso l’esterno, la scelta migliore era quella di effettuare delle prove concrete. Sono partito da un Fixed Layout ePub, creato da me secondo le specifiche Apple. Il noto ePub ‘Illustrazioni di SteG’ (chi mi segue lo conosce da tempo), aveva bisogno di una drastica rinfrescata. Sia perché, come segnalato agli iscritti al mio blog, il codice peccava di molte leggerezze di gioventù, ma sopratutto perché volevo assolutamente che la nuova versione rispondesse ai requisiti chiesti dallo standard. Ma lo standard tardava a diventare tale, e soprattutto mancavano strumenti di verifica. Oggi che finalmente IDPF ha compiuto passi fondamentali sulle specifiche ed è a disposizione di tutti lo strumento di verifica Readium, condivido la nuova versione e descrivo in questo post, le principali opzioni di conversione operate. L’obiettivo era chiaramente quello di convertire tutte le specifiche proprietarie Apple nelle specifiche dettate dallo standard. Dopo la conversione il file si sarebbe dovuto poter leggere senza problemi con Readium (su browser Chrome) perché solo in caso positivo lo standard sarebbe stato confermato. Se oltre a questo il nuovo ePub si fosse potuto leggere di nuovo anche su iPad, il successo sarebbe stato pieno (ma su quest’ultimo punto a dire la verità ero piuttosto scettico :-)). Procediamo per gradi. Le specifiche introdotte da IDPF richiedono la dichiarazione di alcuni parametri fondamentali necessari a caratterizzare l’epub. In particolare, bisogna fare capire al sistema alcune proprietà del libro:

1. se si tratta di layout scorrevole o layout fisso (layout);
2. quale orientamento si preferisce (orientation);
3. se e quando vogliamo la visualizzazione a pagine affiancate (spread).

queste tre specifiche sono raccolte nella proprietà rendition (resa, rappresentazione) e possono assumere i seguenti valori:

1. reflowable (testo scorrevole) oppure pre-paginated (layout fisso);
2. landscape (orizzontale), portrait (verticale), both (entrambi);
3. none (mai), auto (scelta automatica), landscape (solo quando orizzontale), portrait (solo quando verticale), both (sempre).

Ovviamente il richiamo alla proprietà rendition deve essere giustificato da un apposito riferimento a IDPF posto all’inizio:

...

Riassumendo e per fare un esempio: i dati necessari per esprimere un  Fixed Layout da fruire indipendentemente dall’orientamento dell’eReader, ma con visualizzazione a pagine affiancate solo in caso di orientamento orizzontale, sono i seguenti:

...pre-paginatedbothlandscape
...

Restando sempre nel file content.opf, IDPF richiede la dichiarazione del ‘momento’ dell’ultima revisione del documento. Non corrisponde alla data di pubblicazione e deve essere espressa secondo la notazione UTC (Coordinated Universal Time) CCYY-MM-DDThh:mm:ssZ. Questo dato apparentemente superfluo è importante perché etichetta esattamente la versione su cui avviene la lavorazione, e soprattutto tende ad eliminare i noti problemi di cache per i quali dopo l’aggiornamento ad una nuova revisione del libro, l’eReader si ricordava ancora di quella precedente.  Questa l’espressione corretta del parametro:

...2012-07-07T08:58:00Z
...

Ultimo parametro da dichiarare nel file content è la versione: ovviamente 3.0. Le modifiche che riguardano le pagine xhtml sono solo di ‘facciata’ perché la sostanza resta invariata: EPub 3.0 non ha più bisogno del DOCTYPE e ha ridotto all’osso la dichiarazione di codifica dell’utilizzo dei caratteri:

Ultimissima modifica: la generazione di un nuovo file indice, inesistente nella 2.0: il file nav.xhtml. Deve coesistere assieme al precedente toc.ncx che non può essere eliminato per  consentire una certa retro-compatibilità con lettori più datati. Il file nav. xhtml non è altro che una lista che funge da indice. Vi invito a scaricare e aprire l’ePub per verificarne struttura e contenuti. Questo è tutto! Non grandi cose come avete visto. Superata senza nessun errore la fase di convalida con ePubCheck (verificate costantemente di utilizzare la versione più aggiornata) ho testato la lettura con Readium su Chrome. Avevo introdotto in questa nuova versione del libro, alcune specifiche che ritenevo utili e significative per verificare a fondo la compatibilità: Una pagina in Media Overlay (pagina 12) con l’inserimento di un file smil per la lettura sincronizzata e una pagina (pagina 21) contenente una semplice animazione Javascript. Il Media Overlay che avevo descritto in questo post, funziona benissimo in Readium. Unica sbavatura (su cui i programmatori stanno lavorando) è la marcatura visuale e sincronizzata della parola nel momento stesso in cui questa viene letta. La funzione nonostante sia correttamente impostata non è interpretata e la parola non viene evidenziata. Per il resto nessun altro problema. Importante impostare nelle preferenze la visualizzazione a pagine affiancate come da immagine. La voce narrante a pagina 12 è la voce autentica di SteG che si è prestata con entusiasmo come sempre. Nonostante la registrazione audio non ottimale, l’esempio è più che sufficiente perché vi rendiate conto della funzionalità. Lanciate Chrome. Caricate e aprite l’epub  a pagina 12. Cliccando sul pulsante indicato in figura, partirà la lettura del testo.  La pagina 21 contiene invece una semplice animazione in Javascript. Funziona senza problemi (anche se in Readium soffre leggermente perché sorretta da un browser), ma la cosa importante non è tanto il codice Javascript, quanto le dichiarazioni che rispetto al codice devono essere fatte soprattutto nel file content. Vi invito ad aprire ed ispezionare l’epub a tal riguardo. Questa è la pagina: cliccando sulla miniatura della copertina si avvia l’animazione:

Come ultimo passaggio metto in evidenza l’esito dell’introduzione del nuovo file nav.xhtml. Questa la sua rappresentazione in Readium:

e questa invece quella (un po’ più elegante) su iPad:

Suggerisco di aprire l’epub e verificare tutte le specifiche tipiche del Fixed Layout ePub secondo IDPF. Controprova a ritroso: l’ePub costruito non più secondo le specifiche Apple, ma secondo lo standard dettato da IDPF funzionerà ancora su iPad? Ebbene si! Funziona esattamente come prima, compresa la marcatura visuale e sincronizzata del testo durante la lettura che invece a Readium non riesce ancora. Unico riferimento ‘proprietario’ che rimane all’interno dell’epub è il file xml com.apple.ibooks.display-options ancora presente all’interno della cartella META-INF. Ne ha ancora bisogno il  device Apple per sapere che si sta parlando di un Fixed Layout. È presumibile che questo file sparirà a breve, ma questa volta ad essere fuori standard è Apple :-). ___ Considero obsoleta la precedente versione del libro ‘illustrazioni di SteG (eliminata dal server). A brevissimo renderò È disponibile la nuova release descritta in questo post. Sarà inviata automaticamente a tutti gli iscritti (che avevano confermato l’iscrizione)  e a tutti coloro che ne faranno espressa richiesta. Che aspetti? Che ne pensi di questo importante passaggio di IDPF? Hai esperienza di portabilità verso altri eReaders?

ePUB3: ci sei veramente o ci fai?

 

Wood – Mn-que – Poland – 24 lug 07

 

Approfitto di questo articolo di Liz Castro, uscito questa mattina per raccontare alcune mie esperienze e per confermare quello che dico da qualche tempo: ePub3 è maturo e il supporto che i devices delle varie marche gli garantiscono è sempre più confortante.

Il supporto fornito da Readium (sotto Crome), o da Kobo è quasi al massimo se si esclude qualche sbavatura nelle funzionalità più evolute di ePub3. La stragrande maggioranza delle caratteristiche di ePub 3 è correttamente interpretata da iBooks e anche Kobo per iOS nella sua ultimissima versione si comporta bene . Rarissimi problemi si riscontrano nelle conversioni operate da Kindle Previewer verso il formato KF8.

In poche parole: ci siamo

Addirittura la compatibilità tende ad essere retroattiva. Ecco spiegato perché IDPF ha mantenuto il file toc.ncx parallelamente al nuovissimo nav.xhtml. I nuovi lettori non si curano del primo e usano il secondo, ma i vecchi lettori cercano (e trovano) esclusivamente il primo. Ovviamente questa retro-compatibilità ha senso su documenti abbastanza semplici.

Altro dato importante segnalato da Liz e che ho sperimentato anch’io proprio pochi giorni fa con un libro che sto producendo, riguarda il media-overlay, cioè la sovrapposizione/sincronizzazione tra voce narrante e testo scritto di cui avevo parlato in questo post. Fino ad oggi avevo utilizzato questo strumento esclusivamente su iPad usando le specifiche dettate da Apple. Ho preso l’ePub e ho convertito tutte le specifiche di media-overaly secondo il dettame di IDPF (e le differenze non erano di poco conto). Bene: l’ePub ottenuto ha superato ovviamente la fase di convalida con ePubCheck, viene letto benissimo da Readium, ma la cosa interessante è che gira senza problemi anche su iPad.

E non stiamo parlando di funzionalità semplicissime.

Alcuni difetti fastidiosi che ho rilevato, riguardano stranamente certe formattazioni testuali nei CSS che sono diversamente interpretate dai vari sistemi. Dico stranamente perché credo che ormai sulle formattazioni di testo non ci dovrebbe essere più niente da dire. Eppure…
Comunque ci stanno lavorando e in tempo zero arriveranno le soluzioni.

Confermo, da ultimo, la sbavatura in Readium rilevata da Liz sempre sul media-overlay: Readium nella fase di ascolto della voce narrante, non evidenzia le parole in lettura, nonostante il corretto utilizzo dei comandi e della loro sintassi. Anche qui attendiamo sviluppi imminenti.

Cosa ne pensi? Non è tutto oro quello che luccica e c’è ancora strada da fare, ma non pensi che si tratti di una svolta importante?

Deviazioni standard

Jan Flaska – Railroad Tracks – South Bohemia

Nei miei primi e molto affrettati esperimenti di creazione di un eBook secondo il nuovo standard epub3, rimasi inizialmente sorpreso nel vedere come il processo di convalida restituisse esito negativo sulla dichiarazione di font in un foglio css definendola non standard.

Riporto l’esatto messaggio ricevuto:
Font-face reference OEBPS/fonts/nomefont.otf to non-standard font type application/x-font-opentype

Si trattava di un banalissimo font OTF, già usato altre volte nello stesso identico modo e sempre con il superamento della convalida secondo lo standard 2.0.
Superai l’errore scovando le nuove ‘Raccomandazioni’ sulle specifiche pubblicate da IDPF a partire da questa pagina.

Per chi dovesse incorrere nello stesso errore, pubblico una tabellina di sintesi che riporta i Core Media Types secondo ePub3.

 

La cosa importante da tenere presente è che quando una risorsa viene dichiarata esattamente secondo le specifiche indicate in tabella, può essere inclusa nella pubblicazione senza istruzioni di fallback.

Da questa pagina informazioni utili sul Fallback e sulla sua applicazione.

Pensi che possa esserti utile? Ti sei già trovato di fronte a questo tipo di errore?

ePub 3.0: diversamente standard?

Signs – Joe Rooster – 27 aprile 2007 Waco Texas

Epub 3.0 è diventata nell’ottobre 2011 la versione di riferimento per gli ePub, ma sviluppare un eBook secondo questo standard e pensare di farlo ‘girare’ in modo trasversale su dispositivi di marchi diversi è ancora pura follia.

L’esperienza personale giova nel tentativo di dipanare la matassa, ma la situazione è talmente intricata da rendere vano qualsiasi sforzo.

BISG (Book Industry Study Group) nel tentativo di dare una mano a chi affronta il problema, ha messo a punto una griglia di peculiarità nella quale sono evidenziate le caratteristiche ePub 3.0 supportate dai vari dispositivi.

Non illudiamoci che il tentativo sia quello di permettere ad uno sviluppatore di scendere a slalom tra un ‘qui questo si può’ e un ‘qui invece no’, con l’obiettivo di creare il libro ‘universale’ L’iniziativa tuttavia è lodevole e utile perché fornisce una tabella di riferimento con le caratteristiche uilizzabili su ‘quella particolare periferica’.

Si tratta ovviamente di una lista in continua evoluzione e BISG (Book Industry Study Group) promette di mantenerla allineata e aggiornata costantemente anche grazie al nostri feedback (da inviare direttamente a info@bisg.org).

Questo il link diretto per il download della versione più aggiornata della griglia.

ePUB: scrivere codice ‘in bella’ è solo una questione di forma?

Modelli di calligrafia – Carola Bruno – Padova – Gennaio 2012

Nessuna regola scritta vincola chi scrive il codice di un eBooks a farlo in bella forma e ordinando i file secondo chissà quale ordinamento gerarchico. Però aiuta.

Sollecitato a scrivere qualcosa su questo tema, e spinto ulteriormente dopo aver notato come sempre più spesso alcune regole fondamentali di ordine e pulizia vengono disattese anche negli eBook di blasonati editori 😦  scrivo due righe sull’argomento.

Non dico nulla di nuovo o di particolare e i più ‘addentro’ possono tranquillamente leggere altro.

Come sappiamo un ePub non è altro che un guscio compresso che contiene tre componenti fondamentali:
– il file mime-type
– la cartella META-INF
– la cartella OEBPS.

Mentre le prime due fungono sostanzialmente da ‘marcatori’ (il primo per dire all’hardware ‘io sono un ePub’ e il secondo per fare sapere dove poterne trovare le varie parti), la cartella OEBPS di fatto contiene il libro vero e proprio (capitoli, contributi, apparati, stili, scripts …).
Più un libro è articolato e complesso, e più aumenta il numero di file in gioco. Va da se che alcune regole di ordine, gerarchia e pulizia aiutano la programmazione e gli eventuali successivi interventi di modifica.

Il file più importante di un eBook dal punto di vista strutturale è il file content.opf.

Contiene innanzitutto i metadata che riguardano il libro, espressi secondo le specifiche dettate da DCMI ( Dublin Core Metadata Iniziative )

ma è sulla parte che segue che voglio concentrare l’attenzione: l’elemento <manifest>

Il suo scopo è quello di elencare e descrivere tutti i file che concorrono alla pubblicazione.
La sintassi esprime ogni elemento mediante tre ‘indicatori’:

• un id che ‘denomina’ in modo univoco l’elemento in questione;
• l’indirizzamento href che ne ‘esprime’ la posizione all’interno del file epub;
• la componente media-type che ne ‘caratterizza’ la funzionalità.

Quest’ultima componente si esprime seconde le specifiche dettate da IANA (Internet Assigned Numbers Authority) nella sezione MIME (Multipurpose Internet Mail Extensions)

Banalizzando e giusto per fare un esempio, faccio la parafrasi di una espressione tipo reperibile all’interno di un file content:

<item id=”img_001_01″ href=”immagini/riomaggiore.jpg” media-type=”image/jpeg” />

 

In un libro ci sono moltissime di queste espressioni e mi è capitato spesso di prendere in mano content.opf creati senza nessun criterio; un guazzabuglio di definizioni ed elementi senza alcun ordine. E di impazzire per metterci le mani.
E gli stessi file (se un programmatore è disordinato nel content,opf probabilmente lo è anche nel creare la gerarchia dei file) liberi e mescolati tra di loro all’interno della cartella OEPBS.

Meglio un buon ordine che aiuta la stesura e soprattutto le fasi di revisione: ogni file di una certa tipologia va posto in una cartella assieme agli altri file suoi omologhi, e le relative ‘chiamate’ nel file content raggruppate in modo analogo.
La simbologia <!– xxxxx –> esprime un commento di programmazione all’interno del codice e può essere usata per marcare le varie parti:

<!– immagini –>
<item id=”img_001_01″ href=”immagini/riomaggiore.jpg” media-type=”image/jpeg” />
<item id=”img_002_01″ href=”immagini/manarola.jpg” media-type=”image/jpeg” />
<item id=”img_003_01″ href=”immagini/corniglia.jpg” media-type=”image/jpeg” />
<item id=”img_004_01″ href=”immagini/vernazza.jpg” media-type=”image/jpeg” />
<item id=”img_005_01″ href=”immagini/monterosso.jpg” media-type=”image/jpeg” />
<item id=”img_006_01″ href=”immagini/cinqueterre.png” media-type=”image/png” />

<!– audio –>
<item id=”snd_001″ href=”audio/mareggiata.m4a” media-type=”audio/mpeg” />
<item id=”snd_002″ href=”audio/risacca.m4a” media-type=”audio/mpeg” />

<!– css –>
<item id=”css_base” href=”css/base.css” media-type=”text/css” />
<item id=”css_riom” href=”css/riomaggiore.css” media-type=”text/css” />
<item id=”css_mana” href=”css/manarola.css” media-type=”text/css” />
<item id=”css_corn” href=”css/corniglia.css” media-type=”text/css” />
<item id=”css_vern” href=”css/vernazza.css” media-type=”text/css” />
<item id=”css_mont” href=”css/monterosso.css” media-type=”text/css” />

Secondo le espressioni appena viste, a livello gerarchico esisteranno:

una cartella immagini contenente 5 jpeg e un png:
riomaggiore.jpg
manarola.jpg
corniglia.jpg
vernazza.jpg
monterosso.jpg
cinqueterre.png

una cartella audio contenente due basi sonore:
mareggiata.m4a
risacca.m4a

e una cartella css contenente i fogli stile:
base.css
riomaggiore.css
manarola.css
corniglia.css
vernazza.css
monterosso.css

È importante che anche l’attribuzione degli id segua una certa logica. Nell’esempio appena visto ho utilizzato un criterio di progressione:
riomaggiore.jpg è l’immagine 1 del capitolo 1 e ho scelto di indicarla con id 001_01, mentre manarola.jpg, immagine 2 del capitolo 1, sarà indicata con id 002_01.
Inutile sottolineare che gli ‘zero’ all’interno del nome, consentono ordinamenti più precisi: sia dei file nelle gerarchie sia dei nomi all’interno del file content.

Gli utenti che generano ePub da Indesign, conoscono sicuramente il problema della denominazione dei links immagine. Nomi variegati e variopinti che possono andare bene in un impaginato per stampa, tanto ci pensa Indesign a tenerli fortemente ‘al guinzaglio’ ma non aiutano la successiva revisione del codice nel passaggio ad ePUB.

In questo caso ci vengono in aiuto due scripts. Il primo di Marijan Tompa in arte Tomaxxi. Permette di rinominare tutti i contributi immagine a nostro piacimento. La ri-denominazione avviene link per link uno alla volta. Attenzione che i file vengono rinominati definitivamente, quindi nel caso di future eventuali integrazioni da parte di chi aveva fornito i documenti i nomi non saranno più uguali. Meglio lavorare su una copia. Questo il link al sito di Tomaxxi (consiglio una visita approfondita perché è una miniera per chi usa Indesign) e questo il link diretto per il download dello script

Il secondo è quello che preferisco perché rigenera i nomi in batch. Si tratta di uno script di Kasyan Servetsky (altro sito da ispezionare con cura perché ricchissimo di tools e scripts di cui non è possibile fare a meno). Ci chiede una ‘radice’ comune che applicherà a tutti i nomi aggiungendo poi una numerazione sequenziale legata al numero di pagina. Anche in questo caso l’operazione è ‘distruttiva’ quindi lavoriamo sempre su una copia, ma lo script ci restituisce anche un utile report con indicate tutte le sostituzioni effettuate, da conservare  se prevediamo future integrazioni dall’esterno. Questo il link diretto allo script

 

 

 

Tornando al tema principale chiudo citando un aspetto molto importante: l’accortezza nell’utilizzo dei caratteri nel nome dei file. Il matching tra nome dichiarato nel file content e il nome effettivo del file deve essere perfetto. Meglio abituarsi ad utilizzare esclusivamente caratteri minuscoli, evitando spazi e caratteri speciali ad esclusione dell’underscore  ‘ _ ‘ che è sicuro e affidabile per qualsiasi codifica. Cerchiamo di generare nomi  brevi (nei limiti del possibile) e che siano possibilmente esplicativi dell’immagine o meglio ancora, come visto prima, del suo posizionamento all’interno del file ePub.

E tu? Utilizzi strumenti che possono aiutare la stesura o il controllo in fase di scrittura? Hai altre accortezze da suggerire?

FlightCrew: un validatore di EPUB complementare a EpubCheck

Quello che segue è un guest-post di Alberto Pettarin. Una interessante lezione su FlightCrew strumento poco noto ma, come vedremo, fondamentale per una convalida efficace di ePUB.

 

Innanzitutto ringrazio JeanPaul per l’invito a scrivere questo articolo su
FlightCrew, un validatore di EPUB complementare al piu’ noto EpubCheck.

Introduzione a FlightCrew

FlightCrew (FC) e’ un programma open-source gratuito per la validazione
di file EPUB secondo lo standard 2.0.1.
Il primo rilascio ufficiale di FC si deve Strahinja Markovic (ottobre 2010),
l’autore del noto editor di EPUB Sigil.
Attualmente FC e’ manutenuto da John Schember,
che ha sostituito Strahinja anche nello sviluppo di Sigil.
Il codice e gli eseguibili sono rilasciati sotto licenza
GNU LGPL 3 e CC BY-SA 3.0.

L’idea alla base di FC e’ fornire uno strumento piu’ efficiente e
piu’ efficace del validatore messo a disposizione
da IDPF, EpubCheck (EC).

Nello specifico, FC vuole effettuare un’analisi piu’ approfondita di EC
per quanto riguarda la raggiungibilita’ delle risorse e la loro osservanza
dello standard EPUB e, a cascata, di tutti gli altri standard coinvolti:
XHTML, CSS, NCX, OPF, eccetera.
Nonostante FC effettui controlli piu’ sofisticati di EC,
spesso risulta piu’ veloce perche’ e’ scritto in C++,
a differenza di EC che e’ scritto in Java.

FC e’ utilizzabile in tre modalita’: a linea di comando (CLI), tramite
un’interfaccia grafica (GUI) e all’interno di Sigil, di cui costituisce
il “motore” di validazione attivabile cliccando sull’icona
con la spunta verde (“Validate EPUB”).

Le prime due versioni sono scaricabili dalla pagina
Google Code del progetto,
mentre ovviamente Sigil e’ scaricabile da
questa pagina.

Nel resto dell’articolo descrivero’ l’utilizzo a linea di comando,
secondo me il piu’ efficiente per un uso (semi)professionale.
Rispetto a questa versione a linea di comando,
le versioni grafiche offrono in piu’ solo
il drag-and-drop del file da validare
dentro la finestra dell’applicazione (versione GUI)
e la possibilita’ di scorrere l’elenco dei warning e degli error
in una lista ordinata colorata (versioni GUI e Sigil).

Infine cerchero’ di mostrare le analogie e le differenze
tra FC e EC, su una serie di errori comunemente riscontrati negli EPUB.

Utilizzo da linea di comando

Una volta scaricata la versione CLI (command-line interface),
otteniamo un eseguibile che si chiama flightcrew-cli.
Al momento l’ultima release e’ la 0.7.2,
che usero’ per gli esempi di questo articolo.

Nota per gli utenti Linux:
io ho installato flightcrew in /opt/flightcrew, e
creato il seguente alias nel mio file .bashrc per comodita’:

alias flc='/opt/flightcrew/flightcrew-cli'

Nel seguito usero’ sempre flightcrew-cli per non confondere
gli utenti Windows/Mac, ma ovviamente flc e’ molto piu’ comodo…

Il funzionamento e’ molto semplice, non ci sono opzioni
da specificare come per EC:

$ flightcrew-cli book.epub


Se FC non trova problemi in book.epub, restituira’ il messaggio:

$ flightcrew-cli book.epub
No problems found.

e restituira’ al sistema operativo un return code 0,
caratteristica utile da conoscere se vogliamo creare degli script
per automatizzare il nostro un flusso di lavoro.

Se invece FC individua dei problemi, ne restituira’ l’elenco
e passera’ un return code 1 al sistema operativo.
Nella prossima sezione vedremo alcuni esempi comuni.
Generalmente viene anche restituito il file all’interno dell’EPUB
che ha generato l’errore e, se applicabile, la riga relativa.
Uno dei punti di forza di FC e’ proprio una reportistica degli errori
comprensibile, mentre EC (specie le prime versioni) spesso genera
dei messaggi d’errore di difficile comprensione.

Ma il vero punto di forza di FC e’ l’approfondita analisi
dei singoli file contenuti all’interno dell’EPUB e delle loro relazioni.

Il primo tipo di controlli, ad esempio, include una verifica
della conformita’ delle pagine allo standard W3C XHTML 1.1, del content file
a OPF, della TOC alla specifica NCX e via dicendo.
Ovviamente FC controlla anche che l’EPUB sia zippato correttamente,
che vi sia il mimetype file, e via dicendo:
in sintesi, che il file contenitore sia formalmente ben costruito.

Il secondo tipo di controlli, invece, comprende verifiche
che riguardano la “completezza logica” del file EPUB.
A questo gruppo appartengono il controllo che tutti gli elementi
dichiarati nella guide siano anche dichiarati nella spine,
che tutte le risorse presenti nel manifest siano effettivamente
inclusi nel file EPUB, cosi’ come controlla il viceversa,
cioe’ che tutti gli elementi presenti nel file EPUB siano effettivamente
referenziati da qualche pagina.
Un controllo importante effettuato da FC
e’ la verifica che non sia possibile arrivare ad un elemento
(ad esempio tramite la guide o un link interno)
senza che questo elemento sia elencato nella spine.

Ad onor del vero bisogna dire che FC non controlla alcuni elementi
che invece EC controlla, in particolare la raggiungibilita’
degli elementi di fallback (se presenti) e la sintassi delle risorse
in formato DTBook.
Io consiglio sempre di utilizzare entrambi i validatori!

Esempi d’errori e confronto tra FlightCrew e EpubCheck

Di seguito mostrero’ alcuni esempi di errori tipici trovati da FC,
spesso confrontandoli con quanto segnalato da EC (versione 3.0b5).
Utilizzero’ sempre lo stesso file EPUB (corretto) —
una versione “alleggerita” di
Come non detto,
in cui andro’ a inserire, per maggior chiarezza,
un singolo errore per volta.

EPUB zippato male

Un errore comune fra i neofiti consiste nel comprimere la cartella che contiene
le risorse tramite un programma come zip o WinZip,
che di default applica la compressione a tutti i files.
Ricordo che invece il file mimetype deve essere
aggiunto all’archivio ma non deve essere compresso.

FC ce lo ricorda in termini comprensibili:

$ flightcrew-cli zippatoMale.epub
zippatoMale.epub: error 502: Bytes 30-60 of your epub file are invalid. This means that one or more of the following rules are not satisfied:
1. There needs to be a "mimetype" file in the root folder.
2. Its content needs to be *exactly* the ASCII string "application/epub+zip".
3. It needs to be the first file in the epub zip archive.
4. It needs to be uncompressed.
zippatoMale.epub: error 501: The META-INF/container.xml file was not found.


EC invece restituisce questo messaggio criptico:

$ java -jar epubcheck3.jar zippatoMale.epub
Epubcheck Version 3.0b5

ERROR: zippatoMale.epub: Length of the first filename in archive must be 8, but was 12
ERROR: zippatoMale.epub: Required META-INF/container.xml resource is missing

Check finished with warnings or errors

Analogamente, se il file mimetype e’ errato,
perche’ ad esempio c’e’ un carattere di andata a capo di troppo,
avremo i seguenti errori:

$ flightcrew-cli mimetypeErrato.epub
mimetypeErrato.epub: error 502: Bytes 30-60 of your epub file are invalid. This means that one or more of the following rules are not satisfied:
1. There needs to be a "mimetype" file in the root folder.
2. Its content needs to be *exactly* the ASCII string "application/epub+zip".
3. It needs to be the first file in the epub zip archive.
4. It needs to be uncompressed.

$ java -jar epubcheck3.jar mimetypeErrato.epub
Epubcheck Version 3.0b5

Validating against EPUB version 2.0
ERROR: mimetypeErrato.epub/mimetype: Mimetype file should contain only the string “application/epub+zip”.

Check finished with warnings or errors

EPUB con metadati errati

Altro errore che puo’ capitare soprattutto agli inizi,
specialmente se non si utilizza un EPUB editor come Sigil,
consiste nello scrivere metadati non corretti.
Un esempio? La data deve essere nel formato
“YYYY” oppure “YYYY-MM” oppure “YYYY-MM-DD”.
Quindi “2012-6-3” non e’ un valore valido, infatti FC protesta:

$ flightcrew-cli dataNonValida.epub
dataNonValida.epub/OEBPS/content.opf(8): error 1110: The element's value is "2012-3-2", which is not a valid date format.


Purtroppo EC non rileva questo problema:

$ java -jar epubcheck3.jar dataNonValida.epub
Epubcheck Version 3.0b5

Validating against EPUB version 2.0
No errors or warnings detected.

D’accordo, e’ un errore che non dovrebbe causare gravi imbarazzi
ad un eReader, pero’ e’ bene essere a conoscenza di questo genere di situazioni,
specie perche’ molti addetti ai lavori considerano il responso di EC
(e non l’effettiva conformita’ alla specifica EPUB)
come unico parametro di qualita’ dei propri EPUB…

Pagina XHTML elencata nella spine ma non esistente

Dimenticare di copiare una pagina XHTML nella cartella di “assemblaggio”
e’ un errore che puo’ capitare frequentemente
se si lavora a piu’ mani sullo stesso eBook.
In questo caso, FC ci avvisa che effettivamente la pagina testo.xhtml
e’ elencata nel file OPF e nella TOC, ma non esiste nell’archivio:

$ flightcrew-cli paginaInesistente.epub
paginaInesistente.epub/OEBPS/content.opf(23): error 1115: The element's "href" attribute points to file "Text/testo.xhtml" which does not exist.
paginaInesistente.epub/OEBPS/toc.ncx(48): error 1300: This element's "src" attribute value is "Text/testo.xhtml", but that file does not exist.


Il messaggio di EC e’ simile, ma non ci fa presente che
la pagina e’ referenziata da OPF e TOC:

$ java -jar epubcheck3.jar paginaInesistente.epub
Epubcheck Version 3.0b5

Validating against EPUB version 2.0
ERROR: paginaInesistente.epub: OPS/XHTML file OEBPS/Text/testo.xhtml is missing

Check finished with warnings or errors

Pagina XHTML non valida

Cosa succede se commettiamo un errore nello scrivere una pagina XHTML,
ad esempio inseriamo un tag p all’interno di un tag h1?

Entrambi i validatori si comportano bene:

$ flightcrew-cli paginaNonValida.epub
paginaNonValida.epub/OEBPS/Text/testo.xhtml(11): error 301: element 'p' is not allowed for content model '(a | br | span | bdo | map | object | img | svg | tt | i | b | big | small | em | strong | dfn | code | q | samp | kbd | var | cite | abbr | acronym | sub | sup | input | select | textarea | label | button | ins | del | script)'

$ java -jar epubcheck3.jar paginaNonValida.epub
Epubcheck Version 3.0b5

Validating against EPUB version 2.0
ERROR: paginaNonValida.epub/OEBPS/Text/testo.xhtml(11,12): element “p” not allowed here; expected the element end-tag, text or element “a”, “abbr”, “acronym”, “applet”, “b”, “bdo”, “big”, “br”, “cite”, “code”, “del”, “dfn”, “em”, “i”, “iframe”, “img”, “ins”, “kbd”, “map”, “noscript”, “ns:svg”, “object”, “q”, “samp”, “script”, “small”, “span”, “strong”, “sub”, “sup”, “tt” or “var” (with xmlns:ns=”http://www.w3.org/2000/svg&#8221;)

Check finished with warnings or errors

Pagina presente nel manifest ma non nella spine

A mio avviso, EC ha una grossa limitazione:
non effettua alcun controllo di raggiungibilita’ degli elementi dell’EPUB.
Prendiamo il caso in cui una pagina e’ dichiarata nel manifest ma
non e’ inclusa nella spine.
Questo comporta la non visualizzazione della pagina nell’eBook finale!

Sfortunatamente EC non segnala questo genere di problemi:

$ java -jar epubcheck3.jar paginaNonReferenziata.epub
Epubcheck Version 3.0b5

Validating against EPUB version 2.0
No errors or warnings detected.

Viceversa, FC ci segnala il problema:

$ flightcrew-cli paginaNonReferenziata.epub
paginaNonReferenziata.epub/OEBPS/Text/spuria.xhtml: warning 2200: This resource is present in the OPF , but it's not reachable (it's unused).


Un test di velocita’

Infine, ho fatto un rapido test di velocita’,
sulla stessa macchina e sullo steso file EPUB senza errori:

$ time flightcrew-cli book.epub
No problems found.

real 0m2.050s
user 0m1.812s
sys 0m0.148s

$ time java -jar epubcheck2.jar book.epub
Epubcheck Version 1.2

No errors or warnings detected

real 0m5.150s
user 0m7.052s
sys 0m0.168s

$ time java -jar epubcheck3.jar book.epub
Epubcheck Version 3.0b5

Validating against EPUB version 2.0
No errors or warnings detected.

real 0m10.548s
user 0m14.981s
sys 0m0.476s

Altro rapido test, questa volta su un file con gravi errori:

$ time flightcrew-cli book2.epub 2> /dev/null

real 0m8.946s
user 0m8.085s
sys 0m0.560s

$ time java -jar epubcheck2.jar book2.epub 2> /dev/null
Epubcheck Version 1.2

real 0m9.173s
user 0m13.905s
sys 0m0.328s

$ time java -jar epubcheck3.jar book2.epub 2> /dev/null
Epubcheck Version 3.0b5

Validating against EPUB version 2.0

real 0m15.997s
user 0m22.913s
sys 0m0.528s

Come si vede, FC e’ generalmente piu’ veloce di EC:
cio’ e’ vero per la quasi totalita’ dei file EPUB
che mi e’ capitato di controllare.
Viceversa, quando l’EPUB contiene migliaia di pagine
con decine di migliaia di link interni da controllare,
l’analisi piu’ raffinata di FC comporta
un tempo di esecuzione piu’ lungo.

Conclusioni

Concludo questo articolo con due note metodologiche.

Primo, i validatori sono strumenti comodi
per controllare (ancora in fase di lavorazione al PC)
che i propri eBook siano conformi allo standard EPUB,
ma non sostituiscono un test sugli eReader fisici.
Essi sono come i correttori ortografici dei word processors:
sono capaci di trovare gli errori grammaticali in un testo,
ma non garantiscono che esso sia anche “tipograficamente” gradevole
(ne’ che sia semanticamente coerente, ma questa e’ un’altra storia…)!
Inoltre, proprio come i correttori ortografici,
spesso possono non evidenziare tutte le difformita’
rispetto alla specifica di riferimento,
perche’ (a) spesso ne controllano solo un sottoinsieme di criticita’ comuni,
e (b) possono essere affetti da bug essi stessi.
Quindi invito tutti rimanere vigili e non accettare pedissequamente
il responso dei validatori, positivo o negativo che sia,
ma usarlo come uno (tra molti) elementi nel valutare
la qualita’ del proprio eBook.

Secondo, il mio consiglio e’ di utilizzare sempre entrambi
i validatori, non FC in sostituzione di EC o viceversa.
Infatti bisogna ricordare che un validatore produce sempre e solo
veri positivi: dato che EC e FC controllando due sottoinsiemi diversi
della specifica EPUB, usarli entrambi
non puo’ mai essere meno utile che usarne uno solo!

E ora, al lavoro!
Tutti — Autori, Editori, Lettori —
abbiamo voglia di buoni eBook, di eBook di qualita’!

Risorse

1. http://code.google.com/p/flightcrew/
2. http://code.google.com/p/sigil/
3. http://code.google.com/p/epubcheck/
4. http://sigildev.blogspot.it/2010/10/introducing-flightcrew-epub-validator.html
5. http://idpf.org/epub/201
6. http://ebci.it/

Autore

Alberto Pettarin vive a Padova, dove ha recentemente
conseguito il Dottorato di Ricerca in Ingegneria dell’Informazione
e dove sta per concludere un progetto di ricerca post-doc.

Da sempre appassionato di tipografia digitale
(e, quindi, da sempre sfruttato dai suoi colleghi allergici a LaTeX),
da qualche anno si occupa di editoria digitale e di eBook in particolare.
E’ uno dei soci fondatori-coordinatori dell’eBook Club Italia,
per il quale scrive recensioni tecniche di eBook pubblicati in Italia.

Nel suo (pressoche’ inesistente) tempo libero legge,
pedala o gioca a tennis, cucina, guarda i TED Talks
e scrive free software,
quasi sempre con la scusa di fare un favore all’umanita’
(in realta’ gli piace un sacco programmare).

Puo’ essere raggiunto via email (pettarin AT gmail DOT com)
oppure tramite il suo
profilo Linkedin.

Generalmente non parla di se’ in terza persona.