Terminal: طلب الميزة: دعم رسومات sixel

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

الاختبار باستخدام WSL مع Ubuntu على سبيل المثال ، في mlterm يتم تقديم مثل هذه الصور بشكل صحيح على أنها تحتوي على قناع شفاف ويتم الاحتفاظ بلون الخلفية ، بينما في xterm -ti vt340 ، يتم رسم البكسل الذي لم يتم لمسه باللون الأسود ، على الرغم من أن الخلفية بيضاء ، والتي يبدو أنها يعني أنهم يعرضون ستة أنواع على صورة نقطية للذاكرة تمت تهيئتها على أنها سوداء بدون قناع شفاف أو ألفا قبل دمجها في النافذة الطرفية.

أوه. سيكسيل هو شيء رائع جدا.

لقد قررت أنني بحاجة لذلك. يحتاج.

سأقوم بمراجعة العلاقات العامة بسعادة :)

اشتعلت مقابلة Build 2019 اليوم التي ذكرت هذا الطلب. ما زلت أصر على أن Xorg على sixel هو مجرد خطأ . لذا _جدا خاطئ جدا_.

العرض التوضيحي ffmpeg-sixel "ستيف بالمر يبيع CS50 " لا يتعب أبدًا. يجب أن أقول ، إنه أمر مخيب للآمال بعض الشيء أن الفيديو يفتقر إلى الصوت (الصوت يجعل الفيديو حقًا). لوحات المفاتيح لديها بالفعل صوت ، بطبيعة الحال. هم تماما صفير. مجموعة سابقة. ما نحتاجه حقًا هو تسلسل CSI جديد لمقاطع التأليف المتشابكة مع الإطارات ، أمريت؟

كين ، أنا حقًا أستحق هذا لذكر سيكسيلز ؛)

