Tipografia web: quali sono i limiti e quali le possibili soluzioni?

tipProgettare la grafica di un sito web è un vero e proprio atto creativo: certo, non il più libero, visto che bisogna tener conto di griglie, architettura delle informazioni, usabilità, ecc. ma nonostante questo il web designer può utilizzare liberamente colori, texture, pattern ed immagini appropriate per veicolare il messaggio del sito web.
C’è però ancora uno dei maggiori limiti da superare: la scelta limitata dei font.

Quali sono i limiti della tipografia web?

E’ noto che affinchè un font sia visibile sul computer dell’utente, esso dev’essere installato sul suo computer. Ciò riduce la tipografia sul web ad una manciata di font cosiddetti web-safe, e cioè quei font che sono installati praticamente su tutti i computer: Arial, Georgia, Times New Roman, Verdana, ecc. Eppure i caratteri tipografici contribuiscono a supportare la comunicazione di un sito web al pari, per esempio, dei colori. Come possiamo allora superare questi limiti?

L’uso delle immagini in sostituzione dei testi

Finora, la soluzione più comune è stata l’utilizzo di immagini in sostituzione dei testi per i quali si sarebbe adottato un font alternativo a quelli web-safe (principalmente titoli e voci di menu). Ma non si tratta della soluzione più comoda o conveniente, per diversi motivi:

  1. eventuali modifiche al testo comportano modifiche al file grafico;
  2. i motori di ricerca non sono in grado di leggere il testo delle immagini;
  3. se per qualsiasi motivo l’utente non può visualizzare le immagini, potrebbe non vedere il testo alternativo (per esempio nel caso in cui nel CSS è impostata la proprietà text-indent con un valore negativo).

sIFR

Negli ultimi tempi si sono diffuse diverse tecniche di sostituzione dei font che consentono di incorporare i font in una pagina web senza utilizzare le immagini.

La prima a fare il botto è stata sIFR (Scalable Inman Flash Replacement), una tecnica che per raggiungere l’obiettivo combina l’uso di Flash e di JavaScript. Se ti interessa, c’è un tutorial su Html.it che ti spiega come implementarla nel tuo sito.

sIFR presenta però qualche svantaggio. Tuttavia, anche se non è facilissimo da installare, niente che non si possa apprendere con un pó di impegno. È necessario scaricare un file sorgente di Flash e ricompilarlo utilizzando il font desiderato, e nonostante abbia un foglio di stile a parte, alcune proprietà dei CSS vanno assegnate nel file JavaScript. Inoltre, comporta i classici problemi legati all’uso della tecnologia Flash e alla disponibilità o meno del Flash Player.

Cufòn

Molto più semplice è l’uso di Cufòn. Qui un tutorial di Mondoinformatico per implementarlo nel tuo sito.

Questa tecnica richiede il solo utilizzo di JavaScript (niente Flash) e richiede solo un piccolo script da inserire nell’head del documento HTML e due file JavaScript: uno è un motore di rendering; l’altro è un file che va generato caricando il font che si desidera utilizzare, e che trasforma il font in un formato compatibile con tutti i browser (niente di complicato, ci vuole mezzo minuto per generarlo). È una soluzione molto più rapida rispetto a sIFR che non comporta problemi di accessibilità.

Il grande svantaggio di Cufòn è che, al contrario di sIFR, il testo sostituito non è selezionabile; gli sviluppatori dicono di aver trovato una soluzione per tutti i browser tranne Opera, e non appena avranno risolto rilasceranno un aggiornamento che permetterà anche la selezione del testo.

La regola @font-face

Le tecniche di sostituzione dei font sono però degli hack. C’è bisogno invece di una tecnica definitiva, che, almeno teoricamente, é giá stata delineata. Si tratta della regola @font-face dei CSS, che permette di incorporare qualsiasi font con appena due righe di codice:


