間違い -RTLテキストの文脈における矢印の方向

特徴
1

これはDiscourseの双方向設定とは全く関係ありません。

-> を入力すると矢印文字 → に変換されるため、A -> B は「A → B」と表示されます。これは非常にクールです。

しかし、RTLテキストでは矢印が逆方向になります: א -> ב は「א → ב」と表示され、矢印が逆方向になります。（もしあなたがこのバグが修正された未来でこれを読んでいる場合、これは「א → ב」と表示されていました）

ここで入力された文字シーケンスは次のとおりです。

文字 名前
א HEBREW LETTER ALEF
SPACE
- HYPHEN-MINUS
> GREATER-THAN SIGN
SPACE
ב HEBREW LETTER BET

これは、このツール https://unicodedecode.com/ に文字列 א -> ב をコピーして貼り付けることで確認できます。

これは、矢印文字がUnicodeで双方向ミラーリングされないためです。関連文書: https://www.unicode.org/L2/L2022/22026r-non-bidi-mirroring.pdf

特に、矢印および矢印のような文字は、それぞれ鏡像文字を持つことがよくあります。それらは Bidi_Mirrored=Yes プロパティ値を持つべきだと主張することもできますが、それらは持っておらず、今から取得することもできません。

残念ながら、双方向反転する矢印文字は存在しないため、この置換を正しく行うには、双方向のテキスト方向を判断して、<- と -> の矢印を正しく選択する必要があります。これは簡単なタスクではありません。

「いいね！」 1
2

@falco これはバグであり、機能リクエストではないと主張します。出力はユーザーの意図や期待とは正反対です。

3

これは、新しい機能を作成する必要があることを意味します。現在、Unicode仕様に従っているため、Feature requestに再分類しました。

実際の問題に対処することに移り、既存のapi.decorateCooked APIを使用して、#theme-componentで簡単に実行できると思います。

「いいね！」 2
4

ありがとうございます。特に急いで修正してほしいフォーラムはありませんが、Discourseで修正すべきだと思います。

無意味な言葉遊びの議論はしたくないので、この辺で終わりにします。私が言いたいことは言いました。これはバグとして考慮されるべきだと思いますが、それをどうするかはあなた次第です。

ご配慮と迅速なご対応に感謝します :slight_smile:

「いいね！」 1
5

まあ… 人間には限界がある。最後に一つだけ言っておこう（約束する）。私の知る限り、Unicode仕様では -\u003e を → に変換することは推奨されていない（そして、この問題はその理由の一つとなる）。そのため、この既存のDiscourseの機能はUnicode仕様に従っておらず、テキストに関する誤った仮定をして、その過程でこのバグを導入している。私はそのように見ている。（それでも、この機能は素晴らしいと思う）

これで、言いたいことはすべて言った！

「いいね！」 3
6

右から左へ入力する言語で「ダッシュ」の後に「小なり」を入力すると、次のように左向き矢印（←）に変換されることを期待するのは妥当だと思います。しかし、小なりを入力すると、コンポーザーはなぜか大なりを挿入します。これは全く予期せぬ動作でした。これがバグなのでしょうか？

RTLテキストボックス（例えばaljazeera.netの検索ボックス）では、数字や数学記号がRTLテキスト内にLTR順で挿入されることに気づきました。これは自然な動作のように思えます。（ラテン文字でも同様です）

以下に、RTLコンテキストで「小なりは < で大なりは > です」と入力してみます（RTLロケールでどのように動作するかは分かりません）。

‮小なりは < で大なりは > です

「いいね！」 3
7

日常的に右から左へのスクリプトを使用していないですよね？あなたが説明したことにはバグはありません。あなたの発言には曖昧な点があるので、混乱を防ぐために、あなたのコメントの後半部分から先に説明します。

これはまさに期待通りの動作です。このように考えてください。

文字 > は文字通り「より大きい」を意味します。「A > B」という文字列は「AはBより大きい」を意味します。

同様に、「א は ב より大きい」と言うには、「より大きい」を同じコード U+003E の 同じ大なり記号 で置き換えます。しかし、文字列全体がRTLであるため、「א」は「ב」の右側に表示されます。「大なり記号」がLTRと同じようにレンダリングされると、次のようになります：א<ב これは「א は ב より小さい」または「ב は א より大きい」と読まれ、説明されている関係とは正反対になります。

これが、大なり記号をレンダリングする際に、RTLコンテキスト内では視覚的に反転される理由です。しかし、基になる文字とそれを支えるUnicodeデータは、依然として「大なり」記号です。文字列は依然として「א は ב より大きい」を意味します。

さて、最初の質問に戻りましょう。