من: therealkenc [email protected]
تاريخ الإرسال: الأربعاء ، 8 مايو 2019 ، الساعة 4:31:31 مساءً
إلى: مايكروسوفت / المحطة الطرفية
نسخة إلى: مشترك
الموضوع: Re: [Microsoft / Terminal] دعم رسومات Sixel (# 448)

اشتعلت بناء 2019 https://nam06.safelinks.protection.outlook.com/؟url=https٪3A٪2F٪2Fmybuild.techcommunity.microsoft.com٪2Fhome٪23top-anchor&data=01٪7C01٪7Cduhowett٪40microsoft.com ٪ 7C81f48be19f374665cd3408d6d40d4dc6٪ 7C72f988bf86f141af91ab2d7cd011db47٪ 7C1 & sdata = i8rfPCaN٪ 2FxqdF٪ 2F4qRtdN2Py4٪ 2BVRP ٪ZGpwJ الطلب اليوم. ما زلت أصر على أن Xorg على sixel خاطئ تمامًا https://nam06.safelinks.protection.outlook.com/؟url=https٪3A٪2F٪2Fgithub.com٪2Fmicrosoft٪2FWSL٪2Fissues٪2F1099٪23issuecomment-248513013&data=01 ٪ 7C01٪ 7Cduhowett٪ 40microsoft.com٪ 7C81f48be19f374665cd3408d6d40d4dc6٪ 7C72f988bf86f141af91ab2d7cd011db47٪ 7C1 & sdata = J٪ 2BwCnn0z70FkI9lDcus1nMX0z70FkI9lDcus1nMX0 لذلك خاطئ جدا جدا.

ffmpeg-sixel https://nam06.safelinks.protection.outlook.com/؟url=https٪3A٪2F٪2Fgithub.com٪2Fsaitoha٪2FFFmpeg-SIXEL&data=01٪7C01٪7Cduhowett٪40microsoft.com٪7C81f48be19f374664 ٪ 7C1 & sdata = G٪ 2F9mvw1EdADkwChSbHZ٪ 2FI54k9xvXagV٪ 2FxD9VbJtyw7g٪ 3D & محفوظ = 0 "عرض توضيحي لـ Steve Ballmer Sells CS50" https://nam06.safelinks.protection.outlook.com/؟url=2Fttps٪2 2Fwatch٪ 3Fv٪ 3D7z6lo4aq6zc٪ 26feature٪ 3Dyoutu.be والبيانات = 01٪ 7C01٪ 7Cduhowett٪ 40microsoft.com٪ 7C81f48be19f374665cd3408d6d40d4dc6٪ 7C72f988bf86f141af91ab2d7cd011db47٪ 7C1 وsdata = 6IVwBHs6٪ 2F43rXdk6GabiSUpTFS86xUGB6bubfkS3ea0٪ 3D & محفوظة = 0 لم يحصل ثو بالتعب. يجب أن أقول ، إنه أمر مخيب للآمال بعض الشيء أن الفيديو يفتقر إلى الصوت (الصوت يجعل الفيديو بالفعل https://nam06.safelinks.protection.outlook.com/؟url=https٪3A٪2F٪2Fwww.youtube.com٪2Fwatch٪3Fv ٪ 3DEl2mr5aS8y0 & data = 01٪ 7C01٪ 7Cduhowett٪ 40microsoft.com٪ 7C81f48be19f374665cd3408d6d40d4dc6٪ 7C72f988bf86f141af91ab2d7cd011db47٪ 7C1 & sdata =٪ 3DQWKZI . لوحات المفاتيح لديها بالفعل صوت ، بطبيعة الحال. هم تماما صفير. مجموعة سابقة. ما نحتاجه حقًا هو تسلسل CSI جديد https://nam06.safelinks.protection.outlook.com/؟url=https٪3A٪2F٪2Fen.wikipedia.org٪2Fwiki٪2FANSI_escape_code٪23CSI_sequences&data=01٪7C01٪7Cduhowett٪ 40microsoft.com٪ 7C81f48be19f374665cd3408d6d40d4dc6٪ 7C72f988bf86f141af91ab2d7cd011db47٪ 7C1 وsdata = 29pJq5661TXtnn2huLyUMgebTyYMEhTKXpAm19jzqHU٪ 3D & محفوظة = 0 لالتأليف https://nam06.safelinks.protection.outlook.com/؟url=https٪3A٪2F٪2Fen.wikipedia.org٪2Fwiki٪2FOpus_ (audio_format) & data = 01٪ 7C01٪ 7Cduhowett٪ 40microsoft.com٪ 7C81f48be19f374665cd3408d6d40d4dc6٪ 7C72f988bf86f141af91ab2d7cd011db47٪ 7C1 & sdata = XOq6Acz4٪ 2Q7BL

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، واعرضها على GitHub https://nam06.safelinks.protection.outlook.com/؟url=https٪3A٪2F٪2Fgithub.com٪2Fmicrosoft٪2FTerminal٪2Fissues٪2F448٪23issuecomment-490688164&data=01 ٪ 7C01٪ 7Cduhowett٪ 40microsoft.com٪ 7C81f48be19f374665cd3408d6d40d4dc6٪ 7C72f988bf86f141af91ab2d7cd011db47٪ 7C1 وsdata = pnXPvsuGF7l5mQfU2htzFwJnqZjEuW4zNuh1HaBJnKM٪ 3D & محفوظة = 0 ، أو كتم موضوع https://nam06.safelinks.protection.outlook.com/؟url=https٪3A٪2F٪2Fgithub. كوم٪ 2Fnotifications٪ 2Funsubscribe-المصادقة٪ 2FADNHLGXQOYKINZMIBKTB4LTPUNPFHANCNFSM4HLENFOQ والبيانات = 01٪ 7C01٪ 7Cduhowett٪ 40microsoft.com٪ 7C81f48be19f374665cd3408d6d40d4dc6٪ 7C72f988bf86f141af91ab2d7cd011db47٪ 7C1 وsdata =٪ 2F4pMmm7bvPa٪ 2BbFmE1gyN8٪ 2BoTZDKJyRksBrkJpDh٪ 2BLug٪ 3D & محفوظة = 0 .

ذات صلة: # 120

يحتاج.

لول كنت أشاهد البث وقلت لنفسي "هنا رئيسي يكلفني بالعمل مباشرة أمام جمهور الاستوديو".

يرجى جعل هذا أولوية بالنسبة للإصدار 1.0!

يمكن أن تكون الرسوم المتحركة ثلاثية الأبعاد v1.5 😛

يا إلهي

بالتصويت على هذا الطلب ، سيكون سيكسيلز أمرًا رائعًا في المبنى.

انتهيت في نهاية هذا الأسبوع من تنفيذ دعم قراءة sixel لمكتبة TUI المعتمدة على Java والمرخصة من معهد ماساتشوستس للتكنولوجيا ، وكان الأمر بسيطًا بشكل مدهش. يوجد هنا رمز تحويل سلسلة من بيانات sixel إلى صورة نقطية ، ورمز العميل لفئة Sixel هنا .

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

فقط أريد أن أذكره لأشخاص آخرين مهتمين بالدعم النهائي لـ sixel ، وآمل أن يساعدك ذلك.

سأصوت إذا كتب شخص آخر عميل دفتر Jupyter ؛)

