Da Acrobat XI a HTML: ripristinare l'esportazione a HTML 3.2 e HTML 4

In Acrobat XI,  il comando Salva come altro > Pagina Web HTML ha ricevuto significativi miglioramenti, per esempio riguardo le liste e le tabelle. Attraverso questo meccanismo Adobe ha cercato di offrire agli utenti un output HTML che rispettasse il più possibile il look and feel del documento PDF, usando sia i fogli di stile CSS sia stili inline.

Salva pagina Web HTML in Acrobat XI.

Salva pagina Web HTML in Acrobat XI.

Però, soprattutto quando è necessario poter disporre di un file HTML in cui sia presente soltanto la struttura e il meno possibile degli elementi di stile, l’esportazione in HTML 3.2 o HTML 4 delle versioni precedenti era più efficace.

Per ripristinare queste opzioni, è sufficiente recuperare i due file xml che si occupavano della mappatura degli elementi da una versione 9.0 del programma o scaricandoli dal Web.

HTML 3.2.xml e HTML 4.01.xml vanno poi posizionati nella cartella Acrobatplug_insSaveAsXMLMappingTables della vostra installazione di Acrobat.

Il file HTML risultante sarà certamente più pulito e adatto alla successiva rielaborazione per l’utilizzo in un epub.

Annunci

Audiolibri, epub3 e… accessibilità

un attore che legge un libro

Un audiolibro è un libro parlato, la riproduzione vocale di un’opera. In genere, si tratta di un libro classico o un romanzo di grande successo che viene letto da un attore e registrato in file .mp3 o altri formati audio, ma esistono anche audiolibri realizzati appositamente per questo scopo, che includono oltre ai file audio del parlato anche file musicali, scenografie sonore e quanto necessario per rappresentare, per esempio, un’opera teatrale.

Nel nostro caso, un audio e-book sarà composto da diversi file audio organizzati in una struttura e dotato di un sistema di navigazione che ne consenta la fruizione. Esistono degli standard tecnici che si occupano di fornire riferimenti su come realizzare questi audiolibri, il più conosciuto (almeno come acronimo) dei quali è probabilmente DAISY,  Digital Accessible Information System.

Qui iniziano i miei personali dubbi riguardo l’accessibilità: sul sito del Daisy Consortium spicca la scritta “Making Information Accessible for All“. Ma un audiolibro può essere davvero considerato accessibile per tutti? Molto brutalmente, che se ne fa un sordo di un audiolibro? Accessible for all? No. Inoltre, le periferiche hardware Daisy sono veramente costose, tanto da spingere il nostrano CILP (Centro Internazionale del Libro Parlato “A. Sernagiotto” – ONLUS) a sviluppare hardware dedicato a un prezzo decisamente più abbordabile. Sarà per questo, anche, che il consorzio DAISY non è che sia così simpatico?

Comunque, i tipi di Daisy hanno lavorato con gli sviluppatori di Epub 3 per creare la sezione dedicata al rendering audio TTS delle specifiche (attualmente non supportato da alcun reader)  e al meccanismo chiamato Media Overlays che permette di evidenziare in sincrono le parti del testo in lettura e il brano audio corrispondente enfatizzando questo risultato come se fosse la soluzione di tutti i mali.

Niente di nuovo, la stessa cosa si può ottenere da anni con altri strumenti, per esempio provate a leggere un brano con Balabolka, un programma TTS (text-to-speech) gratuito e davvero ben fatto.

Se aprite un epub con Balabolka ed avviate la lettura (in questo caso l’audio proviene dalla sintesi vocale installata, e non da un attore registrato mentre recita il testo), vedrete le parti del testo in lettura evidenziate mano a mano che la lettura procede.

Balabolka in azione: il testo in lettura appare evidenziato.

Balabolka in azione: il testo in lettura appare evidenziato.

Per ottenere lo stesso risultato (l’evidenziazione) ma correlando il testo a una voce recitante (quindi una base registrata, su cui non potete intervenire per quanto riguarda tono, velocità, tipo di voce), i media overlays di epub 3 prevedono l’utilizzo di SMIL (un markup del W3C) e di altre specifiche.

Qui mi sorge un altro grosso dubbio: SMIL (Synchronized Multimedia Integration Language) è un markup collaudato la cui versione più recente (3.0)  risale al 2008. Non riesco a capire che c’entra DAISY, se devo usare SMIL. Boh? Mi risponde indirettamente Matt Garrish nel suo Accessible EPUB 3, scaricabile gratuitamente da O’Reilly (il PDF non è accessibile, ma pazienza).

