Archivi tag: epubcheck

ePUB3: ci sei veramente o ci fai?

 

Wood - Mn-que - Poland - 24 lug 07

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

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?

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”)

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.


EpubChek: La convalida dei file ePub

IDPF [International Digital Publishing Forum] è l’organismo ufficiale preposto alla stesura delle caratteristiche ‘standard’ del formato ePub. Licenziata recentemente la versione 3.0 l’istituto prosegue nel suo lavoro di definizione di standard.

La questione è molto importante perché pone l’obiettivo di definire in modo assolutamente traversale, un formato che possa ‘girare’ senza problemi su tutti i readers o tablet. La partita in gioco è enorme e non sempre fila tutto liscio, ma gli sviluppi sono costanti e di interesse (recentissimo il lancio del progetto READIUM).

IDPF fornisce un comodissimo strumento per verificare quanto un ePub risponda alle specifiche standard: EpubCheck

il logo di ePUBCheck

EpubCheck non compie nessun controllo sulla correttezza del codice interno (per questo esistono altri sistemi di convalida e controllo), ma solo una profondissima verifica sulla correttezza della struttura interna del file; sulla correttezza nell’espressione dei nomi dei file e della loro gerarchia, sul fatto che tutte le componenti siano dichiarate e che tutte le componenti dichiarate siano effettivamente esistenti … in soldoni una verifica completa che tutte le specifiche standard dettate da IDPF siano rispettate.

EpubCheck può essere utilizzato anche on-line da questa pagina (che oggi pare non funzionare) a patto di non verificare materiale commerciale e che il ‘peso’ del file ePub non superi i 10 Mb, ma consiglio vivamente il download del tool in locale per avere libertà assoluta sul materiale da convalidare. Le informazioni seguenti riguardano proprio la convalida di un file ePub in locale.

Come si utilizza EpubCheck.

Il tool funziona su qualsiasi sistema operativo che monti Java 1.5 o superiore. Si lancia da linea di comando e può essere utilizzato in due modalità: standard o avanzata.

Modalità ‘standard’ (da usare per la verifica del file .epub già creato)

java -jar epubcheck.jar file.epub

banalizzando la stringa può essere letta così: chiediamo a Java di lanciare il tool epubcheck.jar incaricato di verificare il file.epub

il nome del tool e quello del file devono essere espressi in modo corretto e completo di percorso

Modalità ‘avanzata’ (da usare per la verifica del singoli file interni o sulla cartella completa, ma non ancora compressa, del libro)

java -jar epubcheck.jar file -mode MODE -v VERSION

Stiamo come prima chiedendo a Java di lanciare il tool epubcheck.jar incaricato di verificare la validità, però questa volta la verifica avviene secondo modalità leggermente diverse e non sul file epub compresso. Vediamo nel dettaglio le specifiche:

– Il parametro MODE può assumere i seguenti valori:

    • opf verifica il solo file opf specificato;
    • nav per convalidare la sola navigabilità del documento (esclusivamente per la versione 3.0);
    • mo per convalidare la sovrapposizione tra componenti meglio detto ‘media overlay’ (esclusivamente per la versione 3.0) Un esempio di media overlay è presente in questa pagina;
    • xhtml per convalidare i soli file .xhtml;
    • svg per convalidare le componenti di codice per le rappresentazioni vettoriali;
    • exp per convalidare la cartella del libro non compressa.

Non mi soffermo sui primi 5 parametri (a mio parere poco utili perché danno solo indicazioni parziali e a volte contraddittorie), quello che invece è importante tenere presente è il sesto.

Permette di compiere la verifica/convalida anche solo della cartella non compressa e, con l’aggiunta dell’opzione -save in caso di esito positivo, di generare il file epub convalidato.

In quest’ultimo caso la sintassi corretta è la seguente:

java -jar epubcheck.jar dir -mode exp -save

dove dir è il nome (completo di path) della cartella che contiene gli elementi del libro

– Il parametro VERSION può assumere esclusivamente i valori 2.0 e 3.0

– L’utilizzo del parametro -help (o abbreviato -h) visualizza il seguente breve messaggio di aiuto:

When running this tool, the first argument should be the name (with the path) of the file to check.
If checking a non-epub file, the epub version of the file must be specified using -v and the type of the file using -mode.
The default version is: 3.0.
Modes and versions supported:
-mode opf -v 2.0
-mode opf -v 3.0
-mode xhtml -v 2.0
-mode xhtml -v 3.0
-mode svg -v 2.0
-mode svg -v 3.0
-mode nav -v 3.0
-mode mo -v 3.0 // For Media Overlays validation
-mode exp // For expanded EPUB archives
This tool also accepts the following flags:
-save = saves the epub created from the expended epub
-? or -help = displays this help message

Se il nostro file non supera la convalida, il tool restituisce l’elenco degli errori riscontrati. È necessario intervenire sui singoli file operando le opportune correzioni e procedere con un nuovo tentativo di convalida, fino al successo definitivo.

Come già detto, viene segnalato anche dalla pagina ufficiale di info su ePUBCheck 3.0 che:

  • qualsiasi verifica sui singoli file interni è necessariamente parziale perché vengono effettuati solo una parte dei test-check complessivi.
  • quando si verifica un file completo (.epub) i parametri MODE e VERSION sono ignorati

Consiglio di mantenere l’attenzione sulle pagine ufficiali di aggiornamento e sviluppo:

Buon (e valido  🙂 ) lavoro.


Altra fantastica raccolta di font proposta da MyFonts

Cito testualmente dalla presentazione di MyFonts:

Se si dovesse definire una keyword per questa raccolta sarebbe: fantasia.

Una raccolta capace di sfidare i cliché e aggiungere quel non so che in più capace di rendere insolita e innovativa la nostra comunicazione.

A voi il link

la font 'populaire' una delle proposte di questa raccolta

la font 'populaire'


What is EPUB3

La cover del libro

O’Reilly, in collaborazione con IDPF, ha pubblicato un breve ma interessante eBook (gratuito previa registrazione) dal titolo What is EPUB3?

Scritto da Matt Garrish vuol essere una guida alle specifiche del formato, determinandone la corretta collocazione all’interno del flusso editoriale digitale e spiegando i motivi (ormai fuori discussione) per cui EPUB3 è destinato a diventare il nuovo standard.

Assolutamente da leggere (link diretto)


EpubCheck si prepara all’arrivo di EPUB3

EpubCheck, il più importante strumento per la verifica e validazione dei file ePub secondo gli standard dettati da IDPF si sta preparando all’arrivo del tanto atteso formato EPUB3.
All’attuale e conosciuta versione ufficiale è stata infatti affiancata la beta 3.0.b1 (ancora in fase di sviluppo) in grado e validare i file ePub3.
Spicca innanzitutto la capacità di analizzare nuovi contenuti come file SVG, elementi multimediali, media overlay (per esempio per la lettura a voce alta) che daranno la possibilità di creare ePub altamente interattivi, ma altre novità estremamente interessanti sono la capacità di analizzare file ePub non compressi (e di salvarne il file compresso dopo la verifica) e anche la possibilità di effettuare verifiche e validazioni dei singoli file componenti (per ora solo gli OPF, gli XHTML, gli SVG e i Media Overlay)

Riporto sintassi e parametri (reperibili comunque alla pagina wiki ufficiale)

La nuova versione richiede java (da 1.5 in su) e può essere utilizzato in modo standard come di consueto:

java -jar epubcheck-3.0b1.jar file.epub

oppure in modo avanzato:

java -jar epubcheck-3.0b1.jar file -mode MODE -v VERSION

dove MODE può essere:

  • opf per la validazione del singolo file opf;
  • nav per la validazione dei documenti di navigazione (solo ePub 3.0);
  • mo per la validazione dei documenti media overlay (solo ePub 3.0) ;
  • xhtml; per la validazione dei file xhtml
  • svg; per la validazione dei file svg
  • exp per validare ePub non compressi. (aggiungendo a exp l’ulteriore stringa –save si può salvare l’ePub finale in formato compresso).

VERSION può essere 2.0 o 3.0

MODE e VERSION vengono ignorati quando si analizza un ePub completo

-help visualizza alcune stringhe di aiuto

java -jar epubcheck-3.0b1.jar -help