لدينا بالفعل مثال لدعم Sixel في mintty وهو مكتوب بلغة C (Vice java). الشيء الوحيد المطلوب هو إعادة بناء معامل C ++ (على الأقل للدعم الأولي). لا يزال من الجيد دائمًا معرفة كيفية تنفيذه في مشاريع أخرى.

لدينا بالفعل مثال لدعم Sixel في mintty وهو مكتوب بلغة C (Vice java). الشيء الوحيد المطلوب هو إعادة بناء معامل C ++ (على الأقل للدعم الأولي). لا يزال من الجيد دائمًا معرفة كيفية تنفيذه في مشاريع أخرى.

هل توجد أي مشكلات تتعلق بترخيص Mintty (GPLv3 أو أحدث)؟

https://github.com/mintty/mintty/blob/master/LICENSE

https://github.com/mintty/mintty/blob/master/LICENSE

من هذا الرابط:

يتم إعادة ترخيص رمز Sixel (sixel.c) بموجب GPL مثل mintty مع
إذن من مؤلفها (kmiya @ Culti)

إذا قمت بترجمة هذا الرمز الدقيق إلى C ++ ، فسيحتاج العمل المشتق إلى ترخيص GPLv3 أو ما بعده ، وفقًا لشروطه ، أو عدم توزيعه على الإطلاق. (يمكن للمرء أيضًا أن يسأل kmiyaculti عما إذا كانوا على استعداد لتقديم sixel.c بموجب ترخيص مختلف ، أو إذا كان متاحًا في السابق ضمن شيء آخر ، ابحث عن نسخة من ذلك المصدر.)

لا أعرف ما هو المقبول أو غير المقبول للتضمين في Windows Terminal - نظريتي السريعة على Windows Terminal تقول إنه مرخص من MIT ، لذلك اعتمادًا على كيفية ربطه / تحميله باستخدام سليل مباشر لـ Mintty's GPLv3 + sixel.c يمكن أن يقود لقضية ترخيص.

على أي حال ، آسف لكونك تتنصت على مشروع شخص آخر هنا ، والعودة إلى الكهف الآن ...

توجد أداة محاكي طرفية متواضعة وقادرة على ستةel مكتوبة بلغة C / C ++ لنظامي التشغيل Windows / Linux ، ولديها فئة SixelRenderer التي يمكنك استخدامها (على الرغم من أنها تحتاج إلى بعض التحسين) ، ولديها ترخيص BSD-3. يمكن القول إن أكبر عيبه هو أنه مكتوب لإطار عمل C ++ معين. لا يزال ، IMO رمز SixelRenderer قابل للترجمة مع القليل من الجهد. (أعرف هذا لأنني مؤلفه. :))

https://github.com/ismail-yilmaz/upp-components/tree/master/CtrlLib/Terminal

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

الاختبار باستخدام WSL مع Ubuntu على سبيل المثال ، في mlterm يتم تقديم مثل هذه الصور بشكل صحيح على أنها تحتوي على قناع شفاف ويتم الاحتفاظ بلون الخلفية ، بينما في xterm -ti vt340 ، يتم رسم البكسل الذي لم يتم لمسه باللون الأسود ، على الرغم من أن الخلفية بيضاء ، والتي يبدو أنها يعني أنهم يعرضون ستة أنواع على صورة نقطية للذاكرة تمت تهيئتها على أنها سوداء بدون قناع شفاف أو ألفا قبل دمجها في النافذة الطرفية.