If you’re coming to this guide from accessibility circles, however, you’re probably wondering why this is considered new and exciting when it sounds an awful lot like the SMIL technology that has been at the core of the DAISY talking book specifications for more than a decade. And you’re right…sort of. Overlays are not new technology, but represent a new evolution of the DAISY standard, which EPUB 3 is a successor to. What is really exciting from an accessibility perspective is the chance to move this production back to the source to get high-quality audio and text synchronized ebooks directly from publishers.

Ma era così anche prima, nessuno ha mai impedito a un publisher di usare SMIL. Boh? Che c’è di eccitante? Mai sottotitolato un video? È la stessa cosa e l’hanno fatto in tanti ben prima che nascesse Epub 3.
Il libro utilizzato nell’esempio di Balabolka è un epub in versione 3, e per vederlo in azione al completo delle sue possibilità una delle pochissime opzioni disponibili (epub 3 non è che abbia avuto questo gran successo) è aprirlo in Google Chrome con Readium. Vediamo che succede.

In Readium il brano in lettura appare evidenziato in giallo.

In Readium il brano in lettura appare evidenziato in giallo.

Ascoltando la lettura, si noterà che al brano recitato in audio corrisponde una evidenziazione in giallo del testo in Readium. Come si ottiene questo? Tramite SMIL e markup.

Osservando la struttura del file epub in Sigil le cose (forse) appaiono più chiare.

In Sigil, è facile vedere il contenuto delle due cartelle Audio e Misc: tutti i file mp3 che costituiscono la libreria audio e i corrispondenti file SMIL che stabiliscono le correlazioni. Nel codice, ciascun brano viene delineato da un tag span.

Il contenuto del file epub in Sigil.

In Sigil, è facile vedere il contenuto delle due cartelle Audio e Misc: tutti i file mp3 che costituiscono la libreria audio e i corrispondenti file SMIL che stabiliscono le correlazioni. Nel codice, ciascun brano viene delineato da un tag span.

Si capisce che è un lavoro non da poco: con uno strumento di authoring bisogna selezionare ciascuna parte del testo che si intende evidenziare, associarvi le parti del brano audio con dei puntatori e aggiornare il file html con tutti gli span corrispondenti, ciascuno con una id diversa.
I file SMIL contengono informazioni di questo tipo:

<p class="chapterTitle"> <par id="p000001"><text src="p002.xhtml#f000001"/><audio clipBegin="0:00:00.000" clipEnd="0:00:02.879" src="../Audio/02_CantodiNatale_Strofa_1_A.mp3"/></par>

E nel corrispondente file html troveremo:

<h1><span id="'p000001">Strofa Prima</span></h1>

Quindi, due approcci completamente diversi: nel primo caso la lettura viene effettuata dalla sintesi vocale, nel secondo si tratta di un laborioso lavoro di sincronizzazione fra markup e file audio.

Ma, i dubbi che ho sono: nel caso Balabolka, il software di lettura è sicuramente accessibile a tutti, nel caso di Chrome/Readium no.

È un audio e-book in Epub 3 definibile come accessibile? A oggi no, o meglio lo è soltanto teoricamente: le specifiche del markup relative all’accessibilità non sono supportate da alcun reader Readium compreso (stiamo lavorando, dicono nelle FAQ. Ok, aspettiamo), e di conseguenza come verificare?  Forse è per questo che la sezione “Best Practice” delle EPUB 3 Accessibility Guidelines per ora appare “Coming Soon”. Dovrebbero esserci novità per febbraio 2013, ok, aspettiamo.

C’è qualcosa di innovativo nell’approccio di epub3? No, in generale per l’accessibilità Epub 3 si appoggia a tecnologie del W3C e le stesse cose si possono fare da anni, utilizzando tecniche standard con risultati anche più trasparenti e senza obbligare “il lettore” ad usare specifici browser ed estensioni non accessibili.

A chi giova ciò? Francamente, a parte discorsi di marketing, non lo capisco. Tempo fa ho chiesto informazioni sul forum di IDPF nella sezione relativa all’accessibilità, domandando esplicitamente che cosa intendessero con “epub accessibility“. Si sono un po’ arrabbiati, pensando che fosse una disfida fra PDF e EPUB – disfida di cui non mi interessava nulla, però onestamente ammettendo che:

You’re kind of presenting an impossible problem, though. Either EPUB stays in the past with XHTML 1.1 and doesn’t get the benefits that will come with native audio/video, mathml, aria support, etc. or, it moves forward and has to live with some instability.

