Xterm.js: دعم لغات RTL

إنه في الواقع أكثر تعقيدًا بكثير ويتضمن الحالة وحتى عكس بعض الشخصيات. أود أن أقول إنه علم خاص به. (وأنا أكن أعمق الاحترام لأولئك الأشخاص الذين كتبوا مكتبات عرض نصوص قوية تتعامل مع جميع مشكلات ثنائية الاتجاه بشكل صحيح ، لذلك لا يتعين علي العبث بها ، لأكون صادقًا.)

أنظر أيضا:
https://en.wikipedia.org/wiki/Bi-directional_text (نظرة عامة جيدة)
https://www.w3.org/International/articles/inline-bidi-markup/uba-basics
https://www.w3.org/International/tutorials/svg-tiny-bidi/ (الافتراض الأولي ليس مرتبطًا ولكنه يشرح بعض الأشياء بشكل أفضل من الرابط السابق)
https://github.com/fevangelou/doctype-mirror/tree/master/bidihowto/bidi-support-in-a-ui

تحرير: أعتقد أن الطريقة التي يعمل بها التحديد الجديد قد تكون في الواقع غير متوقعة لأنها ستتصرف بشكل مختلف عن VSCode نفسه. على سبيل المثال، وبالنظر إلى نص "أغنية מדינת קומבינה يجعلني أفكر"، عندما أبدأ اختيار في "و" ونهاية بين الكلمات العبرية اثنين، وسوف اخترته "الأغنية מדינת"، بينما في وحدة التحكم سوف اخترته "الأغنية קומבינה".

انظر المثال:

ومع ذلك ، سيظل أفضل من طريقة عمل Sublime Text في المرة الأخيرة التي راجعت فيها ، لأنك سترى شيئًا محددًا ولكنك تنسخ شيئًا آخر ، وهو أمر مزعج للغاية.

تضمين التغريدة
بادئ ذي بدء ، سأقدم لك منظورًا موجزًا ​​جدًا للغة العربية والفارسية ، ربما يساعدك (لست متأكدًا مما إذا كانت العبرية هي نفسها).
في اللغتين العربية والفارسية تكون الحروف الهجائية مثل "آ" "ب" "س" وهكذا. والكلمات مكونة من هذه الحروف الهجائية (من الواضح) بقاعدة مختلفة تمامًا بالمقارنة مع الإنجليزية على سبيل المثال.
الفرق أن لدينا أكثر من شكل لبعض الأبجدية مثل "س" ، الشكل الأول هو "س" والشكل الثاني "سـ" والآخر "ـسـ" والآخر "ـس". وما فائدة هذه الأشكال؟ بناءً على مكان ظهور الأبجدية في الكلمة ، يختلف شكل الأبجدية التي نستخدمها. على سبيل المثال ، للأبجدية المذكورة "س" نستخدم الشكل "سـ" عندما تبدأ الكلمة بهذه الأبجدية مثل "سلام". هنا تكمن المشكلة والفرق في الواقع بين لغة مثل الإنجليزية والفارسية أو العربية. نقوم بتوليد كلمات بهذه اللغات من خلال تلخيص الأشكال المختلفة لهذه الحروف الهجائية (نلتزم بها معًا في بعض الحالات). مرة أخرى ، أسلط الضوء على هذه القاعدة: نحن نولد هذه الكلمات من خلال تجميع الأشكال وليس الحروف الهجائية (والتي دائمًا ما تكون مرتبطة بالأبجديات باللغة الإنجليزية) ، يمكنك رؤية بعض الأمثلة أدناه:
لدينا الحروف الهجائية "ک" "ن" "ا" "د" "ی"
أصنع هذه الكلمات بالأبجديات التي تم ذكرها للتو: نادان ، یاد ، دکان
لذا ، لإغلاقها وإعطائك فكرة عما حدث في لقطات الشاشة التي نشرتها ، تقوم المحطة بتقسيم الكلمات إلى أبجدية وعكسها (لذلك لا يتعلق الأمر فقط بالعكس). ألق نظرة على الكلمات التي قمت بإنشائها والحروف الهجائية التي ذكرتها من قبل ، والآن تعرضها محطة VS "منفصلة" و "معكوسة".

التنسيق الصحيح: نادان Terminal: ن ا د ا ن
التنسيق الصحيح: یاد طرفية: د ا ی
التنسيق الصحيح: دکان المحطة الطرفية: ن ک د

