Arabisch hat keine x-Höhe: size-adjust aus den Konturen messen

font-size legt die Größe von nichts fest, was ein Leser sehen kann. Es legt das Geviert fest, und wie viel von dieser Box die Zeichnung füllt, entscheidet die Schriftgestaltung — deshalb können zwei Schriften bei derselben deklarierten Größe um ein Zehntel ihrer sichtbaren Höhe auseinanderliegen, ohne dass irgendwo etwas falsch wäre. Zwischen einer lateinischen und einer arabischen Groteske ist dieser Abstand der Normalfall und nicht die Ausnahme.

Diese Seite setzt Fließtext auf dem breiten Desktop auf 17px, und die arabischen Dokumente nehmen davon 0.9 über einen Multiplikator pro Sprache, also 15.3px. Bei dieser Größe zeichnete Cairo, die Schrift, die diese Seite früher ausgeliefert hat, seinen Zahn — die kurze Senkrechte, mit der beh beginnt, und die Höhe, auf der arabischer Fließtext gelesen wird — mit 7.650px Zeichnung. Zain, unangepasst eingesetzt, zeichnet dasselbe Merkmal mit 6.847px. Kein CSS hat sich geändert; der Absatz hat schlicht ein Zehntel der Zeichnung verloren, an der ein Leser seine Größe misst.

Der Hebel, den CSS anbietet, ist der Deskriptor size-adjust in @font-face: ein Multiplikator auf die ganze Schrift, Konturen und Metriken zusammen, damit zwei Schriften bei einer deklarierten font-size zur Deckung kommen. MDN führt ihn seit September 2023 als Baseline, breit verfügbar, und caniuse setzt ihn bei 93.58 Prozent der Nutzer an. Was dir keiner von beiden gibt, ist die Zahl, die hineingehört.

Jede dieser vier Zahlen ist Arithmetik über eine Glyphen-Bounding-Box und einen Token-Wert und kein Screenshot, und genau darum geht es bei dieser Methode: sie läuft, bevor die Schrift ausgeliefert wird, und sie läuft wieder an dem Tag, an dem die Schrift wechselt.

Dieselben Konturen bestimmen die line-height, auf der diese Absätze sitzen, und diese Zahl ist gemessen statt gewählt — den echten Boden berechnen.

Arabisch hat kein x und keine Versalien, und die Standardreferenz ist deutlich, was das Ausleihen dieser Wörter angeht: benutzt nicht x-Höhe und Versalhöhe, schreibt Azza Alameddine, schlicht weil es im Arabischen kein x und keine Versalien gibt. Was Arabisch stattdessen hat, ist der Zahn, die kurze Senkrechte, mit der beh und teh beginnen; die Schlaufe, der Bauch von heh und waw; das Auge, der Kopf von ain; und das Alef, eine schlichte Senkrechte, die die Oberlängenlinie setzt.

Diese Merkmale über die fünf arabischen Schnitte zu messen, die diese Seite ausgeliefert hat, brachte etwas zutage, das im Stylesheet nicht festgehalten ist. In Cairo sind Zahn, Schlaufe, Auge und das lateinische kleine x auf exakt dieselbe Linie gezeichnet — 0.5000em im Regular und 0.5010em im SemiBold, auf die Designeinheit genau. Wer eine Familie für zwei Schriftsysteme entwirft, hatte diese Gleichung längst in die Konturen geschrieben. CSS hat keine Eigenschaft, die sie wieder auslesen kann.

from fontTools.ttLib import TTFont
from fontTools.pens.boundsPen import BoundsPen
 
f    = TTFont('zain/regular.woff2')
upm  = f['head'].unitsPerEm       # 800 bei Zain, 1000 bei Cairo
gs   = f.getGlyphSet()
name = f.getBestCmap()[0x0628]    # beh — der Zahn
 
pen = BoundsPen(gs)
gs[name].draw(pen)
print(pen.bounds[3] / upm)        # 0.4475
 
# und was man in dieser Schrift nicht glauben darf:
print(f['OS/2'].sxHeight   / upm) # 0.600 — gezeichnetes x endet bei 0.460
print(f['OS/2'].sCapHeight / upm) # 0.874 — gezeichnetes H endet bei 0.695

