Per anni i web designer hanno avuto scelte limitate riguardo ai font da usare sulle proprie pagine web, dovendo ripiegare su quelli più diffusi sui computer dei loro utenti (Verdana, Arial, Courier, ecc: vedere questo articolo).

Negli ultimi anni sono avvenuti almeno due fenomeni di rilievo, che possono cambiare la qualità del web design come lo conosciamo oggi:

1. Sono stati creati e diffusi su molti computer nuovi font per il monitor. La sola Microsoft ha diffuso font come Constantia, Corbel, Calibri, Cambria, Candara, Consolas, prodotti e pensati per le sue applicazioni e diffusi sui nuovi computer con il sistema operativo Vista, ma anche su Mac con le suite di Office.
2. A prescindere dai font presenti sui computer degli utenti, si sono diffuse alcune tecniche per utilizzare font direttamente via web, o come immagini o grazie a nuove potenzialità dei browser.

È dunque giunto il momento di arricchire le nostre scelte tipografiche sul web? Quanto è sicuro utilizzare questi font nelle proprie pagine web? E quali tecniche sono più adatte?

Le prime tecniche di image replacement

Già prima dell’introduzione di nuovi font, i web designer si erano affidati a tecniche di image replacement per sostituire, attraverso i CSS, delle immagini di background al testo prodotto dal browser. La tecnica di base può venir automatizzata con librerie php e javascript come Facelift e con l’uso di Flash (la tecnica è chiamata Sifr; qui in versione Sifr 3, la più aggiornata, opera di Mike Davidson) per generare automaticamente, a partire dal font o da una versione ricodificata del font stesso, immagini anche su più righe, perfino utilizzando gli stili CSS. La versione in Flash rende il testo addirittura ridimensionabile e selezionabile. Il tutto degrada a testo standard per gli utenti che non hanno a seconda del caso javascript o Flash attivo.

I problemi con queste tecniche sono comunque diversi:

1. Se si disabilitano i css, javascript o le immagini, da soli o contemporaneamente, si possono avere problemi di accessibilità (è disponibile un test dei punti di forza e di debolezza delle diverse tecniche)
2. Alcune tecniche prevedono che sia presente sul server una copia del font, o una sua versione ricodificata in Flash. Questo apre la porta a problemi di licenza: i font sul server possono infatti essere intercettati e, se non opportunamente protetti, scaricati illecitamente. Anche dalla versione in Flash può, teoricamente, essere ricostruito il file originale, anche se la procedura è comunque meno semplice che reperire il font direttamente sulle reti di file sharing.

Al netto di questi problemi noti, le tecniche erano comunque sufficientemente robuste (o i difetti poco rilevanti per il pubblico di quei siti) da essere usate anche in siti di vasta audience, per migliorarne la resa estetica, elemento importante anche per aumentare la tolleranza degli utenti, l’usabilità percepita e la credibilità.

Sebbene ancora usate e utilizzabili, le tecniche di image replacement sono state recentemente affiancate da nuovi espedienti che promettono di ottenere risultati anche migliori. In particolare:

1. Per chi non avesse esigenze di perfezione nella resa dei font, ma volesse usare i font più recenti almeno per gli utenti che li hanno installati, è sempre possibile usare nuovi font-stack.
2. Tecniche javascript per disegnare il testo a partire da un font sorgente, usando funzioni avanzate, come VML per Internet Explorer e altre introdotte da HTML 5 (<canvas>) per gli altri browser. Sebbene HTML 5 sia una specifica in progress, alcune sue parti sono state implementate già da alcuni browser (Safari, Firefox, Opera e Chrome), e consentono di far disegnare le lettere direttamente al browser, senza la necessità di produrre e caricare immagini; per Explorer, che non supporta <canvas> si può usare VML, appunto, implementato silenziosamente sul browser di Redmond fin dalla versione 5.0, e finora scarsamente utilizzato (anche Google Maps però usa VML, standard aperto proposto fin dal 1998 da alcune aziende, su Explorer 5.5 e successivi, mentre fa uso di SVG, specifica ufficiale del W3C, sugli altri browser).
3. L’uso nel css della regola @font-face, proveniente direttamente dalle specifiche CSS3, che non sono ancora definitive, ma, come per HTML5, sono già parzialmente implementate su molti browser.

