Standards & Hacks für mehr Schriftenvielfalt

Es ist und bleibt das Dauerthema Nummer 1 für designaffine Frontend-Entwickler: Wie kann man sich in Zukunft über die mangelnde Vielfalt an »websicheren« Schriftarten hinwegsetzen? Gerade in letzter Zeit hat sich viel getan, also gucken wir doch mal:

Stagnation auf niedrigem Niveau: sIFR

Nie so richtig in die Pötte gekommen ist die allseits bekannte und von vielen schon mal ausprobierte Methode, mittels JavaScript und Flash bestimmte Headlines in beliebigen Schriften darzustellen. Derzeit kümmert sich in erster Linie der Däne Niederländer Mark Wubben um die Weiterentwicklung – aktuell ist sIFR 3 r436, aber das ist, denke ich, noch nicht der offizielle finale 3er-Release.

sIFR ist prinzipiell toll und pragmatisch und so weiter, macht aber in der Praxis dann doch oftmals ein bisschen, was es will. Besonders bei ungewöhnlich proportionierten Schriften kann es immer wieder zu ungewollten Umbrüchen kommen, die dann in falschen Schriftgrößen resultieren. Alles ein wenig wackelig. Der Vorteil: Alle Browser, Internet Explorer 5, kommen gleich gut bzw. gleich schlecht mit sIFR zurecht. Der Nachteil: größere Textmengen sind Gift für die Performance. sIFR ist nur was für vereinzelte Überschriften.

Für Grobmotoriker: Fontburner

Vor ein paar Monaten habe ich schon mal kurz Fontburner vorgestellt. Dabei handelt es sich prinzipiell um nichts anderes als eine gehostete Variante von sIFR, bei der man noch weniger Kontrolle über das Feintuning besitzt wie bei lokaler Installation. Ein netter Spaß für Zwischendurch, oder wenn man in seinem Blog dringend eine »authentische« Note benötigt, aber nichts, was man ernst nehmen kann.

Proof of concept: typeface.js

Darauf muss man erstmal kommen! Auf der Website von typeface.js kann man einen beliebigen Font hochladen und in eine JS-Datei konvertieren lassen. Diese enthält im JSON-Format die benötigten Vektordateien für die einzelnen Glypen. Um die eigentliche Darstellung im Browser kümmert sich dann in guten Browsern ein Canvas-Element, im Explorer wird das über VML geregelt. (Wer hätte gedacht, dass aus VML nochmal was sinnvolles wird, oder?)

Starker Tobak für Leute, die auf elegante und performante Lösungen stehen. Es ist ein wirklich waghalsiger Hack – aber er funktioniert! Prinzipiell. Je nachdem, wie komplex die Formen der ersehnten Schrift sind, kann die Font-Datei jedoch sehr groß werden. Und natürlich ist der Einsatz außerhalb von Überschriften definitiv nicht zu empfehlen, handelt es sich doch, ähnlich wie bei sIFR, eigentlich nicht um eine Schriftdarstellungs- sondern um eine Schriftersetzungsmethode. Aber eine sehr pfiffige, wie ich finde. Unbedingt mal ausprobieren!

Spaß mit Anarchie: @font-face mit OpenType und TrueType

Am meisten Aufsehen erregen konnte in den letzten Monaten sicher die Tatsache, dass das Verlinken und Verwenden von beliebigen Schriften im OpenType- oder TrueType-Format in aktuellen Versionen von Safari und Firefox (ab 3.1) sehr umkompliziert möglich ist. Der Vorteil: Die Methode arbeitet ohne Tricks oder krude Konvertierungen. Die Fonts werden temporär heruntergeladen und ebenso temporär installiert, so dass in der Darstellung quasi kein Unterschied zu einem Font besteht, der sich nativ auf dem System des Nutzers befindet. Mit der Ausnahme, dass die Schriftdatei natürlich erst geladen werden muss, was ein paar Sekunden dauern kann – je nach Komplexität und Ausbau der Schrift. Ralf Hermann hat hier eine Demoseite erstellt, die schon großen Spaß macht!

