Eine interaktive Einführung in die überraschende Erfahrung des arabischen Typografie-Renderings und die technische Schuld dahinter

• Arabische Web-Typografie ist ein Problem der Rendering-Infrastruktur, bei dem Buchstabenverbindungen, bidirektionaler Text, Zahlen- und Satzzeichenbehandlung sowie Zeilenausrichtung miteinander verflochten sind; es lässt sich kaum als einfacher CSS-Bug behandeln
• Im klassischen arabischen Satz wurde der Blocksatz nicht durch größere Wortabstände, sondern durch Kashida umgesetzt, also das Verlängern innerer Verbindungsstriche von Buchstaben; modernes text-align: justify in Browsern vergrößert dagegen meist die Abstände zwischen Wörtern
• Bei arabischen Buchstaben wird ein gespeicherter Codepoint je nach Kontext in isolierte, initiale, mediale oder finale Form umgewandelt; ohne OpenType-Features und eine Shaping-Engine werden die Buchstaben getrennt dargestellt
• Die Arabic Presentation Forms von Unicode, Zahlensysteme, der bidirektionale Algorithmus UAX #9 und unsichtbare Steuerzeichen führen in realen Produkten zu Problemen wie fehlgeschlagener Suche, umgedrehten Telefonnummern und verwirrender Cursorbewegung
• Zentrale Grundlagen wie HarfBuzz, Amiri und die W3C Arabic Layout Requirements existieren zwar, doch die arabische Ausrichtung in Browsern und die Nutzung von jstf bleiben weiterhin Implementierungslücken

---

Ausgangspunkt: Ein arabisches Satzproblem, das wie ein „CSS-Bug“ aussah

• In einem Kunden-Dashboard wurden arabische Absätze mit gemischten Inhalten nicht wie im Designentwurf im Blocksatz dargestellt; stattdessen erschien der linke Rand unregelmäßig
• Die lateinische Version desselben Blocks wirkte „fine“, aber im Arabischen beginnen Zeilen rechts, daher entsteht der ausgefranste Rand links
• Selbst mit text-align: justify ließ sich die Zeile nicht so füllen, wie es das Designteam freigegeben hatte, nämlich durch das Verlängern innerer Buchstabenstriche
• Im selben Produkt waren zuvor bereits Probleme mit getrennt dargestellten Namen in PDFs, fehlgeschlagenen Suchindizes und Legacy-Unicode-Codepoints bei der Arabisch-Verarbeitung aufgetreten
• Der Kern des Problems lag nicht in einem bestimmten Stylesheet, sondern im Zustand der arabischen Typografie im Web

Das Problem, das die Tradition des Abschreibens bereits gelöst hatte

• In der klassischen arabischen Schreibtradition wurde Blocksatz nicht durch größere Wortabstände, sondern durch das Verlängern der Verbindungsstriche innerhalb der Buchstabenformen erreicht
• Diese Methode heißt taṭwīl oder in moderner technischer Terminologie kashida und verlängert die Verbindungsstriche zwischen bestimmten Buchstabenpaaren
• Gut gesetzte Naskh-Seiten des 17. Jahrhunderts zeigen bündige Ränder ohne vergrößerte Wortabstände und erzeugen dadurch eine dichte, regelmäßige Textur
• Das von Ibn Muqla systematisierte al-khaṭṭ al-mansūb ordnete Buchstabenformen anhand der rautenförmigen Punktmarke der Rohrfeder, der Höhe des alif und der Proportionen von Bögen
• In dieser Tradition war Zeilenausrichtung kein Problem der Leerraumverteilung, sondern ein Shaping-Problem, bei dem Buchstabenformen und alternative Glyphen gewählt wurden

Ein Buchstabe, vier Formen

