Warum wir Zeichen nicht selbst zeichnen, sondern es der Plattform überlassen
Ist Ihnen schon einmal aufgefallen, dass Hangul ganz normal aussieht, aber nur die chinesischen Schriftzeichen irgendwie ungewohnt wirken? Wenn wir uns entscheiden, die Zeichen nicht selbst zu zeichnen, sondern sie der Text-Engine der Plattform zu überlassen, besteht unsere Aufgabe nicht mehr darin, „was gezeichnet werden soll“, sondern darin, „um welche Schriftart wir bitten“.
Bis Text auf dem Bildschirm erscheint, sind viele Arbeitsschritte nötig. Zeichen müssen in Formen umgewandelt, Zeilen umgebrochen und als Pixel gezeichnet werden. Dabei müssen die Zusammensetzung von Hangul ebenso wie chinesische Schriftzeichen, Emojis, arabische Schrift und Schriftarten-Fallbacks verarbeitet werden.
Wir haben diesen Prozess nicht neu entwickelt. Wir haben ihn Pango und HarfBuzz unter Linux, DirectWrite unter Windows und TextKit 2 unter macOS überlassen.
Denn an diesem Bereich haben die Betriebssysteme über lange Zeit hinweg gefeilt. Hätten wir ihn selbst entwickelt, wäre die Qualität gerade bei schwierigen Aspekten wie CJK-Zeichen oder Barrierefreiheit wahrscheinlich eher schlechter geworden. Außerdem sahen wir das Alleinstellungsmerkmal des Produkts nicht im Renderer selbst, sondern in der Typografie und einem Bediengefühl, das zur jeweiligen Plattform passt.
Stattdessen bestimmen wir, wann etwas erstellt wird
Das Erstellen eines Textlayouts kostet Zeit und Speicher. Große Dokumente enthalten Zehntausende Zeilen, weshalb wir nicht alle auf einmal erstellen konnten.
Deshalb erstellen wir nur die auf dem Bildschirm sichtbaren Zeilen und die Zeilen in ihrer unmittelbaren Umgebung. Zeilen, die sich weit vom sichtbaren Bereich entfernen, werden sofort verworfen. Selbst wenn man lange durch ein 1 MB großes Dokument scrollt, bleiben nur etwa vierzig bis sechzig Layouts aktiv.
Für noch nicht erstellte Zeilen schätzen wir die Höhe im Voraus. Schließlich muss die Bildlaufleiste die Gesamtlänge des Dokuments kennen.
Natürlich kann die Schätzung auch falsch sein. Wenn die neu berechnete Höhe von der erwarteten abweicht, kann sich der Bildschirminhalt verschieben. In diesem Fall korrigieren wir die Scrollposition im selben Frame um genau diese Differenz. Für die Augen des Benutzers sollte es so aussehen, als wäre nichts geschehen.
Eine Zeile, in der Hangul zusammengesetzt wird, zeichnen wir ohne Formatierungen. Denn wenn während der Eingabe Eigenschaften wie Fettdruck oder Ausblenden dazwischenkommen, kann die dem Eingabemethoden-Editor bekannte Zeichenzahl von der auf dem Bildschirm dargestellten Zeichenzahl abweichen.
Das erste Problem, auf das wir stießen, war das Gesicht der chinesischen Schriftzeichen
Wenn man etwas der Plattform überlässt, übernimmt man auch die Standardeinstellungen der Plattform.
Die Standard-UI-Schriftart von Ubuntu enthält kein Hangul. Deshalb wählte das System als Ersatzschriftart Noto Sans CJK JP. Hangul wurde korrekt dargestellt, doch einige chinesische Schriftzeichen erschienen in japanischen Glyphenformen. Das liegt daran, dass manche Zeichen trotz desselben Unicode-Codepunkts in Korea und Japan unterschiedlich aussehen.
Die Lösung war einfach. Wir setzten Noto Sans CJK KR in der Liste der UI-Schriftarten an die erste Stelle.
Wichtiger war jedoch eine andere Erkenntnis. Wenn wir keinen Maßstab festlegen, antwortet die Plattform nicht entsprechend der Sprache des Benutzers, sondern mit ihren eigenen Standardwerten.
Über die Reihenfolge der Schriftarten erzeugen wir sprachspezifische Formen
Ein Schriftarten-Stack sucht die Zeichen von vorne nach hinten. Nur Zeichen, die in der ersten Schriftart fehlen, werden an die nächste Schriftart weitergereicht.
Mithilfe dieser Eigenschaft können wir lateinische Schrift mit Serifen und Hangul serifenlos darstellen. Mit einer einzigen Einstellungszeile kombinieren wir Schriftarten, die jeweils zu den verschiedenen Sprachen passen.
Wenn die Leseschriftart leer bleibt, wird unverändert die Schriftart des Fließtexts verwendet. Wird sie separat festgelegt, ändert sie sich nur im Lesemodus. Im Quellmodus verwenden wir eine Code-Schriftart.
Die Schriftgröße richtet sich nach den Bedienungshilfen-Einstellungen des Betriebssystems. Benutzer, die die Schrift im System vergrößert haben, müssen sie nicht in jeder App erneut einstellen.
Screenreader nutzen dieselbe Grundlage. Da die Barrierefreiheitsfunktionen bereits mit der Textebene der Plattform verbunden sind, müssen wir nur den Inhalt der angeforderten Zeile korrekt übermitteln.
Fehlt eine Übersetzung, schlägt der Build fehl
UI-Sätze werden auf Englisch verfasst und zugleich als Schlüssel der Übersetzungstabelle verwendet. Fehlt eine Übersetzung, erscheint der englische Text unverändert auf dem Bildschirm.
Das Problem ist, dass dabei kein Fehler auftritt. Selbst wenn eine Übersetzung fehlt, mischt sich still und leise englischer Text unter die übrigen Inhalte.
Deshalb haben wir ein Prüfskript erstellt. Es sammelt die tatsächlich im Code verwendeten Sätze und vergleicht sie mit den Übersetzungstabellen für 12 Sprachen. Wird ein Satz nur in einer Sprache hinzugefügt oder eine Übersetzung vergessen, schlägt der Build fehl.
Jede Übersetzungstabelle enthält 304 Schlüssel, während im Code tatsächlich 282 Sätze verwendet werden. Unterstützt werden English, 한국어, 日本語, 简体中文, 繁體中文, Deutsch, Français, Español, Português (Brasil), Русский, Italiano und Polski.
Wenn die Sprache geändert wird, öffnen wir ein neues Fenster mit demselben Dokument und schließen das bisherige Fenster. Würden wir Hunderte bereits sichtbare Widgets einzeln übersetzen, wäre die Wahrscheinlichkeit groß, etwas zu übersehen. Wir kamen zu dem Schluss, dass es sicherer ist, das Fenster beim Wechsel der Sprache einmal neu zu öffnen, als einen komplexen und kaum genutzten Ablauf aufrechtzuerhalten.
Wenn man etwas der Plattform überlässt, ähneln auch die Ergebnisse der Plattform
Selbst bei demselben Dokument sind die Pixel nicht auf jedem Betriebssystem vollkommen identisch. Der Grund dafür sind unterschiedliche Verfahren zur Schriftglättung und unterschiedliche Standardschriftarten.
Wir versuchen nicht, sie mit Gewalt identisch zu machen. Stattdessen halten wir die Grundlagen des Dokuments wie das Größenverhältnis der Schrift, die Zeilenhöhe und die Abstände einheitlich.
Auch das Ergebnis des Schriftarten-Fallbacks kann je nach installierten Schriftarten variieren. Deshalb versprechen wir kein bestimmtes Ergebnis, sondern zeigen transparent, in welcher Reihenfolge die Schriftarten angefordert werden. Benutzer können diese Reihenfolge auch selbst ändern.
Nur weil wir die Zeichen nicht selbst zeichnen, verschwindet unsere Verantwortung nicht. Wir müssen umso genauer festlegen, was wir delegieren und in welcher Reihenfolge wir es anfordern.