Queste tecniche si stanno sostituendo alle tecniche di image replacement, rendendole obsolete, e stanno offrendo la possibilità concreta ai web designer di usare font non consueti sulle proprie pagine web.

Vediamo i pro e i contro (che non mancano) di queste tecniche, il loro grado di maturazione e come usarle nella produzione di siti già oggi.

I font-stack

La proprietà font-family dei CSS consente di specificare font diversi, separati da virgola. I browser tenteranno di utilizzare il primo font, se disponibile sul computer dell’utente. In caso negativo proveranno con il secondo, e così via. È sempre stata buona norma usare più di un font nelle dichiarazioni di proprietà font-family, in modo da accomodare tutti, scrivendoli dal più particolare (e meno diffuso) al più generale e diffuso. E lasciare come ultima indicazione non un font, ma un’indicazione generica di famiglia, come serif o sans-serif (con grazie o senza grazie, una macro-distinzione fra i font). Questa sequenza è uno stack, una pila di font utilizzabili in successione in caso di assenza del font precedente.

Spingendo questo comportamento, implementato da tutti i browser, all’estremo, è possibile scrivere regole css che propongano per primi i font più recenti, per poi degradare, progressivamente, verso font meno recenti ma più diffusi, più generici. un esempio di font-stack è il seguente:

body {
font-family: “Hoefler Text”,
“Goudy Old Style”,
Georgia,
serif;
}

In questo modo, chi ha uno dei primi font, vedrà quello. Gli altri vedranno il Georgia o, se non ce l’hanno, il più generico font graziato disponibile (solitamente il Times New Roman o il Times).

Tecniche javascript

Come già detto, è possibile già oggi consentire al browser di disegnare direttamente il testo con un font, usando per explorer un linguaggio nativo, VML, per gli altri browser l’implementazione del tag <canvas> proveniente dalle specifiche incomplete di HTML 5.
Queste tecniche si appoggiano a javascript (e non sono realizzabili in puro HTML/CSS) per due ragioni:

1. Per servire tecniche diverse a browser diversi
2. Per “tradurre” il font originale in un formato utilizzabile da javascript.

Le librerie più diffuse pronte all’uso che utilizzano questa tecnica sono:

• Typeface
• Cufòn

Da test prestazionali sembra che Cufòn sia il più efficiente. Questi sistemi funzionano così:

1. Prima di tutto bisogna creare una versione javascript del font (per Cufòn è possibile crearla da questa pagina, mentre per Typeface qui.)
2. Poi si caricano font in formato javascript e libreria completa sul server
3. A quel punto si referenziano nella pagina HTML
4. Con una chiamata diretta si indica a quali selettori applicare il nuovo font; di default Cufòn supporta solo selettori diretti, ma è in grado di usare jQuery come selector engine
5. A quel punto è possibile usare una normale dichiarazione css per modificare dimensione e colore dei font, come per qualunque altro font installato sul computer.

I difetti sono:

1. La non comoda selezionabilità del testo – Con Cufòn il testo rimane selezionabile in molti browser (non tutti), ma non sempre la selezione viene evidenziata, dunque un utente di competenze medie può pensare di non riuscire a selezionarlo; con Typeface la selezionabilità è stata aggiunta in seguito e aumenta il peso del javascript (è possibile rinunciarvi)
2. un ovvio aumento di peso dato dai file aggiuntivi (a questo proposito piò essere utile il discorso fatto su usabile.it a proposito del peso delle home page)
3. il decadimento di prestazioni sopra un certo numero di caratteri (attorno al migliaio) che rende queste tecniche già utilizzabili per titoli e sommari, ma non per il corpo del testo
4. Problemi di licenza – Infatti i font utilizzabili online sono solo quelli la cui licenza lo prevede. Attualmente, i font commerciali dovrebbero prevedere troppe varianti alla licenza d’uso (usarli liberamente sul web è diverso che usarli liberalmente su Word, per dire…) per essere un’alternativa di prossima realizzazione, sebbene sia in corso un intenso dibattito sull’argomento, anche presso li W3C, dibattito che esula però dagli scopi di questo articolo.