• Arabisch ist eine durchgehend verbundene Schrift wie Handschrift; es gibt keine Trennung in Druck- und Blockschrift
• Jeder Buchstabe verändert sich je nach Nachbarbuchstaben zu isolierter, initialer, medialer oder finaler Form, und sechs Buchstaben verbinden sich nicht nach vorn, wodurch der Fluss innerhalb eines Wortes unterbrochen wird
• Unicode speichert abstrakte Buchstaben, Schriftarten liefern positionsabhängige Glyphen, und die Shaping-Engine wendet OpenType-Features wie isol, init, medi, fina, rlig, mark und mkmk an
• Ein Wort wie محمد besteht in der Speicherung aus vier Codepoints, erscheint beim Rendern aber nach Glyphenauswahl und OpenType-Lookups als ein zusammenhängender Strich
• Fehlt eine Shaping-Engine wie HarfBuzz oder wird sie von einem PDF-Generator umgangen, werden dieselben Codepoints als voneinander getrennte isolierte Buchstabenformen dargestellt

Unicode-Fossilien: Arabic Presentation Forms

• 8-Bit-Codepages aus der DOS- und frühen Windows-Zeit kodierten nicht abstrakte Buchstaben, sondern die Formen selbst wie initiale oder mediale Varianten als eigene Zeichen
• Unicode übernahm dies aus Gründen der Roundtrip-Kompatibilität, und so blieb der Block Arabic Presentation Forms von U+FB50 bis U+FEFF erhalten
• In neuen Dokumenten sollten diese Codepoints nicht vorkommen, doch PDF-Text-Extractor können sie bis heute ausgeben
• Wird derselbe Name einmal in modernem Unicode und einmal mit Presentation Forms gespeichert, sieht er auf dem Bildschirm gleich aus, wird aber bei String-Vergleich und Suche unterschiedlich behandelt
• Mit NFKC-Normalisierung lassen sich Presentation Forms auf abstrakte Buchstaben zurückführen und Suchausfälle verringern

Software, die Shaping und bidirektionale Verarbeitung überspringt

• Software, die die Shaping-Engine und den bidirektionalen Algorithmus überspringt, zeichnet Buchstaben einzeln in isolierter Form und platziert Zeilen von links nach rechts
• Solche Ausgaben begegnen arabische Leser tatsächlich auf Ladenschildern, Bordkarten, Wasserzeichen und arabischen Beschriftungen in älteren Filmen
• Ältere Photoshop-Versionen, matplotlib mit Standardeinstellungen, verschiedene PDF-Generatoren aus dem npm-Ökosystem und Bondrucker können diese Probleme erzeugen
• Gängige Python-Workarounds wie arabic_reshaper und python-bidi backen mithilfe des Presentation-Forms-Blocks vorgeformte Varianten direkt in den String ein
• Dieser Workaround verlagert die Aufgabe des Renderers in den String selbst und macht letztlich die Mängel des Text-Stacks sichtbar

Drei Arten von Ziffern und Probleme mit Satzzeichen

• Die Ziffern 0–9, die weltweit oft „Arabic numerals“ genannt werden, sind nicht die Ziffernformen, die die meisten arabischen Leser im Alltag verwenden
• In Ägypten, Sudan, der Levante, dem Irak und den Golfstaaten werden die ARABIC-INDIC DIGITS ٠١٢٣٤٥٦٧٨٩ verwendet
• Im Maghreb werden lateinische Ziffernglyphen verwendet, während Iran, Afghanistan und Pakistan die EXTENDED ARABIC-INDIC DIGITS ۰۱۲۳۴۵۶۷۸۹ nutzen
• Im UAX #9 werden Ziffern nicht als starke, sondern als schwache Zeichen behandelt und je nach Richtung des vorangehenden starken Zeichens als europäische oder arabische Zahlen umklassifiziert
• Eine Telefonnummer wie 010-1234-5678 hinter einem arabischen Wort kann auf dem Bildschirm durch neutral behandelte Bindestriche als 5678-1234-010 erscheinen
• Plattformseitige Lösungen trennen die Richtung, indem die Nummer mit ‎ oder <bdi> umschlossen wird
• Als Dezimal- und Tausendertrennzeichen werden im arabischen Raum U+066B ٫ und U+066C ٬ verwendet; ASCII . und , sehen fast gleich aus, haben aber andere Codepoints und bidi-Eigenschaften

Umgehungen und Vereinfachungen von der Druckpresse bis zum Web

