Schriften im Web – was derzeit möglich ist

Leave a comment
Uncategorized

Wenn man ein Faible für Gestaltung, Typografie und Internet hat, dann wird man früher oder später mit einem recht nervigen Umstand konfrontiert werden. Nämlich damit, dass man beim Gestalten von Internetseiten auf eine recht geringe Anzahl von Schriften beschränkt ist, die man verwenden kann. Aber ist das wirklich so, wo liegen die Probleme und was sind die Möglichkeiten die man heute schon hat, um diese Limitierung zu umgehen. Ich werde versuchen ein wenig Licht in die Sache zu bringen ohne es zu technisch werden zu lassen. Es geht mir nur darum, dass die Leute die sich damit gestalterisch beschäftigen Einblick bekommen über das wie wo warum und überhaupt.

Das Problem und das warum:

Als Internetseitendesigner ist man auf eine recht überschaubare Anzahl web sicherer Fonts beschränkt. Aber warum ist das so.
Der Grund dafür liegt in der Art und Weise wie Internetseiten zum eigentlichen Betrachter gelangen. Einfach dargestellt besteht eine Internetseite aus einer Menge Informationen die von einem Server zu einem Betrachter übermittelt wird und dort, auf dem Rechner des Betrachters, vom jeweils benutzten Browser interpretiert wird. Diese Interpretation ist das was man als Nutzer auf seinem Monitor angezeigt bekommt. Zur Darstellung der Internetseite greift der Browser auf die Schriften zurück die lokal auf dem Rechner installiert sind. Wenn ich also eine  bestimmte Schrift für mein Design verwende, dann müssen alle Leute die meine Seite so sehen sollen wie ich es möchte, diese Schrift installiert haben. Oder eben was realistischer ist aber eben auch zu einer solchen Einschränkung führt, als Gestalter muss ich auf diejenigen Schriften zurückgreifen von denen ich ausgehen kann, dass sie auf der größtmöglichen Anzahl von Rechnern installiert sind. Was leider nicht allzu viele sind.
Es gibt einige Übersichten die einem eine Liste mit web-sicheren Schriften an die Hand geben, eine davon findet sich zum Beispiel auf Dustin Brewers Seite.

Die Lösung erscheint einfach. Anstatt auf die Schriften zurückzugreifen die jeder auf seinem Computer installiert hat, stellt man einfach selbst die Schrift bereit. Wie ein Bild, dass man auf seiner Internetseite einbaut und auf dem Server zentral speichert, macht man das auch mit der Schriftdatei. Und in der Tat ist das auch wirklich die Lösung und es gibt einige Möglichkeiten diesen Ansatz in die Tat umzusetzen. Wenn auch technisch einfach, rechtlich ist es leider nicht so.

Wenn man sich eine Schrift kauft, dann kauft man sich eine Lizenz dafür. Man erkauft sich das Recht, diese Schrift für bestimmte Zwecke zu benutzen. Wofür die Schrift verwendet werden darf steht in der sogenannten EULA – dem End User Licence Agreement. Und darin wird oftmals durch die Type Foundries – den Schriftherstellern – der Schrifteinbindung ein Riegel vorgeschoben. Dies gilt übrigens nicht nur für die Einbindung einer Schrift in eine Internetseite, je nach Foundry darf man eine gekaufte Schrift auch nicht in ein noch editierbares PDF-Dokument einbinden. Oder zum Beispiel in die Oberfläche einer Software die man entwickelt hat. Es gibt viel zu erfahren in der EULA und das Durchlesen lohnt sich wenn man vorhat mehr zu machen mit der gekauften Schrift, als sein eigenes Briefpapier zu schmücken.
Übrigens sollte man sich nicht vorschnell freuen wenn in der EULA Fonteinbindung nicht explizit erwähnt wird. Denn auch durch die untersagte Weitergabe an Dritte wird einem die Einbettung untersagt. Und eine Weitergabe ist auf jeden Fall untersagt, sonst könnten die Fonthäuser ja keine Lizenzen mehr verkaufen.
Eine Anlaufstelle für Informationen rund um das Einbetten von Schriften ist die Seite fontembedding.com. Auch wenn die Seite auf den amerikanischen Raum ausgerichtet ist gibt sie einen guten Überblick was zu beachten ist

