@font-face-Einbettung von Fonts in Safari

[Lima]

Gibt es eigentlich eine Liste mit Schriften die es explizit erlauben das man sie in @font-face verwendet? Bei der Delicious steht es ja zum Beispiel schon in den Lizenzbedingungen.

Ich wollt noch anmerken das @font-facekeine Deklaration ist sondern eine At-Regel ist. Das ist durchaus ein Unterschied .

PS: Wer sich für die technische Umsetzung interessiert dem Hilft vielleicht mein kleines Essay über Web Fonts weiter.

Abgetrennt von hier.

[Ralf Herrmann]

Ich wollt noch anmerken das @font-facekeine Deklaration ist sondern eine At-Regel ist. Das ist durchaus ein Unterschied .

Jepp, aber AT-Regel würden 99 Prozent der Typografie.info-Leser nicht verstehen. :wink:

PS: Wer sich für die technische Umsetzung interessiert dem Hilft vielleicht mein kleines Essay über Web Fonts weiter.

Hast du vielleicht Lust, das wir das Thema mal in einem TypoWiki-Artikel zusammenstellen? Also Einsatzbeispiele, Beschreibung der Deskriptoren, Liste der verfügbaren Schriften, …

Und kannst du mir nochmal genau beschreiben, was an der Safari-Implementierung fehlerhaft ist?

Ralf

[Lima]

Jepp, aber AT-Regel würden 99 Prozent der Typografie.info-Leser nicht verstehen. :wink:

Na ob die mit einer Deklaration mehr anfangen können … :P. Wobei eine Deklaration zumindest vom Wort her bekannt sein sollte, darum hast du wohl Recht.

Hast du vielleicht Lust, das wir das Thema mal in einem TypoWiki-Artikel zusammenstellen? Also Einsatzbeispiele, Beschreibung der Deskriptoren, Liste der verfügbaren Schriften, …

Klar ich kann beizeiten mal einen Artikel schreiben den auch technisch nicht so versierte Typografen verstehen. Ich würde damit allerdings noch ein wenig warten. Die Technik steht noch am Anfang, die Vorgaben vom W3C sind zwar quasi schon durch aber was am Ende bei rauskommt kann man nur bedingt einschätzen. Mal schaun was sich in den nächsten Monaten so entwickelt. Wenn genug Wind gemacht wird dann baut das IE Team @font-face vielleicht ja sogar in den IE8 ein.

Ich werde auf jeden Fall am Ball bleiben und wenn genug Infos da sind schreib ich gerne eine Artikel.

Und kannst du mir nochmal genau beschreiben, was an der Safari-Implementierung fehlerhaft ist?

Also meine Beobachtung ist folgende:

Die Implementierung der Schnitte Roman, Bold, Italic, und Bold Italic läuft problemlos. So bald man aber via

@font-face {
font-family: Delicious;
src: url('fonts/delicious/Delicious-Italic.otf') format("opentype");
font-variant: small-caps;
}

der Kapitälchenschnitt eingefügt wird der Roman Schnitt plötzlich auch in Kapitälchen gesetzt. Auch ein font-variant: normal; im @font-face und in den CSS Eigenschaften der Roman Zeile behebt diesen Problem nicht.

Selbiges beim Heavyschnitt mit font-weight: 100;. Auch hier hat es Einfluss auf den Romanschnitt.

Kann auch sein das ich da einen Logikfehler übersehen habe aber für mich ist das klar ein Bug. Ich schau mir das mal Problem gesondert an und grenze es ein. Dann kann ich es genau beschreiben.

[Ralf Herrmann]

Ich würde damit allerdings noch ein wenig warten. Die Technik steht noch am Anfang, die Vorgaben vom W3C sind zwar quasi schon durch aber was am Ende bei rauskommt kann man nur bedingt einschätzen.

Eben weil’s noch am Anfang steht, sollte man es jetzt schon fördern und aktiv mitgestalten.