Problem bleibt natürlich die rechtliche Situation. Der Webdesigner wird quasi mit der Verantwortung allein gelassen und muss sich selber darum kümmern, Schriften zu finden, deren Lizenzbestimmungen ausdrücklich den Einsatz im @font-face-Umfeld erlauben. Gar nicht so leicht – zurzeit sind es gerade mal etwas mehr als eine Handvoll Exemplare Und der Internet Explorer wird den Einsatz von regulären TrueType- oder OpenType-Schriften wohl nie möglich machen, sondern setzt statt dessen konsequent auf das EOT-Format.

Bald offizieller Standard? @font-face mit EOT

EOT gibt’s schon seit über einem Jahrzehnt und bedeutet Embedded Open Type. EOT-Schriften basieren also auf OpenType, haben jedoch ein paar Gimmicks, die einerseits cool sind (Subsetting für kleinere Dateigrößen), andererseits nervig sein können (DRM). Zurzeit wird heftig darüber diskutiert, ob das Einbetten von EOT ein W3C-Standard sein wird. Eine hervorragende und ausführliche Zusammenfassung der Diskussion hat Bert Bos geschrieben. Und den 2008er-Praxistest nahm Jon Tan in seinem Blog vor. Seine Erkenntnis: Es gibt keine brauchbare Software zum Erstellen von EOT-Dateien. Das offizielle Microsoft-Tool ist ein Bag of Hurt, würde Meister Jobs sagen.

Wie dem auch sei: Auf längere Sicht betrachtet stehen alle Zeichen meines Erachtens auf EOT. Und warum auch nicht? Somit haben Fonthersteller die Möglichkeit, ein leicht zu identifizierendes, optimiertes und vielleicht preislich attraktives Format anzubieten, um auch Webdesigner zu ihren Kunden zu machen, wo diese vorher eher sparsam mit der Anschaffung von neuen Schriften waren. Außerdem ist prinzipiell jede Lösung zu begrüßen, bei der alle Browserhersteller mitziehen. Und bei EOT ist dies noch eher zu erwarten als bei unbehandelten OT- oder TT-Schriften.

Fazit

Was bleibt also am Ende des Tages? Wir müssen noch ein paar Jährchen durchhalten, bevor wir wirklich im großen Stil abgefahrene Schriften im Web verwenden können. Aber es ist eigentlich klar, dass es eines Tages möglich sein wird, da prinzipiell alle beteiligten Parteien es wollen. Über das Wie wird man sich schon einig werden, irgendwann. Und bis dahin können diejenigen, die es gar nicht abwarten können, ja weiterhin mit Bastellösungen zubringen. Wenn’s denn sein muss.

update: Ein bisschen sperrig geschrieben, aber es ist halt eine Art Verlaufsprotokoll einer Sitzung diverser wichtiger Menschen: Proposal for a Font Working Group (via Code Candies)

18 Kommentare

David

Ralf Hermanns Seite ist auf meinem Firefox 3.1 Beta eine sichere Methode, den Browser zum Absturz zu bringen.

Ralf Herrmann

Ralf Hermanns Seite ist auf meinem Firefox 3.1 Beta eine sichere Methode, den Browser zum Absturz zu bringen.

Auf welchem Betriebssystem? Diese Demo-Seite wird selbst von dem Mozilla-Entwicklern gern genutzt, etwaige Probleme damit sollten also bekannt sein. Unter Windows gibt es momentan noch Probleme mit OTF in Firefox.

Wie dem auch sei: Auf längere Sicht betrachtet stehen alle Zeichen meines Erachtens auf EOT. Und warum auch nicht?

Zum Beispiel Bedienbarkeit. Da die EOT-Webfonts ja wirklich nur unter den fest im Font voreingestellten URLs funktionieren, ist die Webseite nicht mehr »transportabel«. Sie läuft weder einfach so in einer Testumgebung, noch unter einer Zusatzdomain usw. Das kann den Webdesigner schon zur Verzweiflung bringen.
In den Entwickler-Mailinglisten herrscht momentan eine echte Pattsituation und Bert Bos‹ »Zusammenfassung«, die sehr parteiisch ist, wird da auch sehr kritisch gesehen. Auf welche Seite das Pendel kippt, ist also noch nicht abzusehen. Ich könnte mir genauso gut vorstellen, dass es letztendlich ähnlich zur Geschichte von Download-Musik verläuft, sprich:
Der bessere Schutz (EOT) wird zugunsten einer einfachen Benutzung aufgegeben, die zwar ein gewisses Maß an unlizenzierten Verwendungen mit sich bringt, aber gleichzeitig auch zu größeren Umsätzen führen kann.

