Gli Standard Web per gli E-Book

L’HTML non è solo per il web#section1

E’ per qualunque testo distribuito online.

Le previsioni sulle tecnologie possono ritorcersi contro di noi, ma di questa sono sicuro: il destino dei formati non-HTML è stato segnato da HTML5 e dagli iPad. Le persone finalmente si sono rese conto di ciò che stava lì da tempo a fissarle negli occhi, ossia che l’HTML è grandioso per esprimersi attraverso le parole. Il web è principalmente espressione mediante testi e l’HTML funziona bene per il web. Lo stesso vale per i libri elettronici.

• Gli e-book solitamente non sono “siti web”. Potete pubblicare una copia del vostro libro come pagine web, ma l’e-book ha una struttura logica diversa da quella di un sito web.

• ePub, lo standard internazionale per gli e-book è costituito da HTML (XHTML 1.1 con alcune esclusioni minori). Altri due formati – alcuni tipi di “vero” XML e il DTBook – hanno pari dignità di HTML in ePub; la maggior parte degli sviluppatori userà però XHTML.

• Ogni e-reader esistente con la sola eccezione di Kindle di Amazon può visualizzare libri elettronici in formato ePub. (Il Kindle vi può mostrare la sua variante, AZW, di una variante di HTML [Mobipocket]: due passaggi distante dalla cosa reale. Il Kindle può anche convertire da HTML ad un formato che è in grado di visualizzare, presumibilmente in AZW).

E’ di cattivo gusto esultare di fronte agli sconfitti, ma HTML vince ancora una volta.

L’HTML non va bene per tutti i documenti, dal momento che deficita di importanti caratteristiche strutturali. (HTML5 risolve alcune di queste mancanze, ma non sarebbe d’aiuto per gli e-book di oggi.) L’HTML funziona efficacemente per un gran numero di documenti, molti dei quali vengono definiti libri. Investite contro HTML per la distribuzione online e avrete scommesso sul cavallo sbagliato.

Digressione filosofica#section2

Ogni articolo sui libri elettronici deve ritualmente affrontare il concetto di libro e la relazione tra la sua forma ed il libro. In questo caso, io riconoscerò il merito delle osservazioni del pioniere di internet Jaron Lanier, il quale ci mette in guardia nel suo libro You Are Not a Gadget [“Tu non sei un gadget”, ndr]: le decisioni riguardo al software prese presto possono drammaticamente costituire dei paletti per ciò che potrebbe essere possibile in futuro. (Altri hanno affermato la stessa idea—i progettisti di font tipografici di LettError si erano lamentati già una decina di anni fa riguardo ai limiti che i tool software impongono alle idee creative.)

Io sto illustrando la visione trionfalistica di HTML per la produzione di e-book. Sostenendo quello che sento è ovviamente scommettere sul cavallo vincente, ma sto anche contribuendo a soffocare qualunque forma nuova o non ancora inventata di libro. Appoggiare un formato digitale piuttosto che un altro è sempre un processo eugenetico: tramite questa selezione artificiale nessun nuovo formato potrebbe nascere oppure potrebbe morire prematuramente. Lo sto facendo io stesso proprio adesso minimizzando l’importanza della varianti XML e DTBook del formato ePub.

Sono tuttavia felice di contribuire alla morte dei “vooks” [vook.com] e di altri siti multimediali che si fingono libri. (In un libro, io non voglio un rettangolo con un video che blatera mentre cerco di leggere!) Sono delle specie di pubblicità pop-under animati che nessun utente vuole veramente ma che qualcuno al comando pretende. Contribuire a sterminare questa specie è qualcosa di cui vado orgoglioso. Per altre forme di libro, sostenere il markup HTML in forma stretta può causare danni non ancora calcolabili.

Ciononostante, io stesso sostengo che le opere tipiche di fiction e molti lavori di non-fiction si possono esprimere molto bene mediante e-book in formato HTML. Per raggiungere questo grado di espressione, dobbiamo liberarci dalle convenzioni della carta stampata, che non funzionano per i media elettronici.

