Zum Einsatz kommen momentan zwei Plugins: Last.fm recently played tracks zeigt die – man vermutete das schon – zuletzt gespielten Titel an, allerdings hab ich selbst noch ziemlich im Code rumgepfuscht, um den Output anzupassen. Last.fm records ist für die »Quartalsplatten« zuständig, also die Alben, von denen ich laut last.fm in den letzten 3 Monaten die meisten Songs gehört hab. Zunächst stand der Zeitraum auf 7 Tage. Folge: viel Bewegung in den Charts innerhalb eines Tages. So gefällts mir besser. Der schönere Zeitraum von einem Monat steht leider nicht zur Auswahl.

Die andere Baustelle waren die internen Blogstatistken.

Ich setzte absichtlich und aus Überzeugung keine externen Dienste wie Blogcounter oder Google Analytics ein. Trotzdem interessiert mich (wie vermutlich jeden Seitenbetreiber), wieviele Leser, Bots und Feed-Abonnenten ich habe, welche Artikel gelesen werden und so weiter. Anfangs hatte ich MyStats eingebaut, das zerschoss aber die Feeds und ist im März rausgeflogen. Das dann benutzte Plugin StatPress sah erst gut aus, hat mich schon länger daran zweifeln lassen, ob seine Zahlen denn koscher sind. Es wird nicht mehr weiterentwickelt und scheint auch das Blog insgesamt heftiger  auszubremsen. Als Alternative ist seit kurzem WP SlimStat im Einsatz, dessen Ergebnisse ungefähr zu denen von WP Popular Posts passen. Noch nicht ganz überzeugt bin ich von Feed Statistics, finde derzeit nichts besseres.

Äußerlich hat sich noch eine Kleinigkeit geändert, die mich seit einem Jahr schon fuchst. Die Textausgaben rund um die Kommentarfunkionen wie »xxx comments to…« und »Leave a reply« sind auf Englisch hardgecoded. Jetzt habe ich die endlich mal eingedeutscht und in dem Aufwasch auch die Schriftgrößen für die Beitrags-Überschriften einheitlich gesetzt.

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.

Ich hoffe, es hat nicht übermäßig verwirrt.

Der Hintergrund: Schon in den ersten Blogwochen nervte mich vor allem beim Kommentieren das Eintippen der alten, langen Subdomain-URL. Nach den ersten Wochen war auch klar, dass der thematische Schwerpunkt hier nicht in Richtung »Berichte aus der Provinz« gehen würde. Eine Bemerkung von René Walter (Nerdcore) tat ein übriges und die Namenssuche begann.

Heraus kam…

www.textfresser.de

Der neue Name kommt nicht völlig aus dem Nichts.

In den ersten Blogmonaten habe ich noch alle paar Wochen die Subline des Blognamens geändert, meistens mit leicht permutierten Zeilen aus Songtexten. Am Anfang stand »hält dich das auf was dich anfällt | gehörst du dazu und wie hälst du das aus?« (frei nach: Die Sterne – Themenläden), »you want a room with a view? | you need ideas for walls« (Men without Hats – Ideas for Walls), ganz kurz mal »from the provincial towns you jog round« (The Smiths – Panic). Am längsten hat sich zuletzt gehalten: »ich hab den Text gefressen | ich nehm das Fragezeichen«, zwei kaum entstellte Zeilen aus »Jenseits von Eden« by Ton Steine Scherben.

Textfresser.de hatte den großen Vorteil, noch frei zu sein. Von ungefähr 15 Domain-Ideen war sie jene mit den größten Aussichten, im Spannungsfeld zwischen WTF und FTW einen zwielichtigen Eindruck zu hinterlassen.

Die alte URL bleibt auf absehbare Zeit gültig, die bisherigen Verlinkungen werden weiterhin ihr Ziel finden.

Ich habe nebenbei die Gunst der Stunde genutzt, um die about-Seite auf aktuellen Stand zu bringen, eine der damals verschobenen Aufgaben bei Konna’s Blogseminar. Und was es mit der Keksdose auf sich hat, erzähle ich ein ander mal…

Ich nehm das Fragezeichen.
Doch ich komm morgen wieder.