Noto Kufi ist das Gegenbeispiel. Sein Zahn liegt bei 0.4950 und sein lateinisches x bei 0.5460, 10.3 Prozent auseinander, ein arabisches Wort und ein lateinisches daneben standen also nie auf derselben Mittellinie. Zain landet zwischen beiden: sein lateinisches x steht 2.8 Prozent über seinem Zahn, was nahe an der Harmonie zwischen Latein und Arabisch liegt, die seine README behauptet, und nicht dasselbe ist wie Cairos exakte Deckung.

Cairo und Noto Kufi waren zwei Entwürfe, eine Display-Überschrift und der Absatz darunter konnten sich also in der Schrift unterscheiden. Zain ist ein Entwurf, und zwei Familien zu einer zusammenzuziehen lässt nur Gewicht und Metriken als Hebel übrig — und genau da hört das Verhältnis von Zahn zu Alef auf, eine Randnotiz zu sein, und wird zur Einschränkung.

Dieses Verhältnis ist eine Eigenschaft des Entwurfs und nicht des Schriftsystems. Cairo bewegt sich zwischen seinen beiden Schnitten nur von 0.697 auf 0.702, sieben Tausendstel, innerhalb von Cairo hätte also ein einziger Multiplikator beide Rollen bedient. Zains Werte sind 0.644 und 0.658. Einen Entwurf mit abweichendem Verhältnis einzusetzen ist das, was zwei Werte erzwingt, und keine Sorgfalt im CSS kann sie wieder zu einem zusammenfalten.

Fließtext wird auf Zahnhöhe gelesen, so wie lateinischer Fließtext auf x-Höhe, also gleicht die Fließtextfamilie Zains Zahn an Cairos an: 0.500 geteilt durch 0.4475 ist 1.117, und die Deklaration sagt 112 Prozent. Display wird auf Alefhöhe gelesen — jedes plakative Wort auf dieser Seite ist ein Wort aus Senkrechten —, also gleicht die Displayfamilie Zains Alef an das von Cairo SemiBold an: 0.714 geteilt durch 0.695 ist 1.027, und die Deklaration sagt 103 Prozent.

Diese beiden Antworten liegen 8.76 Prozent auseinander, und diese Spanne ist das ganze Argument. Nimm 112 Prozent auch für Display, und ein arabisches plakatives Wort rendert 9.02 Prozent höher als das Cairo-Alef, an das es angeglichen ist. Nimm 103 Prozent auch für Fließtext, und der Zahn fällt 7.82 Prozent zu kurz aus. Einen Wert zu wählen ist keine Vereinfachung; es ist die Wahl, bei welcher der beiden Rollen man falsch liegen will.

Es gibt außerdem eine konkurrierende Konvention darüber, welche Metrik überhaupt anzugleichen ist. Edo Smitshuijzen gleicht in seinem Text über Proportionen in Zweischrift-Fonts die lateinische x-Höhe an die Höhe der Schlaufe an statt an den Zahn und verlangt vom Entwurf, den Abstand zwischen beiden zu verkleinern. In Cairo ist das Argument gegenstandslos, weil Zahn, Schlaufe und lateinisches x dieselben 0.500em sind. In Zain gehen die beiden Regeln auseinander: der Zahn ergibt 112 Prozent, die waw-Schlaufe 106. Diese Seite ist dem Zahn gefolgt, weil die Schrift, die sie nachbildet, längst alle drei gleichgesetzt hatte.

Zwei arabische Familien durch eine zu ersetzen hat auch verändert, was mit den lateinischen Passagen innerhalb einer arabischen Seite passiert — das unicode-range, das eine Schrift vom Lateinischen fernhält.

CSS liefert eine Eigenschaft für genau dieses Problem. font-size-adjust normalisiert eine Schrift gegen eine andere über das Verhältnis einer benannten Metrik, und der gängige Rat, wie man ihren Wert findet, lautet: setz ein kleines x in beiden Schriften und schieb, bis sie übereinstimmen. Dieser Rat ist durch und durch lateinisch, und die Eigenschaft kann diese Aufgabe aus drei voneinander unabhängigen Gründen nicht erledigen — von denen jeder für sich reichen würde.

Fang mit dem an, der am leichtesten zu sehen ist. Die Wahl der Metrik ist die Wahl der Antwort, und die Eigenschaft bietet keinen Weg, nach der Zeile zu fragen, die eine arabische Schrift braucht.