Un altro modo per esprimere questo concetto è affermare che in queste circostanze i libri dovrebbero essere quanto più libri possibile. I libri stampati devono trarre vantaggio da tutte le caratteristiche che la carta stampata può offrire (risoluzione, le sensazioni che danno al tatto, la portabilità, la collezionabilità), mentre i libri elettronici devo parimenti approfittare dalle loro peculiarità (l’economicità, il fatto di poter essere copiati, il riflusso, la ricerca e l’indicizzazione, la connessione con altre risorse digitali).

Due problemi da risolvere#section3

Se HTML è il linguaggio di markup dominante per la maggior parte degli e-book, allora entrano in gioco gli standard web. Onestamente, non voglio riportare in vita la fine degli anni ’90 e dell’inizio del 2000, quando gli standardisti [persone che supportano gli standard web, ndr] se ne uscivano con un modo sempre leggermente diverso dall’altro per convincere gli sviluppatore a creare codice appropriato per i propri siti. In giro per il web, non si vedono ancora molti siti con codice HTML valido, ma le tabelle per il layout fanno ampiamente parte del passato e la semantica è migliorata parecchio. Probabilmente, gli standard web puri non hanno “vinto”, ma comunque gli standard web non sono proprio andati persi.

Sarebbe un eccesso di sicurezza assumere che questo successo si replicherà immediatamente negli e-book. Gli editori (ci sono pochissimi “sviluppatori” nel mondo degli e-book) non faranno automaticamente la cosa giusta e finora sembra che abbiano scelto di fare proprio quella sbagliata.

Se vogliamo che il codice degli editori per gli e-book sia valido come quello degli standardisti nei siti web, dobbiamo risolvere due problemi.

La semantica#section4

Tipicamente, il codice di un libro elettronico in formato ePub è XHTML 1.1. Ciò implica che il codice deve essere valido senza errori: lo standard ePub richiede l’error handling di XML, quindi non si possono usare tutti quei pasticci di stili di tag permessi da HTML 4.0.

I romanzi e molti libri non-fiction sono semanticamente semplici. Molti sono si possono sistemare con un piccolo range di tag:

• il P (ma non segnate tutto come paragrafo)
• gli Headings (ovviamente H1 dovrebbe essere riservato al titolo del libro)
• l’Emphasis (potrebbe riaccendersi il sempiterno dibattito sulla semantica di CITE rispetto a EM rispetto a I)
• le liste
• il BLOCKQUOTE
• le immagini (con il testo alternativo obbligatorio)

Perfino i non esperti possono imparare rapidamente a riconoscere strutture tanto semplici come queste. Ma il vero problema sono le persone che non hanno nemmeno la minima nozione del più semplice markup.

Metodi di produzione#section5

Affinché il codice degli e-book sia scritto in maniera corretta, in ogni stadio del processo produttivo deve esserci codice scritto bene. Al momento, le cose non funzionano così.

I piccoli spazi tra i puntini in un segno di omissione diventano punti di domanda. Per ulteriori esempi di tragicommedia tipografica negli e-book, guardate la sidebar di questo articolo.

Centinaia, se non migliaia, degli e-book disponibili in commercio delle case editrici legacy sono stati convertiti in “formati elettronici” ricavati acquisendo con lo scanner i libri stampati e convertendo l’OCR risultante in un file di testo. (Esclusivamente file di testo senza markup strutturato). Gli errori di copiatura sono così evidenti che gli e-book sono la prima categoria di libri della storia dell’umanità che potrebbero essere riportati in negozio perché difettosi. A sua volta, questo ha portato alla mitologia che gli e-book non siano altro che “formattazione.” (Non lo sono: sono testo strutturato con degli stili ad esso assegnati.)

Perché gli editori fanno la scansione delle copie cartacee? I libri non sono tutti prodotti sui computers al giorno d’oggi? Sì, ma gli editori possiedono questi files oppure sono in mano a svariati designer freelance? Qualcuno riesce almeno a recuperare questi files? E se fossero stati salvati in una vecchia versione di Quark Xpress o Ventura Publisher? Invece che spulciare tra i files residenti all’interno di computer che comunque non capiscono (sono persone da libro), gli editori ritengono sia più facile mandare il libro a degli offerenti economici per la scansione.

