Skip to content

Linotype zündet neue Stufe bei Webfonts

Linotype Webfonts

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

Dieser Beitrag hat 28 Kommentare

  1. 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.

  2. 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

  3. … 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

  4. 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.

  5. @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.

  6. 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

  7. @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.

  8. 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.

  9. Hmm… die Schrift eignet sich gar nicht – ich vermute, die meisten User werden wie wild an der Monitor-Einstellung rumschrauben, oder gehen davon aus, dass sie über Nacht erblindet sind.

  10. Ich denke, dass sich die Fragen zum Hinting und zum Einbinden mit den nächsten Browsern klären lassen. Störender finde ich aber, dass der Aufbau einer Seite dann von einem Server mehr abhängt, was sich nicht positiv auf die Ladezeiten auswirken dürfte. Da finde ich Webfonts über @font-face wesentlich interessanter.

  11. “Nachteil: Webseiten bedienen sich mehrerer Quellen, was unter Umständen den Seitenaufbau beeinträchtigt.”

    Das Gegenteil ist richtig. Mehrere Quellen (unterschiedliche Domains) sind dem Seitenaufbau sogar förderlich.

  12. man kann das miese Aliasing vielleicht auch der Einbindung von Fonts.com zuschreiben. Die Din kann nämlich durchaus gut aussehen, wie Deine Kollegen von Designmadeingermany demonstrieren (vielleicht liegt es auch an der Schriftgrösse). https://www.designmadeingermany.de/blog/

    Die haben es vermutlich mit Typekit eingebunden, meiner Meinung nach immer noch die vernünftigste (nicht zuletzt preislich gesehen) Lösung auf dem Webfont-Markt.

  13. Danke Jerry, ich hatte die Raute vergessen. Nun ist die DIN auch in der Navi zu sehen, was, wie gesagt, nicht sonderlich schön aussieht aber darum ging es mir erst einmal nicht.

    Das Gegenteil ist richtig. Mehrere Quellen (unterschiedliche Domains) sind dem Seitenaufbau sogar förderlich.

    Das ist ja mal was ganz Neues. Ich denke, so pauschal lässt sich die Behauptung wohl kaum halten, denn wenn Server A gerade am Limit ist, hingegen Server B, auf dem sich das Gros an Daten befindet, ordentlich arbeitet, verzögert sich der Aufbau, da der Zugriff auf Server A eingeschränkt ist. Oder liege ich da jetzt vollkommen daneben?

  14. Solange noch viele User ganz ohne Schrift-Antialiasing im Web unterwegs sind – und von denen gibt es eine Menge – würde ich in kommerziellen Projekten niemals auf Webfonts zurückgreifen. Das Ergebnis ist oft so augenkrebsig, daß die Gefahr frühzeitiger Abbrüche dramatisch steigt. Wer mag, kann ja mal die Schriftglättung abschalten und dann Achims Testseite anschauen.

  15. Ähnlich wie bei den von Fontshop vertriebenen Webfonts, die 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 ist etwas missverständlich ausgedrückt. Die Web FontFonts (die von FontShop) haben keine monatliche, sondern eine einmalige Lizenzgebühr von 40€ pro 500.000 Pageviews im Monat für einen Standardsprachumfang, wohingegen die Linotype-Fonts für die selbe Anzahl Pageviews monatlich 18€ abverlangen.

    Übrigens, die FF DIN Web wurde wie alle anderen Web FontFonts einzeln manuell für die Bildschirmdarstellung unter ClearType (Standard ab Windows Vista bzw. Internet Explorer 7) optimiert und sollte auch im Fließtext keinen Ärger bereiten. DesignMadeinGermany nutzt übrigens die FF DIN Web, während beim Linotype-Service eine Version von Linotype zum Einsatz kommt.

  16. Extensis, der Hersteller von Suitcase bietet mitlerweile mit WebINK auch eine Webfont-Lösung an, die auch auf dem Abo-Modell aufbaut. Beim Kauf vom neuen Fusion 3 bekommt man aktuell 1 Jahr gratis.

    Das ist hier der Vollständigkeit halber evtl. eine Erwähnung wert.

    PS: Habs noch nicht getestet, aber wird wohl ähnlich funktionieren.

  17. @Achim – Das ist ja mal was ganz Neues. Ich denke, so pauschal lässt sich die Behauptung wohl kaum halten, denn wenn Server A gerade am Limit ist, hingegen Server B, auf dem sich das Gros an Daten befindet, ordentlich arbeitet, verzögert sich der Aufbau, da der Zugriff auf Server A eingeschränkt ist. Oder liege ich da jetzt vollkommen daneben?

    Was Tim schreibt, ist richtig. Stichwort Performance bzw. Content Delivery Network bzw. die Fähigkeit der Browser, eine bestimmte Anzahl paralleler Downloads von einer Domain zu verarbeiten. Daher werden Bilder, Stylesheet usw. bei Seiten wie amazon oder ebay von eigenen Domains (amazon-images.com, ebaystatic.com usw.) ausgeliefert. Falls du ein wenig Infos zum Thema brauchst, schaust du dir mal die Best Practices an.

    Wenn ein Server hingegen am Limit ist, dann hilft dir auch ein CDN nichts.

  18. Zum Thema, wo das externe CSS eingebunden werden soll. In der ursprünglichen Beta-Phase der WebFont-Software war es noch »scheinbar« egal. Auch jetzt wäre es logisch egal. Aber…

    dennoch ist es immer zu empfehlen solche Daten im Head-Bereich reinzuladen:
    1. semantisch ist dies der korrekte Weg
    2. ist es schneller, denn der Browser kann den HTTP-Request früher setzen und auswerten und somit das CSS parallel zum Seitenaufbau laden.

  19. weiß zufällig jemand wieviel es kostet, wenn man ca. 6 mio seitenaufrufe pro monat hat? multipliziert man dann einfach mit 20? wird’s teurer oder billiger? darf man dann die fonts auf eigenen servern ablegen?

Schreibe einen Kommentar

Die Netiquette ist zu beachten. Vor dem Hintergrund einer transparenten, sachlich-fairen Debatte wird die Nutzung eines Klarnamens empfohlen.

Folgende HTML-Elemente können verwendet werden: <b> <i> <img src="bildurl"> <a> <blockquote>

An den Anfang scrollen