Den Small-Caps-Bug kann ich bestätigen. Wobei Kapitälchen im Web auch ein schwieriges Thema sind. Einerseits gibt’s die falschen Kapitälchen, dann die richtigen und dann auch noch den Kapitälcheneinzelschnitt (kodiert wie ein normaler Schnitt). Weiß jetzt selber gar nicht, wie man das unter einen Hut bringen soll, bzw. was font-variant: small-caps nun konkret bewirken soll.

Was Webkit beim Weight Matching macht kann ich nicht nachvollziehen. Auf jeden Fall stimmt da etwas nicht, da hast du ganz Recht. Aber ich komm nicht hinter die Logik, die da angewendet wird. Sag bescheid, wenn du’s rausbekommen hast.

Ralf

[Lima]

Eben weil’s noch am Anfang steht, sollte man es jetzt schon fördern und aktiv mitgestalten.

Immer in die richtige Kerbe :D. Das Problem ist halt das man im Moment nur wenig schreiben kann ohne in technische Details zu verfallen. Und die sind für ein TypoWiki ja eher weniger geeignet. Ich werde mal schaun was ich mir aus den Fingern saugen kann. Zwei Absätze und ein paar Links sind besser als nichts.

Den Small-Caps-Bug kann ich bestätigen. Wobei Kapitälchen im Web auch ein schwieriges Thema sind. Einerseits gibt’s die falschen Kapitälchen, dann die richtigen und dann auch noch den Kapitälcheneinzelschnitt (kodiert wie ein normaler Schnitt). Weiß jetzt selber gar nicht, wie man das unter einen Hut bringen soll, bzw. was font-variant: small-caps nun konkret bewirken soll.

Kapitälchen im Web sind wirklich ein Thema für sich. Allerdings dürfte es hier eigentlich überhaupt keine Überschneidungen geben. Der erste Absatz in meinem Beispiel bekommt als Fontangabe lediglich die Familie vom Body vererbt. Er hat also für font-variant den Standardwert "normal".

Das Problem ist also das der Safari font-variant nicht als Schrifteigenschaft versteht. Es wird also kein neuer Schnitt in die Datenbank geschmissen sondern der Roman Schnitt überschrieben.

Ich bau jetzt mal ein Testcase und geh dem auf den Grund …

[Lima]

Ok, jetzt hab ich es. Die Angaben von font-variant: small-caps; oder font-weight: *Zahl*; innerhalb von @font-face läst den Safari keinen neue Schriftschnitt in die Datenbank schreiben sondern er überschreibt einfach den bisher angegebenen Romanschnitt. Selbiges bei den font-stretch Angaben. Ist also kein wirklicher Bug sondern es sind einfach noch nicht alle Vorgaben eingebaut.

Das komische Ergebnis wenn man den Kapitälchenschnitt testet liegt einfach daran das er den geladenen Kapitälchenschnitt noch mal zusätzlich „in Kapitälchen setzt“. Den Typografen dürften bei dieser Abart wohl ganz anderes werden *g*.

Ich werde mal durchtesten was wirklich schon läuft. Ich glaube nicht das es viel mehr als die von mir erwähnten 4 Schnitte sind. Aber selbst das ist ja schon mehr als in den letzten 10 Jahren möglich war.

[Ralf Herrmann]

innerhalb von @font-face läst den Safari keinen neue Schriftschnitt in die Datenbank schreiben sondern er überschreibt einfach den bisher angegebenen Romanschnitt.

Aha! Klar, dann macht es plötzlich Sinn.

Genau diese Dinge sollte man mal zusammenfassen, damit nicht jeder Webdesigner wieder von vorn anfängt. Der Opera-Build scheint ja wieder andere Eigenschaften zu unterstützen. Safari beachtet beispielweise die unicode-range, Opera aber offenbar bislang nicht.

Ralf

[Lima]

Ok, ich seh schon das wird doch ein wenig aufwendiger. Unicode-range hab ich mir bisher noch nicht angesehen, sollte aber natürlich auch erwähnt werden.

