Standards & Hacks für mehr Schriftenvielfalt
12. November 2008
Es ist und bleibt das Dauerthema Nummer 1 für designaffine Frontend-Entwickler: Wie kann man sich in Zukunft über die mangelnde Vielfalt an »websicheren« Schriftarten hinwegsetzen? Gerade in letzter Zeit hat sich viel getan, also gucken wir doch mal:
Stagnation auf niedrigem Niveau: sIFR
Nie so richtig in die Pötte gekommen ist die allseits bekannte und von vielen schon mal ausprobierte Methode, mittels JavaScript und Flash bestimmte Headlines in beliebigen Schriften darzustellen. Derzeit kümmert sich in erster Linie der Däne Niederländer Mark Wubben um die Weiterentwicklung – aktuell ist sIFR 3 r436, aber das ist, denke ich, noch nicht der offizielle finale 3er-Release.
sIFR ist prinzipiell toll und pragmatisch und so weiter, macht aber in der Praxis dann doch oftmals ein bisschen, was es will. Besonders bei ungewöhnlich proportionierten Schriften kann es immer wieder zu ungewollten Umbrüchen kommen, die dann in falschen Schriftgrößen resultieren. Alles ein wenig wackelig. Der Vorteil: Alle Browser, Internet Explorer 5, kommen gleich gut bzw. gleich schlecht mit sIFR zurecht. Der Nachteil: größere Textmengen sind Gift für die Performance. sIFR ist nur was für vereinzelte Überschriften.
Für Grobmotoriker: Fontburner
Vor ein paar Monaten habe ich schon mal kurz Fontburner vorgestellt. Dabei handelt es sich prinzipiell um nichts anderes als eine gehostete Variante von sIFR, bei der man noch weniger Kontrolle über das Feintuning besitzt wie bei lokaler Installation. Ein netter Spaß für Zwischendurch, oder wenn man in seinem Blog dringend eine »authentische« Note benötigt, aber nichts, was man ernst nehmen kann.
Proof of concept: typeface.js
Darauf muss man erstmal kommen! Auf der Website von typeface.js kann man einen beliebigen Font hochladen und in eine JS-Datei konvertieren lassen. Diese enthält im JSON-Format die benötigten Vektordateien für die einzelnen Glypen. Um die eigentliche Darstellung im Browser kümmert sich dann in guten Browsern ein Canvas-Element, im Explorer wird das über VML geregelt. (Wer hätte gedacht, dass aus VML nochmal was sinnvolles wird, oder?)
Starker Tobak für Leute, die auf elegante und performante Lösungen stehen. Es ist ein wirklich waghalsiger Hack – aber er funktioniert! Prinzipiell. Je nachdem, wie komplex die Formen der ersehnten Schrift sind, kann die Font-Datei jedoch sehr groß werden. Und natürlich ist der Einsatz außerhalb von Überschriften definitiv nicht zu empfehlen, handelt es sich doch, ähnlich wie bei sIFR, eigentlich nicht um eine Schriftdarstellungs- sondern um eine Schriftersetzungsmethode. Aber eine sehr pfiffige, wie ich finde. Unbedingt mal ausprobieren!
Spaß mit Anarchie: @font-face mit OpenType und TrueType
Am meisten Aufsehen erregen konnte in den letzten Monaten sicher die Tatsache, dass das Verlinken und Verwenden von beliebigen Schriften im OpenType- oder TrueType-Format in aktuellen Versionen von Safari und Firefox (ab 3.1) sehr umkompliziert möglich ist. Der Vorteil: Die Methode arbeitet ohne Tricks oder krude Konvertierungen. Die Fonts werden temporär heruntergeladen und ebenso temporär installiert, so dass in der Darstellung quasi kein Unterschied zu einem Font besteht, der sich nativ auf dem System des Nutzers befindet. Mit der Ausnahme, dass die Schriftdatei natürlich erst geladen werden muss, was ein paar Sekunden dauern kann – je nach Komplexität und Ausbau der Schrift. Ralf Hermann hat hier eine Demoseite erstellt, die schon großen Spaß macht!
Problem bleibt natürlich die rechtliche Situation. Der Webdesigner wird quasi mit der Verantwortung allein gelassen und muss sich selber darum kümmern, Schriften zu finden, deren Lizenzbestimmungen ausdrücklich den Einsatz im @font-face-Umfeld erlauben. Gar nicht so leicht – zurzeit sind es gerade mal etwas mehr als eine Handvoll Exemplare Und der Internet Explorer wird den Einsatz von regulären TrueType- oder OpenType-Schriften wohl nie möglich machen, sondern setzt statt dessen konsequent auf das EOT-Format.
Bald offizieller Standard? @font-face mit EOT
EOT gibt’s schon seit über einem Jahrzehnt und bedeutet Embedded Open Type. EOT-Schriften basieren also auf OpenType, haben jedoch ein paar Gimmicks, die einerseits cool sind (Subsetting für kleinere Dateigrößen), andererseits nervig sein können (DRM). Zurzeit wird heftig darüber diskutiert, ob das Einbetten von EOT ein W3C-Standard sein wird. Eine hervorragende und ausführliche Zusammenfassung der Diskussion hat Bert Bos geschrieben. Und den 2008er-Praxistest nahm Jon Tan in seinem Blog vor. Seine Erkenntnis: Es gibt keine brauchbare Software zum Erstellen von EOT-Dateien. Das offizielle Microsoft-Tool ist ein Bag of Hurt, würde Meister Jobs sagen.
Wie dem auch sei: Auf längere Sicht betrachtet stehen alle Zeichen meines Erachtens auf EOT. Und warum auch nicht? Somit haben Fonthersteller die Möglichkeit, ein leicht zu identifizierendes, optimiertes und vielleicht preislich attraktives Format anzubieten, um auch Webdesigner zu ihren Kunden zu machen, wo diese vorher eher sparsam mit der Anschaffung von neuen Schriften waren. Außerdem ist prinzipiell jede Lösung zu begrüßen, bei der alle Browserhersteller mitziehen. Und bei EOT ist dies noch eher zu erwarten als bei unbehandelten OT- oder TT-Schriften.
Fazit
Was bleibt also am Ende des Tages? Wir müssen noch ein paar Jährchen durchhalten, bevor wir wirklich im großen Stil abgefahrene Schriften im Web verwenden können. Aber es ist eigentlich klar, dass es eines Tages möglich sein wird, da prinzipiell alle beteiligten Parteien es wollen. Über das Wie wird man sich schon einig werden, irgendwann. Und bis dahin können diejenigen, die es gar nicht abwarten können, ja weiterhin mit Bastellösungen zubringen. Wenn’s denn sein muss.
update: Ein bisschen sperrig geschrieben, aber es ist halt eine Art Verlaufsprotokoll einer Sitzung diverser wichtiger Menschen: Proposal for a Font Working Group (via Code Candies)