Maik

Alle die glauben, dass EOT als offener Standard funktionieren kann, müssen ganz furchtbar betrunken sein. Die „Sicherheit“ des „Schutzes“ beruht zu 100% (und kein Bisschen weniger) auf der Annahme, dass es schwierig sei, die URL-Sperre aus dem Code rauszupatchen. Das ist schon bei verschlüsselten Binaries nur sehr begrenzt richtig (für welches DRM gibt es keinen Crack?!), und bei Open Source (Webkit, Gecko, …) kann man es komplett vergessen, denn da kann per definitionem jeder den Code lesen und korrigieren.
Ich weiß, ich weiß, es stehen schon wieder lauter Idioten Experten in den Startlöchern, um zu rufen: „Das mag ja theoretisch richtig sein, aber uns gehts doch um die Gelegenheitskopierer!“ Aber auch diese Argumentation war schon immer Unsinn. Zwar sind nur sehr wenige Leute in der Lage, einen entsprechenden Hack zu erstellen; ihn zu benutzen ist dann aber eine Ein-Klick-Aktion. Das schaffen auch Gelegenheitskopierer.

Finn

und was ist mit dynamisch generierten grafiken? hat sich bei meinen projekten auf jeden fall bewährt. funktioniert sogar in allen browsern ;) aber natürlich auch nur für headlines & co geeignet.

paul

»weniger … wie«?
Oh, Gerrit!

Lars

Ich benutze dynamische Grafiken, das funktioniert recht gut. Die Demoseite von Ralf läuft bei mir leider (noch?) nicht, bin passionierter Firefoxnutzer ;)

Und Anarchie steht übrigens nicht für Chaos, sondern im Gegenteil für (vernunft-, nicht zwangbasierte) Ordnung.

John

Die Demo-Seite funktioniert im Firefox 3.1ß1 wunderbar.

Jeffrey Zeldman gehen die Ideen aus und er orientiert sich deshalb mittlerweile auch an praegnanz.de. :o)

http://www.zeldman.com/2008/11/13/real-type-on-the-web/

Funktioniert eigentlich das OS-eigene Anti-Aliasing bei den @font-face Schriften?

Thorsten

Also für mich bleibt sIFR derzeit noch erste Wahl – es läuft in allen derzeit wichtigen Browsern vernünftig. Immerhin können damit Headlines im Corporate Font dargestellt werden.

Tests mit @font-face brachte mit einem Font, den ich benötigte, Safari regelmäßig zum Absturz. Und die Schriften Lizenzfrage sehe ich auch derzeit kritisch.

EOT könnte irgendwann vielleicht die Lösung werden – dann müsste Microsoft aber noch eine vernünftige Software für das Konvertieren herausbringen. Das derzeitige Programm ist wohl eher ein schlechter Witz und wollte bei meinen Tests partout einige Schriften nicht erkennen?!

@John: Ja, das OS-eigene Anti-Aliasing greift bei @font-face Schriften. Das sieht schon sauber aus.

Maik

Thorsten, welches Problem „löst“ EOT deiner Meinung nach? Was geht mit EOT, das mit TTF/OTF nicht geht?
Der Kopierschutz ist wie gesagt nur ein Kapierschutz – er hilft bloß Leuten, die laut singend die Finger in die Ohren stecken und die Augen schließen, um bloß nicht einsehen zu müssen, dass man Bits und Bytes nunmal kopieren kann. Auch im EOT-Format.
Bleibt das technische Argument „kleinere Fontdateien.“ Das ist allerdings auch nicht unbedingt wahr. Komprimiert auf den Server packen kann man auch normale Schriftdateien, Content Negotiation. Bleibt Font Subsetting, aber ich behaupte, das will man sowieso nicht. Im Gegensatz zu einem PDF ändern sich Webseiten ständig, und man will nicht bei jeder Änderung die EOTs neu generieren und hochladen, das heißt Subsetting wird in der Praxis sowieso keiner verwenden.

Ruben

Danke für den Ãœberblick über die verschiedenen Möglichkeiten. War schon lange mal fällig, dass man alles gesammelt beleuchten kann. Werde gleich mal weiter stöbern, was sich bei mir am besten eignet und leicht einzubinden ist.
Alles in allem eine gelungene, leicht verständliche Erklärung!