The decision was made to move forward with the web, so that does leave us in a position where we have to talk about an ideal future. I certainly appreciate this fact, as there’s a line I find myself always treading between what you can say is possible versus what is possible right now.

Ok, aspettiamo… Per ora si vede molta confusione, spero che possa servire a rendere più chiare e trasparenti le cose il convegno “eBooks: Great Expectations for Web Standards” organizzato dal W3C in partnership con IDPF e BISG. Magari ce la facciamo a farcela.

Dal word processor a epub: alcune possibili soluzioni

Passare da un formato doc, docx, rtf o odt a epub può essere abbastanza complicato. Molto dipende da come è stato preparato il file di partenza, ovviamente. Valgono le stesse regole necessarie per produrre file PDF accessibili, di cui abbiamo parlato tante volte: uso corretto degli stili di paragrafo, niente formattazioni locali selvagge, niente allineamenti a colpi di tab, barra spaziatrice o tasto Invio a raffica.

Quasi tutti i word processor, anzi direi tutti, dispongono di un’opzione Salva in HTML. Benché con diversi livelli di qualità del risultato, in ogni caso l’HTML prodotto non è adatto ad essere utilizzato in un epub direttamente, bisognerà come minimo ripulirlo da tutto il codice presentazionale (potete anche non farlo, ma ricordate che il contenuto del vostro file epub è in chiaro, chiunque lo potrà vedere e giudicare la qualità del vostro lavoro).

Esistono però alcune soluzioni sul mercato che aiutano molto in queste attività, anche se in qualche caso a pagamento. Di seguito alcuni programmi, scelti con il criterio del rapporto qualità/prezzo, secondo me da valutare. Ovviamente, se qualche lettore volesse aggiungere qualche ulteriore tool, ben contento di completare questa piccola lista.

ePub Maker

ePub Maker (costo attuale 59 $) è un programma che converte file doc e HTML in epub. È piuttosto completo ed efficace, e permette di convertire in batch anche gruppi di file. Il codice prodotto è abbastanza pulito, pronto per essere aperto in Sigil (non penserete che il lavoro sia finito, vero?).

Interfaccia di ePub Maker

Atlantis Word Processor

Questo word processor è davvero sorprendente: ha un basso costo (potete temporaneamente comprarlo a un prezzo speciale di 14.23 euro), ha un’interfaccia praticamente identica a quella di Word 2003, richiede pochissime risorse al computer (pochi mega sull’hard disk, altrettanto in ram), funziona anche in versione portable ed è dotato di tutte le funzioni di un moderno word processor. È ovviamente in grado di aprire i file di Word.

I file possono essere salvati in epub, anche in questo caso con buoni risultati.

No, non è Word, è Atlantis Word Processor

Se visitate il sito del produttore, non dimenticate di scaricare l’utility free Tweak EPUB: è un ottimo coltellino svizzero per fare aggiustamenti e modifiche sui file epub.

Tweak Epub

Writer2ePub

Writer2ePub è un’estensione per il Writer di LibreOffice/OpenOffice (ed è di conseguenza gratuito, anche se viene aggiunta una pagina di “pubblicità” in fondo al file epub prodotto [1. Disattivabile nelle preferenze, come fa notare l’autore del plugin nei commenti]). Per poterlo utilizzare quindi è necessario installare una di queste suite, e nella barra degli strumenti del Writer troverete tre nuovi pulsanti, dedicati alla generazione di file epub a partire dal documento aperto nel programma.
Il risultato è buono ed è possibile personalizzare l’output tramite un pannello di opzioni.

Writer2Epub in Libre Office

Da PDF (o doc, o rtf…) a XHTML senza soffrire troppo

Che dobbiate realizzare un sito o preparare i testi per un epub, poco cambia: è necessario ricavare del codice XHTML di qualità e pulito da un altro formato. Quasi tutti i programmi di impaginazione e word processing dispongono di una opzione “Salva in HTML”, ma se ci avete provato avete già visto i risultati: un file html che tenta di riprodurre l’impaginato (vai a sapere perché), pieno di classi, div span e codice di formattazione. Un programma vale l’altro, tutti producono codice “sporco”.

Con tanta pazienza ci si mette all’opera per le necessarie pulizie, chi con Blocco Note chi con altri editor più sofisticati, Trova e Sostituisci e per i più arditi Grep. Comunque, può essere un’impresa decisamente penosa.

Scrivo questo post per condividere una caratteristica di Dreamweaver che ho trovato molto utile in questa situazione. Vediamo un tipico esempio: ho solo il PDF e devo ricavarne il codice XHTML.

