face the font-face (got to...)face the font-face (got to…)

Für das zuvor erwähnte Projekt »Webseite aufhübschen und innerhalb von drei Tagen einreissen und wieder aufbauen« hab ich mich erstmal ernsthafter mit Webfonts beschäftigt – unter anderem weil es hieß, mein (noch) Lieblingsbrowser Opera könnte nun auch endlich Webfonts und Firefox seit 3.6 3.5 ja sowieso.

Seit vergangener Nacht wird auch hier gefontfaced, zumindest testweise.

Zunächst schien alles ganz einfach: im Fontblog wurde schon im Februar der Webfont-Hype versucht, samt Tutorial und Demofont. Demofont mit nur einem Schnitt ist natürlich nix (außerdem macht die EULA das Leben unnütz schwer), deshalb nach freien Webfonts mit mehreren Schnitten gesucht und bei Font Squirrel fündig geworden. Deren »@font-face-kits« verheißen einfachste Einbindung mit vorgefertigtem CSS-File, das man nur noch anpassen und ins eigene Stylesheet einbauen muß (was beim Atahualpa-Theme per CSS-Insert ja sehr einfach ist). Fonts hochladen, Theme anpassen – fertig!

Nicht.  

Font Squirrel schlägt folgendes CSS vor:

@font-face {
	font-family: 'DroidSansRegular';
	src: url('DroidSans.eot');
	src: local('Droid Sans'), local('DroidSans'), url('DroidSans.woff') format('woff'), url('DroidSans.ttf') format('truetype'), url('DroidSans.svg#DroidSans') format('svg');
}

@font-face {
	font-family: 'DroidSansBold';
	src: url('DroidSans-Bold.eot');
	src: local('Droid Sans'), local('DroidSans-Bold'), url('DroidSans-Bold.woff') format('woff'), url('DroidSans-Bold.ttf') format('truetype'), url('DroidSans-Bold.svg#DroidSans-Bold') format('svg');
}

Nun bin ich nicht der große CSS-Experte, aber mir scheint das gedoppelte src: und die fehlende Formt-Angabe beim eot-Font nicht so ganz koscher. Die Font-URLs oben sind im tatsächlichen Versuchsaufbau natürlich angepasst worden.

Spannenderweise zickt Opera mit dem Codeschnipsel oben echt rum. Vor allem wird nix mehr fett angezeigt, dass bold  sein sollte. Und manchmal steigt Opera 10.51 auch ganz aus und fällt ganz auf die im Browser eingestellten Default-Fonts zurück. Aber das ist nochmal Stoff für einen extra Beitrag.

Einigermaßen verständliche Hilfe in Sachen @font-face-Syntax gabs bei den Leuten von Mozilla und in der css3-Quasi-Doku. Optimiert siehts ungefähr so aus:

@font-face {
	font-family: 'DroidSans';
	font-weight: normal;
	font-style: normal;
	src: url('/fonts/DroidSans.eot') format('embedded-opentype'),
	     local('Droid Sans'), local('DroidSans'),
		 url('/fonts/DroidSans.woff') format('woff'),
		 url('/fonts/DroidSans.ttf') format('truetype'),
		 url('/fonts/DroidSans.svg#DroidSans') format('svg');
}

@font-face {
	font-family: 'DroidSans';
        font-weight: bold;
	font-style: normal;
	src: url('/fonts/DroidSans-Bold.eot') format('embedded-opentype'),
             local('Droid Sans Bold'),
             local('DroidSans-Bold'),
             url('/fonts/DroidSans-Bold.woff') format('woff'),
             url('/fonts/DroidSans-Bold.ttf') format('truetype'),
             url('/fonts/DroidSans-Bold.svg#DroidSans-Bold') format('svg');
}

Sieht besser aus, oder? Neu im Spiel sind die Angaben zu font-weight und font-style, welche die Zuordnung der Dateien zu den jeweiligen Schnitten ermöglichen. Statt (wie im Beispielcode) jedem Schnitt einen eigenen seiteninternen Namen zu geben. Hiermit kann Opera sogar strong/bold wieder als fett anzeigen, scheitert aber daran, die Regular schräg zu rechnen, wenn es kursiv werden soll. Doof, aber stirbt man nicht dran. Vielleicht mal nach nem Webfont mit mindestens vier Schnitten Ausschau halten.

Den nächsten Fallstrick legt WordPress höchstselbst aus. Die manchmal nervende aber oft nützliche Eigenart der automatischen Sonderzeichenersetzung (Reiz-/Suchwort: wptexturize) macht im Zusammenwirken mit Opera echt Stress: Manche Sonderzeichen bekommt der Browser aus Norwegen schlicht nicht darstellt, warum auch immer. Im Font selber sind sie (Firefox stellt sie ja dar), bei lokalen Fonts gibts auch keine Probleme – aber bei Webfonts.

Beispiel: Ich verwende gerne drei Punkte am Ende einer Zeile.
Wordpress macht daraus das Dreipunkt-Zeichen mit der Unicode(?)Nummer 8230.
Opera macht daraus ein »dieses Zeichen kenne ich gar nicht«-Kästchen.

Deppert.

Ebenso transformieren katastrophal einige Hochkommas zu Apostrophen – bei Opera kann man in das Kästchen selber das passende Zeichen auf den Monitor malen. Manche Hochkommas auch nicht – WordPress wird schon wissen, warum nicht.

Workaround: ich gewöhne WordPress grad ab, kritische Zeichen umzuwandeln. Da es kein Plugin dafür gibt, frickeln wir also wieder per Hand im Code (und vergessen hoffentlich nicht, beim nächsten Update den wieder einzuklöppeln).

Hoffentlich ist Opera schneller mit dem nächsten Update, dass @font-face korrekt umsetzt und auch hier Abhilfe schafft.

Grundsätzlich besteht natürlich die Möglichkeit, dass ich Bockmist gecoded habe. Hmmm… Winkt wer mit dem Zaunpfahl? :)
Known Bug: Diverse Fontgrößen müssen noch angepasst werden. Und NoScript-Benutzer müssen die defaultmäßig eingestellte Blockierung von @font-face ausschalten.

Wer bis hierher durchgehalten hat wird merken, dass ich nur mit Firefox und Opera teste. IE ist mir weitgehend egal (irgendwas wird der schon darstellen), Chrome, Safari und den ganzen Rest will ich mir nicht auf die Platte ziehen.

Hat jemand mit seinem Liebings-Browser und dieser Seite Darstellungs-Probleme? Bitte mal melden.

Nachschlag?Opera mit WordPress abschießen to bite the code that feeds Ich hab den Text gefressen… phpMyFotofrust Hinter den Wolken Linkage Section #3 Blogseminar: Pampa macht blau :)