Habe heute morgen meine Arbeit am Palava-Framework, um genau zu sein an der JSON-Serialisierung, beendet und wurde prompt von Detlef mit einer neuen Aufgabe versorgt. Für einen aktuellen Auftrag, den wir gerade an Land ziehen konnten, sollte ich sowas wie eine Machbarkeitsstudie durchführen, obwohl das Wort hier eigentlich Overkill ist. Der Kunde will auf seiner Seite, die wir ihm bauen sollen , diverse Überschriften in bestimmten Schriftarten haben. Ich sollte also recherchieren, inwiefern es möglich ist, in (X)HTML-Seiten eigene Schriften zu benutzen bzw. einzubetten.

Auf folgende Möglichkeit bin ich gestoßen:

@font-face {

font-family: “Frutiger”;
src: url(frutiger.eot), url(frutiger.pfr);

}

h1.frutiger {

font-family: “Frutiger”;
font-size: 150%;

}

Also per CSS eine Schrift deklarieren, die dann bei Bedarf vom Webserver geladen wird. Klingt erstmal gut, allerdings gibts nur zwei verschiedene Formate, die unterstützt werden:
.eot vom IE (ab Version 4.0) und .pfr für Netscape. Gecko-basierte Browser verstehen diese CSS-Anweisung gar nicht.Weil es auf proprietären Technologien basiert, wurde es bereits in CSS 2.1 aus der Spezifikation entfernt.

Nächster Schritt war die Suche nach alternativen Lösungsansätzen. Da haben wir (Anika, Oli & ich) uns zusammengesetzt und mal drüber nachgedacht und sind auf folgende Sachen gekommen:

Alternative #1
GIFs bzw. PNGs mit dem jeweiligen Text und der entsprecheneden Schrift erzeugen und einbetten. Allerdings nicht per Hand, weil sich die Inhalte ja ständig ändern, also müsste man die Bilder vom Backend generieren lassen. Für PHP gibts da beispielsweise schön Libraries, die sowas anbieten. Allerdings kann man den Text dann nicht selektieren und so richtig schnell wird das auch nicht sein.

Alternative #2
Einen Flashfilm erstellen, der als Parameter eine Schriftart (bzw. deren Name) und den zu rendernden Text erhält und das dann darstellt. Dann wäre der Text schonmal selektierbar, allerdings müsste mann den Flashfilm auch skalieren können, falls man mal eine kleinere Schriftgröße nehmen will, bzw. die Position verändert und an der Stelle dann weniger Platz hat.

Alternative #3
So ähnlich wie #1, allerdings erstellt das Backend keine statischen Bilder, sondern SVGs. Also xml-basierte Vektorgrafiken, deren Präsentation dann der Browser übernimmt. Und da liegt dann auch schon der Haken: SVG unterstützen z.B. Firefox und der IE nicht nativ, sonder nur per Plugin. Schade, denn Vektorgrafiken kann man gut skalieren ohne dass sie an Schärfe verlieren und erzeugen weniger Overhead und Traffic als Flash und Bilder.

Alternative #4
Als wir Flash als Variante in Betracht gezogen hatten, kam Anika eine Erinnerung an eine kleine Technologie, die das Problem bereits auf diese Weise gelöst hat. Des Rätsels Lösung heisst sIFR (sprich: siffer) und steht für “Scalable Inman Flash Replacement”. Besteht technisch aus einer JavaScript-Implementierung, die nach dem Seitenladen, dem Dom-Tree traversiert und nach bestimmten class-Attributen sucht. Diese Elemente, werden dann durch einen Flashfilm derselben Größe, mit der im CSS/Script-Bereich deklarierten Schrift gerendert. sIFR ist mittlerweile bereits in Version 3 erhältlich, hat also schon einige Stunden Bugfixing intus. Für nähere Informationen sei euch die offizielle Website ans Herz gelegt und damit man sich auch was drunter vorstellen kann, hier eine Beispielseite.

In letzter Zeit hinke ich ja immer 12h hinterher, was meinen Bericht angeht. Heute bin ich dafür mal besonders früh dran.
Zwei Aufgaben erwarteten mich heute morgen.

1. Warum zum Henker wird im Flashfilm totaler Müll angezeigt, obwohl es super aussehen müsste?
(Sprich, lauter Überschneidungen und schlechte Ausrichtung der Bilder, aber eine gute Bewertung)
2. Im CMS eine dynamische Liste von artverwandten Artikeln erstellen.
(Also wieder etwas mehr über das firmeninterne CMS lernen)

Aufgabe zwei war mit Biancas Hilfe relativ schnell erledigt und kleine Probleme auch ruckzuck behoben. Die Fehlersuche in meinem Algorithmus wurde nicht durch “ne Nacht drüber schlafen” gelöst, wie ich das erhofft hatte, dafür mit peniblem Durchsuchen des Quellcodes und Überlegen. Das Problem war schließlich, dass ich beim Kopieren (eines Objektes, das alle relevanten Daten, wie Position und Ausrichtung enthält) das wichtigste vergessen und statt einer Kopie eine zufällige Variante erzeugt hab’. Schande über mich.

PS:

Heute hat Stoffie Geburtstag und gesellt sich zu mir in den Kreis der “>=23″-jährigen.

Seit ich bei Cosmocode arbeite trink’ ich an einem Tag mehr als sonst in einer Woche. Meine Blase ist dauerhaft überfüllt, aber Tee und Vittel sind einfach zu lecker, um darauf zu verzichten.
Kommen wir zum technischen. Ich (bzw. mein Algorithmus) soll ja einen Flashfilm dynamisch mit XML-Daten befüllen. Da man das SWF aber (noch) nicht on-the-fly zum Neuladen zwingen kann, musste ich mir was einfallen lassen. Dazu habe ich folgenden JavaScript-Code geschrieben:

var oldFlash = document.getElementById(“flashMap”);
var newFlash = oldFlash.cloneNode(true);
var parent = oldFlash.parentNode;
parent.removeChild(oldFlash);
parent.appendChild(newFlash);

Billig und vor allem “quick&dirty”, aber für den Anfang erfüllt es seinen Zweck. Wenn ich also den Flashfilm nicht zwingen kann, seine Daten neuzuladen, dann lad’ ich eben den ganzen Film neu.

Nächstes Problem war die Erzeugung XML-konformer Daten, das war nach ein bisschen Recherche und Copy&Paste aber schnell gelöst. Nach mehrmaligem Testen stellte sich allerdings kein Aha-Effekt ein. Irgendwie kam stimmt die errechnete Bewertung einer Lösung nicht mit der optischen überein. Also mach’ ich, was ich am besten kann: Feierabend und ne’ Nacht drüber schlafen.