Catalina bietet eine neue einheitliche variable Systemschriftart für macOS.
Im Abschnitt „system-ui“ der CSS Fonts Module Level 4-Spezifikation wird das Schriftschnitt-Keyword system-ui definiert. Damit können Entwickler die integrierte, turbooptimierte, lokalisierte, hochqualitative und ohne Download verfügbare Standardschriftart des Betriebssystems direkt auf ihren Websites und in ihren Apps verwenden.
body {
font-family: system-ui;
}
Diese Typografie-Auswahl entspricht der Anweisung „Verwende die Standardsystemschriftart für die aktuelle Sprache dieses Nutzers“.
Unter macOS ist die Schriftart system-ui „San Francisco“. Diese Schriftart wurde von einem Designteam geprüft, getestet und vor Kurzem aktualisiert. Zuerst sprechen wir über die neuen Funktionen für variable Schriftarten in Catalina, dann sprechen wir über einige Fehler und wie die Chromium-Entwickler sie behoben haben.
In diesem Beitrag wird davon ausgegangen, dass Sie mit variablen Schriftarten vertraut sind. Falls nicht, sehen Sie sich den Artikel Einführung in variable Schriftarten im Web und das Video unten an.
Browserkompatibilität
Zum Zeitpunkt der Erstellung dieses Artikels wird system-ui von Chromium (seit Version 56), Edge (seit Version 79), Safari (seit Version 11) und Firefox (seit Version 43) unterstützt, aber nur mit dem Keyword -apple-system. Aktuelle Informationen finden Sie unter Kann ich variable Schriftarten verwenden?
Neue Kräfte
Die neuen Funktionen, die Catalina für das System-Schriftbild eingeführt hat, sind ab Chromium 83 für Webentwickler verfügbar. Die Schriftart system-ui bietet jetzt mehr variable Einstellungen: optische Größenanpassung und zwei individuelle Gewichtsanpassungen:
h1 { font-family: system-ui; font-weight: 700; font-variation-settings: 'wght' 750 ; }
h1 { font-family: system-ui; font-weight: 700; font-variation-settings: 'wght' 750, 'opsz' 20, 'GRAD' 400, 'YAXS' 400 ; }
Unter Mojave ist system-ui eine variable Schriftart mit nur wght Einstellungen. system-ui in Catalina ist eine variable Schriftart mit den Einstellungen wght, opsz, GRAD und YAXS.
Das sind für mich gute Möglichkeiten für ein Design mit progressiver Verbesserung. Sie können sich auch eingehend mit den Feinheiten der Systemschriftart befassen.
wght
Die Schriftstärke kann zwischen 0 und 900 liegen und wird auf alle Zeichen angewendet.
/* 0-900 */
font-variation-settings: 'wght' 750;
opsz
Die optische Abmessung ähnelt der Unterschneidung oder des Buchstabenabstands, allerdings werden die Abstände vom menschlichen Auge statt durch eine Berechnung vorgenommen. Ein Wert von 19 oder niedriger ist für den Abstand zwischen Text und Fließtext vorgesehen, während 20 oder höher für den Abstand zwischen Überschriften und Titeln bestimmt ist.
/* 19 or 20 */
font-variation-settings: 'opsz' 20;
GRAD
Ähnlich wie „Gewicht“, aber ohne Einfluss auf den horizontalen Abstand. Es sind Werte zwischen 400 und 1000 zulässig.
/* 400-1000 */
font-variation-settings: 'GRAD' 500;
YAXS
Streckt die Glyphe vertikal. Es sind Werte zwischen 400 und 1000 zulässig.
/* 400-1000 */
font-variation-settings: 'YAXS' 500;
Optionen kombinieren
Mit ein paar CSS-Zeilen können wir die Schriftarteinstellungen fett formatieren oder andere interessante Kombinationen ausprobieren:
font-weight: 700;
font-weight: bold;
font-variation-settings: 'wght' 750, 'YAXS' 600, 'GRAD' 500, 'opsz' 20;
Und schon sehen Chromium-Nutzer unter macOS deine aktualisierte, benutzerdefinierte 750er-Schriftart mit einigen weiteren Optimierungen. 👍
Spielplatz
Klicke unten im Glitch unten auf Remix to Edit (Zum Bearbeiten Remix), um eine bearbeitbare Kopie des Glitch zu erhalten, und bearbeite dann die neuen font-variation-settings-Optionen, um zu sehen, wie sich dies auf deine Schriftart auswirkt. Dieser Glitch funktioniert nur, wenn du ein macOS Catalina-Gerät verwendest.
In macOS 10.15 wurden dem Systemschriftschnitt neue Funktionen hinzugefügt. In macOS 10.15 wurde im Chromium-Bug-Tracker ein schwieriger system-ui-Fehler protokolliert. Ich frage mich, ob sie verwandt sind.
Anhang: Die system-ui-Regression
Dieser Fall beginnt mit einem anderen Fehler: #1005969. Dieser Fehler wurde für macOS 10.15 gemeldet, da der Schriftabstand von system-ui schmal und überladen wirkte.
Hintergrund
Haben Sie schon einmal bemerkt, dass in macOS 10.14 Ihre Absätze oder Überschriften zu einer anderen Schriftart „gewechselt“ sind, wenn die Größe erhöht oder verringert wurde?
In Mojave (macOS 10.14) wechselte die Schriftart system-ui je nach Zielschriftgröße zwischen zwei Schriftarten. Wenn Text unter 20px lag, wurde von macOS „San Francisco Text“ verwendet. Wenn der Text 20px oder mehr war, wurde von macOS „San Francisco Display“ verwendet. Die optische Größenanpassung wurde statisch in zwei separate Schriftarten integriert.
Catalina (macOS 10.15) enthält eine neue einheitliche variable Schriftart für San Francisco. „Text“ und „Anzeige“ können nicht mehr verwaltet werden. Außerdem wurde die neue Varianteinstellung opsz hinzugefügt, die oben beschrieben wurde.
h1 {
font-variation-settings: 'opsz' 20;
}
Leider ist der Standardwert für opsz in der neuen Catalina-Schrift 20 und die Chromium-Entwickler waren nicht bereit, opsz auf die Systemschrift anzuwenden. Das führte dazu, dass kleinere Größen zu schmal angezeigt wurden.
Um das Problem zu beheben, musste Chromium opsz richtig auf die Systemschriftart anwenden. Dadurch konnte Problem 1005969 behoben werden. Volltreffer! Oder war es…?
Noch nicht erledigt
Hier wurde es knifflig: Chromium hat opsz angewendet, aber etwas sah immer noch nicht richtig aus. Systemschriften auf dem Mac haben eine zusätzliche Schrifttabelle namens trak, mit der der horizontale Abstand angepasst wird. Bei der Fehlerbehebung stellten die Chromium-Entwickler fest, dass unter macOS die trak-Messwerte beim Abrufen horizontaler Messwerte aus einem CTFontRef-Objekt bereits in die Messergebnisse einbezogen wurden. Für die Formbibliothek HarfBuzz von Chromium sind Messwerte erforderlich, bei denen die trak-Werte noch nicht berücksichtigt wurden.
Intern verwendet Skia (die Grafikbibliothek und nicht die Schriftart mit demselben Namen) sowohl die Klasse CGFontRef aus CoreGraphics als auch die Klasse CTFontRef aus CoreText. Aufgrund der erforderlichen internen Konvertierungen zwischen diesen Objekten (zur Wahrung der Abwärtskompatibilität und zum Zugriff auf die erforderlichen APIs in beiden Klassen) gingen in bestimmten Fällen Informationen zum Gewicht verloren und Fettdruckschriften funktionierten nicht mehr. Dieses Problem wurde unter Issue 1057654 erfasst.
Skia muss macOS 10.11 weiterhin unterstützen, da Chromium dies weiterhin unterstützt. In Version 10.11 waren die Schriftarten „San Francisco Text“ und „San Francisco Display“ noch keine variablen Schriftarten. Stattdessen war jede Schriftart eine Familie mit separaten Schriftschnitten für jede verfügbare Stärke. Irgendwann waren die Glyphen-IDs nicht mehr miteinander synchronisiert. Wenn Skia also die Textformatierung (Umwandlung von Text in Glyphen, die gezeichnet werden können) mit „San Francisco Text“ durchführt, würde es unleserlich, wenn es mit „San Francisco Display“ gezeichnet würde, und umgekehrt. Und selbst wenn Skia nur nach einer anderen Größe gefragt hat, wechselt macOS möglicherweise zur anderen. Es sollte möglich sein, immer eine der Schriftarten zu verwenden und sie einfach zu skalieren (mit einer Matrix, um sie zu vergrößern, anstatt eine größere Größe anzufordern). Bei CoreText gibt es jedoch ein Problem, bei dem sbix-Glyphen (farbige Emojis) nicht vergrößert, sondern nur verkleinert werden. Es ist etwas komplizierter. CoreText scheint die vertikale Ausdehnung nach der Matrixanwendung zu begrenzen, was damit zusammenhängt, dass Emojis nicht in einem Winkel von 45 Grad gezeichnet werden können. Wenn Sie möchten, dass Ihr Emoji groß angezeigt wird, müssen Sie in jedem Fall eine Kopie der Schriftart erstellen, um eine große Version zu erhalten.
Um intern Kopien von CTFont-Objekten in verschiedenen Größen zu erstellen und gleichzeitig dafür zu sorgen, dass dieselben zugrunde liegenden Schriftdaten verwendet werden, hat Chromium die CGFont aus der CTFont entfernt und dann eine neue CTFont aus der CGFont erstellt. CGFont-Objekte sind größenabhängig, die magische Umschaltung erfolgt auf CoreText-Ebene. Das hat bis Version 10.154 gut funktioniert. In 10.15 wurden bei dieser Rundreise zu viele Informationen verloren, was zu dem Gewichtsproblem führte. Flutter hat das Gewichtsproblem erkannt und eine alternative Lösung für die Größenanpassung wurde vorgenommen, um das neue CTFont direkt aus dem ursprünglichen CTFont zu erstellen und die optische Größe direkt mit einem alten, aber nicht dokumentierten Attribut in CoreText zu steuern. Dadurch funktioniert die Funktion unter 10.11 weiterhin und andere Probleme werden behoben, z. B. das explizite Festlegen der optischen Größe auf den Standardwert.
Dadurch bleibt jedoch mehr von der „Magie“ von CoreText in der Schrift erhalten. Eine davon besteht darin, dass die Glyphenabstände nicht nur über die trak-Tabelle angepasst werden (deren Anwendung in Chromium bereits durch ein weiteres nicht dokumentiertes Attribut unterdrückt wurde).
CGFont führt keine dieser „magischen“ Aktionen aus. Könnte Chromium die CGFont aus der CTFont entfernen und sie nur verwenden, um Fortschritte zu erzielen? Das würde leider nicht funktionieren, da CoreText bekanntermaßen auch andere Schriftarten verwendet. So werden kleine Emojis beispielsweise etwas größer als von Ihnen gewünscht (verringert sich etwas größer). CGFont weiß das nicht und würde die sbix-basierten Emojis zu nah beieinander platzieren, da Sie sie in einer bestimmten Größe messen, CoreText sie aber etwas größer zeichnet. Chromium möchte, dass die CTFont Fortschritte gemacht werden, aber ohne Nachverfolgung und vorzugsweise ohne weitere mühselige Aktivitäten.
Da die Behebung des Abstandsproblems eine Reihe miteinander verbundener Blink- und Skia-Fehlerkorrekturen erforderte, konnten die Chromium-Entwickler das Problem nicht einfach rückgängig machen. Die Chromium-Entwickler haben auch versucht, ein anderes Build-Flag zum Ändern eines schriftbezogenen Codepfads in Skia zu verwenden. Dadurch wurde das Problem mit fett formatierten Schriftarten behoben, aber das Problem mit dem Abstand verschlechterte sich.
Lösung
Letztendlich wollte Chromium natürlich beide Probleme beheben. Chromium nutzt jetzt die in HarfBuzz integrierten OpenType-Messwertfunktionen für Schriftarten, um horizontale Messwerte direkt aus den Binärdaten in den Schriftartentabellen der Systemschrift abzurufen. So umgeht Chromium CoreText und Skia, wenn die Schriftart eine trak-Tabelle hat (außer bei der Emoji-Schriftart).
In der Zwischenzeit gibt es immer noch das Skia-Problem Nr. 10123, das die Behebung dieses Problems vollständig in Skia verfolgt und wieder Skia verwendet, um die Systemschriftmesswerte von dort abzurufen, anstatt der aktuellen Korrektur, die HarfBuzz durchläuft.