Progressive Enhancement für Perfektionisten: Schriftmetriken im Griff
Wir haben vor Kurzem auf der Webseite unseres Kunden Staatstheater Darmstadt eine neue Version, d. h. aktualisierte Schriftdateien, der Web Font Avenir Next eingebunden. Dabei fiel uns auf, dass sich unerwarteterweise im Firefox-Browser die vertikale Positionierung von Text geändert hat.
Veröffentlicht am:2025-01-24
Besonders auffällig war das in einzeiligen Buttons und Badges, zwei UI-Komponenten mit einem Rahmen:
Andere Browser (Chrome, Edge, Safari) schienen nicht betroffen zu sein. Wie konnte das sein?
Vertikale Font Metriken
Dazu muss man etwas weiter ausholen. Jede Schriftdatei enthält eine Menge von Metadaten, darunter auch solche, die die vertikale Ausrichtung von Text beeinflussen. Aus historischen Gründen gibt es nicht weniger als drei Gruppen von Werten, die sich mit vertikalen Metriken befassen. Sie sind bekannt als hhea, typo (auch bekannt als sTypo oder OS/2) und win (oder usWin). Je nachdem, welche Kombination von Betriebssystem und Anwendung die Schrift gerade anzeigen soll, wird eine andere Gruppe für die Darstellung der Schrift auf dem Bildschirm verwendet. Das (englische) Tutorial Vertical metrics des Schriftarten-Editors Glyphs bietet exzellente Hintergrundinformationen zu diesem Thema.
Für uns ist vor allem relevant, wie sich Browser verhalten. Die Chrome Developer Dokumentation hat dafür eine gute Tabelle[1]:
| Browser | MacOS | Windows |
|---|---|---|
| Chromium | Uses metrics from hhea table. | Uses metrics from typo table if USE_TYPO_METRICS has been set, otherwise uses metrics from win table. |
| Firefox | Uses metrics from typo table if USE_TYPO_METRICS has been set, otherwise uses metrics from hhea table. | Uses metrics from typo table if USE_TYPO_METRICS has been set, otherwise uses metrics from win table. |
| Safari | Uses metrics from hhea table. | Uses metrics from typo table if USE_TYPO_METRICS has been set, otherwise uses metrics from win table. |
Die Metadaten lassen sich auf mehreren Wegen aus einer Schriftdatei auslesen[2], eine sehr einfache Option beschreibt Simon Hearne in seinem umfassenden Artikel:
- Schriftdatei auf https://fontdrop.info/ hochladen
- Das Tab "Data" öffnen
- Werte unter „hhea – Horizontal Header Table“ sowie „OS/2 – OS/2 and Windows Metrics Table“ auslesen
In unserem Fall finden wir für die neuen Dateien der Avenir Next heraus:
hhea – Horizontal Header Table
ascender: 978
descender: -250
lineGap: 0
unitsPerEm: 1000OS/2 – OS/2 and Windows Metrics Table
sTypoAscender: 758
sTypoDescender: -242
sTypoLineGap: 200
usWinAscent: 978
usWinDescent: 250Die Werte geben einen ersten Hinweis: die abweichenden sTypo*-Werte könnten erklären, warum sich Firefox anders verhält. Leider ist genau der Wert USE_TYPO_METRICS nicht in den von fontdrop.info gelieferten Daten enthalten. Visuell ist der Unterschied in einem reduzierten Test aber deutlich erkennbar:
| MacOS Firefox | MacOS Chrome |
|---|---|
 |  |
Die Lösung: Modernes CSS!
Das CSS Fonts Module Level 4 erlaubt das Überschreiben bestimmter Metriken aus der Schriftdatei. Inbesondere stehen uns für unser Problem ascent-override, descent-override und line-gap-override zur Verfügung. Die Spezifikation adressiert hauptsächlich Probleme beim Wechsel von einer Fallback-Font zur gewünschten Web Font; mit den genannten Eigenschaften kann eine Fallback-Font so an die Web Font angeglichen werden, dass kein sog. "flash of unstyled text" (FOUT) zu einem Layout Shift mit Abzügen im Core Web Vital "cumulative layout shift" (CLS) führt.
Die Metriken können aber eben auch als Progressive Enhancement für cross-browser-Ausgleiche einer Web Font eingesetzt werden. Progressive Enhancement deshalb, weil sie zwar nicht von allen Browsern unterstützt werden (Safari bildet hier die Ausnahme, alle anderen Hersteller haben zwischen 2020 und 2021 Versionen mit Support herausgebracht), ein Browser ohne Support aber einfach weiterhin die Werte aus der Schriftdatei nutzt.
Mit den CSS-Metriken können wir also bei der @font-face-Einbindung der Schriftdatei dafür sorgen, dass diese Werte von uns normalisiert werden. Wir nutzen dazu die ursprünglichen hhea-Werte[3]. Die Werte von ascent-override und descent-override werden in CSS in Prozent angegeben, negative Werte sind dabei nicht zulässig. Wir können aber den absoluten Wert des Descenders ohne Vorzeichen verwenden; bei unitsPerEm: 1000 ergeben sich der Formel[4] ascent-override = ascender/unitsPerEm entsprechend 978/1000 * 100%, also ascent-override: 97.8% und analog descent-override: 25%. Für line-gap-override: 0 ist keine Umrechnung nötig, sonst käme die gleiche Formel zum Einsatz.
Nach dem Eintragen der CSS-Metriken sieht unser Test so aus:
| MacOS Firefox | MacOS Chrome |
|---|---|
 |  |
Et voilà!
- https://developer.chrome.com/blog/font-fallbacks#understanding_font_tables ↩
- https://developer.chrome.com/blog/font-fallbacks#reading_font_tables ↩
- Wenn wir für unser CSS genau die Werte als Ausgangsbasis verwenden, die Safari aus der Schriftdatei heranzieht, erreichen wir trotz fehlendem Support in Safari die gleiche Darstellung in allen Browsern. Safari unter Windows greift auf die Werte aus der Tabelle OS2/Win zu, die bei unseren Dateien genau den
hhea-Werten entsprechen (siehe oben). ↩ - https://developer.chrome.com/blog/font-fallbacks#calculating_font_metric_overrides ↩