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.

La maggiore difficoltà della lettura a monitor (circa il 25% più
lenta che su carta) ha posto a designer e progettisti la necessità
di trovare dei modi che potessero bilanciare queste difficoltà.

Secondo la ricerca psicologica, la comprensione della lettura si compone
di due ordini di processi:

1. il primo è percettivo e riguarda la corretta identificazione
   e decodifica delle lettere che compongono le parole e le frasi.
2. il secondo è di livello più elevato e riguarda la
   costruzione di una rappresentazione mentale del significato del
   testo, a partire dalla decodifica svolta dal primo processo.

Questa rappresentazione mentale viene costruita a partire da rappresentazioni
di informazioni microstrutturali, che vanno ad attivare schemi e conoscenze.
Vengono quindi costruite rappresentazioni macrostrutturali e infine un
modello mentale coerente del significato del testo.

Rimandiamo questo secondo aspetto del processo di comprensione della
lettura ad un’ulteriore approfondimento (o ad uno dei corsi di web
writing che proponiamo), e soffermiamoci sul processo primario,
quello della corretta detezione di caratteri e parole. E’ infatti evidente
che il monitor va ad incidere proprio su questo processo, a causa:

• della minor risoluzione rispetto alla carta
• dell’emissione luminosa dei fosfori (più affaticante della
  carta)
• dell’innaturale posizione nella quale ci si trova ad affrontare l’atto
  della lettura su monitor.

La nascita degli screen-font

Queste difficoltà hanno spinto diverse aziende a commissionare
a designer di talento l’ideazione di speciali set di caratteri (le font-family)
che potessero in qualche modo ovviare alla maggior difficoltà di
lettura che si verifica su monitor. In particolare, la Microsoft ha commissionato
al font-designer Matthew Carter l’ideazione di caratteri che potessero
essere utilizzati per il proprio sistema operativo. L’operazione aveva
un doppio obiettivo:

• da una parte commerciale: non è infatti infrequente (anzi,
  è la fonte di reddito principale per molti font desiger) che
  un’azienda commissioni per il suo logo o per la sua comunicazione aziendale
  una famiglia di caratteri personalizzata, che rifletta la filosofia
  dell’azienda e la renda unica dal punto di vista visivo e tipografico.
• dall’altra, la ragione è pratica: avere delle lettere che
  si leggano con facilità su monitor è particolarmente importante
  per il miglioramento delle proprie interfacce.

Già il sistema operativo Macintosh utilizzava da tempo per i messaggi
di sistema un font particolare, il Chicago, dall’aspetto tozzo
e lineare, con poche linee oblique, facile da leggere anche a risoluzioni
piuttosto basse.
Matthew Carter (grazie anche al prezioso contributo di Thomas Rickner),
basandosi su lunghi studi ed esperimenti, ha identificato alcuni parametri
che gli hanno consentito di progettare i cosiddetti screen-font
per Microsoft: il Verdana (nel 1994) e il Georgia (in seguito).

Perché due? Se il Verdana nasce, come abbiamo detto, per essere
usato con il sistema operativo Window, il Georgia è stato pensato
come alternativa al Times per il nascente progetto del Microsoft Network.
Entrambi i tipi di caratteri vengono oggi distribuiti e installati gratuitamente
assieme al browser di casa Microsoft, Internet Explorer. Ciò che
ci spinge a parlare di entrambi questi due tipi di carattere è
che essi appartengono alle due categorie maggiori nelle quali vengono
classificati i font: caratteri con grazie (il Georgia) e senza
grazie (il Verdana).

La grazia perduta

Un tipico esempio di carattere con grazie è il Times (o
il New York per gli utenti Mac). Le sue lettere contegono delle piccole
appendici che accompagnano le linee ascedenti o discendenti "verso"
la lettera successiva. Si ritiene che l’uso faciliti la lettura su carta
e abbellisca i caratteri, soprattutto nel caso di paragrafi lunghi e densi.

L’altra categoria di caratteri è detta senza grazie, o ‘bastoni‘,
perché le sue lettere mancano completamente di queste appendici:
i caratteri sono composti da linee che terminano in maniera netta, come
dei bastoni, appunto. Degli esempi sono l’Arial, il Verdana, l’Impact,
l’Helvetica, il Chicago.

Nell’uso tipografico comune queste due categorie di caratteri assolvono
spesso funzioni logiche complementari: grazie alla loro maggior
facilità di lettura in testi lunghi e con dimensione ridotta, i
caratteri con grazie vengono usati per il corpo degli articoli.
Viceversa, i caratteri bastoni, non sempre adatti a testi lunghi, appaiono
più perentori e autorevoli nel rappresentare i titoli degli
articoli, a dimensioni più grandi, oltre a fornire un utile
contrasto visivo rispetto al carattere utilizzato per il corpo degli articoli.

Su monitor, e quindi su web, le cose come abbiamo visto sono un po’ più
complesse. I due font disegnati da Carter hanno entrambi la caratteristica
di essere più facili da leggere su monitor. Il principale problema
dei monitor è che hanno una bassa risoluzione: di conseguenza non
consentono ai caratteri di rimpicciolirsi mantenendo la nitidezza:

In pratica, come si vede, con il ridursi delle dimensioni del carattere,
il numero di pixel presente sul monitor non è sufficiente a rappresentare
in maniera nitida i dettagli del carattere, che diventa sfocato.

L’anti-aliasing