الآن أسئلتك:
أين يجب قلب السلاسل بالنسبة للعبرية / العربية / الفارسية ، هل أقوم بعكس التسلسلات المستمرة الكاملة للأحرف بين أحرف أسكي؟
ليس لدي أي فكرة عن العبرية ، ولكن في اللغة العربية والفارسية ، يجب أن تنقلب تسلسلات الأحرف عندما تصادف حرف مسافة (فاصل الكلمة هو مسافة) مثل هذا: "من در حال نوشتن هستم" ولكن لا يزال يجب أن تحتفظ "الأشكال" والالتزام الضروري.

كيف من المفترض أن تتفاعل الأحرف مع أحرف مثل 0-9 أو علامات الترقيم؟
حول الأرقام وعلامات الترقيم ، القواعد هي نفسها الإنجليزية والأرقام وعلامات الترقيم تتبع الأحرف. مثله:
من الأمور الأساسية؟
من سالمة "1369" إلى دنیا آمدم.
في الواقع ، فإن تسلسل الأحرف الذي يحتوي على أحرف RTL و non-RTL هو قصة مختلفة تمامًا ، وإذا كنت بحاجة إلى مزيد من المعلومات ، فيمكنني توضيح ذلك.

PS 1:
هذا الرابط هنا هو رمز مصدر تمت كتابته لحل نفس المشكلة في PHP (للإصدارات القديمة بالتأكيد) يمكنك إلقاء نظرة
https://github.com/slashmili/php-gd-persian/blob/master/phpgd/fagd.php

PS 2:
هنا مصدر على ويكيبيديا عن الشخصيات الفارسية
https://en.wikipedia.org/wiki/Persian_alphabet

PS 3:
مرة أخرى ، يجب أن أذكر أنه في الإصدار السابق من VS Code ، كان كل شيء على ما يرام.

PS 4:
حول مشكلة اختيار كلمة تحتوي على بعض أحرف LTR مثل
<p>اینجا را بخوانید</p> الذي ذكره CherryDT ، هناك بعض الأخطاء الطفيفة التي لا

بعد تحديث vscode الخاص بي ، كل شيء معكوس ، هذا سيء جدًا ، يرجى حل هذه المشكلة
أريد الرجوع إلى إصدار أقدم ، إصدار الساحرة على ما يرام؟

@ mostafa69d لحسن الحظ بالعبرية أنه بالكاد موجود. الحروف العبرية البقاء في الغالب نفس في أي موقف داخل كلمة واحدة، إلى جانب عدد قليل من الرسائل التي هي כ الذي يتحول إلى ך، ثم מ الذي يتحول إلى ם، ثم נ الذي يتحول إلى ן، ثم פ الذي يتحول إلى ף وأخيرا צ الذي يتحول إلى . أعتقد أن هذا يجعل تنسيق اللغة العبرية أسهل.

ومع ذلك ، لا تزال هذه الأحرف منفصلة (من حيث ترميز الأحرف) وتعرض دائمًا نفس الأحرف. لا يغيرون مظهرهم عند تحريكهم. (إن وظيفة الكاتب هي استخدام الحرف الصحيح - سواء أكان ذلك أو لا - في الموضع الصحيح).

تكمن مشكلة تقسيم الأحرف في أنها عندما يتم لفها ضمن مسافة واحدة تلو الأخرى ، فإنها تتطلب اتصالاً وستفتقد لتمثيل الشكل (الحروف العربية).

لإصلاح المشكلة ، يجب أن تكون هذه الأحرف في نطاق واحد أو لا تلتف عليها على الإطلاق.

قائمة يونيكود جميع هذه الأحرف
العربية (0600–06FF ، 255 حرفًا)
ملحق عربي (0750–077F ، 48 حرفًا)
العربية الموسعة- A (08A0–08FF ، 73 حرفًا)
نماذج العروض التقديمية العربية- A (FB50 – FDFF ، 611 حرفًا)
نماذج العروض التقديمية العربية- B (FE70 – FEFF ، 141 حرفًا)
الرموز الرقمية الرومي (10E60–10E7F ، 31 حرفًا)
الرموز الأبجدية الرياضية العربية (1EE00–1EEFF ، 143 حرفًا)

القراءة المطلوبة: https://opensource.com/life/16/3/twisted-road-right-left-language-support

من https://github.com/Microsoft/vscode/issues/28571#issuecomment -307991443

هل لديك مثال على محطة أخرى تتعامل مع هذا بشكل جيد؟

