praegnanz.de büro für intervernetzte medien

Gerrit, 14.11.2007

Nachschlag zur font-face-Situation

Bereits vor einem Monat habe ja drüber geschrieben: Der längst vergessene Ansatz, über @font-face im CSS Schriftdateien zu referenzieren und dem Browser temporär nutzbar zu machen, um beliebige Fonts ganz normal vom Browser rendern zu lassen.

Hier zu meinem alten Artikel mit dem kleinen Live-Test

Webkit macht dies seit einiger Zeit. Und andere Browser sollten eigentlich auch nachziehen, tun sie aber derzeit nicht – zumindest Opera 9.50beta und Firefox3beta2 nicht (habe ich eben probiert). Und selbst die Safari-Version auf Mac OS X 10.5.0 ist noch nicht soweit – da kam der Webkit-Build wohl einige Tage zu spät für den Golden Master.

Ich finde das ganze Thema dennoch großartig, denn typografische Vielfalt ist im Web zu selten, und hier hätten wir eine standardkonforme Lösung, die sich sehr smooth in den regulären Gestaltungsprozess mit CSS einfügt. Allein die Rechtefrage ist tricky: Niemand darf so einfach eine Schriftdatei auf einen öffentlichen Webserver stellen, damit ihn irgendwelche Browser verwenden. Und natürlich gibt es keine komplett sichere Lösung, die dieses Problem hundertprozentig lösen könnte. Logisch: Wenn ein User Agent den Font verwenden kann, kann er ihn auch abspeichern. Aber es kostet einen gewissen Aufwand und auch kriminelle Energie, einen solches Script zu schreiben und einzusetzen.

Der erste Schritt wäre also zunächst einmal, Gelegenheitsdiebe fernzuhalten. Und da hat sich Schriftgestalter Ralf Herrmann etwas ausgedacht, nämlich ein PHP-Script, das eine Wegwerfadresse und eine Art Token generiert, mit dem sichergestellt wird, dass der Font nur dann einmalig vom Server ausgeliefert wird, wenn der Request wirklich von der gewünschten Website aus gestartet wird.

Zum entsprechenden Blogeintrag von Ralf Herrmann

Das macht die Sache komplizierter für Leute, die Fonts klauen wollen. Und ist ein deutliches Signal, dass Schriften eben nicht einfach mal so überall heruntergeladen werden dürfen.

Nun müssten folgerichtig die kommerziellen Schrifthäuser nachziehen und ihre Lizenzbestimmungen anpassen. Für das Einbetten in PDF-Dokumente hat das ja vor einigen Jahren ganz gut geklappt – hier herrscht inzwischen Klarheit, was man darf und was nicht. Sollte sich eine derartige Technik wie die von Ralf durchsetzen, dann könnte ein Standard geschaffen werden, der von den liberal denkenden Schrifthäusern auch genutzt werden könnte. Wenn schon nicht für das gesamte Repertoire, dann zumindest für einzelne, screenoptimierte Fonts. Was wäre das? Schön.

