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.