• Das 1514 in Fano gedruckte Kitāb Ṣalāt al-Sawāʿī war das erste arabische Buch aus beweglichen Lettern und zeigt getrennte Buchstabenverbindungen sowie fehlerhafte Punktpositionen
• Der 1537 in Venedig erschienene Paganini-Qurʾān scheiterte kommerziell an Satz- und Textfehlern; ein Exemplar wurde 1987 in einer Klosterbibliothek in Venedig gefunden
• Die Geschichte eines osmanischen Druckverbots stützt sich problematischerweise auf Berichte europäischer Reisender, da die ursprünglichen Edikte Bayezids II. und Selims I. nicht erhalten sind
• Die Bulaq Press in Kairo wurde 1820 von Muhammad Ali gegründet und verbesserte die Qualität des arabischen Metallsatzes durch Hunderte Lettern und viel Geduld
• Der Kairoer Qurʾān von 1924 wurde in der Amiria Press im Metallsatz hergestellt und trug zur Standardisierung von Text und Typografie im 20. Jahrhundert bei
• In den späten 1950er Jahren entwickelten Kamel Mrowa und Linotype für 90-spaltige Magazine Simplified Arabic, indem sie Initialformen mit medialen und Finalformen mit isolierten zusammenlegten und Ligaturen reduzierten
• Simplified Arabic ermöglichte eine günstige und schnelle Zeitungsproduktion und dominierte innerhalb einer Generation arabische Newsrooms

Das Kashida, das das Web noch immer nicht zeichnen kann

• In frühen Entwürfen des CSS Text Module Level 3 gab es für text-justify einen Wert kashida, und Internet Explorer 5.5 implementierte ihn bereits im Jahr 2000
• IE 5.5 bot auch die Eigenschaft text-kashida-space, doch da andere Browser sie nicht umsetzten, verschwand der Wert aus der Spezifikation
• In modernem Chrome, Firefox und Safari funktioniert text-align: justify im Arabischen, indem die Abstände zwischen Wörtern vergrößert werden
• Das Issue zur arabischen Ausrichtung in der CSS Working Group ist mindestens seit 2015 offen, und die Arbeit an den W3C Arabic Layout Requirements begann im selben Jahr
• Kashida-Blocksatz erfordert eine wiederholte Aushandlung zwischen Shaping und Layout auf Zeilenebene, weil verlängerte Glyphen ihre Breite ändern und diese Breitenänderung wiederum Umbrüche und benötigte Verlängerung beeinflusst
• OpenType besitzt seit den 1990er Jahren die jstf-Tabelle, mit der Fonts Prioritäten für die Ausrichtung angeben können, doch Shaping-Engines lesen sie kaum, und Font-Designer liefern sie selten mit
• Microsoft Word und InDesign Middle East Edition unterstützen Kashida-Blocksatz, aber die Browser-Renderer, in denen die meisten Menschen tatsächlich lesen, können Buchstaben nicht dehnen

Tatweel-Hacks sowie Probleme mit Ligaturen und Vokalzeichen

• Ein häufiger Web-Workaround besteht darin, das Zeichen U+0640 TATWEEL direkt in den Text einzufügen, damit es wie ein verlängerter Strich aussieht
• Da Tatweel den Inhalt verändert, entstehen Probleme bei Suchtreffern, Copy-and-Paste, Screenreadern und beim Reflow in Spalten
• Der von Tatweel gezeichnete Strich ist kein Kashida, das nach Font- und Zeichenregeln gesetzt wird, sondern ein vom Autor erratener, schreibmaschinenartiger Balken
• OpenType-Ligaturen sind in rlig, liga und dlig unterteilt; wenn notwendige Ligaturen wie lām-alif zerbrechen, ist der Text nicht nur unschön, sondern falsch
• Wird U+200C ZERO WIDTH NON-JOINER zwischen Buchstaben eingefügt, bleiben die gespeicherten Zeichen erhalten, das Rendering erzwingt jedoch isolierte Formen
• Safari ignoriert "rlig" 0 und "liga" 0, daher bleibt eine Demo zum Deaktivieren notwendiger Ligaturen dort wirkungslos
• Amiri ist eine Naskh-Schrift von Khaled Hosny, die 2011 unter der SIL Open Font License veröffentlicht wurde und seit dem Rewrite auf Version 1.0 im Jahr 2022 geschwungene Kashidas und ausgefeilte Stapelung von Vokalzeichen bietet
• Kartenkomponenten mit line-height: 1 und overflow: hidden können die oberen Vokalzeichen in vollständig vokalisiertem Arabisch abschneiden

