Troika: 右から左へのテキストレイアウトのサポート

まず、これに取り組んでいただきありがとうございます。 アラビア語とRTLのレイアウトをサポートすると、多くの人に役立ちます。
私はいくつかの最初のテストを行いました。標準のアラビア語テキストは、カイロ、レモナダ、シェヘラザードのフォント（Tachkilなし）でほとんどサポートされています。

私はアラビア語の次の2つのルールをテストしていました。

1. 文字の書き方の3つの形式（最初、途中、最後に1つ）と接続（合字）が適切かどうか。
2. 発音の表示のセットであるTachkil ُ َ ً ٌ（まれな場合を除いてインターネットで見つけるほとんどのテキストでは使用されません）

ミルザでは、一部の内部文字が接続されていません（内部文字またはその他の文字の代わりに文字の終了形式が配置されます）

tachkilを使用すると、一部のフォントは正常に機能しましたが、他のフォントはその隣の文字の形式を変更しました。 ボックスに書いたテキストを使って作業したものもあれば、コピーしたテキストを使っていないものもあります。

括弧「（」、「）」のようなアラビア文字以外の文字を使用すると、それらは切り替えられます（逆にする必要があります）。

これは私が行った簡単なテストです。もっとチェックして、物事がおかしくなるところの詳細を説明する必要があります。 （フォントも確認する必要があります。一部のフォントでは必要な文字が表示されません）

まことにありがとうございます！ それがまともなスタートを切ったと聞いてうれしいです。

単語位置の置換の結果がフォントによって異なるのは興味深いことです。 Typrの単語位置検出ロジックは常に同じであるため、これらのフォントがTyprが処理しない置換をエンコードする方法に何か違いがあるはずです。 特にミルザを調べて、違いを判断できるかどうかを確認します。

私はこれらの文字を知らないので、自分で正しいか間違っているかを判断できないので、期待される結果を備えたターゲットテストケースをいくつか教えていただければ非常に役立ちます。

入力テキスト：xxx
次のようになります：[画像]
フォントAで正しく見える：[画像]
フォントBで正しくないように見えます：[画像]

括弧に関しては、それがBidiアルゴリズムのペアブラケット部分だと思います。 それが自分で取り組むかどうかはまだわかりませんが、必ず調べていきます。

大まかな双方向レイアウトをサポートするコードをプッシュしました。 現在、方向範囲を定義するためにLRO / RLO / PDF制御文字を使用するのは純粋に手動です。 全自動ビディははるかに複雑で、まだ頭をそのスコープに巻き付けていますが、範囲を（行の折り返しと選択で！）レイアウトできることは重要なスタートです。

昨日フィードバックを投稿していませんでした。 週末にフルテストをすることを考えましたが、段階的に行う方がいいと思います。
非常にうまく機能するフォントから始めましょう（一部のフォントでは問題が発生する可能性があります）。私はフォントScheherazadeを使用しましたが、CairoとLemonadaで同じ結果が得られます。
MirzaフォントとAmiriフォントは、常に接続されていない文字を表示します。
フォントNotoSans、Robotoはまったく機能しません。

下の写真では、私は文字の間違った形を意味するために赤を使用しました、そして緑は正しい形です。
この問題は、Tachkil（ボーカルノート）またはラテン文字または数字の文字がある場合にのみ発生します。

1. 最終的なフォームの代わりに、内部フォームがあります。
2. 単語の中には、最初のフォームの代わりに、内部フォームがあります。 （単語の中には合字がない文字もあります）
3. 単語の直後に数字がある場合、（كم2）は終了形式を保持します。
4. 番号が逆になります。

私が使用したテキスト：
كم2。
كم2
بِسماللَّهالرحمنالرحيم
بِسمِاللَّهِالرَّحمٰنِالرَّحيمِ

この回答には、文字がどのように描かれるかについての絵が含まれています
https://www.quora.com/How-can-anyone-read-Arabic-as-the-letters-are-all-connected-to-each-other/answer/Hashem-Mohamed-4

このマークアップされたテストケースをどうもありがとう、それは非常に役に立ちます!!! それは本当に私が物事を理解するのに役立ちます。

