Schlagwort: webfonts

Domainübergreifene Zugriffe auf Webfonts (CORS)

Gelegentlich werden Webfonts von einer anderen Domain/ einem anderen Server eingebunden (Cross Origin Request). Im Zuge dessen kann es vorkommen, dass der Zugriff auf diese Dateien auf Grund der Einhaltung der Same-Origin-Policy abgelehnt wird und die Schriften nicht geladen werden. Glücklicherweise gibt es mit Cross Origin Ressource Sharing (CORS) aber eine Methode, um diese Cross Origin Request zu ermöglichen. Dazu muss folgender Code in die .htaccess eingefügt werden:

# BEGIN CROSS ORIGIN RESSOURCE SHARING FOR WEBFONTS
<FilesMatch "\.(ttf|eot|woff)$">
    <IfModule mod_headers.c>
        Header set Access-Control-Allow-Origin "*"
    </IfModule>
</FilesMatch>
# END CROSS ORIGIN RESSOURCE SHARING FOR WEBFONTS

Dadurch wird das Aufrufen von Dateien der Formate ttf, eot und woff von fremden Origins ermöglicht.

Links

HTTP access control (CORS)
Same-origin policy

Lesetipp: faux bold vermeiden & verschieden fette Schriftschnitte richtig einbinden

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.

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…

Links

Quick Tip: SVG Fonts & @font-face