Die Verbreitung ist das kleinste der drei Probleme, und die beiden Stellen, an denen du nachschlägst, widersprechen sich. caniuse gibt font-size-adjust global 88.02 Prozent mit voller Unterstützung ab Chrome und Edge 127; MDN trennt die Syntaxen, setzt die Form mit Metrik-Schlüsselwort auf Chrome und Edge 129, Firefox 129 und Safari 18 und führt die Eigenschaft als Baseline 2024. Beides gelesen am 26. August 2026. Der Deskriptor ist dagegen seit drei Jahren breit verfügbar.

Die Eigenschaft, die für den Größenabgleich zwischen Schriften entworfen wurde, hängt also an einem Feld, das gegen einen Buchstaben definiert ist, den Arabisch nicht hat — und in der Schrift, die diese Seite tatsächlich ausliefert, liegt dieses Feld um fast ein Drittel daneben. Der grobe Multiplikator pro Schrift ist das einzige Werkzeug der Plattform, das eine Messung tragen kann, für die CSS kein Vokabular hat.

Die lateinische Seite dieser Website deklariert auf jeder Schrift ein size-adjust, ein ascent-override und ein descent-override — drei synthetische Familien über vier physische Dateien, und zwei dieser Familien zeigen auf dieselbe .woff2 und deklarieren dabei verschiedene Metriken. Das arabische Stylesheet deklariert nur das size-adjust. Das ist die eine Stelle, an der die beiden Dateien absichtlich nicht übereinstimmen.

Die lateinischen Overrides gibt es, damit ein Quicksand-Tausch nicht gegen Arial neu umbricht. Arabisch kann sich dasselbe nicht kaufen, denn weder Quicksand noch Arial trägt überhaupt Arabisch: der echte Fallback ist irgendein Naskh, den die Plattform gerade mitbringt, und es gibt nichts Stabiles, woran man sich hängen könnte. Und dann sagt die Arithmetik, dass die Overrides ohnehin fast nichts gebracht hätten.

Was die Overrides sonst gebracht hätten — eine Zeilenbox, gegen die die bestehenden line-heights schon abgestimmt waren —, liefert das size-adjust von selbst, weil es Ascent und Descent der Schrift zusammen mit den Konturen skaliert.

Der Plan, mit dem diese Phase begann, schrieb diese Overrides als rohe Prozentangaben der Zeichnung neben das size-adjust, und er wäre um genau 12 Prozent falsch gewesen. Das Stylesheet hält diese Zahl fest und gibt den falschen Mechanismus dafür an: es sagt, das Override wäre nicht skaliert worden, weil die Anpassung zuerst greife und das Override das Ergebnis ersetze. CSS Fonts 5 sagt das Gegenteil — alle Metriken, die zu dieser Schrift gehören, einschließlich der über @font-face-Deskriptoren gesetzten Overrides, werden mit dem angegebenen Prozentsatz skaliert.

Die 12 Prozent überleben die Korrektur, aus dem spiegelbildlichen Grund. Ein ascent-override von 130.3 Prozent und ein descent-override von 57.1 Prozent, also Cairos Box als Zeichnung ausgedrückt, ergeben mit einem size-adjust von 112 Prozent multipliziert 2.0989em, wo 1.874em gemeint waren. Zwei unabhängige Wege kommen auf dieselbe Zahl, die Entscheidung war also so oder so richtig — die Begründung, die ein späterer Leser aus dieser Datei mitnimmt, aber nicht.

Das Stylesheet sagt ja, und das Übergabedokument sagt es zweimal: jeder arabische Absatz behält die Satzbreite, die Umbruchpunkte und die Zeilenzahl, die er heute hat. Für diesen Text nachgemessen, zeigt alles in die andere Richtung, und die Behauptung wird von nichts gestützt, was im Repository festgehalten ist.

Einen Zahn an einen Zahn anzugleichen ist eine vertikale Operation. Die Dickte ist eine eigene Größe, die kein vertikaler Abgleich steuert, und Zain ist ein breiterer Entwurf als Cairo. Löst man die kontextuellen Formen über die Einzelsubstitutionen initial, medial, final und isoliert der jeweils eigenen GSUB-Tabelle auf — 91 Substitutionen im Testabsatz, in keiner der beiden Schriften eine fehlende Glyphe — und summiert die Dickten, ergeben sich die Zahlen unten.

Die Zeilen werden länger, die Umbruchpunkte wandern und die Absätze werden höher. Die optische Entscheidung überlebt die Korrektur — den Zahn anzugleichen ist weiterhin der richtige Weg, arabischen Fließtext gegen eine lateinische Schrift zu bemessen —, die Folge aber, die dafür behauptet wurde, nicht, und ein Rebuild, der sein arabisches Layout auf unveränderten Umbruchpunkten kalkuliert hätte, wäre spät überrascht worden.