Lösungswege

Als ich sagte dass die Lösung einfach sei, dann war das natürlich nicht ganz korrekt. Das Prinzip ist einfach, die technische Umsetzung jedoch nicht. Eine Einbindung von Schriften war geraume Zeit einfach nicht in den Standards die das Word Wide Web Consortium – kurz W3C – herausgibt und die den Aufbau von Internetseiten definiert, vorgesehen. Es mussten erst Wege geschaffen werden, die die Anzeige von Schriften ermöglichen ohne diese auf dem Rechner des Betrachters zu installieren. Und diejenigen die bis jetzt am häufigsten Verwendung finden, sind eher Umwege.

sFir, Cufon und andere – die Image Replacement Technique

Um es nicht zu technisch werden zu lassen erkläre ich lieber das Prinzip dieser Umwege oder Hacks. Denn es ist mit geringen Abweichungen der Prozesse, bei allen gleich. Es nennt sich Image Replacement Technique.
Hierfür wird in die Internetseite ein zusätzlicher Programmcode eingefügt. Dieser generiert wenn man ihm den Befehl dazu gibt, punktuell aus dem vorgegebenen Textinhalt und mit Hilfe einer hinterlegten Schrift ein temporär verfügbares Bild. Dieses Bild wird in die Internetseite eingesetzt und wie alle anderen Bilder auch, an den Nutzer übertragen und ihm dort angezeigt. So bekommt der Nutzer auch dann eine schöne Schrift zu sehen, wenn er sie gar nicht installiert hat. Toll, nicht!?
Leider hat diese Technik mehr als einen Haken. Ein ganz einfaches Beispiel: Jemand hat die Bildanzeige grundsätzlich ausgestellt um Bandbreite zu sparen. Derjenige sieht nichts, oder Programmcode, oder den ursprünglichen Text in einer Standardschrift seines Systems. Natürlich kann man für diese Eventualisät vorbeugen und eine auf Standardschriften angepasste Gestaltung für diesen Fall hinterlegen, aber es ist unschön und arbeitsintensiv. Man kann auch auf andere Bildgenerierungsweisen ausweichen, aber was wenn Javascript – was die bei diesen Prozessen häufig eingesetzte Programmsprache ist – deaktiviert ist, oder Flash, oder …?
Wer genug Zeit investiert kann viele dieser Eventualitäten umgehen oder Kompromisse finden. Aber diese sich möglicherweise ergebenden Probleme sind gar nicht die Kernschwachstelle dieser Technik. Das ist nämlich viel mehr der Datenaufwand.
Diese Technik wird oftmals nur für Headlines benutzt, aus dem einfachen Grund dass die Erstellung eines solchen Textbildes Rechenkraft benötigt – also Zeit – und dem Nutzer die Bilddaten dann erstmal übertragen werden müssen – Zeit und Kosten. Schon eine auf diese Art erzeugte bloße Headline kann schnell mal 100kbyte betragen. Was dann eine komplette Textseite von der Länge dieser Ausführungen hier an Speicher beanspruchen würde… zuviel.
Wer mehr zu diesem Thema und den vielen verschiedenen Ansätzen dieser Technik erfahren möchte, kann dies unter anderem bei meiert.com tun. Dieser Artikel – übrigens deutschsprachig – liefert einen Überblick der gängigen Methoden und geht detaillierter und technischer auf ihre Unterschiede ein.

.EOT

