Xterm.js: دعم وصلات الخط

أعتقد أننا لسنا مهتمين بالأحرف المركبة العادية (في الواقع ، سيكون من السيئ تمكين الأحرف المركبة لـ li وما شابه) ، ولكن لأشياء مثل == ، !== ، => وهكذا. فيما يلي قائمة لطيفة من الأحرف المزدوجة التي يدعمها خط fira code monospace:
https://github.com/tonsky/FiraCode/blob/master/showcases/all_ligatures.png

ماذا سيحدث إذا كان نصف الرباط بلون مختلف؟ كيف ستتعامل مع هذا؟

LoganDark هل هذا يعمل حتى مع

لا و ​​لا.

أتساءل عما إذا كان من الممكن سحب كود العرض من txtjs ، لأنهم اكتشفوا كيفية تقديم الحروف المركبة ، على الرغم من أنني أعتقد أنهم يرسمون النص يدويًا. http://txtjs.com/examples/Text/ligatures.html

devsnek لا أعتقد أنها مشكلة فعلاً في تقديم النص. تكمن المشكلة في معرفة ارتباط الحرف بحيث يمكن جمعهما معًا (حاليًا "==" يتم رسمها كـ "=" و "=" ، وليس "==").

Tyriar لن

devsnek نعم ، ولكن يتم رسم كل خلية في الشبكة بشكل فردي مع بعض الاستثناءات (الرموز التعبيرية ، https://github.com/sourcelair/xterm.js/pull/938 لمزيد من السياق

devsnek هذا أنت

إخلاء المسؤولية: خارج الموضوع تمامًا ، مجرد تعليق عشوائي

LoganDark هل هذا يعمل حتى مع

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

أعتقد أنه من المقبول تمامًا إظهار الرموز الفردية إذا كان وضع التجسيد _not_ هو نفسه لجميع الأحرف الأساسية.

@ Qix - سيكون اقتراحي إذن هو رسم كل النص مرة واحدة ثم القيام بالتلوين في المنشور. سيؤدي ذلك إلى التخلص من أي مشكلات في الأحرف المركبة ، ولن يتطلب الكشف عن أزواج الروابط (على الرغم من أنه قد يكسر التوافق مع الخطوط ذات العرض المتغير ، أو حتى الخطوط أحادية المسافة التي تكون متوقفة قليلاً / لا تحتوي على عرض صحيح)

سوف تبدو الأحرف المركبة متعددة الألوان من لتلوينها IMO.

نعم ، لا أعتقد أن الحروف المركبة متعددة الألوان ستعمل. كما أنه يتعارض مع كيفية عملهم تحتها ، حيث يتم رسم حرف رسومي واحد في البداية ، وليس متعدد.

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

الآن بعد أن تم إصدار 2.0.0 الفائق ، قد تحتاج الحلول البديلة الضيقة إلى أولوية أعلى

المرجع https://github.com/zeit/hyper/issues/914#issuecomment -361034148

يعد تحديد تعيينات الحروف الرسومية يدويًا من الصعب كسرها. مما يمكنني قوله ، فإن إجراء تجربة لائقة من هذا يتطلب ما يلي:

1. قم بتعيين عائلة الخط المحددة مرة أخرى إلى الملف / المخزن المؤقت الذي يحتوي على بيانات الخط الفعلية (otf / ttf / woff / إلخ)
2. تحليل البيانات من جدول GSUB للخط وترجمته إلى مجموعة معقولة من القواعد لاستبدال الصورة الرمزية
3. قم بتمرير نوع من الخريطة أو وظيفة التعيين إلى xterm لتحديد ما سيتم عرضه لتسلسل أحرف معين

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

• لا توجد طريقة يمكنني العثور عليها لجلب بيانات الخط باستخدام واجهات برمجة تطبيقات المتصفح ، لذلك لن يعمل هذا كميزة مباشرة لـ xterm.js ، ولكن على الأرجح كحزمة / امتداد منفصل مع خطاف مكشوف بواسطة xterm.js

• يعد تعيين اسم CSS font-family لخط ما إلى ملف الخط الخاص به في Windows أمرًا مؤلمًا ولكنه يبدو ممكنًا. الطريقة الوحيدة التي وجدتها حتى الآن هي جلب كل شيء في %WINDIR%\Fonts وتحليل كل ملف أجده (المفسد: إنه بطيء حقًا). لم تجرب منصات أخرى حتى الآن. (ملاحظة: لقد حاولت أيضًا رفع الاسم من السجل ولكن التسمية لا تتماشى مع بعض الخطوط مثل تلك الموجودة في خطوط الطالب الذي يذاكر كثيرا. يستخدمون عائلة وعائلة فرعية "مفضلة" لم يتم التقاطها في اسم السجل ولكن يتم استخدامه في css font-family . إذا كنت فضوليًا ، يكون مفتاح التسجيل في HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts )

• توجد مكتبة تسمى opentype.js تقوم بتحليل كامل لجداول خطوط OpenType ولديها وظيفة font.stringToGlyphs(str) التي تتعامل مع الحروف المركبة الأساسية ، لكن الحروف المركبة لـ Fira Code (والعديد من خطوط الربط الشائعة الأخرى إن لم يكن جميعها) استخدام ميزة تسمى البدائل السياقية التي لم يتم دعمها بواسطة opentype.js (المدرجة ضمن المخطط ). يتم تحليل جدول GSUB الضروري إلى JSON من أجلك ، لذلك من الناحية النظرية كل ما هو مفقود هو تفسير بيانات الجدول.

• تستبدل الحروف المركبة في كود فيرا (وأعتقد أن البعض الآخر) الحروف الرسومية الأصلية بأعداد متساوية من الحروف الرسومية ، بدلاً من حرف واحد عريض إضافي (للحفاظ على خصائص الخط الأحادي). بالنسبة لسلسلة مثل ==> ، سينتهي الأمر بأن يخبرك الخط باستبداله بحرفين "LIG" (بشكل أساسي مسافة فارغة) ، متبوعًا بالحرف الرسومي الفعلي للربط ، والذي لا يزال من الناحية الفنية مسافة واحدة فقط حرف واسع. على الرغم من كونه أحادي العرض ظاهريًا ، فإن مسار الحرف الأخير يمتد إلى ما وراء الجانب الأيسر من المربع المحيط بالحرف ليغطي المساحة التي يشغلها حرفان LIG قبلهما. انظر أدناه للحصول على مرئي (0 و 600 هما جوانب مربع الشخصية). لا أعرف ما إذا كان هذا يعقد مهمة العارض أو ما إذا كان سيتعين تحويله قبل تمريره إلى xterm.js ، ولكن هناك شيء يجب أن تكون على دراية به.

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

• OpenType معقد. من المسلم به أنني لست خبيرًا في عرض الخطوط ، لكن عدد الاختلافات المحتملة التي تؤدي إلى أنواع مختلفة من العرض كبير جدًا. بدون مكتبة مدمجة تقوم برسم الخرائط لنا ، أعتقد أن الطريقة الأكثر منطقية لمهاجمة ذلك هي بشكل تدريجي. يستخدم Fira Code على وجه التحديد تنسيق Chaining Context Substitution 3 ، لكنني متأكد من وجود خطوط شائعة أخرى تستخدم خطوطًا مختلفة. نظرًا لأن لكل منها دلالات مختلفة قليلاً ، فمن المنطقي البدء بواحد والانتقال من هناك.

princjef شكرًا إنها مفيدة حقًا! لقد كنت أضع بعض الأفكار في هذا الموضوع منذ يومين ، وتوصلت إلى الاستنتاج التالي:

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

TBH ، لا أعتقد أنه يستحق الجهد المبذول لدعم الحروف المركبة في الوضع الحالي 😔

mofux أعتقد أنني وجدت طريقة (مستساغة إلى حد ما) لجعل الحروف المركبة تظهر في xterm.js من خلال الاقتراب منها من زاوية مختلفة. لقد فاتني بطريقة ما أن اللوحة القماشية ستعرض تلقائيًا الأحرف المركبة في تحقيقاتي الأولية. تصبح الحروف المركبة الداعمة مسألة التأكد من عرض الأحرف ذات الصلة معًا.

تحقيقًا لهذه الغاية ، قمت بتعديل عارض النص لعرض أحرف ذات سمات متطابقة (fg ، bg ، إلخ) كمجموعة واحدة. لن يؤدي هذا إلى عرض جميع الأحرف المركبة بشكل صحيح (وقد يؤدي إلى ظهور بعض الأحرف التي لا ينبغي أن تكون كذلك) ، ولكن يجب أن يؤدي إلى عرض ربط في أي مكان يتوقع شخص ما رؤيته. إليك لقطة شاشة لـ NeoVIM في التطبيق التجريبي باستخدام Fira Code (كما هو موضح في Firefox ، ويعمل أيضًا في Chrome ولكن ليس Edge):

الفرع موجود هنا إذا أراد الناس إلقاء نظرة: https://github.com/princjef/xterm.js/tree/ligature-support

بضع ملاحظات حول هذا:

• لم أقم بأي قياس معياري ، لكنني أراهن أن هذا لن يكون جيدًا للأداء. من خلال تجميع جميع الأحرف ذات النمط نفسه معًا ، يتم إلقاء أطلس الشخصيات بشكل أساسي من النافذة ، حتى في الأماكن التي لا توجد بها حروف مركبة (نظرًا لأننا لا نعرف أين ستكون / لن تكون). عندما أقوم بعرض أحرف متعددة معًا ، قمت فقط بتعيين رمز الحرف على Infinity للتأكد من أنني سأتجنب أي تخزين مؤقت.
• ربما توجد بعض حالات الحافة حول عرض الأحرف والتداخل التي لا أتعامل معها بشكل صحيح. هذا في الغالب إثبات للمفهوم في هذه المرحلة.

ماذا عن تقديم النص باستخدام أطلس الأحرف ، ثم إعادة عرضه في الخلفية ككتلة من النص أثناء الخمول؟ إذا كانت النتيجة هي نفس الصورة ، فيمكنك التخلص من النص المدمج والعودة إلى الأطلس. من خلال تقسيم سلاسل النص في الخلفية ، قد يكون من الممكن معرفة سلاسل النص التي يتم ربطها.

الجزء الصعب في ذلك هو أن عرض الأربطة لا يعتمد فقط على الأحرف التي تم استبدالها برباط ولكن أيضًا على سياقها. على سبيل المثال ، يجب أن يعرض '=== 1' علامات المساواة الثلاث على هيئة حروف مركبة ولكن '====' يجب أن يعرض نفس العلامات الثلاث المتساوية كأحرف منفصلة. لا يوجد حد لمدى اتساع هذا السياق ، لذلك سيكون من الصعب ومن المحتمل أن يكون عرضة للخطأ لتحديد قواعد وقت عرض الرابط من مخرجاته فقط.

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

هل من المعقول أن يكون لديك إعداد لتمكين الحروف المركبة ، التي تكتب
خط كامل في وقت واحد للمحطة؟ يبدو أن هذا من شأنه
ضمان العرض الصحيح ، وستكون نتيجة الأداء اختيارًا لـ
الناس الذين يهتمون بالحروف المركبة أكثر من السرعة.

في يوم الأحد ، 22 أبريل 2018 ، الساعة 16:21 ، كتب جيف برينسيبي [email protected] :

الجزء الصعب في ذلك هو أن تصيير الرابط يعتمد
ليس فقط على الأحرف التي تم استبدالها برباط ولكن أيضًا على سياقها.
على سبيل المثال ، يجب أن يعرض '=== 1' العلامات الثلاث المتساوية على هيئة روابط ولكن
يجب أن يعرض '====' نفس علامات المساواة الثلاث كأحرف منفصلة.
لا يوجد حد لمدى اتساع هذا السياق ، لذلك سيكون صعبًا و
من المحتمل أن تكون عرضة للخطأ لتحديد قواعد وقت تقديم الرابط
فقط من ناتجها.

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

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/xtermjs/xterm.js/issues/958#issuecomment-383420281 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAKyryMlayIQijY32GpWBmpvCUi13Wfbks5trRBigaJpZM4PRej6
.

princjef واو ، من السهل جدًا متابعة عمليات التحرير الخاصة بك ويبدو أن xterm يمكنه دعم الأحرف المركبة مع العارض. الحيلة هي فقط معرفة كيفية تعيين القواعد. هذا يعطيني الأمل.

princjef تحقيق عظيم!

لا توجد طريقة يمكنني العثور عليها لجلب بيانات الخط باستخدام واجهات برمجة تطبيقات المتصفح ، لذلك لن يعمل هذا كميزة مباشرة لـ xterm.js ، ولكن على الأرجح كحزمة / امتداد منفصل مع خطاف مكشوف بواسطة xterm.js

princjef أرى دعم الأربطة في نهاية المطاف يعيش على النحو التالي

• some-magical-package : تقوم وحدة العقدة الأصلية بسحب معلومات الخط الأصلي ، وتعيين سلاسل خط الويب إلى الملفات إن أمكن. يمكن أن يتم ذلك في AsyncWorker لتقليل نتيجة الأداء. ليست مشكلة كبيرة إذا تم ذلك ببطء ، وعند التشغيل الأول يستغرق الأمر عدة ثوانٍ للمسح وإجراء التحديث.

• xtermjs/xterm-ligature-support : ملحق يعتمد على العقدة ويستخدم some-magical-package للحصول على معلومات الخط وتخزينها مؤقتًا. يمكن لهذا الملحق إجراء فحص كلما تم اكتشاف خطوط غير معروفة في دليل الخطوط وطرد الخطوط عند إزالتها. أتوقع شيئًا مثل هذا مثل واجهة برمجة التطبيقات التقريبية:

  /** Returns a list of characters to be drawn together */
  export function getLigatures(fontFamily: string): string[] { ... }
  

هناك بعض الحروف المركبة التي لا معنى لها في المحطة ، حتى إذا كان الخط يدعمها (مثل li)

mofux لست متأكدًا من أننا بحاجة إلى القلق بشأن هذا؟ إذا طلب المستخدم الأحرف المركبة ألا يجب أن نعرضها جميعًا؟

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

mofux يجب أن نكون قادرين على إضافة دالة بسهولة لرسم مجموعة من الأحرف المتجاورة معًا.

princjef : لم أقم بأي قياس معياري ، لكني

wavebeem : هل من المعقول أن يكون لديك إعداد لتمكين الحروف المركبة ، التي تكتب سطرًا كاملاً في المرة الواحدة إلى المحطة؟

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

أيضًا فيما يتعلق بالأداء ، من المحتمل أن أعمل على إضافة خيار عرض DOM احتياطيًا في الأشهر القادمة نظرًا لوجود العديد من الأشياء التي يمكن أن تسوء مع دعم GPU في Chromium. راجع https://github.com/xtermjs/xterm.js/issues/1360. ستعمل الحروف المركبة خارج الصندوق في هذا الوضع.

ماذا عن تقديم النص باستخدام أطلس الأحرف ، ثم إعادة عرضه في الخلفية ككتلة من النص أثناء الخمول؟ إذا كانت النتيجة هي نفس الصورة ، فيمكنك التخلص من النص المدمج والعودة إلى الأطلس.

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

Tyriar أعتقد أن التصميم العام الذي وصفته منطقي. قد نكون قادرين على الابتعاد عن شيء لا يعتمد على الكود الأصلي للعثور على الخطوط في some-magical-package ، لكنه بالتأكيد سيعتمد على النظام الأساسي / نظام الملفات. لقد بدأت في اللعب بتحليل البدائل السياقية البديلة ولكن من الصعب تحديد مقدار الوقت الذي سيستغرقه الأمر بشكل صحيح.

أعتقد أيضًا أننا سنحتاج في النهاية إلى واجهة مختلفة قليلاً عن some-magical-package :

export function getSubstitutionRanges(fontFamily: string, text: string): Promise<[number, number][]>;

قواعد تحديد الحروف المركبة نفسها معقدة ومخبأة في عمق الخط نفسه. بدلاً من تمرير بيانات الخط نفسها ووضع عبء تفسيرها على xterm.js ، أود ترك ذلك للمكتبة الأخرى وجعلها تخبر xterm.js عن الأحرف التي يجب عرضها معًا. كما أن جوانب lookahead / lookbehind للسياق تعقد عملية التحليل. على سبيل المثال ، يتم تعيين '===' إلى حرف ربط ، ولكن ليس إذا كان متبوعًا بعلامة يساوي أخرى.

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

المشكلة الحقيقية الوحيدة هي تطبيق أساليب غير متجانسة عليها.

فقط لا تفعل. مرر كل سلسلة من النمط المستمر إلى الوظيفة بشكل منفصل. قد تتمكن من إجراء استثناء للنص المسطر إذا تم رسم التسطير بشكل منفصل.

قد نتمكن من التخلص من شيء لا يعتمد على الكود الأصلي

👍

قواعد تحديد الحروف المركبة نفسها معقدة ومخبأة في عمق الخط نفسه. بدلاً من تمرير بيانات الخط نفسها ووضع عبء تفسيرها على xterm.js ، أود ترك ذلك للمكتبة الأخرى وجعلها تخبر xterm.js عن الأحرف التي يجب عرضها معًا.

princjef يبدو هذا أفضل ، فكلما قل تأثير xterm.js في هذا المجال كان ذلك أفضل.

المشكلة الحقيقية الوحيدة هي تطبيق أساليب غير متجانسة عليها.

لا أعتقد أن أي شيء آخر يحاول القيام بذلك ، يجب علينا فقط إضافة حروف مركبة للنص الذي يستخدم نفس النمط.

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

ما زلت بحاجة إلى معرفة جزء البحث عن الخط. سنركز على ذلك بعد ذلك. توجد بعض الحزم بالخارج ولكن يبدو أنها كلها إما عربات التي تجرها الدواب أو سيئة الصيانة

princjef إذا كنت تريد التحقق من الخطوط الأخرى ، فأنا أستخدم Iosevka .

حسنًا ، لقد قمت بإنشاء حزمة تسمى font-ligatures (تُعرف أيضًا باسم some-magical-package ) وبعض الحزم المرتبطة حتى نتمكن من العثور على الخط الصحيح بكفاءة ثم معرفة مكان الأحرف المركبة لإدخال نص معين.

قضيت بعض الوقت في تحسين عملية العثور على الخط. على جهاز Surface Pro 4 مع حوالي 150 خطًا ttf / otf ، يمكنني جلب البيانات الوصفية للخط لكل منهم في 300-400 مللي ثانية. غالبًا ما يكون منضمًا إلى الإدخال / الإخراج ويمكن تشغيله في الخلفية لدورات التجسيد القليلة الأولى أثناء تحميله ، ولكن يجب أن يكون سريعًا بما يكفي ليتم تحميله بحلول الوقت الذي يبدأ فيه البرنامج النصي ويخرج بعض النص. بمجرد تحميله ، يمكننا تشغيل عرض لتحديث أي نص قد يكون موجودًا بالفعل. يمكن تكرار ذلك كلما تغير الخط أو يمكننا تخزين القائمة الكاملة مؤقتًا في المرة الأولى (أحضر القائمة الكاملة في البداية على أي حال).

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

ومع ذلك ، لم أمضِ أي وقت في تحسين / ضبط تحليل الأربطة. لقد أجريت بعض الاختبارات السريعة ويبدو أن تحليل الحروف المركبة يستغرق من 2 إلى 20 مللي ثانية لسلسلة طول معتدلة (اقرأ: سطر واحد). لا يزال هناك متسع كبير للتحسين ، لذا فأنا لست قلقًا جدًا في الوقت الحالي. كنت أرغب في الغالب في إخراج هذا لإظهار الواجهة والسماح للأشخاص بركل الإطارات إذا أرادوا.

تبدو رائعةprincjef! ما رأيك في إضافة الاختبارات إلى Fira Code مقابل 0xc0ffee ، 0x1234 ، و 17x32 ؟ (يتحول x إلى تسجيل مرات على هؤلاء)

تضمين التغريدة

أجريت بعض الاختبارات السريعة ويبدو أن تحليل الحروف المركبة يستغرق من 2 إلى 20 مللي ثانية لسلسلة طول معتدلة (اقرأ: سطر واحد)

هل يمكنك توجيهي إلى بعض الرموز المهمة التي تتحقق من هذا؟

@ j-f1 ، نعم هذه تعمل أيضًا: https://github.com/princjef/font-ligatures/blob/master/src/index.spec.ts#L136 -L137

Tyriar لقد أضفت للتو معيارًا أساسيًا يمكنك اللعب به. يبدو نمط الاستدعاء مثل node bench/lines.js <font-name> <input-text> [iterations] . يمكنك أيضًا تمرير سلسلة متعددة الأسطر أو توسيع ملف إدخال للنص وسوف يتنقل عبر الأسطر لمحاولة تجنب التحسينات غير الواقعية من تشغيل نفس الإدخال بالضبط بشكل متكرر.

أثناء كتابة ذلك ، لاحظت أنه حتى عندما أستخدم العديد من خطوط الإدخال المختلفة ، فإنها لا تزال تشهد زيادة كبيرة في الأداء بعد التشغيل الأول. بالنسبة إلى ما يقرب من 10 من مدخلات الأحرف ، أرى متوسط ​​جزء من جزء من المللي ثانية لـ Iosevka وما يزيد قليلاً عن نصف ميلي ثانية لكود Fira. إما أن أواجه حالة خاصة أو أن Turbofan يعمل فهو سحر. لا تزال غير فعالة بما يكفي لاستخدامها كما هي ولكني سأبدأ في التركيز على تحسينات الأداء بعد ذلك (عند هذه النقطة ربما سأضيف أيضًا معيارًا أفضل للتعرف على التحسينات).

بضع ملاحظات:

• نظرًا للطريقة التي تعمل بها البدائل ، أتوقع أن يقيس وقت التنفيذ خطيًا مع حجم الإدخال ، على الرغم من أنني لم أتحقق من ذلك
• نظرًا لعدد الأحرف المركبة وطريقة عمل البدائل ، فإن Fira Code أكثر كثافة في التحليل من Iosevka أو Monoid. أرى بانتظام أن القيام برمز فيرا يستغرق من 5 إلى 10 أضعاف الوقت الذي تستغرقه Iosevka.
• تعمل الخطوط التي لا تحتوي على حروف مركبة بشكل أسرع ويمكن تحسينها بشكل أكبر. إذا لم يكن هناك بدائل سياقية في الخط ، يمكنني القيام بإنهاء سريع باستخدام مجموعة نتائج فارغة (أو يمكننا فقط تجاوز المكالمة على مستوى أعلى).

لقد بدأت في تتبع جانب الأداء في مشكلة منتهية في الحزمة التي أنشأتها (https://github.com/princjef/font-ligatures/issues/2). فيما يلي الأرقام الأولية التي تم نسخها من هناك لعدد قليل من التكوينات (جميع الأرقام مرات بالمللي ثانية). الأعمدة الخمسة الأولى هي لكل سطر من المدخلات والآخران لكل حرف. العمود الثاني إلى الأخير هو العمود الذي أولي اهتمامًا أكبر له. أنا أصور لحوالي 0.5 ميكروثانية لكل حرف (0.0005 بالمللي ثانية):

الاسم | AVG | STDEV | 5٪ | 50٪ | 95٪ | AVG (CHAR) | STDEV (CHAR)
----------------------- | ------- | --------- | ------ | -------- | ------- | ------------- | ----------------
كود فيرا: code.txt | 5.9570 | 12.6951 | 0.5270 | 5.1020 | 12.2330 | 0.1443531 | 0.2091743
كود فيرا: noLigatures.txt | 12.1932 | 3.4402 | 8.1420 | 12.1205 | 15.5900 | 0.1321094 | 0.0334362
إيوسيفكا: code.txt | 0.5571 | 1.4722 | 0.0485 | 0.3215 | 1.6155 | 0.0135005 | 0.0333483
إيوسيفكا: noLigatures.txt | 0.7476 | 0.4230 | 0.4365 | 0.6030 | 1.7725 | 0.0080998 | 0.0044501
مونويد: code.txt | 0.8896 | 1.6637 | 0.0910 | 0.6625 | 1.9225 | 0.0215566 | 0.0482166
أحادي: noLigatures.txt | 1.6661 | 0.6935 | 1.0695 | 1.4450 | 2.6910 | 0.0180521 | 0.0071922
أوبونتو مونو: code.txt | 0.0402 | 0.3935 | 0.0080 | 0.0220 | 0.0605 | 0.0009735 | 0.0090228
أوبونتو مونو: noLigatures.txt | 0.0356 | 0.0644 | 0.0120 | 0.0280 | 0.0805 | 0.0003858 | 0.0006891

الآن بعد أن أصبحت هناك بيانات أساسية جيدة ، سيكون لدينا فكرة أفضل عن المكاسب التي تحققت مع كل تعديل للأداء.

Tyriar هل لديك تفضيل للمكان الذي تعيش فيه الحزمة xterm-ligature-support وكيف تصل إلى هناك؟

يبدو أنك تفكر في أنه يجب أن يخضع لمؤسسة xtermjs (التي تبدو معقولة بالنسبة لي) ، لكن ليس لدي القدرة على إنشاء / الدفع إلى مستودع في المؤسسة. هل تفضل وضعه في الريبو تحت المستخدم الخاص بي والذي يتم ترحيله إلى المؤسسة أم أنك تريد إنشاء مستودع كعب يمكنني تقديم علاقات عامة ضده؟

من وجهة نظر المراجعة ، من المنطقي إنهاء # 1460 أولاً ، لذا لا داعي للاندفاع ولكني أريد معرفة مكان تفريغ الكود بمجرد أن يصبح جاهزًا.

princjef لقد أنشأت https://github.com/xtermjs/xterm-ligature-support ومنحتك وصول المسؤول. أفترض أنك رأيت كيف تعمل الوظائف الإضافية الأخرى ولكن هذا سيكون أول ملحق خارجي رسمي. لذا استخدم الإضافات الداخلية و https://github.com/CoderPad/xterm-webfont كمرجع للتنفيذ 😄

سوف تحقق من العلاقات العامة قريبا 👍

نشر تحديثًا في vscode repo على https://github.com/microsoft/vscode/issues/34103 ، إليك العمل المتبقي قبل أن نسميه مغلقًا في xterm.js:

• دمج xtermjs / xterm-addon-ligatures في xtermjs / xterm.js repo ، وهذا سيمكن النشر الآلي ويضمن استمرار الاختبارات
• ربط الأحرف المركبة في العرض التوضيحي
• قم بإعداد بعض اختبارات محرك الدمى التي تتحقق من عمل الأحرف المركبة على جميع العارضين (dom ، canvas ، webgl)
• قلل من التبعيات قدر الإمكان

شكرا لكل العمل الشاق هنا جميعا! 😄 👍

إذا جاز لي أن أسأل ،

رأيت أيضًا أن هذا يمكن أن يعمل في المتصفح ، لكنه سيكون بطيئًا للغاية. إذا جاز لي أن أسأل ، ما مدى بطء هذا الإصدار الذي يعمل في المتصفح؟

شكر!

@ torch2424 لا أعتقد أنه من الممكن مع كيفية عمل العارضين حيث يعتمد دعم الأربطة على تحليل ملف الخط (بدون ترميز مثل ما هو متاح من قبل المستخدم).

Tyriar شكرا على الاستجابة السريعة!

هذا أمر مؤسف ، لكن كان من الجيد أن يكون لديك. لقد فكرنا في إصدار إلكتروني ، لذلك ربما سنحصل على ذلك كميزة مضمنة 😄 شكرًا!

حسنًا ، أعتقد أنه يجب أن يكون ذلك ممكنًا ، إما باستخدام خط ويب وتحميل ملفات الخط نفسها (urgh) في نطاقات JS لاستخراج بيانات ربط الأحرف. لست متأكدًا مما إذا كان هذا ممكنًا / يستحق القيام بذلك بهذه الطريقة ، حيث أن استخراج الأربطة يعد تأثيرًا كبيرًا في الأداء. لست متأكدًا من استخدام الذاكرة ، يمكن أن يصبح ملف الخط كبيرًا جدًا ، ربما يحتوي

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

إذا كنت ستقوم بتحميل خط الويب الخاص بك يدويًا من ملف وقمت بحقن محتويات نفس الملف بشكل منفصل في التعليمات البرمجية لتحليل الحروف المركبة ، فمن الممكن نظريًا القيام بذلك دون الحاجة إلى التخلي عن تحسينات التخزين المؤقت للحروف الرسومية في العارض. ومع ذلك ، لم يتم تصميم الملحق الحالي مع وضع حالة الاستخدام هذه في الاعتبار لأنه يتطلب مزيدًا من التنسيق والأسلاك اليدوية مقارنة بالحالة غير المستعرضة.

لست متأكدًا مما إذا كان هذا ممكنًا / يستحق القيام بذلك بهذه الطريقة ، حيث أن استخراج الأربطة يعد تأثيرًا كبيرًا في الأداء. لست متأكدًا من استخدام الذاكرة ، يمكن أن يصبح ملف الخط كبيرًا جدًا

يمكن أن يكون هذا بالتأكيد مشكلة لبعض الخطوط. تم تحسين حزمة معالجة الأربطة بشكل كبير من أجل كفاءة البحث / الكشف ، والتي تأتي الآن على حساب أوقات التحميل الأطول واستهلاك الذاكرة. سيختلف بشكل كبير من خط إلى آخر ، ولكن من الجيد أن تضعه في الاعتبار.

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

princjef Thx للرؤوس ، هذا يبدو طريقة مرهقة ، imho لا تستحق الفائدة التي تقدمها بعد ذلك.

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

تحديث على هذا ، لقد قمت للتو بدمج الإضافات المركبة في قاعدة الكود (https://github.com/xtermjs/xterm.js/pull/2847) ، قد لا يزال معطلاً قليلاً ولكن من الصعب معرفة ذلك بدون إعداد اختبارات التكامل ( https://github.com/xtermjs/xterm.js/issues/2896).

حاليًا ، يعمل الملحق فقط في المتصفح + وقت تشغيل العقدة (مثل الإلكترون) ، وقد توصلت إلى اقتراح أتوقع أن يعمل فقط في المتصفح والذي سيسمح لنا بإسقاط أقسام العقدة وإدخالها في VS Code (https: / /github.com/microsoft/vscode/issues/34103). تم تصنيفها بالمساعدة المطلوبة إذا أراد أي شخص أن يعطيها لقطة https://github.com/xtermjs/xterm.js/issues/2897.

يجب أن ننظر في استخدام Font Access API (حاليًا في الإصدار التجريبي الأصلي) للوصلات المضافة.

أنا أستخدم ttyd الذي يشارك المحطة الطرفية عبر الويب ويستخدم xterm.js. كما ترى في الصورة أدناه لم يتم تحميل الرموز بشكل صحيح. كانت مرئية في المحطة الأصلية. لكنهم مفقودون على الويب.

UziTech أوه ، هذا يبدو رائعًا! أعتقد أن أي عمل يتم إنجازه في هذا المجال يجب أن يتطلع إلى الأمام حتى نتمكن من الاستفادة منه باستخدام واجهة برمجة التطبيقات للوصول إلى الخط.

UziTechTyriarprincjef
أعتقد أن كود API للوصول إلى الخط يمكن وضعه في حزم font-ligatures .
بعد اكتشاف ما إذا كانت العملية في المستعرض أو العقدة / الإلكترون ، يمكن أن تقرر ما إذا كنت تريد استدعاء API للوصول إلى الخط أو استخدام الطريقة الحالية.

لقد خلق دليل hacky من مفهوم وحصل على تشغيله في التجريبي في بلدي شوكة (localFonts فرع)

يمكنك تجربته بعد تمكين #font-access في chrome://flags (يلزم التحديث مرة واحدة بعد السماح بالوصول إلى الخطوط)

يمكنني محاولة فتح العلاقات العامة إذا كان هذا يبدو جيدًا لك.

بعد اكتشاف ما إذا كانت العملية في المستعرض أو العقدة / الإلكترون ، يمكن أن تقرر ما إذا كنت تريد استدعاء API للوصول إلى الخط أو استخدام الطريقة الحالية.

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

أيضا عمل عظيم لجعله يعمل! هذا رائع 😍

يمكننا require لهم بعد اكتشاف الميزات فقط إذا لزم الأمر.
ويمكن لمشاريع الويب التابعة فقط تمييزها على أنها خارجية أثناء التجميع.

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

👍 قد أفرط في التفكير في قلق المجمع كما ذكرت أن هناك حلولاً بديلة. أتوقع أننا سنقوم بإيقاف / إلغاء خيار Electron بمجرد تشغيل الوصول إلى الخط في Electron على أي حال.

Tyriar هل يمكننا الحصول على إصدار التحديث في أداة البحث عن الخطوط قريبًا؟

UziTech [email protected] يجب أن يكون ذلك ، لقد أنشأت تذكيرًا لإخراج الإصدار 4.10 https://github.com/xtermjs/xterm.js/issues/3220

لقد فتحت princjef / font-ligatures # 22 كخطوة أولى لإنجاز ذلك