Der bidirektionale Algorithmus und ein Cursor, der lügt

• Versionsnummern, englische Bezeichner, URLs oder französische Wörter in arabischen Absätzen rufen den Unicode Bidirectional Algorithmus UAX #9 auf
• Arabische Buchstaben sind starke Rechts-nach-links-Zeichen, lateinische Buchstaben starke Links-nach-rechts-Zeichen, Ziffern folgen als schwache Zeichen dem Kontext, und Leerzeichen sowie Satzzeichen gelten als neutrale Zeichen
• Der Algorithmus weist Zeichen Richtungs-Klassen zu, interpretiert schwache und neutrale Zeichen schrittweise, vergibt Einbettungsebenen und kehrt Runs derselben Ebene um
• Da sich die visuelle Reihenfolge auf dem Bildschirm und die logische Reihenfolge im Speicher unterscheiden, müssen Cursorbewegung, Mausklicks und Auswahl ständig zwischen beiden übersetzen
• An den Grenzen von Runs gibt es zwei legitime Cursorpositionen, eine logische und eine visuelle; Chrome, Firefox, Qt und Outlook können damit unterschiedlich umgehen
• Das Schreiben gemischter arabisch-englischer Texte bleibt selbst 2026 in wichtigen Editoren, E-Mail-Clients und Chat-Anwendungen standardmäßig eine Erfahrung mit hoher kognitiver Last
• Ein Bereich wie الصفحات 10-20 kann wegen Regel W2 und neutral behandeltem Bindestrich wie „20 bis 10“ aussehen und lässt sich durch ein vorangestelltes U+200E LEFT-TO-RIGHT MARK korrigieren

Funktionierende Grundlagen und verbleibende Lücken

• Khaled Hosny schuf Amiri, schrieb das HarfBuzz-Kommandozeilenwerkzeug hb-shape und war zudem Co-Maintainer von HarfBuzz
• Behdad Esfahbod schrieb vor Hosny große Teile von HarfBuzz und trug damit zur Shaping-Engine bei, die heute arabische Buchstaben in Browsern korrekt zeichnet
• Brill beauftragte John Hudson mit der Brill-Schrift, um alle für seinen Semitics-Katalog nötigen Transliterationszeichen abzudecken, und veröffentlichte sie 2011 kostenlos für nichtkommerzielle Nutzung
• Der Sakhr AX-170 war ein saudi-kuwaitischer MSX-Computer von etwa 1984, der Arabisch aus dem ROM darstellte und Arabic-BASIC-Bezeichner von rechts nach links unterstützte
• HarfBuzz, Amiri, Scheherazade, die Presentation-Forms-Unterstützung in GNU Unifont, Noto Arabic und die W3C-Dokumente zu Arabic Layout beruhen in hohem Maß auf der Arbeit weniger Einzelpersonen, Organisationen und Freiwilliger
• Browser-Hersteller übernahmen HarfBuzz, nachdem es kostenlos fertig vorlag, leisteten aber kaum Beiträge zu der Layout-Schleife, die die Ausrichtungsweise der Schreibtradition auf dem Bildschirm umsetzen würde
• Die verbleibende Lücke ist ein gut verstandener Algorithmus, der nur noch in einigen Layout-Engines implementiert werden muss; der unregelmäßige linke Rand im Kunden-Dashboard ist die für Nutzer sichtbare Form dieser fehlenden Investition

[GN⁺]

Lobste.rs-Kommentare

