Font Face Replacement: aspettando @font-face
Una delle problematiche che da sempre rappresenta un vincolo importante nel design di pagine web è la scelta delle font da utilizzare per la visualizzazione dei testi. Le tecnologie supportate nello sviluppo e nel parsing delle pagine web hanno difatti da sempre imposto molti limiti nella scelta delle diverse tipologie di caratteri.
Come molti sanni i browser visualizzano i caratteri utilizzando le librerie font disponibili sul computer dell’utente. Ne consegue che è preferibile usare quei tipi di caratteri che hanno maggior diffusione sui computer di tutto il mondo (Georgia, Verdana, Times, Arial, Tahoma, Lucida, etc.).
Tale limite nel design tradizionale delle pagine web viene superato creando immagini ad hoc dei testi (headline, pulsanti, etc.) e inserendole nelle pagine web o direttamente come immagini (tecnica che comporta gravi problemi sotto l’aspetto semantico) o con tecniche di image replacement (per approfondimenti vedi: Revised Image Replacement - Dave Shea). Tale tecnica, seppur valida sotto il profilo dell’accessibilità e della conformità agli standard web, può comportare però dei problemi riguardo la quantità di lavoro da svolgere e di regole css da implementare (per ogni testo vanno create immagini e regole css ad hoc).
Per ovviare a questo problema lo standard css2 prevedeva l’adozione negli standard web del modulo css @font-face.
@font-face {Grazie a tale tecnica è possibile dichiarare una font all’interno delle regole css associando ad essa un file di riferimento (ttf, otf, etc.). In buona sostanza, tale tecnica sposta la reperibilità della font dal client (il computer dell’utente) al server.
font-family: XXXXX;
src: url('xxxxx.ttf');
}
h1 {font-family: XXXXX;}
Purtroppo, per via della scarsa adesione agli standard dei browser attualmente in commercio e per ragioni legate alla proprietà degli standard delle tipologie di font, tale regola css è di fatto supportata solo dal browser safari dalla versione 3.1. In verità tale tecnica è supportata anche dei browser Internet Explorer dalla versione 4 in avanti ma casa Microsoft impone l’utilizzo di una tipologia di font proprietaria (Embedded OpenType - EOT). Tale limite impone quindi la creazione di regole css ad hoc per i browser di casa Microsoft.
Per ovviare a tali inconvenienti si sono implementate diverse tecniche di sostutizione della font (Font Face Replacement) grazie all’uso di altre tecnologie (javascript, flash o php con supporto gd). Di seguito pubblico una lista di alcune di queste tecniche con una breve introduzione.
Lo script, realizzato da David Chester, sfrutta la capacità di disegno vettoriale dei browser (canvas e VML) per renderizzare il testo. La tecnica è di semplice utilizzo: basta integrare nella propria pagina web il motore di scripting javascript typeface.js e il file di conversione javascript che indica, a secondo del tipo di font, come convertire le lettere in disegno vettoriale. Tale file va creato ad hoc per ogni specifico font che si intende utilizzare grazie alla procedura presente sul sito web typeface.js.
La tecnica, seppure di semplice utilizzo e di facile implementazione, presenta diversi inconvenienti: il testo, una volta “convertito” in disegno vettoriale, non è più “selezionabile” (in parole semplici… non è più un testo!) e va creato lo scripting di trasformazione per ogni font che si intende utilizzare, appesantendo inevitabilmente il peso delle proprie pagine web.
La tecnica, implementata da Simo Kinnunen, utilizzo lo stesso sistema di vettorializzazione del testo utilizzata da typeface.js, con cui condivide anche pregi e difetti. Per un analisi dettagliata delle differenze tra le due tecniche e per un confronto tra di esse si vede l’interessante post di Kilian Valkhof dal titolo Cufón vs. Typeface.js, which one is better?
Sifr utilizza la tecnologia Adobe Flash per renderizzare testo. Adobe Flash permette infatti di utilizzare la font che si ritiene opportuna integrando il typeface all’interno del file swf. Passando le variabili opportune quindi la tecnica sifr sostituisce al testo un file swf che quindi lo visualizzerà con il typeface desiderato. Gli inconvenienti per tale tecnica anche qui sono diversi: a differenza di cufòn e typeface.js che utilizzano solo javascript come tecnologia di supporto, la tecnica sifr associa all’utilizzo di javascript anche quello di adobe flash, con tutti i problemi che ne comporta sotto il profilo dell’accessibilità e di velocità di caricamento della pagina. Inoltre, anche in questo caso, va sempre e comunque realizzato un file swf ad hoc per ogni font che si intende utilizzare.
FLIR (Face lift image replacement)
La tecnica, sviluppata da Cory Mawhorter, differisce dalle altre perchè utilizza un motore di scripting server-side per la realizzazione delle immagini da sostituire ai testi. Difatti FLIR genera on-the-fly le immagini contenenti i testi a cui si intende attribuire il typeface utilizzando php e la libreria gd di manipolazione e realizzazione delle immagini. La libreria, più complicata da usare rispetto a typeface.js o cufòn, necessita ovviamente del supporto server al linguaggio di scripting utilizzato (php+gd).
Approfondimenti
http://webfonts.info/wiki/index.php?title=%40font-face_browser_support
http://jorenrapini.com/blog/web-design/font-face-replacement-and-embedding-techniques-and-resources
http://kilianvalkhof.com/2009/javascript/cufon-vs-typefacejs-which-one-is-better/
http://www.mikeindustries.com/blog/sifr/
http://facelift.mawhorter.net/
http://cufon.shoqolate.com/generate/
http://www.divitodesign.com/2008/11/render-text-with-javascript-typeface-js/
sIFR: come installare e configurare correttamente il font replacement | paitadesignblog