Die Messung hat ehrliche Grenzen. Der Testabsatz enthält keine Lam-Alef-Paare, was für diesen einen String den größten Ligatur-Störfaktor entfernt; nichts hier wurde von einem Browser gerendert. Es ist fontTools, das die Substitutionstabellen jeder Schrift selbst liest, was genügt, um Richtung und Größenordnung festzustellen, und nicht genügt, um vorherzusagen, wo eine bestimmte Zeile umbricht.

Eine Zeile ist eine Funktion aufgelöster Font-Metriken, und deshalb kann auch ein Splitter für Animationen nicht laufen, bevor die Schriften da sind — Text in einer verbundenen Schrift zerlegen.

Ein Metrik-Multiplikator ist nie lokal. Weil size-adjust Ascent und Descent der Schrift zusammen mit den Konturen skaliert, ist Zains Content-Box bei 112 Prozent 1.859em hoch — jedes Element mit line-height 1 hat also negativen halben Durchschuss, und seine Zeichnung hängt in beide Richtungen aus der eigenen Zeilenbox heraus.

Der Button-Roll-up auf dieser Seite beschneidet sein Label mit einem Fenster, das bei 94 Prozent dieser Box geschnitten ist, was für Quicksand bequem ist und für Zain nicht. An den Konturen von Zain Bold gemessen, reicht das finale yeh bis -0.46625em und ain bis -0.41380em; bei 112 Prozent sind das -0.5222em und -0.4635em unter der Grundlinie einer 1em-Box. Das Fenster hat dem Wort die Punkte unten abgeschnitten, und der arabische Kontaktlink im Golden Master hat einen anderen Buchstaben gerendert — ein Schreibfehler in den eigenen Worten des Inhabers, in einem Linktext, in Produktion.

/* src/styles/locale/arabic.css, gekürzt */
html[lang='ar'] :is(.btn-text, .text-eyebrow) {
  --ar-label-lh: 1.55;   /* war 1, und 1 hat beschnitten */
  --text-offset: 2em;    /* wo die Zeichnung des Zwillings beginnt */
}
 
html[lang='ar'] .text-clip-w {
  /* Latein schneidet bei 94%; Zains Unterlängen brauchen 114% */
  clip-path: polygon(0 -2%, 0 114%, 100% 114%, 100% -2%);
}
 
/* das Fenster bei 114% einer 1.55em-Box reicht bis 1.767em,
   und die Zeichnung des Zwillings beginnt bei 1.845em. */

Der Browser-Testlauf, der die arabischen Routen absichert, kann diese Klasse von Fehlern nicht sehen. Er vergleicht die Bounding Boxen aufeinanderfolgender Zeilenelemente bei vier Viewports, und zwei arabische Zeilen kollidieren Zeichnung gegen Zeichnung, nie Box gegen Box — die Herleitung mit fontTools ist also der stärkere Test und der Browserlauf der schwächere. Es andersherum zu sagen, verkehrt den ganzen Sinn des Messens an den Konturen.

Eine beschnittene Unterlänge ist einer der Fehler, an die logische Eigenschaften von allein nicht heranreichen — sieben Fehler in rechtsläufigem Layout.

Keine der Zahlen oben lässt sich übertragen. Sie sind Zain gegen Cairo, bei den Größen einer einzigen Seite, für zwei Rollen, die es auf dieser Seite zufällig gibt. Übertragbar ist die Methode, und sie ist sieben Schritte lang — die ersten drei sind dieser Text, und die letzten vier haben dieses Repository je einen Fehler gekostet.

Die Grenze der Methode gehört genauso klar ausgesprochen wie die Methode selbst. Sie regelt die vertikale Größe und sonst nichts: die Dickte wandert, die Umbruchpunkte wandern, und keine einzelne CSS-Eigenschaft hält beides. Und sie ist eine Konstante pro Schrift, die ganze Herleitung läuft also an dem Tag wieder, an dem die Schrift wechselt — was sie auf dieser Seite auch getan hat.

Schritt sechs ist eine Messung für sich, und die Böden dieser Seite sind mit ihrer Arithmetik veröffentlicht — der arabische line-height-Boden.

Wenn du einen Build in mehr als einem Schriftsystem planst und die Typografie lieber vor dem Layout klären willst, beginn ein Gespräch.