EOT ist streng genommen kein eigenes Verfahren, es setzt viel mehr dort an wo das @font-face Verfahren Lücken aufweist – worauf ich später noch eingehen werde – nämlich den Kopierschutz.
1997 veröffentlichte Microsoft seine Entwicklung des EOT Formates (Embedded Open Type Format). Aus jedem True Type und Open Type Font lässt sich schnell und einfach von seiten des Gestalters eine Datei mit der Endung .eot herstellen. Diese Datei kann dann mit dem Befehl @font-face in die Internetseite eingebunden werden. Wenn eine Internetseite nun eine solche Schrift beinhaltet, dann wird diese Datei nach Bedarf an den Nutzerrechner übertragen, die benötigten Zeichen temporär installiert und die Internetseite erstrahlt so, wie man sich das als Designer erdacht hat. Die Kopierschutzmaßnahmen die Microsoft einbaute sind z.B. die Aufsplittung der Schriftdatei in viele kleine Pakete, die Bindung der Schriftdatei an eine bestimmte Webseitenadresse der die Verwendung gewährt wird, Datenverschlüsselung usw.
Mit einiger Handarbeit soll es zwar möglich sein aus diesen Einzelteilen auch wieder die komplette Schrift zu rekonstruieren, doch das ist wohl nicht der Grund warum dieses Format noch kein etablierter Standard ist.
Als 1997 Microsoft dieses Format vorstellte baute es die Unterstützung hierfür natürlich sofort in seinen eigenen Browser Internet Explorer ein. Durch die Unterstützung durch Adobe und Monotype wäre eine Etablierung dieses Formates durchaus möglich gewesen. Das passierte allerdings nicht. Woran es scheiterte konnte ich nicht genau feststellen, doch ein Hinweis den ich häufiger fand war ganz einfach: Es kam von Microsoft, das war Grund genug es nicht zu unterstüzten.
Sicher fest steht, dass erst 2007 Microsoft einen Aufbau-Entwurf an das W3C zur Entwicklung und Etablierung von EOT als Standard schickte. Dieser Entwurf wurde vom W3C jedoch wegen Sicherheitsbedenken abgelehnt und im März 2008 schickte Microsoft einen aktualisierten Entwurf ans W3C. Eine Empfehlung vom W3C an die Browserhersteller dieses Format zu unterstützen blieb jedoch aus und so scheint es, versinkt Microsofts eigentlich vielversprechendes Format langsam aber sicher im Dunkel.

.EOT lite

Soweit ich es verstanden habe gibt es mittlerweile eine abgespeckte Variante von Microsofts EOT-Format. Der wesentliche Unterschied besteht darin dass die Bindung an eine bestimmte Internetseitenadresse herausgenommen wurde und der Lizenzierungsaufwand für die Schrifthäuser damit vereinfacht wird.

@font-face

@font-face ist nun das eigentliche Verfahren, auf das viel Hoffnung gesetzt wurde. Denn nun endlich soll es möglich sein ohne den Umweg der Bilderstellung, die Schriften zu verwenden die man gerne verwenden möchte. Und es funktioniert. Bedingt.
Die Verwendung von @font-face ist sehr einfach, denn es ist ein einfacher CSS-Befehl. Man hinterlegt eine Schrift auf dem Server, definiert im Quellcode der Internetseite den Zielpfad zu dieser Schrift und mit dem @font-face-Befehl dass diese Schrift verwandt werden soll und kann dann ganz normal auf das volle Repertoire der CSS-Gestaltung zurückgreifen. @font-face sorgt dafür, dass die Schriftdatei geöffnet, installiert und alles so angezeigt wird wie man das möchte. Total cool eigentlich.
Doch das Problem damit ist, dass die Schriftdatei vollkommen ungeschützt auf dem Server liegt. Damit die Anzeige funktioniert wird sie temporär an den Nutzer übertragen und installiert und wer möchte kann sich diese Schrift einfach aus dem Cache-Ordner kopieren. Oder direkt vom Server ziehen wenn er im Quellcode den Pfad dahin ausfindig gemacht hat. Außerdem ist @font-face zwar nicht ganz neu, wird aber erst seit kurzem von den gängigen Browsern unterstützt. Firefox beherrscht es seit Version 3.5, Safari seit 3.1 und für Opera läuft gerade die offene Beta der Version 10 die ebenfalls @font-face unterstützen soll.  Internet Explorer unterstützt es eh schon lange, allerdings beschränkt auf EOT-Files.
Das Verfahren funktioniert also, doch solange die Schrifthäuser davor Angst haben müssen dass ihre Schriften ganz einfach kopiert und weitergegeben werden können werden sie ihre EULA ganz sicher nicht öffnen. Es gibt verschiedene Ansätze das Kopieren der Schriften zu erschweren – Verschlüsselung, Aufsplittung usw. all das was auch Microsoft macht – aber bis jetzt hat nichts davon die Schrifthäuser überzeugt, weshalb die Nutzung von @font-face und damit ein reichhaltigeres Schriftbild im Internet noch auf sich warten lässt.
Es gibt allerdings eine Hand voll Free Fonts die in ihrer EULA auch die Einbindung in deine Internetseite mittels @font-face erlauben. Eine Liste dieser Schriften findet sich bei webfonts.info

