Troika: Unterstützung für das Textlayout von rechts nach links

Erstellt am 5. Apr. 2021  ·  11Kommentare  ·  Quelle: protectwise/troika

Anstelle einer vollständigen erweiterten Textformungslösung (z. B. harfbuzz.wasm) hätte ich gerne eine grundlegende, sofort einsatzbereite Unterstützung für das RTL-Layout. Typr enthält bereits ein gewisses Maß an Unterstützung für arabische Glyphen-Ersetzungen, obwohl ich nicht weiß, wie vollständig das ist.

Ich habe bereits einige sehr grundlegende RTL-Layout-/Umbruchlogiken hinzugefügt. Lassen Sie uns dieses Problem verwenden, um Fehler damit und andere Lücken in der Unterstützung zu verfolgen.

Temporäre Testseite: https://troika-examples.netlify.app/#text -rtl

Hilfreichster Kommentar

Ich habe eine vollständigere Implementierung der Join-Typ-Erkennung vorangetrieben; Die Logik, die ich von Opentype.js übernommen hatte, erwies sich als unvollständig. Die neue Implementierung bettet tatsächlich eine stark komprimierte Version der Unicode-Joint-Type-Definitionen ein, sodass sie jetzt alle kombinierbaren Zeichen auf Arabisch und anders handhaben sollte. Es gibt auch einen anständigen Geschwindigkeitsschub über den Typr-Code.

@MichaelHazani Da Sie sich freiwillig gemeldet haben, Hebräisch zu testen, denke ich, dass dies jetzt für Sie bereit ist. Sie können diese Testseite verwenden, auf der ich ein paar hebräische Schriftarten zum Dropdown-Menü "Schriftart" hinzugefügt habe, und Sie können Ihren eigenen Text eingeben. Danke!

Alle 11 Kommentare

Zuerst möchte ich Ihnen sehr danken, dass Sie daran gearbeitet haben. Die Unterstützung von arabischen und RTL-Layouts wird für viele Menschen nützlich sein.
Ich habe einige erste Tests gemacht, der arabische Standardtext wird meistens gut in den Schriften cairo, Lemonada, Scheherazade (ohne Tachkil) unterstützt.

Ich habe diese 2 Regeln für Arabisch getestet:

  1. Ob die 3 Schriftformen in Ordnung sind (eine am Anfang, in der Mitte, am Ende) und Verbindungen (Ligatur).
  2. Tachkil, das ist der Satz von Hinweisen für die Aussprache ُ َ ً ٌ (wird in den meisten Texten, die Sie im Internet finden, außer in seltenen Fällen nicht verwendet)

In Mirza sind einige interne Buchstaben nicht verbunden (die Endung des Buchstabens wird anstelle der internen gesetzt oder anders)
arabicTachkil

Mit Tachkil funktionierten einige Schriftarten gut, während andere entweder die Form des Zeichens daneben änderten. Einige haben mit einem Text gearbeitet, den ich in die Box geschrieben habe, während sie mit einem kopierten Text nicht gearbeitet haben.

Wenn ich nicht-arabische Buchstaben wie Klammern "(", ")" verwende, werden sie vertauscht (müssen umgekehrt werden.).

Dies ist ein kurzer Test, den ich gemacht habe, ich muss mehr überprüfen und Ihnen mehr Details geben, wo die Dinge seltsam werden. (Ich muss auch die Schriftarten überprüfen, einige Schriftarten bieten nicht die erforderlichen Zeichen)

Vielen Dank! Ich freue mich zu hören, dass es einen anständigen Start hatte.

Es ist interessant, dass das Ergebnis für Wortpositionsersetzungen je nach Schriftart variiert. Die Wortpositions-Erkennungslogik in Typr ist immer dieselbe, also muss es etwas anderes geben, wie diese Schriftarten ihre Ersetzungen codieren, die Typr nicht handhabt. Ich werde mich speziell mit Mirza befassen, um zu sehen, ob ich einen Unterschied feststellen kann.

Da ich diese Zeichen nicht kenne und daher selbst nicht richtig oder falsch unterscheiden kann, wäre es sehr hilfreich, wenn Sie mir einige gezielte Testfälle mit erwarteten Ergebnissen geben könnten, vielleicht nur einzelne Wörter, etwa wie:

Eingabetext: xxx
Sollte so aussehen: [Bild]
Sieht korrekt aus in Schriftart A: [Bild]
Sieht in Schriftart B falsch aus: [Bild]

Was die Klammern betrifft, denke ich, dass dies der Paired Brackets -Teil des Bidi-Algorithmus ist. Ich bin mir noch nicht sicher, ob ich das alleine in Angriff nehmen werde, aber ich werde es auf jeden Fall prüfen.

Ich habe Code mit etwas grober bidirektionaler Layoutunterstützung gepusht. Im Moment ist es rein manuell, LRO/RLO/PDF-Steuerzeichen zu verwenden, um Richtungsbereiche zu definieren. Vollautomatisches Bidi ist viel komplizierter und ich beschäftige mich immer noch mit dem Umfang, aber die Reichweiten (mit Zeilenumbruch und Auswahl!) zu legen, ist ein wichtiger Anfang.

image

Es tut mir wirklich leid, dass ich gestern kein Feedback gepostet habe. Ich habe darüber nachgedacht, am Wochenende einen vollständigen Test zu machen, aber ich denke, es ist besser, die Dinge in Schritten zu machen.
Fangen wir mit Schriftarten an, die sehr gut funktionieren (bei einigen Schriftarten können einige Probleme auftreten). Ich habe die Schriftart Scheherazade verwendet, aber Cairo und Lemonada liefern das gleiche Ergebnis.
Mirza- und Amiri-Fonts zeigen immer getrennte Buchstaben.
Die Schriftarten Noto Sans, Roboto funktionieren überhaupt nicht.

Im Bild unten habe ich Rot verwendet, um die falsche Form des Buchstabens zu bedeuten, und Grün ist die richtige Form.
Das Problem tritt nur auf, wenn wir Tachkil (Vokalnoten) oder ein lateinisches oder Zahlenzeichen haben.

  1. Anstelle des endgültigen Formulars haben wir ein internes Formular.
  2. Innerhalb des Wortes haben wir statt der Anfangsform die innere Form. (innerhalb des Wortes haben einige Buchstaben keine Ligatur)
  3. Wenn wir direkt nach dem Wort eine Zahl haben (كم2), behalten wir die Endung bei.
  4. Nummern sind vertauscht.

arabThree

Text, den ich verwendet habe:
كم2.
كم 2
بِسم اللَّه الرحمن الرحيم
بِسمِ اللَّهِ الرَّحمٰنِ الرَّحيمِ

Diese Antwort enthält ein Bild, wie Buchstaben gezeichnet werden
https://www.quora.com/How-can-anyone-read-Arabic-as-the-letters-are-all-connected-to-each-other/answer/Hashem-Mohamed-4

Vielen Dank für diesen markierten Testfall, das ist immens hilfreich !!! Es hilft mir wirklich, die Dinge zu verstehen.

Die Logik von Typr zur Erkennung der Wortposition ist definitiv fehlerhaft; Ich habe es mit einer von opentype.js angepassten Logik überschrieben und das Ergebnis scheint jetzt viel besser zu sein:

image

Ich werde diesen Typr-Fix nach weiteren Tests wieder in den Upstream einbringen.

Das Problem "Zahlen sind vertauscht" wird mit der BiDi-Arbeit behandelt, die ich begonnen habe. Das kann vorerst mit expliziten LRO/PDF-Zeichen umgangen werden.

Halten Sie diese Art von Testfällen bereit! 🤩

Das war schnell.
Nun, ich habe nichts gefunden, das mehr repariert werden muss, außer was mit der von Ihnen erwähnten BiDi-Arbeit getan werden kann (Zahl und Klammern können häufig mit arabischem Text verwendet werden).
Können Sie ein Beispiel für die Verwendung von LRO/PDF-Zeichen zeigen? Ich konnte das gemischte Textbeispiel nicht selbst reproduzieren.

Die letzte Sache, die nicht mit arabischem Text, aber vielleicht mit dem SDF-Rendering zusammenhängt, ist, dass einige Zeichen innen schwarz sind, wenn 2 Zeichen wie hier miteinander verbunden sind
image
image
und manchmal innerhalb desselben Charakters
image
Dies ist nur bei der Schriftart Lemonda sichtbar. Scheherazade, Cairo funktionieren gut (vielleicht, weil die Charaktere an der richtigen Stelle zusammenkommen).
(Sieht aus wie eine boolesche Operation im Vektor-Rendering-Tool.)