• Wirklich ein großartiger Artikel
  Und ich mag, dass dieses Zeichen ﷽ nur ein einziger Codepoint ist. Wenn man es kopiert, ist das irgendwie faszinierend.
  Es bedeutet angeblich „Im Namen Allahs, des Allerbarmers, des Barmherzigen“.

  • Bei ﷽ ist dieser Satz aus dem Artikel poetisch:
    „Ein Monument aus einer Zeit, in der niemand Rendering-Engines traute und das Rendering in die Kodierung eingebrannt war. Wie eine rezitierende Fliege, für immer in Bernstein konserviert.“
  • Dieses Unicode-Zeichen wurde auch hier behandelt: https://lobste.rs/s/7s4sjp
    Es hat Spaß gemacht, den Literaturverweisen des dort verlinkten Wikipedia-Artikels nachzugehen: https://lobste.rs/c/dq2ucz
    Kurz gesagt: Dieses Zeichen kam in Unicode, weil es in einer pakistanischen Codepage enthalten war, und dort war es enthalten, weil es eine rechtliche Vorgabe gab, diese Formulierung in juristischen Dokumenten aufzunehmen. Da Urdu eine indoeuropäische Sprache ist, wäre es mit der damaligen Technik wohl schwierig gewesen, zum Schreiben der Basmala gewissermaßen per „externem Aufruf“ auf eine arabische Codepage umzuschalten.
    Leider zeigen nicht alle Kommentare die Stärken dieser Community

• Meta: Das ist ein weiteres hervorragendes Beispiel dafür, dass solche Artikel einen typography-Tag brauchen

  • Ich verstehe nicht, warum. Das Thema wirkt ziemlich beliebt — gibt es wirklich eine starke Nachfrage, solche Inhalte auszublenden?
    Bei lobste.rs dienen Tags hauptsächlich dem Filtern

• Die text-justify-Eigenschaft in IE — damals gab es viele interessante Dinge. Es gab auch text-justify: newspaper; Jahrzehnte später haben manche das mit Knuth-Plass oder etwas Ähnlichem erklärt, aber ich glaube nicht, dass es das tatsächlich war.
  https://mediumwell.com/wp-content/uploads/… zeigt, dass das Verhalten, das damals als text-justify: newspaper bezeichnet wurde, dem heutigen text-justify: inter-character in der Spezifikation entspricht.
  IE hatte wirklich schon ziemlich früh viele coole Funktionen, und andere Browser haben solche Features einfach im Korb „zu schwierig“ liegen lassen. Manche kamen nie zurück, andere erst nach 15 oder 30 Jahren. Firefox bekam text-justify: inter-character 2017, Chromium hat diesen Teil erst vor ein paar Monaten implementiert, und Safari hat es noch immer nicht.

• Ein unglaublich großartiger und lehrreicher Artikel. Besonders gut fand ich den historischen Hintergrund, der der ganzen Geschichte einen breiteren Kontext gibt.
  Als jemand mit sowohl einem geschichtswissenschaftlichen Abschluss als auch einer IT-Karriere traf der Artikel genau meine beiden Interessen.

• Irgendetwas im Artikel lässt meinen LLM-Detektor ausschlagen, was schade ist. Gerade weil er Tiefgang hat und weniger dokumentierte Teile des modernen Tech-Stacks behandelt.
  Ein Beispiel für eine LLM-artige Passage ist diese hier, und dieses Gefühl zieht sich durch den ganzen Artikel:
  „Der Grund, warum kein Browser das anbietet, ist strukturell, und als Hindernis ist diese Struktur ziemlich elegant. Lateinische Ausrichtung behandelt geformten Text als etwas Festes, misst Wörter, gießt den verbleibenden Raum in die Abstände und ist fertig. Shaping und Layout bleiben in ihren jeweiligen Boxen, und jeder produktive Text-Stack ist um diese Trennung herum entworfen. Kashida-Ausrichtung reißt diese Box auf.“
  Ich würde @lr0 gern fragen, ob der Haupttext dieses Artikels mit einem LLM erzeugt, überarbeitet oder übersetzt wurde. Falls ja, könnte es besser sein, den Grad der Kontrolle des LLMs über die Endausgabe anzupassen. Frühere Blogposts, etwa https://lr0.org/blog/p/gpt/ und https://lr0.org/blog/p/linux_new_users/ , wirkten deutlich menschlicher.