Linotype schaltet in Sachen Webfonts einen Gang höher. Das im Mai gelaunchte Webfonts-Portal bietet seit gestern über 7.000 Schriften zur Auswahl an und führt Bezahl-Abonnements für Agenturen und Webdesigner ein. Anders als bei den von Fontshop vertriebenen Webfonts, die jeweils eine Einmalzahlung vorsehen und in der Grundlizenz (500T pi) bei 40 Euro starten, entrichtet man bei Linotype eine monatliche Nutzungsgebühr, die sich nach der Zahl der Seitenaufrufe richtet.
Das kleinste Standard-Webfonts-Abo gibt es für 9 Euro pro Monat. Es beinhaltet insgesamt 250.000 Seitenaurufe für eine beliebige Anzahl an Domains. Die Professionell-Webfonts-Version startet ab einer monatlichen Gebühr von 90 Euro für insgesamt 2,5 Millionen Seitenaurufe, ebenfalls auf einer unbegrenzten Anzahl an Domains. Erst in diesem Paket ist der Download jeder verfügbaren Schrift möglich, um etwa vor Live-Gang des Webprojekts auch Entwürfe mit den ausgewählten Schriften anzulegen.
Weiterhin stehen rund 2.200 Schriften bereit, die sich gratis in das eigene Webprojekt implementieren lassen, sofern diese denn nicht mehr als 25.000 Seitenaufrufe pro Monat produzieren. Die Zahl der Seitenaufrufe lässt sich deshalb sehr leicht beziffern, da die Schriften allesamt auf externen, von Linotype betreuten Servern liegen, was freilich Vor- und Nachteile hat. Vorteil: man muss die Schrift nicht erst installieren. Nachteil: Webseiten bedienen sich mehrerer Quellen, was unter Umständen den Seitenaufbau beeinträchtigt. Wir reden hier über ca. 20-150 KB, die pro Schrift zusätzlich geladen werden. Übrigens stehen auch diese 2.200 Schriften als Download zur Verfügung.
Ich habe mich einmal im Webfonts-Portal angemeldet und mir darauf hin eine eigene statische Testseite angelegt: Darstellung von Webfonts (Link wurde entfernt). Hier ist überall meine Hausschrift DIN im CSS hinterlegt, rein um das Prinzip zu testen. Dabei habe ich auch festgestellt, dass die CSS-Anweisungen nicht zu 100% überschrieben werden. In der Testseite ist die Schrift innerhalb der Navi weiterhin Arial, obwohl diese eigentlich hätte überschrieben werden sollen. Bei der Integration des Code-Schnipsels spielt es offenbar keine Rolle, ob man ihn zwischen den <head> oder den <body> tag packt. Hier gibt es im nachfolgend aufgeführten Tutorial und im Admin-Bereich widersprüchliche Angaben.
Derzeit gibt es im Portal außer Englisch keine Sprachauswahl. Die Preise sind lediglich in US-Dollar angegeben. Ein Termin für eine deutschsprachige Umgebung steht noch nicht, es wird aber daran gearbeitet. Auch die Usability der Admin-Umgebung ist noch ausbaufähig. Das Stöbern nach Schriften gestaltet sich doch etwas schwierig, da die Filterfunktionalität keine Mehrauswahl erlaubt.
Wie man die Schriften in die eigene Website integriert, zeigt das folgende Video-Tutorial (5:25min).
- webfonts.fonts.com
Ich habe mir deine Testseite angesehen und mir fallen folgende Probleme auf:
– das Anti-Aliasing ist (im Firefox) bei kleinerem Schriftgrad grauenhaft, daher nicht unbedingt für Fließtext einsetzbar.
– bei den Kommentaren werden die Umlaute nicht dargestellt (Im Beitrag selbst schon – also liegt es wohl nicht an der Font selbst !?)
Alles in allem werden sich Webfonts aber sicherlich im Laufe der Zeit durchsetzen, da die Browser Fehler ausmerzen werden und die Vorteile mMn einfach überwiegen.
Servus Achim,
das deine Headline weiter in Arial daher kommt, liegt halt daran, dass dies in deiner style.css so geschrieben steht:
#main_menu li a {...
font-family:Arial,Helvetica,sans-serif;
...
}
Und dieser Selektor gewinnt nun mal. Mir ist weiterhin aufgefallen, dass in der StyleSheet-Datei, in der der eingebettete Font auf die jeweiligen Elemente angewendet werden soll, sämtliche ID-Selektoren falsch sind. Also anstatt #main_menu steht dort lediglich ein main_menu. Wäre dieser richtig, würde er übrigens auch gegen den oben genannten Selektor verlieren.
Hoffe, du kannst damit was anfangen.
Ciao
Ralf
… und die Texte sind in der Din sehr schlecht lesbar, kann mal also in diesem Fall nicht empfehlen. Aber gut, dass Linotype die aktuell “übersichtliche” Schriftenauswahl voran bringt, man kann sicher schöne Projekte damit umsetzen bei denen man die vielffältigen Types gut zum Einsatz bringen kann. Ich bin mal gespannt auf gute Beispiele.
Grüße
Till
Auch ich muss mit Kritik daher kommen. Das “s” sieht im Fließtext fettgedruckt aus und macht das Schriftbild daher sehr unruhig. Die kleinen Links in der rechten Navigationsleiste sehen auch nicht wirklich schön aus, da hier noch das “M” irgendwie fettgedruckt aussieht.
Dieser Effekt verschwindet übrigens, wenn man die Seite vergrößert. Irgendwie scheint da also so einiges mit dem Skalieren noch nicht zu stimmen.
Insgesamt ist das Schriftbild dadurch sehr unruhig. Evtl. mag es mit anderen Fonts des Paketes besser aussehen, bis jetzt bin ich aber noch nicht überzeugt.
Dass in den Kommentaren die Umlaute nicht richtig angezeigt werden, liegt wohl an einer mangelnden UTF-8-Zeichenumwandlung, hat damit vermutlich nichts mit der Schrift zu tun.
@Alex Das Problem mit den Umlauten ist das Ergebnis von copy & paste. Das hat mit den Webfonts nichts zu tun. Im Content hatte ich sie händisch korrigiert.
@Ralf Hmmm… das ist richtig, nur sollte man doch meinen, dass diese Anweisung von dem Befehl gleichen Namens seitens des Webfonts-Portals überschrieben wird, was aber nicht der Fall ist. Wenn ich dort “main_menu li a“ als Klasse anlege, bleibt dies ohne Auswirkung. Übrigens sind dort auch die tags “a” und “li” einzeln definiert.
Ist es eventuell erforderlich, dass die “hauseigenen” CSS entfernt werden müssen, damit es nicht zu diesen Konflikten kommt? Weiß da jemand mehr?
> und die Texte sind in der Din sehr schlecht lesbar,
Ich hatte ja geschrieben, dass es mir rein um das Prinzip ging.
Dass die DIN in klein so komisch aussieht liegt wohl eher daran, dass sie nicht wie die normalen Webfonts für Bildschirme optimiert wurde und zum anderen an der Kantenglättung von Windows, die ja alles ins Pixelraster verschiebt, damit die Schrift schärfer ist.
Würd mich mal interessieren, wie die Testseite aufm Mac aussieht, der rendert ja wieder anders. Da gibts ja selbst bei den üblichen Fonts Unterschiede, hier schön zu sehen: http://www.typechart.com
@Achim: “Ist es eventuell erforderlich, dass die ‘hauseigenen’ CSS entfernt werden müssen, damit es nicht zu diesen Konflikten kommt? Weiß da jemand mehr?”
Jein. Wenn ich im Firebug kurz deine Regel ausschalte, wird die DIN korrekt verwendet:
https://cl.ly/4986502d46e7a68ee1e3
Das liegt daran, dass deine Angabe “#main_menu li a” in der CSS-Kaskade einfach stärker bewertet wird als die einzeln definierten Elemente bei Lintotype. Solltest du auch diesen Pfad dort eingetragen haben, wie du sagst, kann ich nur antworten, dass er laut Firebug aktuell nicht ausgegeben wird. Versuch nochmal, “#main_menu li a” dort einzutragen, denn das Stylesheet von Linotype wird später geladen und sollte deins (bei genau gleichem DOM-Pfad) übertrumpfen.
Oder auch: was Ralf gesagt hat. :)
Vielleicht ist meine Darstellung eine andere (Monitor-Auflösung 1680×1050), aber ich würde die Din selbst in den Heads nicht einsetzen: Man kann die Form gerade erahnen und sie sieht aus, als hätte jemand an ihr genagt. Ab einer gewissen Größe (so 4-5 mal größer) wird es interessant…
Also schon für das eine oder andere Projekt, aber eher selten.
@ Patrick: Hier ist ein Screenshot unter Mac (OS 10.4., Safari 4.0.3.)