Allerdings lasse ich Opera erst einmal aussen vor. Die 9.27 beherscht doch noch überhaupt kein @font-face, oder? Nightly Builds o. ä. mit einzubeziehen wäre ein wenig viel. Da ändert sich laufend was und es würde den Webentwicklern auch nicht wirklich helfen.

[Ralf Herrmann]

Hier gibts auch ein paar Antworten: :D

http://developer.apple.com/documentatio ... 1266-Fonts

[Lima]

Ja, aber nur zu Schrifteigenschaften von CSS 2.1. Die sind ja auch richtig implementiert. Die Probleme entstehen ja nur in Zusammenhang mit @font-face. Und davon steht in der Doku leider noch überhaupt nichts :(.

[Markus Wäger]

Hallo Leute,

der Fontblog hat heute einen Artikel mit dem Titel „Apple erklärt den Schriftentwerfern und -verlagen den Krieg« veröffentlicht. Ich finde die damit losgetretene Diskussion und eine Teil der Kommentare etwas …

Wie ich in meinem Kommentar geschrieben habe, ist es ja eh kein Problem an Fonts zu kommen, wenn man sie klauen will – auch ohne, dass ich das umständlich irgendwo raus rendere. Ich verstehe den Aufstand nicht ganz. Das einzige was alle, die dafür sind, dass die Leistungen der Schriftdesigner honoriert werden, ist doch einfach Bewusstsein schaffen.

Greetinx. Markus

[Ralf Herrmann]

Hallo Leute,

der Fontblog hat heute einen Artikel mit dem Titel „Apple erklärt den Schriftentwerfern und -verlagen den Krieg« veröffentlicht. Ich finde die damit losgetretene Diskussion und eine Teil der Kommentare etwas …

Naja, das ist ja auch ein bewusst provokanter Blog-Beitrag. Das muss ja entsprechende Diskussionen provozieren.

Die ersthaften Diskussionen zu dem Thema werden woanders geführt.

Wie ich in meinem Kommentar geschrieben habe, ist es ja eh kein Problem an Fonts zu kommen, wenn man sie klauen will – auch ohne, dass ich das umständlich irgendwo raus rendere. Ich verstehe den Aufstand nicht ganz. Das einzige was alle, die dafür sind, dass die Leistungen der Schriftdesigner honoriert werden, ist doch einfach Bewusstsein schaffen.

Das sehe ich nicht ganz so. »Bewusstsein schaffen« klingt immer toll, aber gibt es weniger Raucher, seit penetrant Bewusstsein für die Risiken geschaffen wurde? Sind Musikraubkopien passé, weil man Bewusstsein geschaffen hat, dass das illegal ist? Nicht wirklich.

Die beste Waffe gegen Musikdownloads war nicht Bewusstsein, sondern der Apple Music Store, mit seinem Konzept: mach es so einfach und günstig und schnell, dass man lieber einen Dollar ausgibt, als sich durch die entsprechenden Tauschbörsen zu quälen.

In gleicher Weise sollte man bei Fonts darüber nachdenken, ob das Webembedding nicht vielleicht andere, nutzerfreundlichere Lizenz- und Nutzungsmodelle zur Grundlage habe könnte.

Ralf

[Markus Wäger]

Ich sehe das nicht anders als du Ralf. Du hast (leider) recht – die meisten Leute sehen dich an, als kämest du von einem anderen Stern, wenn du dafür plädierst, dass man die Leistungen die der Schriftdesigner erbringt, auch bezahlt werden soll. Aber manchmal hört man ein leises Klick im Kopf des Gesprächspartner, und Mancheiner denkt zum ersten mal darüber nach, dass Schriften tatsächlich nicht auf Festplatten wachsen.

[Ralf Herrmann]

Ich hab mal eine Online-Umfrage zum Thema eingerichtet, die sich speziell an alle Webdesigner (egal ob privater Weblog oder Profi-Webdesigner) richtet: http://www.befrager.de/befragung.aspx?projekt=6743

Freue mich über rege Teilnahme!

[Poms]

Zur Umfrage: Der Punkt das einige Foundries die Fonts auf deren Server stellen und diese von dort abgerufen werden würden.

Hmm, das ist schwierig, da alle diese Foundries (auch die Kleinste …) garantieren müssten, das die Fonts IMMER verfügbar sind, bei Ausfällen ein 24 h Service aktiv ist, der z.B. Deutsch spricht. Das würde nicht nur die Kundenseite verschrecken, verunsichern, auch die Webdesigner.

[Ralf Herrmann]

Klar, dass das ein Punkt ist, über den man disktutieren muss.

Aber: Was passiert denn schlimmstenfalls? Der Font wird nicht ausgeliefert und stattdessen greift der übliche Fallback-Mechanismus. Der Text fehlt dann nicht, sondern wird wie üblich in Verdana und Co. angezeigt. Da sowieso nicht alle Browser schlagartig diese Technik implementiert haben werden, sähe man dann gegebenenfalls die Webseite ein paar Stunden so, wie sie sowieso alle sehen, die einen Browser benutzen, der das gar nicht kann. Klingt für mich also nicht so dramatisch …

Ralf

[Poms]

Da man ja das Konzept des "Corporate Designs für alle Medien" verkauft, und nur deshalb die Argumentation – Kunde lizensiert Webschrift ( bzw. begleitende Printschrift ) – funktionieren kann, wäre das schon dramatisch. Klar, den Fallback gibt es immer, aber das ist ja hierfür kein Argument.

Für mich wird diese Methode erst dann wichtig, wenn diese Methode in allen User Agents, die Relevanz haben, (zumindest IE, Firefox, Safari, *) läuft. Vorher ist entweder die Zielgruppe "nur Mac" oder man experimentiert halt damit bzw. arbeitet bis zu diesem Zeitpunkt mit sIFR oder Flash-Only, oder Grafiken, um den User an die neuen Schriften (z.B. Graublau) zu "gewöhnen". Gerade in der Übergangszeit könnte das zu erheblich mehr Arbeitsaufwand für den Webdesigner führen, der natürlich dafür nicht adäquat bezahlt werden wird, was der "Stoßrichtung" an sich abträglich sein könnte.

Was ganz anderes: Warum gibt es eigentlich keine Georgia Print, lohnt sich das nicht für Ascender(?) oder hat das mit etwas Rechtlichem zu tun?

*Opera wird das ja wahrscheinlich auch recht schnell bieten. Was ist mit Camino?

[Jens Kutilek]

Warum gibt es eigentlich keine Georgia Print, lohnt sich das nicht für Ascender(?) oder hat das mit etwas Rechtlichem zu tun?

Miller ist doch Georgia Print, oder? ;)