Und danke nochmal für deine Arbeit.

Danke! Ich arbeite derzeit daran, eine vollständige Bidi-Algorithmus-Implementierung hinzuzufügen, die meiner Meinung nach alle anderen Probleme, die Sie bisher beschrieben haben, beseitigen sollte.

Der „BiDi 1“-Text in der Dropdown-Liste des Beispiels enthält ein Beispiel für LRO/PDF, aber machen Sie sich vorerst keine Sorgen darüber, es ist nur ein Notbehelf und ist sowieso nicht wirklich korrekt. True Bidi wird besser sein.

Das Problem mit der booleschen Füllung bei dieser Schriftart ist das gleiche wie in # 57 besprochen, denke ich.

Wir haben jetzt volle Bidi-Unterstützung!

image

Es gibt ein paar Bidi-Snippets auf der Beispielseite, aber testen Sie sie mit Ihrem eigenen gemischten rtl+ltr-Text.

Dies wurde zu einem klassischen Beispiel dafür, wie ich in einen Kaninchenbau hinunterging; Ich habe keine passende JS-Bidi-Implementierung gefunden und wollte fribidi.wasm nicht einbringen, also entschied ich mich, eine neue JS-Implementierung als Nacht- und Wochenendprojekt zu wagen. Siehe https://github.com/lojjic/bidi-js! Ich muss dort einige Dokumente hinzufügen, aber es ist gemäß den offiziellen Bidi-Tests vollständig konform, ziemlich klein (~ 10 KB) und ziemlich schnell, obwohl es wahrscheinlich weiter optimiert werden könnte.

Ich bin sehr zufrieden mit dieser Lösung und wie wenig sie zur Bündelgröße beiträgt. Ich denke, wir sind jetzt ganz nah dran an der vollen RTL-Unterstützung. Ich muss jedoch die Verknüpfungslogik für Formulare überdenken. Mir wurde klar, dass die Logik, die ich von opentype.js angepasst habe, nur arabische Skripte verarbeitet, aber keine anderen, die auch Verknüpfungen ausführen.

Ich habe eine vollständigere Implementierung der Join-Typ-Erkennung vorangetrieben; Die Logik, die ich von Opentype.js übernommen hatte, erwies sich als unvollständig. Die neue Implementierung bettet tatsächlich eine stark komprimierte Version der Unicode-Joint-Type-Definitionen ein, sodass sie jetzt alle kombinierbaren Zeichen auf Arabisch und anders handhaben sollte. Es gibt auch einen anständigen Geschwindigkeitsschub über den Typr-Code.

@MichaelHazani Da Sie sich freiwillig gemeldet haben, Hebräisch zu testen, denke ich, dass dies jetzt für Sie bereit ist. Sie können diese Testseite verwenden, auf der ich ein paar hebräische Schriftarten zum Dropdown-Menü "Schriftart" hinzugefügt habe, und Sie können Ihren eigenen Text eingeben. Danke!

Sieht großartig aus!
("Nun, der Test scheint ein Erfolg zu sein. Satzzeichen sind dort, wo sie sein sollten; Rechtsausrichtung sieht gut aus. Beide Schriftarten zeigen Hebräisch so an, wie es angezeigt werden sollte. Das Umschalten auf Englisch, dh dieses Wort, bricht die Ausrichtung nicht. Gut gemacht!")
image

Ich habe v0.41.0 mit der bisher hier geleisteten Arbeit veröffentlicht. Es gibt zweifellos andere RTL-Skripte, die eine zusätzliche spezialisierte Behandlung erfordern, aber dies gibt eine solide Grundlage, die meiner Meinung nach von Fall zu Fall behandelt werden kann. Und es besteht immer die Möglichkeit, ein optionales Harfbuzz-Plugin (#91) für einige der fortgeschritteneren/undurchsichtigeren Fälle zuzulassen.

Nochmals vielen Dank @boulabiar und @MichaelHazani für Ihre unschätzbare Hilfe hier!!! 🎉

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

lojjic picture lojjic  ·  18Kommentare

arpu picture arpu  ·  43Kommentare

stephencorwin picture stephencorwin  ·  39Kommentare

atlmtw picture atlmtw  ·  47Kommentare

drcmda picture drcmda  ·  11Kommentare