.webfont

Unter dem Titel .webfont entsteht gerade ein neuer W3C-Standard-Vorschlag. Erstellt von Erik van Blokland und Tal Leming soll es eine Alternative zu Microsofts propriätären EOT-Format werden und die Verwendung von Schriften im Internet so einfach wie möglich machen. Hierbei wird die Schrift in zwei Dateien aufgesplittet. Eine Datei enthält die eigentlichen Schriftinformationen – Buchstabenaufbau etc. – und eine Datei die Metadaten – Autor, Verkäufer, Schriftname, Lizenzbeschränkungen etc. .Die Metadaten werden vom Browser ausgelesen und je nachdem welche Lizenzbeschränkungen darin angegeben werden, die Installation und Verwendung erlaubt. Damit wäre es möglich, eine Verwendung nur für Print zuzulassen, oder nur für Web. Zusammen mit der Angabe von Internetseitenadressen denen die Verwendung gewährt wird, enstünde damit eine Art Kopierschutz.
Diesen Vorschlag unterstützen bereits sehr viele Schrifthäuser, doch wann sich das W3C damit befassen und dieser Vorschlag als Standard umgesetzt wird, ist noch nicht klar. Erst wenn sich ein möglichst vollständiger Support der Schrifthäuser abzeichnet wird das W3C anfangen seine Mühlsteine mahlen zu lassen, und dann müssen auch erstmal noch die Browserhersteller diesen Standard annehmen und in ihre Produkte einbauen.

Open Type Permission Table

Einen ähnlichen Ansatz wie Erik van Blokland und Tal Leming verfolgt auch der Vorschlag von David Berlow Er schlägt vor Lizenzdaten und dergleichen einfach zum jetzigen Bestand der Open Type Daten hinzuzufügen. Das ist technisch einfach realisierbar, birgt jedoch das Risiko der Manipulation durch die Nutzer. Denn Open Type Daten lassen sich relativ leicht öffnen, interpretieren und damit auch manipulieren. Die Lizenzbeschränkungen ließen sich leicht aushebeln und die Schriftdateien damit weiterverbreiten.

Typekit

Da .webfont und David Berlows Vorschlag noch ziemlich in den Startlöchern stehen und man noch weit davon entfernt ist, sich auf einen Standard zu einigen versuchen einige Gestalter durch Erweiterung/Verfeinerung bestehender technischer Möglichkeiten schon heute Schriftgestaltung möglich zu machen.
Typekit ist ein solcher Versuch. Hier erkauft sich der geneigte Internetseitenbetreiber durch eine monatliche Gebühr eine Lizenz zur Verwendung einer Schrift auf seiner Internetseite. Die Schriftdatei verbleibt auf dem Server von Typekit und man verlinkt in seinem Code zu dieser Datei. Ich habe leider nicht viel mehr über Typekit in Erfahrung bringen können, doch da Typekit das .webfont-proposal unterstützt gehe ich davon aus, dass die Einbettung der Schrift über den @font-face-Befehl erfolgen wird und kein Image Replacement Verfahren zum Einsatz kommt. Wie die Schriftdatei verschlüsselt werden soll ist mir nicht bekannt.
Außerdem ergeben sich automatisch Fragen wie: Was passiert wenn ich nicht weiterzahle. Was passiert wenn deren Server ausfällt oder generell hohe Netzauslastung zu spüren ist. Wird der Inhalt dennoch angezeigt und wenn ja mit welcher Schrift? Muss man warten bis die Daten von Typekit übertragen wurden bevor man überhaupt irgendetwas angezeigt bekommt. etc.