Ci sono diverse soluzioni ai problemi di licenza:

1. usare solo font free (e ce ne sono di ottimi)
2. usare un servizio specifico che assolve alla fonte il problema, versando delle royalties dominio-specifiche (il font verrà anche protetto contro lo scaricamento deliberato). Alcuni servizi di questo tipo già esistono, e altri ne sono annunciati. In pratica, anche i font, sul web, si potranno pagare come un servizio, se questo modello funzionerà.

Dovrebbe a questo punto essere chiaro, insomma, che i problemi di licenza sono più complessi di quelli tecnici, tanto che molti cominciano a lamentarsi dell’arretratezza complessiva della normativa sui diritti di utilizzo, non solo di software e musica, ma di tutto ciò che si può avere in formato digitale (cioè qualunque prodotto di comunicazione).

In definitiva, le tecniche javascript sono già mature, utilizzabili per testi brevi ma non brevissimi, a patto di risolvere i problemi di royalties. Naturalmente chi non ha javascript attivo vedrà una versione della pagina con un font normale, dichiarato nel css secondo l’ordine di priorità.

Il font-embedding e l’uso della regola @Font-face

La regola @font-face, prevista nei CSS3, prevede – se l’utente non lo ha installato sul suo computer – lo scaricamento di un font dal server per l’uso diretto, incorporato, nella pagina web. Sorprendentemente, è supportato da moltissimi browser. Dunque, è una tecnica già utilizzabile, e non ha le controindicazioni di limiti alla lunghezza del testo e di peso di ulteriori file (tranne il font, naturalmente, che può pesare qualche decina di kilobyte). I difetti principali di questa tecnica sono tre:

1. Problemi di licenza (per i quali valgono sostanzialmente le stesse considerazioni fatte per la soluzione javascript)
2. Non è utilizzabile da Firefox per le versioni inferiori alle 3.5 (un bacino d’utenza ancora alto: al momento in cui scriviamo tra il 16% e il 25% a seconda dei siti); questi potranno però leggere i propri testi in un altro font, secondo l’ordine di graceful degradation della corrispondente dichiarazione CSS.
3. Richiede un hack per Internet Explorer. Tuttavia, l’hack è in questo caso robusto e testato (anche se lo è solo da inizio settembre 2009). Semplicemente, bisogna servire Explorer con un diverso formato del font (un formato dedicato, EOT, per la quale può servire un’utility di conversione), e con una dichiarazione dalla sintassi specifica.

Il modo corretto per servire un font a tutti i browser che la supportano, è, dunque, secondo questo articolo di Paul Irish, da cui è tratto l’esempio, la seguente:

@font-face {
font-family: ‘Graublau Web’;
src: url(‘GraublauWeb.eot’);
src: local(‘Graublau Web Regular’), local(‘Graublau Web’),
url(‘GraublauWeb.otf’) format(‘opentype’);
}
h1 {
font-family: ‘Graublau Web’, Arial, sans-serif;
}

Così si definisce la nuova famiglia “Graublau Web”, che poi può essere usata in seguito in qualunque dichiarazione css, come una famiglia font qualsiasi. La prima dichiarazione src è per Explorer, e usa il formato proprietario .eot (che peraltro è anche l’unico ad essere in regola con i problemi di licenza, perché incorpora un meccanismo di DRM) . La seconda è per gli altri browser, e non viene capita da Explorer a causa dell’istruzione format(), che blocca il suo parsing. Il nome del file deve essere messo fra virgolette (doppie o singole) per Opera. Il nome del file nella dichiarazione local deve corrispondere al nome del font (non del file), comprese le maiuscole.