Questa non è un’ipotesi: abbiamo innumerevoli esempi da guardare proprio ora (vedi sidebar.).

La gara verso il basso#section6

Gli e-book stanno appena cominciando a prendere piede e già le parti più importanti di un e-book —il copy ed il markup— sono diventate le vittime di una gara verso il basso.

Qual è la soluzione? Il formato canonico di un libro dovrebbe essere l’HTML. Gli autori dovrebbero scrivere in HTML, creando un manoscritto che possa essere trasformato direttamente in e-book. Un manoscritto potrebbe quindi essere importato in quel fossile che l’industria editoriale si rifiuta di lasciarsi alle spalle, Microsoft Word. (L’operazione Track Changes di MS Word è diventata una specie di metadone per un’industria editoriale drogata).

Comporre un libro stampato partendo da questo sorgente, convertendolo due volte (HTML → Word → InDesign) vuol dire usare un workflow testato e funzionante, con il vantaggio aggiunto di produrre in uscita un PDF taggato dotato di buona semantica.

Ora, l’affermazione precedente è così ottimistica da risultare ridicola. Gli autori non cominceranno certo a scrivere in HTML, né tanto meno in quel formato XML che richiede Ben Hammersley. La copia di un libro continuerà a essere salvata in un file MS Word, Xpress e/o InDesign. Per quanto siano storpiati ed inadeguati, questi copy saranno poi “esportati” nella “formattazione” per e-book.

Tuttavia, invece di evitare gli errori come passo iniziale, l’industria dell’editoria potrebbe scegliere di correggere tali errori dopo che sono stati fatti – ma solo nel caso in cui gli autori, specialmente gli autori di grido con agenti spietati, si lamenteranno apertamente fintanto che gli editori non avranno sistemato intere produzioni di e-book. Questo non porterà di sicuro come risultato che gli autori scrivano HTML di buona qualità e robusto per i nuovi libri, ma almeno sistemerà parte della confusione.

Esperimenti in corso riguardanti gli e-book#section7

C’è molta attività nello “mondo” dei libri elettronici, dai think tank virtuali come Book Oven al copy-editing in crowdsourcing di Bite-Size(d) Edits, per nominare due siti co-gestiti dagli impresari Hugh McGuire e Stephanie Troeth. Altri due progetti stanno lavorando sulle possibilità del codice strutturato e standardizzato nel processo di creazione dell’e-book.

• ePub Zen Garden si pone l’obiettivo di essere per i layout e la tipografia degli e-book quello che CSS Zen Garden è stato per il web design, cioè molto. Il nuovo Zen Garden potrebbe trarre beneficio dall’esperienza del vecchio Zen Garden, offrendo più di un testo canonico a cui assegnare uno stile. Comunque, il concetto è sicuramente vincente (Potete aiutare dando il vostro contributo.)

• Thinkubator della Simon Fraser University sta lentamente producendo un progetto che si sviluppa sulla capacità di InDesign di salvare una rappresentazione round-trip di un file InDesign come XML. Convertire un output XML nel formato ePub XHTML potrebbe non essere banale, ma non è impossibile e potrebbe riuscire ad automatizzare il processo.

  A quel punto, non sarebbe necessario insegnare agli autori a scrivere in HTML: dovremmo solo insegnare ai desktop publisher ad usare nomi di stili strutturali, non di presentazione (Heading 2, Emphasis, Blockquote) per le traduzioni successive. Per gli autori che conoscono il codice, questo stesso metodo di produzione accetta XHTML come file sorgente, che può poi essere tradotto in un documento nativo InDesign o PDF senza file intermedi.

La separazione del contenuto dalla struttura non è mai stata così importante#section8

L’ePub usa XHTML 1.1 come linguaggio di markup, a cui si possono anche associare dei fogli di stile—ma solo CSS2, nessun’altra versione. Pertanto e come sempre dovrebbe essere, il markup deve rimanere separato dalla presentazione.

