Mit Catalina wird eine neue einheitliche variable Systemschriftart in macOS eingeführt.
Im Abschnitt „system-ui“ der CSS Fonts Module Level 4-Spezifikation wird das Schriftart-Keyword system-ui
definiert. Damit können Entwickler die integrierte, turbooptimierte, lokalisierte, qualitativ hochwertige Standardschriftart des Betriebssystems direkt auf ihren Websites und in ihren Apps verwenden, ohne sie herunterladen zu müssen.
body {
font-family: system-ui;
}
Diese typografische Entscheidung entspricht der Aussage „Verwende die Standardsystemschriftart für das aktuelle Gebietsschema 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 werden wir die neuen, spannenden Funktionen für variable Schriftarten in Catalina vorstellen und dann auf einige Fehler und die Art und Weise eingehen, wie die Chromium-Entwickler sie behoben haben.
In diesem Beitrag wird davon ausgegangen, dass Sie bereits mit variablen Schriftarten vertraut sind. Falls nicht, sehen Sie sich Einführung in variable Schriftarten im Web und das Video unten an.
Browserkompatibilität
Zum Zeitpunkt der Erstellung dieses Dokuments wird system-ui
von Chromium (seit Version 56), Edge (seit Version 79), Safari (seit Version 11) und Firefox (seit Version 43) unterstützt, allerdings mit dem Keyword -apple-system
. Aktuelle Informationen finden Sie unter Kann ich variable Schriftarten verwenden?.
Neue Funktionen
Die neuen Funktionen, die Catalina für die Systemschriftart 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 einzigartige 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
unter Catalina ist eine variable Schriftart mit den Einstellungen wght
, opsz
, GRAD
und YAXS
.
Das sieht für mich nach einigen interessanten Möglichkeiten für Progressive Enhancement aus. Wenn Sie möchten, können Sie sich genauer mit den Feinheiten der Systemschriftart befassen.
wght
Akzeptiert eine Schriftstärke zwischen 0
und 900
und wird auf alle Zeichen angewendet.
/* 0-900 */
font-variation-settings: 'wght' 750;
opsz
Die optische Größenanpassung ähnelt dem Kerning oder dem Buchstabenabstand, aber der Abstand wird vom menschlichen Auge und nicht durch mathematische Berechnungen bestimmt. Ein Wert von 19
oder darunter ist für den Abstand von Text und Fließtext vorgesehen, während 20
oder darüber für den Abstand von Überschriften und Titeln verwendet wird.
/* 19 or 20 */
font-variation-settings: 'opsz' 20;
GRAD
Ähnlich wie „Gewicht“, aber ohne die horizontale Breite zu verändern. Es werden Werte zwischen 400
und 1000
akzeptiert.
/* 400-1000 */
font-variation-settings: 'GRAD' 500;
YAXS
Dehnt das Symbol vertikal. Es werden Werte zwischen 400
und 1000
akzeptiert.
/* 400-1000 */
font-variation-settings: 'YAXS' 500;
Optionen kombinieren
Mit wenigen Zeilen CSS können wir die Schrifteinstellungen anpassen, z. B. die Schriftstärke ä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 Ihre aktualisierte, benutzerdefinierte Schriftstärke 750 mit einigen anderen interessanten Anpassungen. 👍
In macOS 10.15 wurden der Systemschriftart neue Funktionen hinzugefügt und in macOS 10.15 wurde ein schwieriger system-ui
-Fehler im Chromium-Bugtracker protokolliert. Ich frage mich, ob sie verwandt sind.
Anhang: Die system-ui
-Regression
Diese Geschichte beginnt mit einem anderen Fehler: #1005969. Dieser Fehler wurde für macOS 10.15 gemeldet, da der system-ui
-Schriftabstand schmal und gedrängt wirkte.

Hintergrund
Ist Ihnen unter macOS 10.14 schon einmal aufgefallen, dass sich die Schriftart Ihrer Absätze oder Überschriften geändert hat, wenn die Größe erhöht oder verringert wurde?
Unter Mojave (macOS 10.14) wurde für die Schriftart system-ui
je nach Zielschriftgröße zwischen zwei Schriftarten gewechselt. Wenn Text unter 20px
war, wurde unter macOS „San Francisco Text“ verwendet. Wenn der Text 20px
oder mehr Zeichen enthielt, wurde unter macOS „San Francisco Display“ verwendet. Die optische Größenanpassung wurde statisch in zwei separate Schriftarten integriert.
Mit Catalina (macOS 10.15) wurde eine neue kombinierte Variable Font für San Francisco eingeführt. Die Verwaltung von „Text“ und „Display“ ist nicht mehr erforderlich. Außerdem wurde die neue Einstellung für Varianten opsz
hinzugefügt, die oben beschrieben wird.
h1 {
font-variation-settings: 'opsz' 20;
}
Leider ist der Standardwert für opsz
in der neuen Catalina-Schriftart 20
und die Chromium-Entwickler waren nicht bereit, opsz
auf die Systemschriftart anzuwenden. Das führte dazu, dass kleinere Größen zu schmal dargestellt wurden.
Dazu musste Chromium opsz
korrekt auf die Systemschrift anwenden. Dadurch wurde Problem 1005969 behoben. Volltreffer! Oder war es…?
Noch nicht erledigt
Hier wurde es schwierig: Chromium hat opsz
angewendet, aber etwas sah immer noch nicht richtig aus. Systemschriftarten auf dem Mac haben eine zusätzliche Schriftarttabelle namens trak
, mit der der horizontale Abstand angepasst wird. Bei der Arbeit an der Korrektur stellten die Chromium-Entwickler fest, dass beim Abrufen horizontaler Messwerte aus einem CTFontRef
-Objekt unter macOS die trak
-Messwerte bereits in die Messergebnisse einbezogen wurden. Für die Shaping-Bibliothek HarfBuzz
von Chromium sind Messwerte erforderlich, bei denen die trak
-Werte noch nicht berücksichtigt sind.