@font-face {

font-family: Museo;

src: url('https://percorso/Museo.otf');

}

Tutto risolto allora? Non esattamente. Vanno considerati due aspetti, uno tecnico e l’altro legale.

Per quanto riguarda l’aspetto tecnico, la regola @font-face non è ancora supportata da tutti i browser. Al momento, la supportano solo Safari (dalla versione 3.1) e Internet Explorer (dalla versione 4); ma @font-face è compatibile anche con le versioni beta già rilasciate di Firefox 3.5, Opera 10 e Chrome 2, perciò molto presto sarà supportata da tutti i principali browser. Resta qualche problema di retrocompatibilità con le versioni precedenti, ma, almeno per il futuro, la parte tecnica è risolta.

Ora c’è da considerare l’aspetto legale. Torniamo un attimo indietro per fare una precisazione: Internet Explorer consente di utilizzare questa regola solo dopo aver convertito il font in formato .eot attraverso appositi strumenti rilasciati da Microsoft. Si tratta di un formato proprietario pensato e realizzato per tutelare il copyright di chi ha realizzato il font stesso. Questa soluzione non è stata però mai condivisa dai produttori degli altri browser, perchè giudicata troppo complessa. Safari e presto tutti gli altri browser, invece, daranno la possibilità di utilizzare @font-face con i due formati più diffusi per i font: .ttf e .otf.

Ma allora, scartata la soluzione di Internet Explorer, come la mettiamo con la tutela dei copyright?

Typekit

Il 27 maggio è stato annunciato un nuovo servizio che dovrebbe partire in estate: Typekit. Il progetto non è ancora nemmeno in beta, i dettagli non si conoscono, ma più o meno dovrebbe funzionare così: Typekit ospita il file del font sul suo server; il designer paga a Typekit la licenza per poter linkare al font dai CSS, per mezzo di @font-face e di una riga di JavaScript in più; Typekit paga le royalty alle foundries). Così, se da una parte @font-face risolve l’aspetto tecnico dell’incorporazione dei font sul web, dall’altra Typekit potrebbe risolverne definitivamente l’aspetto legale.

Se Typekit funzionasse davvero, le foundries potrebbero essere incoraggiate nel rilasciare le licenze per il web linking, oggi così rare proprio per la mancanza di un buon sistema di tutela (qui una lista dei pochi font con una licenza di questo tipo); al tempo stesso, gli sviluppatori di Internet Explorer potrebbero convincersi a rinunciare al formato .eot e a supportare anche .ttf e .otf al pari degli altri browser. Come ho già detto, è ancora tutto da vedere.

Non si conoscono i prezzi (anche se faranno parte della libreria di Typekit pure i font gratuiti), non si conosce la velocità dei server di Typekit, non si conoscono i dettagli della licenza. L’idea però è buona e il team dietro Typekit pare essere di ottimo livello (il più “esposto” è Jeffrey Veen, che ha lavorato in passato al lancio di altre start-up quali Flickr, Blogger e Google Analytics).

Ad ogni modo, @font-face, Typekit, Cufòn, sIFR ecc. sono tutte manifestazioni di un problema sentito dai designer e che, una volta risolto, potrebbe davvero cambiare la faccia del web.

Tag: , ,

L'autore

Graziano Scaldaferri: Grande appassionato di grafica web e CSS, ritiene fondamentale studiare il lavoro degli altri ed essere aggiornato sulle novità del web design. È autore di Blogging CSS, un blog dove analizza siti CSS, scrive tutorial e raccoglie risorse per il web design.

Sito web dell'autore | Altri articoli scritti da

Articoli correlati

Potresti essere interessato anche ai seguenti articoli:

10 commenti

Trackback e pingback

  1. sIFR: come installare e configurare correttamente il font replacement | paitadesignblog
    [...] How To Implement sIFR3 Into Your Website sIFR su blog.html.it htHow to install and configure sIFR Two colors in…