Apro il file in Acrobat Pro, provo ad esportarlo come XHTML, utilizzando le opzioni disponibili a secondo del caso.

Salvataggio del file in xhtml a partire da PDF

Vediamo che è successo.

L’orrendo codice prodotto: e ora chi lo pulisce?

Bè, ok, non è un gran risultato pensando che tutto il codice presentazionale è superfluo e va eliminato. Un lavoro lungo e noioso. Però forse no, un momento, apro il file in Dreamweaver.

Osservando il codice, è evidente che la spazzatura è generata da un’enorme quantità di attributi style, class ed elementi span.

IDEA!

Il Trova e Sostituisci di Dremaweaver fa ovviamente questo lavoro, ma anche altro. Fra le varie opzioni, permette anche di cercare uno specifico tag e rimuoverne gli atttibuti. Nel nostro caso, tutti i tag con attributo style.

Rimozione di tutti gli attributi style e relative definizioni in un colpo solo.

Ripeto la stessa operazione per class, seleziono Commands > Apply Source Formatting così metto anche in bella vista il codice, e… ok, fa proprio un’altra impressione. In pochi minuti di lavoro.

Il codice ripulito.

Probabilmente sarà necessario qualche altro ritocco, ma certo è un’altra cosa.

Epub 3 e accessibilità

dubbi su epub 3 e accessibilitàCon molta (troppa) enfasi, qualche tempo fa Eric Freese (membro del EPUB3 Working Group) affermava che mentre in Epub 2 le caratteristiche di accessibilità dovevano essere implementate tramite una combinazione di EPUB e DTBook (non ne conosco uno che se ne sia preoccupato, anzi che sia a conoscenza di questo particolare), con HTML5 non è più necessario usare DTBook perché “accessible by design”.
Se non funziona, è colpa degli editori incapaci. Lo notate il sorrisino, vero?

Cosa succede in realtà? Vediamo qualche semplice esempio. Come ben esposto nella Screen Reader User Survey #4 di WebAIM (maggio 2012), uno dei principali riferimenti per chi usa uno screen reader per leggere un testo restano i titoli, come è facile immaginare.

Lecito aspettarsi che almeno questo importantissimo elemento venga rispettato, vero? Invece no…

L’algoritmo di outline di HTML5 permette di usare  un elemento h1 per ciascun titolo contenuto in una pagina, e il valore del titolo viene ridefinito in relazione al livello di annidamento degli elementi di sezione (section) in cui h1 è posizionato. Anche se le specifiche di HTML “incoraggiano” a usare un solo elemento h1, è permesso l’uso di elementi da h1 a h6 che derivano il rank dal livello di annidamento della sezione.

Per chiarezza:

<h1>Level 1</h1>
<nav>
<h1>Level 2</h1>
</nav>
<section>
<h1>Level 2</h1>
<article>
<h1>Level 3</h1>
<aside>
<h1>Level 4</h1>
</aside>
</article>
</section>

È la stessa cosa di

<h1>Level 1</h1>
<nav>
<h2>Level 2</h2>
</nav>
<section>
<h2>Level 2</h2>
<article>
<h3>Level 3</h3>
<aside>
<h4>Level 4</h4>
</aside>
</article>
</section>

Abbastanza prevedibilmente, Jaws non interpreta i titoli del primo esempio. Peggio, con Jaws 13 succede che un h4 di questo tipo viene interpretato come h2, generando ovviamente una certa confusione nel lettore.

Così, l’unico modo per cavarsela è usare gli elementi da h1 a h6 alla vecchia maniera. Dopo dieci anni di sviluppo di HTML 5 siamo ancora qui. E stiamo parlando del solo markup di base, anzi nemmeno, dei soli titoli. Mah.

Indesign, catene di testo ed epub

Indesign permette di esportare gli impaginati in formato epub (sì, anche epub 3, ma non fatelo), ma alcune volte questa azione si conclude in una pena (leggi pain in the ass): il testo esportato è completamente confuso, i brani sembrano disposti a caso ed aver perso la loro sequenza logica, e bisogna eseguire un laborioso processo di copia/incolla/taglia/cuci per sistemare il testo. Perché?
Spesso questo accade perché testo ed immagini sono stati inseriti in frame non concatenati, tracciati manualmente sulla pagina per accogliere del contenuto pensando soltanto alla stampa: in fin dei conti, se a monitor funziona funzionerà anche in stampa. Anni di WYSIWYG ci hanno abituati a questo.
Ma, esportando in epub o altri formati (HTML, doc, qualsiasi formato richieda del contenuto linearizzato) la sequenza logica del testo può andare persa, perché in assenza di precise indicazioni il programma adotterà la strategia più semplice, ovvero esporterà i contenuti così come si presentano a monitor partendo dall’angolo superiore sinistro della pagina verso il basso a destra.
Così, se le colonne fossero tagliate per esempio da un titolo che si estende su più di una di esse, quei contenuti appariranno alla rinfusa. Eventuali immagini inserite finiranno in fondo al documento, e le note meglio non parlarne.