Intern verwendet Skia (die Grafikbibliothek, nicht die gleichnamige Schriftart) sowohl die Klasse CGFontRef
aus CoreGraphics
als auch die Klasse CTFontRef
aus CoreText
. Aufgrund erforderlicher interner Konvertierungen zwischen diesen Objekten (die zur Aufrechterhaltung der Abwärtskompatibilität und zum Zugriff auf erforderliche APIs in beiden Klassen verwendet werden) würde Skia unter bestimmten Umständen Informationen zum Schriftgewicht verlieren und fette Schriftarten würden nicht mehr funktionieren. Dieses Problem wurde in Problem Nr. 1057654 nachverfolgt.
Skia muss macOS 10.11 weiterhin unterstützen, da Chromium es weiterhin unterstützt. Unter 10.11 waren die Schriftarten „San Francisco Text“ und „San Francisco Display“ nicht einmal variable Schriftarten. Stattdessen war jede Schriftart eine Familie separater Schriftarten für jedes verfügbare Gewicht. Irgendwann waren die Glyphen-IDs nicht mehr synchron. Wenn Skia also die Textformatierung (Umwandlung von Text in Glyphen, die gezeichnet werden können) mit „San Francisco Text“ durchführt, wäre das Ergebnis bei der Darstellung mit „San Francisco Display“ unverständlich und umgekehrt. Auch wenn Skia nur eine andere Größe angefordert hat, kann macOS zur anderen wechseln. 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 Schriftgröße anzufordern). Bei CoreText
gibt es jedoch ein Problem, bei dem die sbix-Glyphen (Farb-Emojis) nicht vergrößert, sondern nur verkleinert werden. Es ist etwas komplexer. CoreText
scheint die vertikale Ausdehnung nach der Anwendung der Matrix zu begrenzen. Das liegt wahrscheinlich daran, 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 sicherzustellen, dass dieselben zugrunde liegenden Schriftartdaten verwendet werden, hat Chromium die CGFont
aus dem CTFont
abgerufen und dann ein neues CTFont
aus dem CGFont
erstellt. CGFont
-Objekte sind größenunabhängig. Die Umstellung erfolgt auf CoreText
-Ebene. Bis zur Version 10.154 hat das auch funktioniert. In Version 10.15 ging bei diesem Roundtrip zu viel Information verloren, was zu dem Gewichtsproblem führte. Flutter hat das Problem mit dem Schriftgewicht erkannt und eine alternative Lösung für die Größenanpassung gefunden, um die neue CTFont
direkt aus der ursprünglichen CTFont
zu erstellen und die optische Größe direkt mit einem alten, aber nicht dokumentierten Attribut in CoreText
zu steuern. So funktioniert alles weiterhin unter 10.11 und andere Probleme werden behoben (z. B. das explizite Festlegen der optischen Größe auf den Standardwert).
Dadurch bleibt jedoch mehr von der CoreText
-Magie in der Schriftart erhalten. Einer dieser Gründe scheint zu sein, dass die Glyphenvorschübe auf eine andere Weise als nur über die trak
-Tabelle angepasst werden. Die Anwendung dieser Tabelle wurde von Chromium bereits durch ein weiteres undokumentiertes Attribut unterdrückt.
CGFont
macht nichts von dieser „Magie“. Vielleicht könnte Chromium CGFont
von CTFont
entfernen und es nur für die Vorschläge verwenden? Leider funktioniert das nicht, da CoreText
auch auf andere Weise Schriftarten manipuliert. So werden beispielsweise kleine Emojis etwas größer dargestellt, als Sie eigentlich angefordert haben. CGFont
weiß nichts davon. Daher würden die auf sbix basierenden Emojis zu nah beieinander liegen, da Sie sie in einer bestimmten Größe messen, CoreText
sie aber um einen bestimmten Betrag größer zeichnen würde. Chromium möchte die CTFont
-Innovationen, aber ohne Tracking und vorzugsweise ohne andere Manipulationen.
Da für die Behebung des Problems mit dem Abstand eine Reihe von miteinander verbundenen Blink- und Skia-Korrekturen erforderlich war, konnten die Chromium-Entwickler das Problem nicht einfach durch Zurücksetzen beheben. Die Chromium-Entwickler haben auch versucht, ein anderes Build-Flag zu verwenden, um einen schriftartbezogenen Codepfad in Skia zu ändern. Dadurch wurde das Problem mit den fettgedruckten Schriftarten behoben, aber das Problem mit dem Abstand trat wieder auf.
Die Korrektur
Letztendlich wollte Chromium natürlich beide Probleme beheben. Chromium greift jetzt auf die integrierten OpenType-Schriftartmesswertfunktionen von HarfBuzz zurück, um horizontale Messwerte direkt aus den Binärdaten in den Schriftarttabellen der Systemschriftart abzurufen. Dadurch umgeht Chromium CoreText
und Skia, wenn die Schriftart eine trak
-Tabelle hat (außer bei der Emoji-Schriftart).

In der Zwischenzeit gibt es weiterhin Skia-Problem 10123, um die vollständige Behebung dieses Problems in Skia zu verfolgen und wieder Skia zu verwenden, um die Systemschriftartmesswerte abzurufen, anstatt der aktuellen Lösung, die über HarfBuzz
erfolgt.