Das gab es doch schon mal – die Einbettung von Schriften über CSS. Richtig, vorgeschlagen wurde diese Möglichkeit schon beim Standard CSS2 aber mit der Fassung CSS2.1 wieder verworfen. Mit CSS3 kehrt font-face zurück und es ziehen alle Browserhersteller mit – Microsoft Internet Exporer, FireFox, Opera und Safari – alle unterstützen mittlerweile die Möglichkeit, eigene Schriften über eine Pfadangabe im CSS auf die Seite einzubinden. Der gestalterischen Freiheit sind damit keine Grenzen mehr gesetzt. Vorbei die Zeiten komplexer “Workarounds”, vorbei die Zeiten, in denen man nur zwischen ein paar “websicheren” Schriftarten wählen konnte. Klingt gut, stimmt es auch?
In Sachen Schrift war das World Wide Web lange Zeit eine echte Wüste. Es gab nur wenige unterschiedliche Schriftarten, die man verwenden konnte. Was blieb, wenn das Design anderes vorgesehen hatte?
- Variante 1: Das “Ersetzen” von Text mit Bildern – wahlweise über eine Vordergrundgrafik (ganz schlecht für Suchmaschinen), oder via CSS über eine Kombination von verwendeten Hintergrundgrafiken (die schönen Schriften) und versteckten Inhalten.
- Variante 2: Über den Einsatz von Flash, wie es bspw. die Bibliothek sIFR (Scalable Inman Flash Replacement) macht.
- Variante 3: Über eine Kombination von Canvas und VML, bei der mit Hilfe von JavaScript eine spezielle Schriftdatei gerendert wird, dies ist bspw. bei Cufón, oder Typeface der Fall.
Die CSS Syntax
Alles aufwendige, zeit- und lade-intensive Verfahren. Und jetzt, alles ganz einfach: Quell-Datei im CSS angeben und fertig. Nein, so einfach ist es leider nicht. Auch die schöne neue CSS3 Welt hat noch einige Tücken, wenn es um die Einbettung von Schriften geht. So schaut es von der blanken Theorie zunächst einmal aus:
@font-face {
font-family: derFontName ;
src: url( /location/of/font/FontDateiName.ttf ) format("truetype");
}
/* Nun hat man über den Font-Namen (derFontName) Zugriff,
und verwendet den Schrifttyp wie andere Schriftarten auch... */
h1 {
font-family: derFontName , verdana, helvetica, sans-serif;
}Die hier gewählte Syntax entspricht der CSS3 Spezifikation, diese läßt verschiedene Schriftformate zu: “TrueType” (ttf), “opentype” (ttf,otf), “TrueType-aat (ttf), “Embedded OpenType” (eot) und “Scalable Vector Graphic” (svg,svgz). Im Internet Explorer läuft das Ganze ein wenig anders ab (dafür unterstützt der IE die Möglichkeit Schriften einzubetten aber auch schon seit der Version 4.0!). Zunächst: Der IE kennt nur das “eot” Format (Embedded OpenType), und weil er nur ein Format kennt, entfällt im IE eben auch die Angabe zum Format. Für den Internet Explorer sähe die gleiche Syntax wie folgt aus.
@font-face {
font-family: derFontName ;
src: url( /location/of/font/FontDateiName.eof );
}Eine solche Abweichung ließe sich leicht über conditional comments realisieren. Wenn solche “IE-only” Stylesheets ohnehin schon für ein Projekt genutzt werden, ist das ein absolut gangbarer Weg. Paul Irish schlägt in seinem Artikel “Bulletproof @font-face syntax” eine andere Vorgehensweise vor. Er kombiniert IE und Non-IE Anweisungen in einem CSS-Element:
/* Die CSS Syntax aus dem Artikel Bulletproof font-face syntax
von Paul Irish */
@font-face {
font-family: 'Graublau Web';
/* der IE stoppt hier...*/
src: url('GraublauWeb.eot');
/* weil er damit nicht umgehen kann */
src: local('☺'),
url('GraublauWeb.ttf') format('truetype');
}Der Smiley in local('☺') ist kein Fehler, sondern ein Feature. Die local Anweisung erlaubt es Browsern auf dem Clientsystem nachzusehen, ob eine entsprechende Schriftdatei dort vorhanden ist und im Erfolgsfall auf sie zurückzugreifen, anstatt die Typo von der URL zu laden. Das kann Ladezeiten minimieren, birgt aber ein Problem. Paul Irish weist in seinem Artikel darauf hin, dass eine lokale Schrift mit gleichem Namen nicht unbedingt der gewünschten (im CSS eingebundenen) Schrift entsprechen muß. Um diesen “Fehler” zu umgehen, nutzt er den Smiley – laut Spezifikation schlicht ein ungültiger Font-Name. Ob man in der local Anweisung einen solchen Weg geht und damit auf die Möglichkeit verzichtet, ggf. auf eine bereits installierte Schrift zuzugreifen sollte Fallweise entschieden werden.
Zum konvertieren der Schriften in das eot Format lässt sich das kostenfreie Microsoft Werkzeug WEFT verwenden, oder man nutzt einen Online Konverter wie den von Kirsle.net.
Ob über conditional comments oder über die von Paul Irish vorgeschlagene Variante – @font-face läßt sich in der Mehrheit der Browser einsetzen, und im Vergleich zu manch anderen CSS-Weichen, die man für die Unterstützung einer großen Browser-Palette eingehen muß, ist die Syntax relativ einfach zu verwenden. Alles halb so wild…
Stolpersteine
Nicht so schnell, es gibt noch einige Auffälligkeiten in Sachen font-face. Eine Reihe von “Stolpersteinen” über die man sich im Klaren sein sollte, bevor man font-face einsetzt:
- Nicht alle Formate funktionieren browserübergreifend: Auch wenn laut CSS3 Spezifikation das eot (embedded-opentype) Format unterstützt wird, damit kann nur der Internet Explorer umgehen (siehe bspw. diese Forumsdiskussion). WOFF (Web Open Font Format) hingegen läuft momentan nur im FireFox 3.6.
- Konvertierungen können unterbunden werden: Will man möglichst viele Browser unterstützen, kommt man ohne eot nicht weiter. Konvertierungen von ttf auf eot sind aber nur dann möglich, wenn der Urheber der Schrift dieses nicht unterbindet. Und selbst wenn sich die Schrift konvertieren lässt, kann dieses schon eine Verletzung der Lizenz-Rechte darstellen.
- Fehlende Zeichen: Viele der frei verfügbaren Fonts sind nicht vollständig, es fehlen bspw. Umlaute oder Zahlen. In solchen Fällen greift die alternativ definierte Schrifttype, die Schrift wechselt im schlimmsten Fall also mitten im Wort.
- Beachtung der Lizenzrechte: Was für die Konvertierung in das eot Format gilt, gilt natürlich auch für die Verwendung von ttf-Schriften. Eine interessante Diskussion hierzu findet man bspw. in dem Artikel: “Aller – wirklich großes FreeFont Tennis“.
- Kleinste Syntax-Fehler werden bestraft: Minimale Abweichungen in der CSS Notation führen zu Fehlern. Lässt man bspw. die Anführungszeichen bei der Local-Anweisung weg, läuft das Ganze im Opera nicht mehr. Nennt man die Microsoft spezifische eot Anweisung nicht zuerst, scheitert der IE.
- Schwierigkeiten mit font-style: Bei dev.opera.com wird darauf hingewiesen, dass die Version 10 einen Bug bei der Implementierung von font-face hat. Fett und Kursiv Variantionen der Schrift können nicht über das CSS Element
font-style gesetzt werden.
- Das Render-Verhalten von Schrift bei @font-face: Die Qualität der Darstellung von Schrift kann sehr unterschiedlich sein. Das zugrundeliegende Problem steckt tief im System: Unter Windows werden nur die Schriften ordentlich und lesbar auf dem Bildschirm angezeigt, die auch für den Bildschirm optimiert wurden. Diese Optimierung nennt sich Hinting, ein zeitaufwendiges und mühsames Verfahren bei der Erstellung von Schriften. Deshalb gibt es nur recht wenige Schriften, die ein gutes Hinting beinhalten, und noch viel weniger, die kostenfrei zur Verfügung stehen. Daher sehen viele der derzeit für
@font-face zur Verfügung stehenden Schriften im Web unter Windows so miserabel aus. Den Schriften fehlt das Hinting.
- Render-Verhalten die Zweite: Schriftenglättung: Auch bei der Glättung von Schrift fällt das Ergebnis von System zu System zum Teil sehr unterschiedlich aus. Zum einen kann es sein, dass die Kantenglättung gar nicht aktiviert ist (Cleartype muss unter Windows XP erst aktiviert werden), zum anderen sind die Verfahren von MAC und Windows unterschiedlich. Abweichungen in der Darstellung sind daher unvermeidlich.
- Rendering die Dritte, das Verhalten beim Laden der Seite: Das Laden einer Schriftdatei kostet Zeit – wie lange, das ist abhängig von vielen Faktoren – aber es ist spürbar und manchen Fällen sogar sichtbar. Firefox rendert den Text zunächst mit einem Webstandard-Font. Erst wenn die individuelle Font-Datei vollständig geladen ist, wechselt die Ansicht, die Seite “flackert”. Je größer die Unterscheidung zwischen dem nachgeladenen Font und dem websicheren Fallback, desto augenfälliger wird das Ganze. Beim Webkit hingegen werden die Inhalte erst eingeblendet, wenn die entsprechende Datei geladen ist. Steve Souders gibt in seinem Blog noch den wichtigen Hinweis, dass im Internet Explorer überhaupt nichts passiert, bis die Schriftdatei fertig geladen ist – unter der Vorraussetzung, dass es vor der CSS Syntax einen
SCRIPT Block gibt. Paul Irish beschreibt in seinem Artikel Fighting the @font-face FOUT eine JavaScript basierte Lösung, die das Verhalten vom Webkit nachbildet, um so den “flash of unstyled text” (FOUT) zu unterdrücken, eine alternatives Szenario – in Kombination mit Jquery findet man bei BoxCar Press.
- Am Ende hängt es vom Client ab: Auch wenn alles richtig läuft, sicher sein, dass die Seite nun im gewünschten Layout angezeigt wird, kann man sich nicht. Sowohl im Internet Explorer (Extras > Internet Optionen > Sicherheit > Spezieller Level > Downloads > Font Download) als auch bei FireFox (Extras > Einstellungen > Inhalt > Schriftarten & Farben > Erweitert > Seiten das Verwenden von Schriften erlauben) lässt sich die Unterstützung einfach abschalten bzw. muß eingeschaltet werden. In den Versionen IE7 and IE8 werden eigene Fonts unter der höchsten Sicherheitsstufe nicht angezeigt und im IE6 taucht bei höchster Sicherheitsstufe nach jedem Neuladen der Seite, jedem internen Verweis ein Dialog auf, ob man die Schrift herunterladen will – ein unerträglicher Zustand.
- Richtiger Mime-type: Auf Windows Servern kann es notwendig sein, die Dateiformate OTF und TTF mit dem korrekten MimeType (application/octet-stream) auszuliefern.
- Cross-Domain @font-face: Eine volle url für die Schrift-Datei lässt sich so ohne weiteres nicht angeben, Firefox erlaubt keinen cross-domain Zugriff bei den Schriften. Wie man diese Sicherheitseinschränkung umgehen kann zeigt der Eintrag von Paul Straw.
Fazit
font-face gehört die Zukunft und es lässt sich auch heute schon einsetzen. Aber bevor man eine so gestaltete Seite online stellt, ist intensives Testen erforderlich. Die Schwierigkeiten in Sachen Rendering, Schriftenglättung sind so systemspezfisch, dass man mit allem rechnen muß – da reicht ein Rechner mit einem Betriebssystem zum Testen nicht aus. Ladezeiten abhängige Darstellungsprobleme – die “ungestalteten Inhalte” erfordert wohl auch nach wie vor den Einsatz von JavaScript. Nichts desto trotz ist diese Variante performanter als ein komplett scriptbasierter Ansatz. Mit dem WOFF (Web Open Font Format) kommt zudem ein neues, weiteres Format ins Spiel. Es wird browserübergreifend funktionieren, und schneller geladen werden (WOFF ist kein neues Schriftformat, sondern eine komprimierte Fassung einer TTF oder OTF Datei). Noch läuft WOFF zwar nur im FireFox 3.6, soll aber im Internet Explorer (ab Version 9), Opera und Chrome implementiert werden. Dass der Internet Explorer unter bestimmten Umständen das Laden der Dateien vollständig unterbindet bzw. unmöglich macht, legt die Verwendung von conditional comments nahe – auch wenn der Ansatz von Paul Irish sicher eleganter ist. Die Verwendung von @font-face ist nicht ganz so unproblematisch, wie es zunächst den Anschein hat. Die Tage der ewig gleichen Schriftlayouts sind dennoch gezählt. Wie schnell und wie weit das gehen wird, hängt sicher auch von den jeweiligen Lizenzen und damit verbundenen Kosten ab, aber auch auf dem “freien Markt” lassen sich immer mehr Schriften finden. Wie bei vielen neuen Techniken ist Vorsicht geboten, doch der Mehrwert (Suchmaschinen Optimierung, geringe bis gar keine Scriptlast, selektierbarer, skalierbarer und druckbarer Text) gegenüber den anderen Alternativen (Flash, Grafiken, Canvas+VML) spricht für den Einsatz von @font-face.
Weiterführende Artikel