Questo problema è l’effetto dell’antialiasing a basse dimensioni.
Di cosa si tratta? L’antialiasing è una sorta di sfumatura che
rende il contorno delle lettere più morbido attraverso l’utilizzo
di pixel intermedi fra il colore di primo piano e di sfondo. L’antialiasing
nasce come espediente per superare la seghettatura dei contorni delle
lettere dovuta alla bassa risoluzione del monitor, ed è molto efficace
per dimensioni del carattere più grandi. Come abbiamo visto, però,
è una soluzione che a piccole dimensioni crea una sfocatura fastidiosa
che ostacola la lettura.

I browser e i sistemi operativi sono impostati in maniera da eliminare
l’antialiasing (a meno di non intervenire nelle preferenze), ma ciò
non sempre risolve il problema: le lettere sono, sì, più
definite, ma anche più irregolari, sopratutto a piccole dimensioni:

Il problema non riguarda solo le grazie o la nitidezza del carattere.
Su monitor spesso è anche l’avvicinamento fra i caratteri
a creare qualche problema. Alcuni programmi spaziano in maniera difettosa
alcune lettere, che si trovano così più vicine di altre
all’interno della stessa parola, creando raggruppamenti irregolari e ostacolando
la lettura. Nell’immagine qui sopra, la spaziatura fra le lettere ‘ix’
e le lettere ‘el’ nella parola ‘pixel’ sono sbilanciate anche a 11 pixel.

Omettiamo altri dettagli tecnici, per arrivare alla soluzione che Carter
ha utilizzato, soprattutto con il Verdana: questo set di caratteri appartiene
alla categoria ‘senza grazie’, ed elimina così i problemi specifici
legati alle piccole appendici dei caratteri. In più è particolarmente
curata la spaziatura fra le lettere, che è stata resa uniforme.
Fra gli altri pregi del Verdana va citato l’ottima resa del grassetto,
il bold tipografico, che serve ad enfatizzare i caratteri. Avendo pochi
pixel a disposizione, anche l’ingrossamento del carattere può essere
un problema, ma Carter lo ha brillantemente risolto.

Conseguenza: il carattere ‘perfetto’ per la lettura a monitor, anche
a dimensioni piccole.
Il Georgia, che pure non ha avuto l’enorme successo del Verdana anche
se sta conoscendo una stagione particolarmente fortunata dal momento che
un crescente numero di siti inizia ad utilizzarlo, è un carattere
con grazie particolarmente ben spaziato, e conserva una qualche parentela
stilistica con il più famoso Palatino.

Le dimensioni contano

Risolti dunque i problemi di leggibilità su monitor?
Magari. In realtà, la lettura è ancora faticosa: se miglioramento
c’è stato non è tale da farci gridare al miracolo. Le risoluzioni
dei monitor sono sempre basse, e, soprattutto, molti designer con la vista
di una lince continuano a progettare più per le proprie diottrie
che per quelle del pubblico medio, abbassando troppo la dimensione dei
caratteri.

Le sorprese maggiori vengono però da una serie di ricerche sulla
leggibilità dei font sul monitor condotte da Michael Bernard
et al. (Vai
alla ricerca, fuori da questo sito).
Secondo queste ricerche, a dimensioni dai 10 pixel in su, non vi
sarebbero significative differenze nell’accuratezza della lettura fra
gli screen-font (Verdana e Georgia) e font più tradizionali come
il Times e l’Arial. Non solo: la velocità di lettura è generalmente
maggiore per Times e Arial rispetto al Courier (il carattere che assomiglia
alla macchina da scrivere) e al Georgia!

Le sorprese non finiscono qui. La ricerca ha rilevato anche alcuni parametri
soggettivi, come la leggibilità percepita. Ovvero, l’impressione
di maggior o minor leggibilità che diversi font davano ai soggetti,
indipendentemente dalla prestazione reale. Ebbene, la leggibilità
percepita è generalmente maggiore per Courier, Arial e Georgia!

La piacevolezza dei font, invece, cambia ancora le carte in tavola. Il
Georgia sembra essere più attraente di Arial e Courier, e il Times
sembra più piacevole del Courier. Tuttavia, la scelta del font
preferito cambia ancora i risultati, a dimostrazione di quanto difficili
siano queste ricerche: il carattere scelto come preferito dai soggetti
(di età comprese fra i 18 e i 55 anni) è il Verdana, che
ha anche le prestazioni complessivamente migliori: non eccelle,
cioè, in alcuna categoria, ma ha risultati buoni un po’ in tutte
le misure.

Ulteriori ricerche sembrano necessarie, e altre ne sono state già
condotte, con soggetti di diverse età, dagli stessi autori. I risultati
sono ancora più complessi, e non li riassumeremo qui. Questo genere
di studi è però importante perché ci ricorda che
è bene evitare di lasciarsi andare con troppa leggerezza ad affermazioni
assolute: molte volte dipende davvero da quale angolatura si guardano
le cose (detto in maniera più rigorosa: con quale metodologia e
quali assunti si conducono le ricerche). Per quanto riguarda la pratica
sui nostri siti, Verdana e Georgia hanno comunque prestazioni discrete,
al pari dell’Arial, e sono scelte relativamente ‘sicure’.

Comunque decidiamo di comportarci, è importante mantenere almeno
una ferrea coerenza: a funzione uguale dovrebbe corrispondere sempre
tipo, stile e dimensione di carattere uguale. Niente di più
sciatto che veder utilizzato per gli articoli una volta l’Arial e una
volta il Verdana… oppure lo stesso carattere, ma con dimensioni diverse!
Ma queste sono norme di buon design e di buon senso, prima ancora che
di usabilità. Il buon senso non sempre dà le risposte migliori,
ma in questo caso pare essere una bussola più che affidabile e
a buon mercato rispetto a ricerche utili, ma dai risultati complessi e
dalle interpretazioni ancora non definitive.