12 Kommentare

  1. Einsiedler am 14. November 2007 #

    Du hast aber auch die Kommentare drüben gelesen, oder? Und der Wikipedia-Artikel handelt zwar von Tokens, hat aber nix damit zu tun. Substanz?

  2. Gerrit van Aaken am 14. November 2007 #

    Substanz gibt’s bei mir niemals, das ist mir zu anstrengend! Und die meisten Kommentare drüben sind erst nach diesem Posting geschrieben worden, okay? In der Wikipedia gab es leider keinen expliziten Artikel über Software-Tokens, deswegen habe ich den verlinkt, der sich auf das bezieht, woher das Token-Konzept stammt, nämlich aus der Hardware. Also halt den Rand, bitte.

  3. Daniel H. am 14. November 2007 #

    Einziger Wermutstropfen wäre dann wohl die unterschiedliche Font-Darstellung von Windows, Linux und OS X. :(

  4. Martin Lange am 14. November 2007 #

    Ist diese Sicherungsvariante von Ralf Hermann wirklich so sicher? So wie ich das auf die schnelle sehe ist es lediglich ein gesperrtes CSS Script, dass nur mit entsprechendem »Referer« geht und so den Pfad zur Schriftartendatei verbirgt. Wenn man den Pfad aber so besitzt kann man sie theoretisch aber einfach downloaden, oder irre ich mich da?

  5. Einsiedler am 14. November 2007 #

    Gerrit, das ist mir jetzt sehr peinlich und auch unangenehm. Ja, man soll nicht mit schlechter Laune Kommentare schreiben, das erwischt immer die Falschen. Aber, man soll auch den Mut haben, seine Fehler einzusehen und höflich um Verzeihung zu bitten. Daher bitte ich ganz offiziell um Entschuldigung, ich habe mich im Ton vergriffen. Wenn Du diese nicht annehmen willst, so habe ich dafür vollstes Verständnis, ich war einfach zu ruppig.

    @Martin Lange: Der Ansatz wäre sicherer (nicht sicher), wenn das »Tokenprinzip« eine echte Blackbox wäre, dessen Integrität man sicherstellen könnte. Da aber die Daten ausgeliefert und werden müssen und auf dem Client – dem Feindesland – in vollkommener Klarversion vorliegen müssen ist der Ansatz aus Sicherheitsaspekten für die Katz. Mehr noch: Er suggeriert Sicherheit, wo keine ist.

  6. marcus am 14. November 2007 #

    mir reichen die paar systemfonts. wozu mehr?

    und ehrlich: unter den professionellen schriften gibt es kaum welche, die gut für den bildschirmeinsatz geeignet sind oder mehr als dem gelegentlichen headline-einsatz genügen.

    das hat vor allem mit der »geisteshaltung« der schriftgestalter zu tun. diese sind dann doch alle sehr der printwelt verhaftet.

    glauben sie mir … ich weiss, wovon ich rede ;)

    andererseits — übergreifende einsatzmöglichkeiten könnten das natürlich ändern. werden sehen …

  7. Tobias am 15. November 2007 #

    Ich glaube nicht, das wir jemals z.B. ‘ne echte FF Meta als ‹embedded font› sehen werden. Subsets von Fonts in PDF sind total was anderes, weil man da keinerlei TTF in die Hand bekommt, sondern nur die Outlines, und das ganze Kerning, etc, ist nicht dabei.

    Wer hindert mich eigentlich daran, wenn ich ‘ne Webseite mit tollen Fonts gefunden hab, diese hinterher aus meinem Browsercache zu angeln?

    Nice idea, won’t fly.

  8. mike am 15. November 2007 #

    Das Web ist nich Adobe.
    Es wäre zu wünschen, dass ich unrecht habe, aber das wird so nicht kommen, da haben die Rechteinhaber schon ihre Hand drauf.
    Hinzu kommt noch ein technisches Problem: es ist nicht schön, dass Hinz und Kunz nicht die Schrift ihrer Wahl ins Web pusten kann, aber, und das ist der springende Punkt, es ist auch nicht Scheisse.
    Die Monokultur von 4-5 Schriften im Web kann man getrost unschnafte finden, über eine »Multi»kultur von Millionen Fonts muss man sich aber Gedanken machen.
    Man stelle sic nur einmal vor jeder Frontpagekünstler könnte die Schrift seiner Wahl verwenden – ohweh – dann doch bitte weiter so rudimentär, wie’s jetzt ist.
    Genug Flash-»künstler« zeigen schon ausreichend, wie man Webseie vergewaltigen kann.

  9. Gerrit van Aaken am 15. November 2007 #

    @Einsiedler: Nix für ungut, sowas passiert halt mal. Du kannst gerne wiederkommen :-)

  10. Ralf Herrmann am 15. November 2007 #

    >>dass nur mit entsprechendem »Referer« geht und so den Pfad zur Schriftartendatei verbirgt

    Nein, so funktioniert es nicht.
    Die Aufgabe war, die Klartext-URL durch eine dynamische zu ersetzen, die a) nicht direkt einsehbar und b) nur von bestimmten Domains angefordert werden kann. Nicht mehr und nicht weniger. Einen echten Download-Schutz kann es nicht geben, da der Font ja herunter geladen werden MUSS.

    Es ist nicht zu erwarten, dass Anbieter wie Linotype plötzlich ihre ganze Library so anbieten, aber man muss zumindest darüber diskutieren. Denn wie oben schon gesagt: Schriftanbieter leben in der Printwelt und sehen das Netz eher als Verkaufs- oder Raubkopierkanal, nicht jedoch als Markt.

    Aber schaut doch mal ein paar Jahre in die Zukunft: Das iPhone macht Webseiten schon jetzt zum Produkt-Interface. Adobe, Google und Microsoft beginnen ihre Anwendungen ins Netz zu bringen. Es geht also nicht mehr nur um’s »Webseiten lesen«.
    Dass WEFT vor vielen Jahren scheiterte, war nicht verwunderlich. sIFR ist ein Hack für die Übergangszeit. Echte Webfonts müssen und werden kommen. Zu welchen Bedingungen das passiert, ist jetzt zu diskutieren.

  11. Gero am 15. November 2007 #

    Hhhhmmmm  …

    Bin ich eigentlich der einzige, der das Font-Embedding nicht in Gang bekommt – bei dem also der/die/das Nightly-Webkit (r27811 / 15.11.) beim versuchten Font-Embedding sang- und klanglos absäuft (naja, schon mit der obligatorischen »Ignorieren / Neustarten«-Fehlermeldung)?
    Und zwar egal, ob unter Leopard oder Tiger – Tiger allerdings schon als 10.4.11, also nach dem Update auf Safari 3.0.4.

    ... Und beim Windows-Webkit läuft zwar die neue Safari-Beta (auch 3.0.4) mit dem korrekten frameworkPath an, will aber von eingebetteten Fonts nicht wirklich etwas wissen.

    Ist es zu stark, bin ich zu schwach – oder gibt es alternative Deutungsansätze? Danke auf jeden Fall schon mal im voraus.

  12. Martin H. am 20. November 2007 #

    Nur so dazwischen gefragt: Wenn man per PHP-Script bei jedem Seitenzugriff eine neue URL/Token für den Font generiert, dann muss doch auch der Font bei jedem Seitenbesuch erneut geladen werden, oder? Was wiederum Ladezeit und Trafik unnötig erhöhen würde…

Kommentar schreiben

Nutzt Textile zum Strukturieren eures Textes.
SEO-Beiträge werden gelöscht, auch bei thematisch passendem Spam.