Typotheque Web Font Service

Typotheque – bis dato nur bekannt als Schrifthersteller – möchte in Kürze ebenfalls ein Web Schriften Lizensierungsprogramm starten. Hierbei wird nach Angabe der Internetseitenadresse für welche man die Schrift verwenden möchte, eine EOT-Datei erstellt und man erhält einen Link zu dieser Datei welchen man in seinen Internetseitenquellcode einsetzt. Die Schriftdatei selbst verbleibt auf dem Server von Typotheque.

Fazit:

.webfont und Berlowes Open Type Permission Table ähneln sich stark und machen im Prinzip nichts anderes, als einen für Druck gedachten Schriftsatz mit Lizenzverbeinbarungen zu erweitern die die Verwendung einschränken sollen. Allerdings ist das scheinbar leicht manipulierbar und in Anbetracht der Tatsache dass es jahre dauern kann bis ein neuer Standard etabliert ist, stellt sich die Frage ob es nicht praktischer wäre einfach breit Microsofts EOT oder eben EOT lite Format zu unterstüzen. Es generiert aus einer für Druck gedachten Schrift einen aufs Web ausgerichteten Datensatz und schon damit ist die Verwendung eingeschränkt. Vielleicht sollte man einfach seine Antipathien gegenüber Microsoft abbauen.

Typotheques Ansatz gefällt mir dahingehend schon ganz gut, denn das Rad wird nicht wieder neu erfunden sondern einfach mit dem gearbeitet was schon da ist. Vor allem wenn sich die Lizenzgebühren für den Endbenutzer in Grenzen halten und die Einbettung der Schriften wirklich so einfach von statten gehen wird, sehe ich da durchaus eine Chance endlich Schriftvielfalt im Netz zu sehen.
Selbiges gilt natürlich auch für Typekit. Wobei der Erfolg von Typekit maßgeblich von der Unterstützung durch die Schrifthersteller abhängt, da sie kein eigenes Angebot haben. Solange die Schrifthersteller das Gefühl haben dass ihre kostbaren Daten zu leicht kopiert und zweckentfremdet werden können, werden sie Typekit nicht mit Lizenzen unterstützen.

Ansonsten gilt, dass wer sich heute schon durch ein individuelles Schriftbild von der Masse absetzen möchte,immer noch auf Image Replacement Techniken zurückgreifen  muss und damit in der Menge an Text beschränkt ist. Wer uneingeschränkt Text setzen möchte ist durch die geringe Menge an Schriften eingeschränkt, welche die Schrifteinbindung erlauben und durch noch Kompatibiliätsprobleme. Nicht jeder surft mit der aktuellsten Browserversion.

Es ist also auch heute noch nicht möglich sich typografisch voll und ganz auszutoben und ein für alle funktionierender Konsens zeichnet sich noch nicht ab. Leider.

Ich hoffe ich konnte mit meinen Ausführungen einen Überblick über den derzeitigen Stand der Dinge geben. Es ist kein einfaches Thema und sollte ich etwas vergessen haben, freue ich mich über Hinweise und werde meinen Text gerne entsprechend erweitern. Ansonsten freue ich mich natürlich auch über eure Meinungen zum Thema.

Appendix (weitestgehend englischsprachige Links):


Liste der fürs Web sicheren Schriften


Informationen rund um das Thema Schrifteinbindung

Übersicht der verschiedenen Image Replacement Techniken und ihrer Unterschiede

EOT-Submission an das World Wide Web Consortium
Microsofts “Font Embedding for the Web” Seite

EOT Lite
What is EOT Lite

Free Fonts die @font-face Einbettung erlauben
@Font-Face Specs

.webfont proposel 2
.webfont Schrifthersteller Unterstützer

Open Type Permission Table
Open Type Permission Table Specs

Typekit

Typotheque Web Font Service

Leave a Reply