Ma i creatori di e-book provengono dal business dell’editoria. Sono scrittori, editori e desktop publishers: ovviamente, tenteranno di modificare e deformare il codice ed il testo per riprodurre le caratteristiche dei layout della carta stampata, che in realtà dovrebbero essere governati dai CSS, gestiti dagli e-book reader o dimenticati completamente. In alcuni casi, dovete effettivamente modificare il testo di un libro per far sì che funzioni come e-book, in altri casi non dovete farlo.

I task che i CSS devono gestire#section9

• Capolettera. E’ facile trovare e-book in commercio in cui la prima parola ha un errore: la parola è scritta come se la prima lettera fosse seguita da uno spazio e dal resto delle sue lettere. E’ un artefatto del capolettera, che, nel desktop publishing, sono solitamente resi come lettere separate sconnesse dal resto della parola. Negli e-book standard-compliant, dovete dimenticarvi dei capilettera o usare un selettore CSS (:first-letter).

  Lo stesso vale per il trattamento dei caratteri delle prime parole (spesso le prime n parole) di un capitolo o di una sezione. Può essere che le prime cinque parole usino il maiuscoletto (small caps) o il grassetto (bold). Non c’è modo di ottenere questo effetto al momento con i CSS, sebbene potete assegnare uno stile all’intera prima riga di un paragrafo. Potreste dover racchiudere le prime n parole in uno SPAN con una classe (che potrà poi essere portata in Word e InDesign per l’assegnamento di ulteriori stili).

• Maiuscoletto. I software che interpretano HTML (non solo i browser web) hanno parecchie difficoltà con il maiuscoletto. La dichiarazione CSS è sufficientemente semplice—font-variant: small-caps. Ma anche se il software ha accesso ad un font con per cui sono stati disegnati caratteri maiuscoletti autentici, solitamente non li userà: userà piccoli falsi maiuscoletti al loro posto (lettere maiuscole regolare con una dimensione in punti più piccola). Il maiuscoletto falso è spesso troppo piccolo, quasi sempre troppo leggero e spesso con una spaziatura insufficiente tra le lettere.

  Gli e-book devono usare i CSS per specificare il maiuscoletto. Ma quello che vedrete in giro in questo momento sarà il falso maiuscoletto, non il vero.

• Colonne. Malgrado quello che possa pensare l’ex ricercatore di Microsoft Bill Hill, il testo continuo su più colonne non ha senso in una finestra che si può ridimensionare e/o in cui si può fare scroll. (Volete che le colonne continuino ad aggiustarsi davanti ai vostri occhi?) Le colonne potrebbero aver senso in uno schermo fisso ed immobile. Per quello scopo, si potrebbe tentare con il modulo CSS3 per le colonne sebbene l’uso nel mondo reale potrebbe mostrarne le debolezze, ad esempio con il posizionamento delle illustrazioni, degli heading che vanno su più colonne ed dei callouts.

• Indentatura. Una delle più semplici (ma anche delle meno seguite) convenzioni della tipografia dei libri. Indentare la prima riga di un paragrafo che viene dopo un altro paragrafo ma niente altro non è mai stato così semplice da fare come con i CSS: p+p { text-indent: number }.

  Le linee vuote tra i paragrafi sono un artefatto di Microsoft Word e sono inoltre molto usate per il testo sullo schermo. Nella composizione tipografica di un libro, sono un errore (ma non ditelo ad O’Reilly, la casa editrice di libri di informatica che ama questo “formato”). Se davvero volete una linea vuota tra due paragrafi, aggiungete un margin-bottom a P. La copia sorgente non dovrebbe mai essere inquinata con caratteri di carriage-return estranei al testo, che sono poi difficili da eliminare.

I task che devono essere gestiti dal software dell’e-reader#section10