همم. VT340 أنا أمام يكرم المعلمة P2 في DCS P1 ؛ P2 ؛ P3 ؛ q التسلسل الذي يبدأ تسلسل SIXEL. من ناحية أخرى ، يبدو أن Xterm تتجاهلها. ولكن إذا استخدمت تسلسل السمات النقطية ("Pan؛ Pad؛ Ph؛ Pv) ومنحها ارتفاعًا وعرضًا ، فسيؤدي ذلك إلى مسح الخلفية حتى تحصل على بكسل أسود.

كنت أفكر في الحصول على نسخة تجريبية مجانية من محاكي ttwin والتحقق من اختلاف سلوكه عن VT340 و Xterm باعتباره VT340.

لكن ... +1 على فكرة دعم SIXEL بشكل عام و +10 لفكرة الخروج باختبارات التوافق.

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

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

مرحبًا ، إليك بعض الروابط ذات الصلة بالبحث:

• "أساسيات لبروتوكول صورة جيدة " في Terminal-wg ( ومناقشة سابقة مرتبطة )
• هذا الخيط الهائل حول دعم sixel

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

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

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

تم وصف محاذاة البيانات الرسومية Sixel و ReGIS (بشكل سيئ) في كتيبات مختلفة. تتم محاذاة صور Sixel على حدود خلية الأحرف. إذا كنت تريد حدًا أسودًا حول صورة ما ، فعليك إضافة وحدات البكسل السوداء بنفسك ؛ ليس هناك مفهوم لأي شيء مثل هامش HTML أو المساحة المتروكة. يصف كل سطر من بيانات sixel شريطًا بارتفاع ستة بكسلات. إذا كنت تحاول محاذاة بيانات صورة sixel مع أحرف نصية على محاكي طرفي ، فقد يكون هذا محبطًا لأن البرنامج الذي ينشئ بيانات sixel قد لا يعرف عدد وحدات البكسل التي يبلغ ارتفاع كل حرف رسومي فيها. إذا كان لديك برنامج xterm للمدرسة القديمة في متناول يدك ، فيمكنك رؤية ذلك عن طريق بدء تشغيله في وضع vt340 ، وتحديد أحجام خطوط مختلفة (لمنحك أحجام خلايا أحرف مختلفة) ثم طباعة بعض البيانات الستة التي تحاول محاذاة بيانات الصورة مع النص بيانات. (هذا ملف اختبار بسيط يبدو صحيحًا عندما أخبر خادم الخطوط باستخدام 96DPI وأنا أحدد خطًا من 15 نقطة. يؤدي تعديل حجم الخط إلى خروج الصور بشكل متزايد من المحاذاة مع النص. https: //gist.github. كوم / OhMeadhbh / 3d63f8b8aa4080d4de40586ffff819de)

لم تواجه vt340s الأصلية هذه المشكلة لأنه (بالطبع) لم تتمكن من تحديد حجم الخط عند تشغيل الجهاز.

الشيء الآخر الذي يمكنك رؤيته من تلك الصورة ، والذي لم يتم وصفه جيدًا في وثائق sixel هو أن طباعة سطر من بيانات sixel ينشئ "هامشًا أيسر افتراضيًا" لبيانات الصورة. إذا قمت بإجراء المعادل الأخلاقي لـ CR أو CRLF باستخدام الأحرف "$" أو "-" ، تتم طباعة السطر التالي بالنسبة إلى الهامش الأيسر الظاهري ، وليس الهامش الأيسر الحقيقي على الجانب الأيسر من المحطة.

أتمنى أن يساعدك هذا.

انتقل أخيرا إلى الوراء لقراءة هذا. آسف على الرد المتأخر.

الاختبار باستخدام WSL مع Ubuntu على سبيل المثال ، في mlterm يتم تقديم مثل هذه الصور بشكل صحيح على أنها تحتوي على قناع شفاف ويتم الاحتفاظ بلون الخلفية ، بينما في xterm -ti vt340 ، يتم رسم البكسل الذي لم يتم لمسه باللون الأسود ، على الرغم من أن الخلفية بيضاء ، والتي يبدو أنها يعني أنهم يعرضون ستة أنواع على صورة نقطية للذاكرة تمت تهيئتها على أنها سوداء بدون قناع شفاف أو ألفا قبل دمجها في النافذة الطرفية.

لا ينبغي أن يكون من الصعب للغاية دعم الشفافية في xterm. لقد كنت أبحث في الكود لأسباب أخرى. أخشى أن يعتمد شخص ما في مكان ما على سلوك Xterm هذا ، لذا أوصي بوضعه خلف علامة التوافق ، والتي يجب أن تكون أيضًا مباشرة. ولكن بعد ذلك هناك مسألة القيمة الافتراضية. ماذا يجب أن يكون الافتراضي؟ أسود أو شفاف.

هل نعرف ما فعله VT240 و 241 و 330 و 340 الأصلي؟ هل يمكنني أن أقترح محاولة تمثيل تجربة VT الفعلية بأمانةكسلوك افتراضي؟ يمكنك اختبار ذلك عن طريق طباعة أحرف مسافات مقلوبة ، ثم وضع طبقات رسومات سداسية فوقها ورؤية اللون الذي تظهره وحدات البكسل غير المحددة.

لا أعلم أنني أهتم كثيرًا بما هو الإعداد الافتراضي لمحطة msft طالما أن هناك إمكانية للتصرف مثل Xterm لمحاكاة VT340. يفترض الكود الذي كتبته لعمل خطوط تسجيل عبر ssh في المحطة الطرفية أن سلوك "البكسل غير المحدد أسود" الموضح أعلاه. سأضطر إلى إعادة كتابة هذا الرمز إذا أجرينا هذا التغيير.

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

لم تواجه vt340s الأصلية هذه المشكلة لأنه (بالطبع) لم تتمكن من تحديد حجم الخط عند تشغيل الجهاز.

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

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

مرحبًا ، إليك بعض الروابط ذات الصلة بالبحث:
"أساسيات لبروتوكول صورة جيدة" في Terminal-wg

Sixel مكسور لأنه لا يمكن دعمه بواسطة tmux بأجزاء متجاورة.

استغرق الأمر بعض العمل (في الواقع الكثير من العمل ) ، ولكن مع sixel ، يمكن للمرء أن يؤدي تقريبًا جميع حيل "الصور في المحطة" التي يمكن للمرء تصويرها:

• صور مقنعة ذات طبقات لكل خلية في محطة طرفية: https://jexer.sourceforge.io/images/sixel_many_images.png

• نافذة طرفية عائمة (متعددة الإرسال) في محطة طرفية تستخدم sixel لدعم عرض مزدوج بنمط VT100: https://jexer.sourceforge.io/screenshots/jexer_sixel_in_sixel.png

• المحطات الطرفية المبلطة "tmux-style" مع الصور: https://gitlab.com/klamonte/jexer/-/wikis/uploads/7603381f82414ef9ae214bfcf759c064/example_tilingwm2_1.png

• جلسة طرفية مشتركة متعددة الرؤوس مع أحجام خلايا نصية مختلفة تظهر نفس المؤامرة: https://jexer.sourceforge.io/screenshots/multiscreen_2b.png

• استخدام sixel لعرض CJK والرموز التعبيرية غير الموجودة في خط الجهاز الرئيسي: https://jexer.sourceforge.io/screenshots/xterm_sixel_cjk.png

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

إذا لم يكن هناك شيء آخر ، فإن sixel هو نقطة انطلاق جيدة للعمل على البنية التحتية الجانبية للطرف من الصور والنصوص المختلطة. عند التحدث من التجربة المباشرة ، فإن الجانب الطرفي (تخزين / عرض الصور) يبلغ حوالي 1/4 من صعوبة جانب مُضاعِف الإرسال / التطبيق (tmux / mc et al).

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

كما هو موضح من قبل Therealkenc ومزيد من الشرح بواسطة klamonte في 640292222 ، يمكن التعامل مع كل شيء بستة صور ، حتى الصور جنبًا إلى جنب ، ولكنها تتطلب بعض العمل.

منذ فترة ، كنت أعمل مع عدد قليل من الأشخاص الآخرين على وضع احتياطي لـ tmux ، باستخدام رسومات يونيكود متقدمة لتمثيل صور sixel في محطات لا تدعم sixel.

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

كان الرمز المجال العام. يمكن استخدامها على الفور كخطوة أولى نحو دعم sixel:

• اكتشاف وقت إرسال تسلسل sixels ، ثم حساب استبدال نص unicode

• دبله تسلسل unicode هذا ، المدعوم بالفعل بواسطة Windows Terminal

• لاحقًا ، عندما يتم تنفيذ sixels ، يتم تصيير تسلسل sixel في الجزء العلوي.

هل انت مهتم؟

راجع للشغل أتعرف هنا على مخططاتي المألوفة لـ gnuplot x ^ 2 sin و 10 sin (x) ، ويسعدني أنها قدمت بعض الإلهام 😄

لو سمحت.

DHowett هل acac350 خطوة أولى نحو تقديم رسومات sixel فعليًا؟ أتلقى طلبات للحصول على دعم sixel في Microsoft Terminal من الأشخاص الذين يستخدمون ssh ويرغبون في عرض أدلة الصور باستخدام برنامج lsix الخاص بي.

سورتا. لدينا الآن القدرة على التعامل مع تسلسلات DCS الواردة. لم نقم بتوصيل أي معالجات حتى الآن ، ولكن امتلاك البنية التحتية للقيام بذلك كان أمرًا مهمًا للغاية. :ابتسامة:

إليك بعض التحديثات. لدي فرع عامل هنا . تبدو لقطة الشاشة المبكرة كما يلي:

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

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

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

WSLUser شكرا على الاهتمام. لقطة الشاشة هذه في الواقع منذ حوالي شهر ، عندما لا توجد حتى المعلمات الرائعة للعلاقات العامة من j4james. عملي بالكامل داخل Windows Terminal ، وليس conhost. لقد عرضت هذا العلاقات العامة على فريق وحدة التحكم داخليًا وأحرزت بعض التقدم منذ ذلك الحين. لكنني عالق بسبب المشكلة الفارغة.

نعم ، سأعيد القاعدة الأساسية وأضيف https://github.com/microsoft/terminal/pull/7578 و https://github.com/microsoft/terminal/pull/7799. من هناك ، ربما ترى ما هو مفقود في ConPTY لوضع التمرير. أتساءل أن Mintty تستخدم التمريري لوضع ConPTY.

أتساءل أن Mintty تستخدم التمريري لوضع ConPTY.

متأكد من أن Mintty لا يستخدم فارغًا على الإطلاق

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

قد يؤدي ذلك إلى إفساد بعض التحسينات لدينا (مثل لا يمكننا مسح صفوف EraseLine التي تحتوي على بيانات ستةel) ، ولكنها قد تكون بداية جيدة بما فيه الكفاية

\

ربما يمكن تنوير فارغة لتجاهل خلايا الطلاء ذات الرسومات الحجمية ، وافترض فقط أن المحطة الطرفية ستترك تلك الخلايا وشأنها.

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

1. كيف سيتفاعل هذا مع تدفق DCS (والذي لا أعتقد أنه لدينا حل حتى الآن). أفترض أننا سنحتاج إلى نوع من مفهوم الدفق المنفصل الذي يمر عبر دفق البايت ليتم تفريغه في نفس الوقت الذي يتم إرساله فيه إلى المخزن المؤقت conhost ، ولكن يبدو أن هذا سيضيف الكثير من النفقات غير الضرورية إلى العملية.
2. لن يعمل هذا إلا إذا كنت تعرف حجم خلية البكسل للمحطة الفارغة. لقد ذكرت من قبل أن أفضل حل لـ Sixel هو مطابقة حجم الخلية لمحطات VT الأصلية ، وإذا كنا نفعل ذلك فلن تكون هذه مشكلة. ومع ذلك ، على حد علمي ، لا توجد محاكيات طرفية أخرى تفعل ذلك ، لذلك لن تعمل مع أي شخص آخر.

تصبح المشكلة الثانية التي طرحها @ j4james أكثر تعقيدًا مع مراعاة اختلاف الخط وحجم الخط المختلف وتغيير حجم الخط. لذلك بشكل عام أعتقد أن هناك ثلاثة جوانب لهذه المشكلة:

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

تصبح المشكلة الثانية التي طرحها @ j4james أكثر تعقيدًا مع مراعاة اختلاف الخط وحجم الخط المختلف وتغيير حجم الخط. لذلك بشكل عام أعتقد أن هناك ثلاثة جوانب لهذه المشكلة:

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

قلقي الأكبر هو أنك يبدو أنك تتجاهل مشكلة دفق DCS ، والتي أتوقع أنها قد تغير بشكل أساسي بنية الحل. الخطوات التي أود أن أراها هي: 1. حل # 7316 ؛ 2. اتفق على حل لحجم بكسل الخلية ؛ 3. الحصول على شيء يعمل في conhost. 4. بمجرد حل جميع المضاعفات في conhost ، عندها فقط ضع في اعتبارك كيف نجعلها تعمل بشكل فارغ.

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

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

获取 Outlook لنظام التشغيل iOS https://aka.ms/o0ukef

في المناقشة في https://github.com/microsoft/terminal/issues/57 ، اعتقدت أن الخطوط الفارغة لا تهتم بالخطوط على الإطلاق؟

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

yatli نعم. هذا أيضًا ما يجعل المشكلة صعبة.

ستشغل الصورة مقاس 10x20 بكسل خلية ذات حرف واحد بالضبط

هذا خطأ للأسف ، على الأقل بالنسبة لإعداد الخط الحالي.

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

@ skyline75489 الرجاء الاطلاع على تعليقي المحدث حول "المرساة"

تحتاج بنية بيانات الخلية إلى التحديث كـ char | sixel anchor

يجب أن يحتوي مرساة sixel على معلومات حول:

• مؤشر إلى كائن الصورة
• منطقة خلية الحرف التي تحتلها ، بالأرقام العائمة (على سبيل المثال 5.2 سطرًا × 7.8 عمودًا)

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

ستشغل الصورة مقاس 10x20 بكسل خلية ذات حرف واحد بالضبط

هذا خطأ للأسف ، على الأقل بالنسبة لإعداد الخط الحالي.

ما أقترحه هو أنه يجب عليك إثبات هذه القضية. إذا قمت بإنشاء صورة 10x20 بكسل وإخراجها على محطة DEC VT320 حقيقية ، فستأخذ حرفًا واحدًا بالضبط (على الأقل في وضع 80 عمودًا). لذا إذا كنا نحاول محاكاة هذه المحطة ، فعلينا فعل الشيء نفسه. إذا كان حجم خطك الحالي 30 × 60 ، فأنت بحاجة إلى زيادة حجم الصورة. إذا كان الخط الخاص بك أصغر ، فأنت تصغر حجم الصورة.

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

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

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

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

لن أتظاهر بأن هذا النهج لن يكون له أي سلبيات ، لكنني أعتقد أن الإيجابيات تفوق السلبيات.

ماذا لو كان الخط له نسبة عرض إلى ارتفاع مختلفة عن 10:20؟

ماذا لو كان الخط له نسبة عرض إلى ارتفاع مختلفة عن 10:20؟

هل لي أن أقترح قراءة هذا النقاش الطويل - و "الوحشي" إلى حد ما - حول المشاكل العامة المتعلقة بالصور المضمنة في المحاكيات النهائية .

يمكن أن يعطيك فكرة عامة.

مع أطيب التحيات

ماذا لو كان الخط له نسبة عرض إلى ارتفاع مختلفة عن 10:20؟

قد تكون الصورة ممتدة أو مضغوطة قليلاً ، لكنني لا أعتقد أن هذه نهاية العالم.

اسمحوا لي أن أوضح بمثال من العالم الحقيقي. تخيل أنني شرير بوند ، ولدي نظام أمان قديم يستخدم VT340 كواجهة أمامية. الآن بسبب فيروس كورونا ، أنا في وضع الإغلاق وأعمل من المنزل ، لذلك أقوم بتسجيل الدخول إلى النظام عن بُعد باستخدام Windows Terminal. إذا تطابقنا تمامًا مع VT340 ، فهذه ليست مشكلة - تبدو المحطة كما يلي:

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

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

ربما تكون هذه مسألة تفضيل شخصي ، لكنني أعلم أنني سأختار بالتأكيد الخيار 1 على الخيار 2.

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

ربما تكون هذه مسألة تفضيل شخصي ، لكنني أعلم أنني سأختار بالتأكيد الخيار 1 على الخيار 2.

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

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

أعتقد أنه من الأفضل تركيزهم.

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

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

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

سيؤدي فرض 10:20 أيضًا إلى خدوش قبيحة. (على سبيل المثال ، كيفية الرد على طلب حجم نافذة المحطة الطرفية بالبكسل. قل الحقيقة ، بافتراض أنهم سيضعون النوافذ على الشاشة؟ أو ، قم دائمًا بإرجاع 800x480 ، بافتراض أن المستخدم يقوم بتحجيم الصور لمخرجات sixel؟ )

هل نتحدث بالفعل عن تزييف المحطة الطرفية 10:20 حرفًا لصورة sixel؟

نعم.

يجب أن تكون المحطة الطرفية الحديثة حيادية للخط

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

باستخدام تسلسل الهروب ، يمكن لبرنامج تشغيل المستخدم تحديد حجم خلية الحرف بالبكسل وتحديد كيفية التعامل بذكاء مع التشويه لهذا التطبيق.

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

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

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

لدي 300+ VT340 في محطات الطاقة النووية التي أود ذلك في النهاية
يستبدل.

هناك حزم مضاهاة طرفية تجارية يمكننا استخدامها ، لكنني أعتقد ذلك
جميعهم باستثناء شخص واحد كانوا من EoL'd.

لقد استبدلنا بعضها بأجهزة كمبيوتر Linux تعمل بنظام XTerm (أو أقل
بشكل متكرر ، Win10 + Hummingbird + WSL يعمل بنظام XTerm) ، لأنه يحتوي على ملف
منتصف الطريق لائقة مفتوحة المصدر sixel التنفيذ ونوع من السيئ ، ولكن
تطبيق ReGIS مفتوح المصدر.

احتمالية كتابة برنامج جديد لهذا الجزء من هذا
النظام الذي يولد تيار ثماني بتات هو لا شيء.

إذا كان هدفك هو إرسال رسومات عبر دفق ثماني مضمن ، فهناك
هي خيارات أخرى. ولكن إذا كنت ترغب في دعم رسومات sixel ، فيجب عليك ذلك
دعم رسومات sixel بطريقة تشبه في منتصف الطريق السابقة
تطبيقات. هذا ، للأسف ، يعني أنه يجب عليك محاكاة ملف
سلوك الأنظمة النموذجية (مثل VT240 و VT241 و VT330 و VT340
الطرفية) حتى عندما يتعلق الأمر بدمج الرسومات مع النص.

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

https://vimeo.com/user32814426/review/467991744/ac5892fa7e

يجب أن تكون المحطة الطرفية الحديثة حيادية للخط

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

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

باستخدام تسلسل الهروب ، يمكن لبرنامج تشغيل المستخدم تحديد حجم خلية الحرف بالبكسل وتحديد كيفية التعامل بذكاء مع التشويه لهذا التطبيق.

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

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

مساوئ هذا النهج هي:

1. It's proprietary, so wouldn't work on a real terminal, or any terminal emulator that exactly matched a real terminal.

هذا ليس جانبًا سلبيًا. هذا يعني فقط أن البرنامج يجب أن يتراجع عن فعل ما كان سيفعله على أي حال: افترض أن $ TERM == يعني "VT340" أن خلايا الأحرف هي 10:20 ، وتعني "VT240" 10:10 ، وتعني "mskermit" 8: 8 ، وما إلى ذلك وهلم جرا.

أيضًا ، إنه ليس تسلسلًا مملوكًا لـ xterm. الحصول على حجم الشاشة يسمى تسلسل هروب "dtterm" ، ولكن تم تنفيذه لأول مرة في SunView (SunOS ، 1986). أعتقد أنه تم توثيقه لاحقًا في دليل برمجة PHIGS (1992). حاول إرسال "\ e [14t" إلى عدد قليل من المحاكيات الطرفية وسترى أنه مطبق على نطاق واسع.

2. If the user changes their font size while your application is running, then your calculations will no longer be correct, and images will be rendered at the wrong size (unless you're continuously recalculating the font size which seems impractical).

هذه ليست مشكلة. يقوم البرنامج ببساطة باعتراض SIGWINCH ويعيد حساب ما إذا كانت النافذة قد تغيرت بالفعل.

3. If the user has a high resolution display, and/or large font size, you're forced to send through a massive image to try and match that resolution. Considering how inefficient Sixel is to start with, that can amount to a lot of bandwidth.

نعم ، sixel غير فعال للغاية. ولكن على أجهزة الكمبيوتر الحديثة ، يعد إرسال الصور بملء الشاشة أمرًا مفيدًا للغاية ، حتى عبر ssh. هل لدى Microsoft Terminal نوع من قيود معدل البث بالباود؟

بالمناسبة ، أعتقد أن sixel لديها وضع "DPI عالي" حيث يتم مضاعفة كل نقطة في العرض والارتفاع. لم أستخدمه مطلقًا ولا أعتقد أن xterm ينفذه حتى ، ولكن ربما يخفف ذلك من المخاوف بشأن النطاق الترددي.

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

هذا "الوضع" هو ببساطة محاذاة الأحرف والرسومات تمامًا كما فعلت المحطات الطرفية الستة التاريخية المختلفة والمحاكيات الحالية. أعترف ، لا أفهم لماذا لا يمكن أن تفعل الشيء نفسه في Microsoft Terminal. إذا قلت أن هذا الخطأ في الساعة 10:20 هو أفضل ما يمكن القيام به ، فسوف أثق في أنك على صواب وأشكرك على القيام بذلك. الصورة المشوهة أفضل بكثير من لا شيء.

باستخدام تسلسل الهروب ، يمكن لبرنامج تشغيل المستخدم تحديد حجم خلية الحرف بالبكسل وتحديد كيفية التعامل بذكاء مع التشويه لهذا التطبيق.

@ hackerb9 ، ما هو تسلسل الهروب الفعلي للحصول على أبعاد الخط؟

يمكن العثور على تسلسلات XTerm ذات الصلة هنا: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html - ابحث عن XTWINOPS.

بالإضافة إلى ذلك ، في نظام التشغيل Unix ، يمكنك عادةً الحصول على حجم البكسل الداخلي للمحطة جنبًا إلى جنب مع حجم الخلية باستخدام TIOCGWINSZ ioctl. مع opensh هذا يعمل عن بعد أيضًا.

تمامًا كنقطة بيانات ، فإن فرع sixel لـ libvte يتخذ المسار الحيادي لحجم الخلية الذي يتحدث عنه @ hackerb9 . إنه يتعامل مع بيانات sixel الواردة على أنها "مثالية للبكسل" وتعيد قياس الصور التي تم تلقيها مسبقًا عبر مستويات التكبير وأحجام الخطوط لتغطية مدى خلية ثابت. عند الدمج ، سيكون هذا التطبيق متاحًا لجزء كبير من محاكيات Linux الطرفية ، بما في ذلك GNOME Terminal ، و XFCE Terminal ، و Terminator ، وما إلى ذلك. ظاهريًا ، يبدو أن هذا قابل للتشغيل المتبادل مع XTerm و mlterm على الأقل.

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

بالإضافة إلى ذلك ، في نظام التشغيل Unix ، يمكنك عادةً الحصول على حجم البكسل الداخلي للمحطة جنبًا إلى جنب مع حجم الخلية باستخدام TIOCGWINSZ ioctl. مع opensh هذا يعمل عن بعد أيضًا.

ترجع وحدة تحكم Linux دائمًا 0 ... يجب إصلاح ذلك ، على الرغم من ذلك ، ولكن يبدو أنهم غير مستعدين أيضًا: - /