[specimen=Georgia Print:3kfzrzhn]30461[/specimen:3kfzrzhn]

[Poms]

Ah danke Jens, ja hatte ich schon gehört, aber wieder vergessen.

[Ralf Herrmann]

Miller ist doch Georgia Print, oder? ;)

Interessant. Wusste ich auch noch nicht. Das macht sich ja super, wenn man ein CD macht, wo Web und Print gleichermaßen wichtig sind.

Aber zurück zum Thema, …

da alle diese Foundries (auch die Kleinste …) garantieren müssten, das die Fonts IMMER verfügbar sind,

Ich gehe nicht davon aus, dass in 5 Jahren jede kleine Foundry einen Webfont-Service hat. Entweder stürzt sich einer der großen Anbieter auf das Thema, oder aber es entwickeln sich ein ein oder zwei Webdienste, die das dann für alle anderen verwalten – sozusagen ein mywebfonts.com. :wink: So oder so wären diese Anbieter dann ja locker in der Lage, für ordentliche Verfügbarkeit und Server-Performance zu sorgen.

[Poms]

Wir reden ja noch am sogenannten blauen Tisch; nächster Punkt – das unterschiedliche Schriftenrendering in den Browsern.

Window Vista läuft ja vorallem bei Professionellen schlecht. Es werden massenhaft neue Notebooks ausgeliefert, die anstatt der "logischen" Win Vista-Version, das bewährte Win XP Professional installiert haben.