キーボードレイアウトをヘブライ語やアラビア語のようなRTL言語に変更すると、Shift + , （< が印刷されているキー）のキーコンビネーションは、実際には「大なり」記号 > を入力します。これは、検索ボックスで見つけたようなRTLコンテキストでは、‏>‏ としてレンダリングされます。

[編集：次の段落は、あなたがテストした内容を少し誤解していたときに書かれました。RTLキーボードでLTRボックスに入力していると思っていましたが、実際にはその逆でした。それでもあなたの混乱を解消できたことを願っています。]

しかし、あなたはまだラテンキーボードレイアウトを使用しているので、そのキーコンビネーションを押すと、「小なり」記号 < が挿入されます。しかし、RTLでは右側にあるものが左側にあるものより小さいことを意味するため、‏<‏ としてレンダリングされます。

結論：文字は同じですが、そのレンダリングはミラーリングされます。

ここまでの説明で理解していただけたなら、それが -< または RTL では ‏-<`‏ となり、おそらくあなたが意図したものではないことを理解していただけるでしょう。

うまく説明できましたか、それともさらに混乱させてしまいましたか？

「いいね！」 1
8

公式のUnicodeドキュメントの方が良いと思われる場合は、こちらをお試しください: UAX #9: Unicode Bidirectional Algorithm 「mirror」でCtrl+Fを検索すると、良い説明と例が見つかります。

「いいね！」 1
9

おっしゃる通り、経験もなく、ラテン語キーボードで入力しています！

なので、黙っているべきなのですが、ラテン語キーボードで「3<6」と入力すると、以下のようになります。

image
image200×126 1.98 KB

おそらく、あなたが正しく、私が間違っていることを示しており、それは驚くことではありません！

「いいね！」 2
10

とんでもない！ RTLユーザーだけがRTLのバグについて議論したり修正したりすることが許されるとしたら、私たちはもっとひどい状況になっていたでしょう！ この機会に、この件についてご紹介しました。 頭を整理するには時間がかかるはずです。 これについてさらに質問や疑問があれば、喜んでお答えします。

「いいね！」 1
11

Unicodeメーリングリストに参加し、このようなケースの解決策となるUnicodeへの追加を提案しました。寄せられた回答の一つがこれです。

（私：）問題は、この置換が（私の知る限り）レンダリングコンテキストなしで行われることです。テキストは単なる文字コードのシーケンスです。テキストの方向を知ることは合理的ではありません。テキストの方向が、置換時に利用できないコンテキストに依存する場合、完全に不可能なこともあります。

上記は厳密には不正確です。今日の真剣なテキストレンダリングは、HarfBuzzのようなシェーピングエンジンを必要とし、「-」と「>」の合字「→」は、合字をサポートするフォントと連携してそのようなシェーパーによって行われます。シェーピングエンジンは、bidiコンテキストとシェーピングするテキストのスクリプトを認識しているため、原理的には矢印をミラーリングできます。

彼らはこのようなものについて話しています：GitHub - tonsky/FiraCode: Free monospaced font with programming ligatures

盲目的な文字置換ではなく、合字アプローチに切り替えることを検討してください。もう一つの議論の余地のある利点は、コピー＆ペーストした場合、テキストは矢印ではなく「-」と「>」のままになることです。

実装方法の技術的な詳細については調べていません。このソリューションを使用することを選択した場合は、あなたに任せます。

編集：案の定、特にFira TextはRTLを念頭に置いて設計されていないため、レンダリングはうまくいっていませんが、少なくとも正しい方向を向いています！https://fonts.google.com/specimen/Fira+Code?preview.text=A%20->%20B,%20א%20->%20ב
Firefox：

image
image473×164 5.61 KB

今日、これを正しく行い、RTL/bidiを明示的にサポートするフォントが存在するかどうかはわかりません。

「いいね！」 1
12

面白いことに、Chromium では異なる結果が得られます。
編集：今は再現できないので、このスクリーンショットを撮ったときに間違って入力したのだと思います。
編集：そして今、再び再現できます。状況は悪いです。

image
image524×165 5.86 KB

ブラウザのレンダリングエンジン/シェイパーがこのタスクに対応できていない可能性があります。もっと調査する必要がありますが、これは私が今焦点を当てるべきこと ではありません…

編集：フォーラムの制限により、前の返信からこれを削除する必要がありました。
参考までに、この置換を担当するコードは次のとおりです。

「いいね！」 1
14

前述したように、この問題に対するUnicodeソリューションの提案に取り組んでいます。そこでは、ここで説明したよりも徹底的かつ明確に問題を説明しているはずです。まだ作業中ですが、ご覧ください: Making sure you're not a bot! (パーマリンク)

特に、Discourseのセクションをご覧ください。

もちろん、Unicodeがこの提案を受け入れたとしても（最終的に提出するとき）、信頼できるほど広く実装されるまでには何年もかかるため、それを待つのは良い計画ではありません。