• Sillabazione e testo giustificato. Tutti si lamentano del testo completamente giustificato (testo come margine destro e sinistro diritti) negli e-reader: si fa più fatica a leggerlo perché la spaziatura tra le lettere e tra le parole è peggiore, a causa dell’inserimento degli spazi bianchi. Qual è la ragione di ciò? Gli e-reader tendono a non dividere con un trattino le parole che non ci stanno su di una riga: questa operazione è complessa e non è ancora stata resa perfetta nemmeno per le lingue in cui c’è una grande spinta dal mercato affinché venga applicata, come ad esempio in inglese.

  Per usare il gergo dell’industria, questa questione riguarda completamente H&J [hyphenation – dividere le parole che vanno a capo con un trattino – e justification – testo giustificato, ndr]. Gli autori devono resistere alla tentazione di aggiungere dei caratteri soft-hyphen [caratteri che specificano dove è permesso un a capo ma non lo forzano, ndr] ai testi elettronici. Il trattino di “a capo” è puramente una convenzione visiva, che cambia quando cambia il layout (come ad esempio quando si passa da una visualizzazione lunga e stretta ad una wide).

  La sillabazione negli e-book dovrebbe essere fatta dagli algoritmi e dai dizionari. Nell’editoria cartacea, le persone che fanno proofreading possono sovrascrivere le decisioni di un sistema H&J, ma quando si legge un e-book non si ha accanto uno di questi proofreader. Il software dell’e-reader deve quindi implementare la sillabazione: nessun altro dovrebbe occuparsene.

• Legature. Una delle primissime cose che chiunque si interessi di tipografica impara è l’uso delle legature: solitamente una f seguita da f, i o l. Unire le lettere in legature evita spiacevoli collisioni, come la cima di una f che va addosso al puntino di una i.

  Così come per la sillabazione, le legature sono un puro artefatto per la visualizzazione. Il motore di rendering deve occuparsi del loro inserimento, non siete voi a dover riempire il vostro testo sorgente di caratteri di legatura. (Cosa succederebbe se volessi mettere in maiuscolo grosse porzioni di testo? Cosa succederebbe se volessi fare una ricerca nel testo o cercare una parola che contenga un carattere di legatura nel dizionario? Ovviamente, potreste creare un software molto intelligente che superi il problema, ma in questo caso è più semplice evitare il problema). Le legature più rare, come ct e st, sono problematiche anche per i motori di visualizzazione [display engine, ndr], non solo per il testo sottostante.

  Quando dovete attivamente prevenire l’uso delle legature, come in un URL che include le lettere fi o fl, sembrano non esserci altre possibilità se non aggiungere un carattere nonjoiner di larghezza zero tra le lettere. (Non ci sono dichiarazioni CSS che abilitino e disabilitino le legature, sebbene ci sia una proposta in CSS3 che dovrebbe permettere di farlo).

• Punteggiatura sospesa [hanging (hung) punctuation, ndr]. Comporre tipograficamente alcuni segni di punteggiatura, come le virgolette ed i trattini, leggermente fuori dal margine rende il testo stampato più gradevole e potrebbe anche migliorare il testo su uno schermo. Anche questo è lasciato al display engine, non al testo o al suo autore.

Alterazioni al testo del libro#section11

Un’autentica separazione tra il markup strutturale e la presentazione sarà impossibile da ottenere nei libri più spesso che nei siti web. Le features tipografiche comuni ai libri possono adeguatamente essere espresse negli e-book solo effettuando un’alterazione sacrilega del manoscritto sorgente.

• Trattini. Nella versione in cui è comunemente usato nei testi stampati, il trattino lungo (—) [em dash, ndr] senza spazi né a destra né a sinistra, non funziona per il testo su schermo. I motori di rendering potrebbero essere così ottusi da mandare a capo una riga prima o dopo il trattino lungo. Ovviamente, tale problema potrà essere risolto un giorno o l’altro, ma in ogni caso questo carattere viene meno alla sua funzione intrinseca, ossia di spezzare il testo per le frasi di apposizione e per quelle parentetiche. Il trattino breve (–) [en dash, ndr] circondato da uno spazio a destra e da uno a sinistra evita i problemi di interruzione di linea e funziona meglio per lo scopo desiderato. (In breve: niente_spazio-trattino_lungo-niente_spazio non funziona; spazio-trattino_breve-spazio funziona.)

