Gerrit van Aaken erklärt in Webfonts: Fette Fehlerquelle, wie das Einbinden von unterschiedlich fetten Schnitten einer Schrift funktioniert. Eine sehr gute, aktuelle, deutsche Zusammenfassung zu einer Technik, die zum Handwerkszeug eines Frontend Developers gehört und die leider oft falsch genutzt wird.
Schlagwort: @font-face
Aggressives Firefox-Schriftcaching mit Versionsnummern austricksen
Sämtliche Firefox-Versionen, die ich unter Ubuntu, Windows 7 und Mac OS X benutze, speichern einmal geladene Webfonts sehr aggressiv. Aggressiv bedeutet in diesem Fall, dass ein normales Löschen des Caches zum Neu-Laden der Schrift nicht ausreicht, stattdessen muss zusätzlich noch der Browser neu gestartet werden. Da dies im Entwicklungsprozess doch eher unschön ist, bin ich dazu übergegangen eingebundene Webfonts mit einer Versionsnummer innerhalb des @font-face-Blocks zu versehen. Beim Ändern der Schrift erhöhe ich die Versionsnummer manuell und zwinge Firefox so, die Schrift neu zu laden. Klappt wunderbar und ist wesentlich entwicklerfreundlicher als das Schließen und Wiederöffnen des Browsers.
@font-face {
font-family: '[Iconfont-Name]';
src:url('../fonts/[Iconfont-Name]/[Iconfont-Name.eot]?1.0');
src:url('../fonts/[Iconfont-Name]/[Iconfont-Name.eot]?1.0#iefix') format('embedded-opentype'),
url('../fonts/[Iconfont-Name]/[Iconfont-Name.woff]?1.0') format('woff'),
url('../fonts/[Iconfont-Name]/[Iconfont-Name.ttf]?1.0') format('truetype'),
url('../fonts/[Iconfont-Name]/[Iconfont-Name.svg]?1.0#[Fragmentbezeichner]') format('svg');
font-weight: normal;
font-style: normal;
}Lesetipp: Über die richtige Einbindung von Webfonts
Im Smashing Magazine gibt es zwei sehr gute Artikel zum Thema @font-face. In Avoiding Faux Weights And Styles With Google Web Fonts wird erklärt, wie Schriften über das Google Font Directory richtig eingebunden werden können. Ganz so trivial ist das nämlich nicht, denn die Einbindung á la Google Webfonts funktioniert nicht richtig im IE 7 und 8. Dies führt dazu, dass diese beiden Versionen des Internet Explorer einzelne Schriftschnitte „faken“ und so die Lesbarkeit und Darstellung von Textabschnitten verschlechtern. Und obwohl der Fehler seit Juni 2010 bekannt ist, wurde er scheinbar immer noch nicht gefixt, so dass der verlinkte Artikel nach wie vor aktuell ist.
Der zweite Artikel, Setting Weights And Styles With The @font-face Declaration , beschäftigt sich- unabhängig von Google Webfonts- mit der richtigen Einbindung von verschiedenen Schriftschnitten, geht dabei über bold und italic hinaus und behandelt auch so verrückte Sachen wie einen eventuellen light- oder semibold-Schriftschnitt samt Fallack-Lösungen für Geräte, die mit @font-face nichts anfangen können (hallo Windows Phone 7.5).
@font-face, SVG-Schriften und Fragmentbezeichner
Um SVG-Schriften mittels der @font-face-Syntax einzubetten, wird bekanntlich folgendes Css benötigt:
@font-face {
font-family: "Open Sans Regular";
src: url("../fonts/open-sans-regular/OpenSans-Regular-webfont.svg#OpenSansRegular") format("svg");
}Spannend ist der Fragmentbezeichner hinter dem Dateinamen, von mir fett hervorgehoben. Normalerweise sollte dieser nämlich in der Schriftdatei noch einmal auftauchen, nämlich als Attributwert für id innerhalb dieses XML-Snippets:
<font id="OpenSansRegular" horiz-adv-x="1171">Tja. Normalerweise.
Unterscheiden sich der Attributwert und der Fragmentbezeichner, wird die Schrift nämlich nicht geladen und der davorsitzende Frontend-Entwickler kann eine ziemlich lange Zeit damit verbringen, diesen Fehler zu finden…