Catalina bietet unter macOS eine neue Systemschriftart für einheitliche Variablen.
Im Abschnitt 'system-ui' der Spezifikation des Moduls für CSS-Schriftarten wird ein system-ui-Schriftart-Keyword definiert, mit dem Entwickler die integrierte, turbooptimierte, lokalisierte und Mega-hochwertige Standard-Betriebssystemschriftart, die keinen Download benötigt, direkt auf ihren Websites und in ihren Apps verwenden können.
body {
font-family: system-ui;
}
Diese Typografie entspricht etwa dem Befehl „Verwenden Sie die Standard-Systemschriftart für das aktuelle Gebietsschema dieses Benutzers“.
Unter macOS lautet die Schriftart system-ui „San Francisco“. Diese Schriftart wurde von einem Designteam geprüft, getestet und vor Kurzem aktualisiert. Zunächst behandeln wir die neuen spannenden Schriftartfunktionen für Variablen in Catalina. Anschließend sprechen wir über einige Fehler und wie Chromium-Entwickler sie gelöst haben.
In diesem Beitrag wird davon ausgegangen, dass Sie bereits mit variablen Schriftarten vertraut sind. Falls nicht, sehen Sie sich die Einführung in variable Schriftarten im Web und das Video unten an.
Browserkompatibilität
Zum Zeitpunkt der Erstellung dieses Artikels unterstützt system-ui Chromium (seit 56), Edge (seit 79), Safari (seit 11) und von Firefox (seit 43), aber mit dem Schlüsselwort -apple-system. Weitere Informationen finden Sie unter Kann ich variable Schriftarten verwenden?.
Neue Kräfte
Die neuen Funktionen, die Catalina für die Systemschriftart eingeführt hat, stehen Webentwicklern ab Chromium 83 zur Verfügung. Die Schriftart system-ui verfügt jetzt über mehr variable Einstellungen: optische Größe 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
;
}
Auf Mojave ist system-ui eine variable Schriftart mit nur wght-Einstellungen. Während system-ui in Catalina eine variable Schriftart mit den Einstellungen wght, opsz, GRAD und YAXS ist.
Für mich sind das ein paar tolle Progressive-Enhancement-Designmöglichkeiten! Werfen Sie einen Blick auf die Feinheiten der Systemschrift, wenn Sie möchten.
wght
Akzeptiert eine Schriftstärke zwischen 0 und 900 und wird gleichmäßig auf alle Zeichen angewendet.
/* 0-900 */
font-variation-settings: 'wght' 750;
opsz
Die optische Größenanpassung ist vergleichbar mit der Unterschneidung oder dem Abstände zwischen Buchstaben, aber die Abstände werden von einem menschlichen Auge statt durch Mathematik vorgenommen. Ein Wert von 19 oder darunter ist für den Abstand zwischen Text und Text vorgesehen, während 20 oder höher für den Abstand zwischen Anzeigeüberschriften und Titeln vorgesehen ist.
/* 19 or 20 */
font-variation-settings: 'opsz' 20;
GRAD
Ähnlich wie Gewicht, aber ohne horizontale Abstände zu berühren. Es werden Werte zwischen 400 und 1000 akzeptiert.
/* 400-1000 */
font-variation-settings: 'GRAD' 500;
YAXS
Dehnt das Symbol vertikal aus. Es werden Werte zwischen 400 und 1000 akzeptiert.
/* 400-1000 */
font-variation-settings: 'YAXS' 500;
Optionen kombinieren
Mit ein paar Zeilen CSS können wir die Schriftarteinstellungen in eine Fettschrift unserer Wahl ändern 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 die verbesserte, benutzerdefinierte Gewichtung von 750 und ein paar andere Änderungen. 👍
Spielplatz
Klicke unten im Glitch auf Zu bearbeitende Remixe, um eine bearbeitbare Kopie des Glitches zu erhalten. Bearbeite dann die neuen font-variation-settings-Optionen, um zu sehen, wie sich das auf die Schriftart auswirkt. Denk daran, dass diese Störung nur funktioniert, wenn du ein macOS Catalina-Gerät verwendest.
Unter macOS 10.15 wurden der Systemschriftart neue Funktionen hinzugefügt. Unter macOS 10.15 wurde im Chromium-Programmfehler-Tracker ein kniffliger system-ui-Fehler protokolliert. Gibt es einen Zusammenhang?
Anhang: Die system-ui-Regression
Diese Story beginnt mit einem anderen Fehler: #1005969. Dies wurde gegen macOS 10.15 gemeldet, weil der Schriftabstand von system-ui schmal und überladen wirkte.
Hintergrund
Ist Ihnen unter macOS 10.14 schon einmal aufgefallen, dass Ihre Absätze oder Überschriften beim Ändern der Schriftgröße an eine andere Schriftart angedockt wurden?
In Mojave (macOS 10.14) wechselt die Schriftart system-ui je nach Zielschriftgröße zwischen zwei Schriftarten. Wenn der Text unter 20px war, hat macOS „San Francisco Text“ verwendet. Wenn der Text 20px oder größer war, hat macOS „San Francisco Display“ verwendet. Die optische Größe wurde statisch in zwei verschiedene Schriftarten integriert.
Catalina (macOS 10.15) hat eine neue Schriftart für einheitliche Variablen für San Francisco veröffentlicht. „Text“ und „Display“ müssen nicht mehr verwaltet werden. Außerdem wurde die zuvor beschriebene Einstellung der Variante opsz übernommen.
h1 {
font-variation-settings: 'opsz' 20;
}
Leider lautet der Standardwert für opsz in der neuen Schriftart Catalina 20 und die Chromium-Entwickler waren nicht bereit, opsz auf die Systemschriftart anzuwenden. Dadurch wurden kleinere Anzeigen zu schmal dargestellt.
Um dies zu beheben, musste Chromium opsz richtig auf die Systemschrift anwenden. Dadurch wurde Problem #1005969 behoben. Gewonnen! Oder war das...?
Noch nicht erledigt
Hier wurde es schwierig: Chromium hat opsz angewendet, aber irgendetwas sah immer noch nicht richtig aus. Systemschriftarten auf Mac-Computern haben eine zusätzliche Schrifttabelle namens trak, in der der horizontale Abstand optimiert wird. Bei der Arbeit an der Lösung stellten Chromium-Entwicklern fest, dass die trak-Messwerte unter macOS beim Abrufen horizontaler Messwerte aus einem CTFontRef-Objekt bereits in den Messwertergebnissen berücksichtigt wurden. Für die Formbibliothek HarfBuzz von Chromium sind Messwerte erforderlich, bei denen die Werte für trak noch nicht berücksichtigt sind.
Intern verwendet Skia (die Grafikbibliothek, nicht das Schriftbild desselben Namens) sowohl die CGFontRef-Klasse aus CoreGraphics als auch die CTFontRef-Klasse aus CoreText. Aufgrund der erforderlichen internen Konvertierungen zwischen diesen Objekten (für die Aufrechterhaltung der Abwärtskompatibilität und den Zugriff auf benötigte APIs in beiden Klassen) ging Skia unter bestimmten Umständen Gewichtsinformationen verloren und fett formatierte Schriftarten funktionierten nicht mehr. Dies wurde unter Problem Nr. 1057654 beobachtet.
Skia muss macOS 10.11 weiterhin unterstützen, da Chromium es immer noch unterstützt. Am 10.11 waren die Schriftarten "San Francisco Text" und "San Francisco Display" noch nicht einmal variable Schriftarten. Es handelte sich vielmehr um eine Familie separater Schriftarten für jede verfügbare Schriftstärke. Irgendwann wurden die Glyphen-IDs nicht mehr synchron. Wenn Skia also Textformen (Text in gezeichnete Glyphen) mit „San Francisco Text“ umwandelt, wäre es unsinnig, wenn er mit „San Francisco Display“ gezeichnet würde, und umgekehrt. Und selbst wenn Skia gerade nach einer anderen Größe gefragt hat, kann macOS zur anderen wechseln. Es sollte möglich sein, immer eine der Schriftarten zu verwenden und sie einfach zu skalieren (mithilfe einer Matrix, um sie zu vergrößern, anstatt eine größere Größe zu verlangen). CoreText hat jedoch ein Problem, bei dem Sbix-Glyphen (Farb-Emojis) nicht nach oben (nur nach unten) skaliert werden. Es ist etwas komplexer. CoreText scheint nach der Matrixanwendung die vertikale Ausdehnung zu begrenzen, was damit zusammenhängt, dass keine Emojis bei 45-Grad-Winkeln gezeichnet werden können. Wenn Ihr Emoji groß dargestellt werden soll, müssen Sie auf jeden Fall eine Kopie der Schriftart erstellen, um eine größere Version zu erhalten.
Um also intern Kopien von CTFont-Objekten in unterschiedlichen Größen zu erstellen und gleichzeitig sicherzustellen, dass dieselben zugrunde liegenden Schriftdaten verwendet werden, hat Chromium das CGFont aus dem CTFont abgerufen und dann ein neues CTFont aus dem CGFont erstellt. CGFont-Objekte sind größenunabhängig, der magische Wechsel erfolgt auf CoreText-Ebene. Dies funktionierte bis 10.154 problemlos. In 10:15 ging dieser Umlauf zu viele Informationen verloren, was zu einem Gewichtsproblem führte. Flutter bemerkte das Gewichtungsproblem und eine alternative Korrektur der Größenänderung wurde vorgenommen, um die neue CTFont direkt aus dem ursprünglichen CTFont zu erstellen und die optische Größe direkt über ein altes, aber undokumentiertes Attribut in CoreText zu steuern. Dadurch funktioniert das System weiterhin in Version 10.11 und es werden andere Probleme behoben, z. B. das explizite Einstellen der optischen Größe auf den Standardwert.
Dadurch bleibt jedoch mehr von der „Magie“ von CoreText in der Schriftart erhalten. Einer davon scheint, dass die Glyphe auf andere Weise weiter optimiert wird als nur in der Tabelle trak (die Anwendung, die Chromium bereits durch ein weiteres undokumentiertes Attribut zu unterdrücken versuchte).
CGFont kann diese „Magie“ nicht ausführen. Vielleicht könnte Chromium das CGFont also aus dem CTFont entfernen und es einfach nutzen, um Fortschritte zu erzielen? Das würde leider nicht funktionieren, da CoreText bekanntermaßen auch Schriftarten auf andere Weise vermischt. So werden beispielsweise kleine Emojis etwas größer, als Sie eigentlich angefordert haben. CGFont weiß das nicht. Deshalb würden die Sbix-basierten Emojis am Ende zu dicht beieinander liegen, da Sie nur eine Größe messen, aber CoreText sie um eine bestimmte Größe vergrößern würde. Chromium möchte die CTFont-Fortschritte zwar, aber ohne Tracking und vorzugsweise ohne jegliches Nachdenken.
Da für die Behebung des Abstandsproblems eine Reihe miteinander verbundener Blink- und Skia-Korrekturen erforderlich waren, konnten die Chromium-Entwickler das Problem nicht einfach rückgängig machen. Die Chromium-Entwickler haben auch versucht, zum Ändern eines schriftbezogenen Codepfads in Skia ein anderes Build-Flag zu verwenden, wodurch das Problem mit fett gedruckten Schriftarten behoben, aber das Abstandsproblem inzwischen behoben wurde.
Lösung
Letztendlich wollte Chromium natürlich beides beheben. Chromium nutzt jetzt die in HarfBuzz integrierten Schriftartfunktionen von OpenType-Schriftarten, um horizontale Messwerte direkt aus den Binärdaten in den Schriftartentabellen des Systems abzurufen. In diesem Fall umgeht Chromium CoreText und Skia, wenn die Schriftart eine trak-Tabelle enthält (außer bei der Emoji-Schriftart).
In der Zwischenzeit gibt es noch das Skia-Problem Nr. 10123, um dieses Problem vollständig in Skia zu beheben und wieder Skia zu verwenden, um die Messwerte für die Systemschriftarten von dort abzurufen, anstatt die aktuelle Korrektur für HarfBuzz zu verwenden.