يبدو أن mlterm أفضل من المحطة الطرفية المتوسطة (التي لا تعتمد على الويب).

إنها مخطوطة ولكن في بعض الحالات مقطوعة ، أعتقد أنه يمكن حلها عن طريق تغيير الخط ، تم نسخ هذه الفقرة من ويكيبيديا ، والأحرف الزرقاء هي علامة RTL ، وهذه هي الطريقة التي يخرجها vim و mlterm تجعلها باللون الأزرق.

قد تتمكن واجهة API الخاصة بنجار الأحرف من حل هذا الأمر ، ومن المحتمل أن نجعل كل ما هو متجاور من اللغة العربية / العبرية / إلخ. تنضم أحرف unicode ويتم رسمها في نفس الصورة الرمزية.

لما يستحق ، تعمل وحدة التصحيح بشكل جيد مع نصوص RTL. هذا ما جربته:

وهذا هو الإخراج على وحدة التصحيح:

لكن المحطة لا تزال كما هي:

أنا أستخدم VS Code - Insiders v1.31.0.

babakks فقط konsole و mlterm ، وهما متاحان في جميع التوزيعات.

@ elieobeid7babakks ماك OS الانتاج محطة RTL بشكل صحيح

ضع PR لإصلاح هذا ، إذا أراد أي شخص اختبار الفرع الذي سيكون مفيدًا لأنني لا أتحدث هذه اللغات. https://github.com/xtermjs/xterm.js/pull/1899

لاختبار:

git clone https://github.com/Tyriar/xterm.js
cd xterm.js
git checkout 701_rtl_support
yarn
yarn watch

# another terminals
yarn start

قد تحتاج إلى تثبيت بعض التبعيات https://github.com/Microsoft/node-pty#dependencies

يرجى الانتظار قليلا :)

لقد كنت أعمل مؤخرًا على دراسة وتقييم المستندات الحالية وعمليات تنفيذ RTL في المحطات ، والتوصل إلى (مسودة) توصية. سأفرج عنه قريبًا الآن.

إنها طريقة أكثر تعقيدًا مما يعتقده المرء أولاً. القليل من المفسد: إذا بدأت خلط الأحرف وفقًا لخوارزمية BiDi ، فسيصبح من المستحيل عمليًا الحصول على تجربة عرض تحرير نصوص مدركة لـ BiDi (على سبيل المثال vim ، emacs ...) أعلى هذا النظام الأساسي . (وللرد على التعليقات القليلة السابقة: لا ، و konsole ، و mlterm ، و macOS Terminal لا تفهمها بشكل صحيح أيضًا.)

egmontkob هل يأخذ هذا في الحسبان حقيقة أننا نحصل على دعم

Tyriar آسف Tyriar ، لكنها لا تزال خاطئة. لقد علقت تحت طلب السحب.
https://github.com/xtermjs/xterm.js/pull/1899#issuecomment -455333377

تحدد المواصفات كيف يجب أن تبدو اللوحة القماشية بعد تلقي بعض البيانات. المواصفات لا تهتم بما هي الواجهة الخلفية للمحاكي الطرفي (على سبيل المثال لوحة رسومية ، أو متصفح (HTML DOM) ، أو محاكي طرفي آخر (tmux)) ، إنها مهمة المحاكي الطرفي لتنفيذ السلوك المحدد بأي وسيلة .

وأحد جوانب السلوك المحدد هو أنه في بعض الحالات ، يجب تبديل خلايا الأحرف وفقًا لخوارزمية BiDi (لأغراض العرض فقط ، دون التأثير على التخزين الفعلي) ، لأن هذه هي الطريقة المعقولة الوحيدة للحصول على أدوات مساعدة بسيطة مثل "cat "إنتاج المخرجات المرغوبة ؛ وفي بعض الظروف الأخرى ، لا يجب إعادة ترتيب الخلايا ، لأن هذه هي الطريقة الوحيدة التي يمكن أن يقوم بها vim / emacs / من يمكنه عمل BiDi الخاص به. هناك تسلسلات هروب تتحكم في هذا السلوك. وهناك الكثير من القصة أكثر من هذا.

يرجى الاطلاع على مسودة مواصفات BiDi المنشورة على https://terminal-wg.pages.freedesktop.org/bidi/ . نرحب بالتعليقات وأفكار التحسين وما إلى ذلك في أداة تعقب المشكلات الخاصة بها.