Also haben wir mindestens 3 Szenarien, die Safari Bildschirmglättung, die Windows-ohne (voreingestellte) Bildschirmglättung und die Vista (mit voreingestellter) Cleartype-Glättung.

Wie wir von den Vista-Schriften wissen, ohne eine Glättung sind diese nicht wirklich für das Web geeignet.

Nun, wie verhält es sich dann mit anderen (vermeintlich) fürs Web gemachten Schriften, wie sollen diese die Hürde nehmen – man stelle sich vor @font-face funktioniert in den genannten relevanten Browsern? Wird dann mit dem nächsten IE-Sicherheitsupdate Cleartype automatisch aktiviert? :o Wie kann man für unterschiedliche Bildschirmglättungsverfahren Fonts optimieren? Gibt es bis dahin völlig neue Monitor mit "brutal hoher Auflösung" mit der ich dann auch eine "Didot in 14pt" sauber darstellen kann, somit keine "Webfonts" mehr gebraucht werden?

[Sebastian Nagel]

Also haben wir mindestens 3 Szenarien, die Safari Bildschirmglättung, die Windows-ohne (voreingestellte) Bildschirmglättung und die Vista (mit voreingestellter) Cleartype-Glättung.

Das stimmt nicht ganz: XP hat durchaus Schrift-Antialiasing standardmäßig aktiviert, nur eben nicht Cleartype. Wahrscheinlich, weil zu Erscheinen von XP TFT-Monitore noch nicht *so* verbreitet waren, und Cleartype auf CR-Röhre macht sich schlecht.

[Ralf Herrmann]

MS pusht das Thema Cleartype ja schon von sich aus. Vista hat es standardmäßig an, der IE7 auch, glaube selbst wenn es im System nicht aktiv ist. In ein paar Jahren hat es sich dann endgültig durchgesetzt und die Röhren sind dann auch weg.

Wenn ich über @font-face-Einbettung nachdenke, dann eh 2 bis 5 Jahren in die Zukunft gedacht. Insofern passt das schon.

Ich bastel ja schon testhalber an einem Webfont-vom-Fontserver-Einbindungs-Skript. Das unterscheidet auch den User Agent schon. Ist also auch kein Problem, Font und CSS-Deklarationen exakt auf den Client zuzuschneidern bzw. diesen auszuschließen, wenn die Darstellungsqualität zu schlecht wäre.

Wir müssen wohl erst mal eine Schalte-Cleartype-an-Aktion im TV starten. :wink:

Ralf

[Poms]

>XP hat durchaus Schrift-Antialiasing standardmäßig aktiviert

Schriftenglättung in XP namens "Standard":

Bei einer im Browser groß anzeigten Schrift wird diese deutlich wahrnehmbar geglättet, aber bei einer Verdana 10px wird diese nicht offensichtlich geglättet, sie erscheint ungeglättet. Das meinen die unbedarften User mit – die Schrift ist in Windows so schön scharf –, also beispielsweise eine Verdana oder Arial.

Vorallem wenn man das mit der Glättung von Cleartype oder gar Safari vergleicht.

Haben wir es so gesehen nicht mit mindestens 3 ziemlich unterschiedlichen Schriftglättungs-Konzepten zu tun? Wie gesagt die Vista Schriften funktionieren erst mit Cleartype zufriedenstellend und wahrscheinlich auch mit Safari einigermaßen, aber nicht mit der Default-Schriftenglättungseinstellung (für alle Größen) in Win XP.

[Poms]

Vista hat Cleartype standardmäßig an, der IE7 auch, glaube selbst wenn es im System nicht aktiv ist.

Gerade ausprobiert, WOW, echtes WOW, da ich immer Cleartype aktiviert habe, hab ich dieses Feature nicht bemerkt, da ja sowieso alles Cleartype-geglättet war bzw. ich den IE 7 nur zum testen benutze.