Si può evitare questo pasticcio e inutile lavoro di sistemazioni ed appicciconi utilizzando correttamente gli strumenti disponibili in Indesign.

Prima di tutto, attivate la visualizzazione dei Text Threads: View > Extras > Show Text Threads. Vedrete apparire intorno ai frame che contengono il testo delle particolari icone.

Text Threads visibili in Indesign

I simboli In (rossi) indicano dove fare clic per aggiungere testo in ingresso; analogamente, Out da dove prendere il testo da porre nell’In successivo. Se il testo viene disposto nei frame collegati in questo modo, l’esportazione sarà corretta indipendentemente dalla posizione del frame nella pagina. Quando posto su questi simboli, vedrete il cursore cambiare di forma per indicare l’azione che si sta svolgendo.

E le immagini? Bisognerà ancorarle al testo. Il modo più semplice è posizionare il cursore di inserimento testo nel punto dove l’immagine apparirà, importare l’immagine (o l’oggetto) selezionando File > Place ed utilizzare gli strumenti del menu contestuale che appare facendo clic destro sull’immagine stessa dopo averla inserita (per esempio, per accedere alle opzioni di Fitting,  Effect, Captions, ecc.).

La finestra di dialogo Anchored Object permette di stabilire la posizone dell’immagine rispetto al testo circostante o a particolari punti della pagina (chi ha trafficato un po’ con i CSS riconoscerà immediatamente le opzioni Inline).

Opzioni di posizionamento degli oggetti ancorati.

Se il file viene preparato in questo modo, l’esportazione sarà indolore e vi eviterete una quantità di grattacapi successivi qualsiasi sia il formato di esportazione scelto.

In ogni caso, se ci si trova nella situazione di dover lavorare su documenti complessi e queste operazioni non sono state effettuate in precedenza, il lavoro di editing da svolgere è comunque parecchio. In questa situazione può essere utile ricorrere a strumenti come TextStitcth di Rorohiko Resource, che permette di automatizzare alcune delle operazioni necessarie.

Epub vs. PDF vs. MOBI vs. Godzilla vs. Frankenstein

PDF, Epub, Mobi, KF8: la guerra dei formati

Che gran traffico su questi e-book. E quanti formati, quasi tutti incompatibili e insidiosi da convertire. Così, un e-book che funziona decentemente su una periferica è completamente inutilizzabile su un’altra, e così via. PDF, Epub, Mobi, KF8, tutti contro tutti. La torre di e-Babel.

Inoltre, molte delle versioni elettroniche disponibili sono realizzate malamente, evidentemente in economia e grande velocità senza alcuna verifica. Ovvio che a pagare è sempre l’utente, che qualche volta spenderà dei soldi per comprare degli e-book ma probabilmente si stuferà presto.

Trovo quindi del tutto sciocchi molti dei discorsi sul mercato degli e-book, la loro diffusione, l’esplosiva crescita, la prodigiosa macchina da guerra e così via, in gran parte basati su slogan, fuffa marketing e speranze personali (in Italia, in altri posti per quello che conosco sembra una cosa più seria). Che futuro può avere un mercato che vende prodotti avariati?

D’altra parte, capisco anche la confusione degli editori. Probabilmente in gran parte all’oscuro degli aspetti tecnici, vedono il loro e-book aprirsi in un qualche reader complice il service all’arrembaggio del momento che promette conversioni velocissime a prezzi ultra bassi e pensano eccoci, siamo pronti per il futuro (MOAR! LOOK MA IM IN TEH FUTUAR! We’re totally not going to go extinct now!”). E bisogna fatturare, c’è la crisi, e così via.

Io se fossi un editore sarei preoccupato del mio catalogo. Quale formato utilizzare per gli originali? Quale sarà il formato che mi permette di disporre di tutti i miei contenuti nella forma più flessibile possibile, la più universale, quella che più facilmente si adatterà ai formati di distribuzione attuali e futuri? Ci vuole quanto meno un formato standardizzato, creato da un ente super-partes, completo quanto basta.

Già, ancora il W3C e i suoi markup. Ma i markup originali, non quelli “modificati” o proprietari.