Typografie.info TypoForum

[(Name ausgeblendet)]

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.

[(Name ausgeblendet)]

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.

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

[(Name ausgeblendet)]

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

Na ob die mit einer Deklaration mehr anfangen können … . 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

Code: Alles auswählen

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

[(Name ausgeblendet)]

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

[(Name ausgeblendet)]

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

Immer in die richtige Kerbe . 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 …

[(Name ausgeblendet)]

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.

[(Name ausgeblendet)]

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

[(Name ausgeblendet)]

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.

[(Name ausgeblendet)]

Hier gibts auch ein paar Antworten:
http://developer.apple.com/documentatio ... 1266-Fonts

[(Name ausgeblendet)]

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 .

[(Name ausgeblendet)]

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

[(Name ausgeblendet)]

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

[(Name ausgeblendet)]

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.

[(Name ausgeblendet)]

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!

[(Name ausgeblendet)]

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.