• Caratteri di spaziatura. Potete assolutamente utilizzare caratteri di spaziatura più larghi o più stretti rispetto allo spazio standard di una parola. Gli spazi em, en e thin sono tutti definiti in Unicode, insieme a molti altri e la loro visualizzazione a video è piuttosto buona e in via di miglioramento. Uno spazio standard tra parole o uno spazio nonbreaking tra parole è il carattere sbagliato in molti costrutti, come tra livelli annidati di virgolette o apostrofi adiacenti alle virgolette:

  • “I’ve Got Chills. They’re Multiplyin’ “
    (apostrofo; spazio thin; fine delle virgolette doppie)
  • “Technical is something techies do. ‘I’m a creative—I don’t touch that!’ ”
    (fine virgolette singole; spazio thin; fine virgolette doppie)
  • It’s a nod to the “ ’80s New Wave” sound of the Cars and Blondie
    (aperte doppie virgolette; thin space; apostrofo)

• Apici, pedici, frazioni. In teoria, qualsiasi carattere può essere composto come apice o pedice, solitamente cambiando di significato (πr² and πr2 sono due cose differenti). I font spesso hanno dei caratteri già disegnati per essere apici e pedici, tipicamente le cifre (⁰¹²³⁴⁵⁶⁷⁸⁹) e le lettere usate negli ordinali (13th, 13e) e nelle formule di saluto nella corrispondenza (Mlle, Sra.). Spesso i font hanno più apici e pedici di quelli definiti in Unicode, ma dove c’è un superior o un inferior in Unicode, si deve usare quello invece del markup SUB o SUP.

  La matematica merita un discorso a parte, come sempre. Non cercate di falsificare le frazioni come se steste usando una macchina da scrivere. Si dovrebbero sempre usare i piccoli numeri dei caratteri Unicode per le frazioni comuni. Non c’è un metodo affidabile in HTML e CSS per costruire le frazioni usando i caratteri Unicode superior e inferiors e le barre di frazione, né tanto meno esiste un metodo per creare frazioni annidate.

  Sezioni. La mancanza più grande di HTML per quel che riguarda i documenti lunghi è l’assenza di sezioni. Ci sono in HTML5, ma ePub non usa HTML5. Le sezioni possono a volte essere distinte dal resto mediante l’uso degli heading nei libri non-fiction, ma il paradigma classico della progettazione dei libri imporrebbe di lasciare uno spazio ulteriore tra le sezioni (con caratteri tipografici diversi per le prime parole di una nuova sezione): ciò non può semplicemente essere segnato tramite markup in HTML. (In casi non comuni, capita che le sezioni finiscano alla fine di una pagina stampata e si debba dedurre che è finita una sezione).

  C’è un’altra tradizione della composizione dei libri che può essere adattata ai testi elettronici ‚ comporre una ghirlanda [fleuron, ndr] o una greca tra le sezioni. E’ funzionalmente equivalente all’uso di HR, a cui si possono assegnare, con difficoltà, degli stili per farlo apparire meno intrusivo. Ciò nonostante, state semplicemente suggerendo che le sezioni sono cambiate ma non state incapsulando le sezioni nel loro markup.

• Note a pié di pagina e riferimenti bibliografici. In HTML continuano a mancare strutture per queste, per le note a margine e per i callout come i pull quote. Le note a pié di pagina devono trasformarsi in riferimenti bibliografici in fondo al libro, che, nel caso migliore, creando un problema nel caso in cui tale e-book avesse già dei riferimenti bibliografici. E’ una mancanza grave.

Note speciali sulle tabelle#section12

Ancora una volta, le tabelle continuano ad essere qualcosa che gli e-book non possono rendere. Leggo questa affermazione come un’ammissione del fatto che le persone che si occupano di “convertire” gli e-book non capiscono il markup delle tabelle. Anche le tabelle più complesse possono avere il loro markup in HTML (Ciò di cui possono realmente lamentarsi è quanta larghezza occupa una tabella—forse più della larghezza che il display di un certo e-reader ha nativamente).

Conclusioni#section13

Sperimentare con la forma del libro è una cosa, ma la struttura di un e-book non è qualcosa che possiamo decidere mentre procediamo. Non dovremmo fingere che non ci siano regole né dovremmo importare concetti direttamente dai libri stampati, perché non tutti questi funzionano per i libri elettronici. Il formato dominante per il futuro dell’e-book, ePub, può trarre beneficio dalla nostra esperienza ormai quasi decennale di costruzione di siti web standard-compliant.