単語の位置を検出するためのTyprのロジックは間違いなく誤りです。 opentype.jsから採用されたロジックでオーバーライドしましたが、結果ははるかに良くなっているようです。

さらにテストした後、Typrの修正をアップストリームに戻すことに貢献します。

「数字が逆になっている」問題は、私が始めたBiDiの作業で処理されます。 今のところ、これは明示的なLRO / PDF文字で回避できます。

これらの種類のテストケースを今後も続けてください！ 🤩

それは速かった。
さて、あなたが言及したBiDi作業を使用して実行できることを除いて、さらに修正が必要なものは見つかりませんでした（数字と括弧はアラビア語のテキストで広く使用できます）。
LRO / PDF文字の使用方法の例を示していただけますか？ 混合テキストの例を自分で再現することはできませんでした。

最後に、アラビア語のテキストとは関係ありませんが、SDFレンダリングに関係している可能性があります。ここのように、2つの文字を接続すると、一部の文字の内部が黒くなります。


時には同じキャラクターの中で

これは、Lemondaフォントでのみ表示されます。 シェヘラザード、カイロはうまく機能します（おそらくキャラクターが正しい場所で接続しているためです）。
（ベクトルレンダリングツールのブール演算のように見えます。）

そして、あなたの仕事にもう一度感謝します。

ありがとう！ 私は現在、完全なbidiアルゴリズムの実装を追加する作業を行っています。これにより、これまでに説明した他のすべての問題が解決されるはずです。

例のドロップダウンの「BiDi1」テキストにはLRO / PDFの例がありますが、今のところ心配しないでください。これは単なる一時的なものであり、とにかく正しくありません。 真のビディが良くなります。

そのフォントのブール塗りつぶしの問題は、＃57で説明したものと同じだと思います。

ビディをフルサポートしました！

サンプルページにはいくつかのbidiスニペットがありますが、独自の混合rtl + ltrテキストを使用してテストを行ってください。

これは、私がうさぎの穴を下る典型的な例になりました。 適切なJSbidi実装が見つからず、fribidi.wasmを持ち込みたくなかったので、夜と週末のプロジェクトとして新しいJS実装を試してみることにしました。 https://github.com/lojjic/bidi-jsを見よ！ そこにいくつかのドキュメントを追加する必要がありますが、公式のBidiテストによると完全に準拠しており、非常に小さく（〜10kb）、かなり高速ですが、おそらくもっと最適化できます。

私はこのソリューションに本当に満足しており、バンドルサイズに少ししか追加されません。 現在、完全なRTLサポートに非常に近づいていると思います。 ただし、結合フォームロジックを再検討する必要がありますが、opentype.jsから採用したロジックはアラビア文字のみを処理し、結合を行う他のスクリプトは処理しないことに気付きました。

結合型検出のより完全な実装をプッシュしました。 私がOpentype.jsから採用したロジックは、不完全であることが判明しました。 新しい実装は、実際には高度に圧縮されたバージョンのUnicode結合型定義を組み込んでいるため、アラビア語などで結合可能なすべての文字を処理できるようになりました。 また、Typrコードよりもまともなスピードバンプを提供します。

@MichaelHazaniヘブライ語のテストを志願して以来、これで準備ができたと思います。 「フォント」ドロップダウンにいくつかのヘブライ語フォントを追加したこのテストページを使用して、独自のテキストを入力できます。 ありがとう！

素晴らしく見える！
（「まあ、テストは成功したようです。句読点は本来あるべき場所です。右揃えは見栄えがします。どちらのフォントもヘブライ語を表示どおりに表示します。英語、つまりこの単語に切り替えても、配置が崩れることはありません。素晴らしい！"）

これまでにここで行った作業でv0.41.0をリリースしました。 間違いなく、追加の特殊な処理を必要とする他のRTLスクリプトがありますが、これにより、ケースバイケースで処理できると思う十分なベースラインが得られます。 また、一部のより高度な/あいまいなケースでは、オプションのHarfbuzzプラグイン（＃91）を許可する可能性が常にあります。

ここで貴重な助けをありがとう@boulabiarと@MichaelHazani !!! 🎉