Ralf Herrmann

kleine Fontdateien
Das ist in der Tat ein Mythos, da etwa OTF schon von Hause aus eine hervorragende Komprimierung mitbringt.

Subsetting
So ein userbasiertes Subsetting, wie von WEFT erzeugt, basiert auf statischen Webseiten den 90er Jahre. Das kann man in der Tat heut nicht mehr gebrauchen.
Subsetting nach Codepages (Latin1/Greek/Cyrillic …) ist sehr sinnvoll für Webfonts, aber das sollte der Schriftanbieter direkt als Einzelfonts anbieten.

Dennoch ist es ein Trugschluss zu behaupten, wenn es keinen perfekten Schutz gibt, dann kann man jeglichen Schutz gleich weg lassen. Nur weil es keine perfekten Alarmanlagen gibt, lässt man in Ladengeschäfte auch nicht nachts die Tür offen.
Es kommt darauf an, dass Schutz und Anwendbarkeit in einem gesunden Verhältnis stehen.

aljas

Der Vollständigkeit halber möchte ich noch auf P+C DTR (PHP + CSS Dynamic Text Replacement: http://code.google.com/p/pcdtr/) von João Makray hinweisen … aber wahrscheinlich hast Du diesen Ansatz aus guten Gründen ausgelassen. Er steckt wohl noch in den Kinderschuhen; aber ich finde dessen grundsätzlichen Gedanken sehr ansprechend, gänzlich auf JavaScript und Flash zu verzichten.

Maik

Der „Schutz“ kann nur mit dem Mikroskop von „gar kein Schutz“ unterschieden werden. Der zusätzliche Aufwand ist enorm, man bedenke nur die zusätzlichen Tools auf beiden Seiten und die vielen zusätzlichen, fehleranfälligen Codezeilen für die Verschlüsselung und den Restriktionsabgleich und die Schlüsselverwaltung und was da alles dranhängt. Die unerwünschten Nebenwirkungen sind gigantisch.
Ralf, deine Aussage ist zwar prinzipiell richtig, aber der Punkt ist doch gerade, dass man mit DRM einfach nicht zu einem „gesunden Verhältnis“ kommt. Nichtmal in die Nähe. Hat noch nie geklappt, wird nie klappen, brauch man gar nicht erst versuchen.

John

Noch ein Hinweis: OTF funktioniert im Firefox 3.1ß1 unter Windows noch nicht. Ich hatte jetzt ewig rumprobiert, bis ich den Kommentar von John Daggett entdeckte:

http://opentype.info/blog/2008/10/25/sneak-peek-font-face-in-firefox-31/

@Ralf Könntest Du momentan vielleicht noch drauf hinweisen. Das irritiert. ;-)

Ralf Herrmann

Die neueste Meldung zum Thema: Die Entwickler haben sich gerade wieder getroffen und sind nach einer langwierigen Diskussion mit verhärteten Fronten zu einem erfreulichen Kompromiss-Konzept gekommen:
http://www.w3.org/Fonts/Misc/minutes-2008-10

Danach würde man TrueType-/OpenType-Fonts einfach um die nötigen Infos der URL-Bindung erweitern und die Browser-Hersteller würden sich darauf einigen, fortan dieses neue Format, sowie TrueType-/OpenType-Fonts ohne diese Infos zu unterstützen. Das würde bedeuten EOT wäre überflüssig und selbst IE würde dann das direkte Verlinken von TrueType-/OpenType-Fonts unterstützen.

jan

hallo. eine kurze zwischenfrage. seitdem font-stretch ja nun schon seit gut einem jahrzehnt implementiert werden soll und dies ja wahrscheinlich nicht so bald geschieht. gibt es eine methode, die zu einem ähnlichem resultat kommt, die markieren zulässt. javascript oder ähnliches?

Harald Kampen

Mit dem Adobe SVG-Plugin konnte man eingebettete Schriften ausgeben, die sich genauso verhalten haben wie normale Fonts. Die Schriften wurden bzw. werden base64-codiert in der CSS abgelegt, auch als Subset. Nur bei ein paar Schriften wurde da wegen Lizenzen gemeckert. Welches Format dieser Technik zugrunde liegt weiß ich nicht. Sowas wär schon was feines für HTML, auf jeden Fall besser als Flash, Pixel- oder Vektorlösungen.

Kommentar verfassen