Tutti i browser tranne explorer, cercano prima il file nel computer locale dell’utente. Solo se non lo trovano, lo scaricano dal server e lo utilizzano.

Usare il formato SVG per includere altri browser

Dalla festa rimangono, allo stato attuale, esclusi alcuni browser. Oltre a Firefox nelle versioni inferiori a 3.5, che andranno progressivamente a ridursi, anche Chrome non supporta nativamente i webfont fino alla versione 3. O meglio, li supporta, ma dopo un’attivazione da linea di comando. Qualcosa che il nostro utente non farà mai. È annunciato un supporto per la versione 4 stabile, ma al momento non si vedono novità dalle versioni alfa. C‘è però un formato supportato sia da Chrome 0.3 e successivi, sia Opera 9 e successivi, sia da Safari in versione iPhone OS 3.1. Si tratta del formato SVG: in pratica, il nostro font viene ridefinito in questa variante di XML, già standard W3C per la grafica vettoriale.

Con FontForge è possibile fare una conversione da .ttf a .svg del nostro font, eventualmente anche eliminando parte dei glifi non usati per alleggerire il peso del font (operazione chiamata “subsetting”). A quel punto la regola di Paul Irish può essere riscritta come segue:

@font-face {
font-family: ‘Graublau Web’;
src: url(‘GraublauWeb.eot’);
src: local(‘Graublau Web Regular’), local(‘Graublau Web’),
url(“GraublauWeb.svg#lg”) format(‘svg’),
url(‘GraublauWeb.otf’) format(‘opentype’);
}
h1 {
font-family: ‘Graublau Web’, Arial, sans-serif;
}

La chiamata al formato .svg va eseguita referenziando anche l’id del font, che trovate nel tag <font id="lg"> aprendo il file prodotto con un editor di testo. Così abbiamo incluso anche Chrome, Opera9 e Safari mobile nel nostro parco browser, con relativamente poco sforzo (una volta imparata la conversione). Cioè un altro 5-10% di browser a giudicare dalle nostre statistiche. Rimane escluso praticamente solo il 15% per cento che usa una versione inferiore alla 3.5 di Firefox (queste percentuali sono solo indicative e possono cambiare anche di molto a seconda della tipologia di sito).

La miglior soluzione e alcuni piccoli problemi

Va precisato che in prospettiva (da qui in avanti) questa sembra di gran lunga la soluzione migliore, sia per facilità di implementazione, che per ragioni di accessibilità. I problemi tipici dell’image-replacement e della disabilitazione di immagini, css e javascript, vengono infatti risolti automaticamente, perché non c‘è alcuna immagine da generare. Purtroppo non sembra dietro l’angolo la soluzione dei problemi di diritti per le licenze online dei font. Si tratta di capire se questo significherà un aumento dell’utilizzo dei font free, alcuni magari cloni veri e propri di font commerciali più noti, oppure il successo di servizi di Font-as-a-service, o, magari, il diffondersi, come in altri campi, di pratiche di utilizzo diffuso dei font pur in mancanza della licenza.

Problemi tecnici con le varianti dei font

Alcuni font sono distribuiti con più “pesi”. In teoria via CSS si puòi specificare il peso di un font (dall’ultra-light all’ultra-black) con la proprietà font-weight: 100-900. In realtà questo non avviene, anzi, vi sono discrepanze fastidiose con diversi browser. Potete farvene un’idea più precisa in quest’articolo di Richard Rutter. Sono disponibili altre informazioni su differenze di rendering e di kerning, e un test case su diversi modi di servire il font via css, inclusa la codifica base64.

Problemi di licenza e soluzioni miste

I problemi di licenza e l’uso del @font-face embedding sono al centro del sito Font Squirrel, che presenta moltissimi font free e già con un kit di formati e le regole CSS pronte per il @font-face embedding.

Due soluzioni (e doppio lavoro) in una

Se usate font free, cioè se risolvete i problemi di licenza, è possibile anche pensar di usare in contemporanea @font-face e Cufòn, in modo da coprire un maggior numero di browser. Con un check javascript è possibile valutare se il font è disponibile, sia direttamente sul computer dell’utente che tramite scaricamento con @font-face. Ad esempio, questo check andrebbe bene per le versioni di Firefox inferiori alla 3.5. Nel caso il font non risultasse disponibile, né il browser supportasse @font-face, allora si potrebbe passare ad utilizzare Cufòn.

La procedura dettagliata e i file javascript necessari sono disponibili in questo articolo di Kilian Valkhof. Ci sono alcuni effetti collaterali (ad esempio in Explorer, perché Cufòn verrebbe prima applicato e poi sostituito con il @font-face, e le contromosse, che pure esistono, non sono così robuste). Insomma si rischia di complicarsi la vita: dovete valutare valutare voi se il vostro design merita tutto questo lavoro. Dal lato utente, è chiaro che @font-face è la soluzione migliore perché permette selezionabilità del testo e stati :hover sui link. Si tratta di valutare se,

Il futuro

Con l’obsolescenza delle vecchie versioni di Firefox, verrà sempre più usata la tecnica che si basa sul @font-face, usando Cufòn solo come alternativa temporanea. Aprendo a sua volta dei problemi: come evitare che, come nei primi anni del web, si usino font illeggibili, problematici, non nati per il monitor? Come preservare una corretta leggibilità? Il consiglio è di usare font di cui si conoscano le prestazioni di leggibilità (ma ricerche del genere non sono frequenti), o di limitarsi, nell’uso di font anomali, a quelli più leggibili e comunque a caratteri sufficientemente grandi (oltre una certa dimensione, molti font hanno leggibilità paragonabile).

Sintesi

In sintesi:

• Se vi importa la precisione grafica per la quasi totalità dei vostri utenti e non vi importano molto le questioni di accessibilità, né il peso (file immagine diversi possono dover essere caricati in pagine diverse, rendendo impossibile il caching); o se volete per forza usare font che non hanno licenze web, dovrete continuare a usare le tecniche di image-replacement.
• Se vi importa la precisione grafica e volete essere sicuri che venga preservata per il più ampio pubblico possibile, non vi crea difficoltà usare solo font free, e riuscite a tenere sotto controllo il peso complessivo dei file prodotti (che vengono scaricati solo alla prima pagina), scartate i font-stack e l’image replacement e orientatevi su tecniche javascript, oppure, valutandone la fattibilità, soluzioni miste @font-face + tecniche javascript.
• Se vi importa la precisione grafica, ma siete in grado di tollerare che una certa percentuale di utenti (che andrà progressivamente calando) visiti una versione subottimale del vostro design, e non vi servono font non free, usate il @font-face: la scelta pagherà con il passare del tempo.
• Se non vi importa la precisione grafica ma volete solo variare un po’ i vostri font, anche solo per una parte dei vostri utenti, provate a usare i font-stack. Eliminerete anche i problemi di licenza, oltre che quelli di peso, perché non dovete caricare nulla sul server.

Gli scenari coperti dalle varie soluzioni, come si vede, sono piuttosto differenti, non sovrapponibili. L’importante è che definiate i vostri obiettivi e valutiate i pro e i contro delle diverse tecniche nel vostro specifico caso.

Ulteriori letture

• Ottima sintesi in italiano su tutta la questione dei webfonts
• La proposta di un formato compresso che dovrebbe risolvere i problemi di licenza dei font (in inglese)
• Come diventare un signore dei font sul web, in inglese
• Oltre a Font Squirrel, altri luoghi in cui trovare font senza problemi di diritti per l’incorporamento nelle pagine web sono The League of Moveable Type e la Exlibris di Jos Buivenga

Corsi e aggiornamenti

Il tema di questo articolo è discusso anche nel nostro corso di css design, proposto in-house ad enti e aziende. L’articolo potrebbe venir modificato in seguito alle prime letture per render conto dell’inevitabile evoluzione della materia. Ne daremo conto sul blog.