Terminal: Permintaan Fitur: dukungan grafis sixel

Saat menerapkan Sixel, penting untuk menguji dengan gambar yang mengandung transparansi.
Transparansi dapat dicapai dengan menggambar piksel dengan warna berbeda tetapi tidak menggambar beberapa piksel dalam salah satu warna Sixel, membiarkan warna latar belakang seperti itu.
Saya percaya ini adalah satu-satunya cara untuk menggambar Sixels non-persegi panjang dengan benar, dan akan sangat bagus dengan transparansi akrilik latar belakang di Terminal Windows baru.

Pengujian menggunakan WSL dengan Ubuntu misalnya, dalam mlterm gambar tersebut dirender dengan benar sebagai memiliki topeng transparansi dan warna latar belakang disimpan, sedangkan di xterm -ti vt340, piksel yang tidak tersentuh digambar hitam, meskipun latar belakangnya putih, yang tampaknya menyiratkan mereka membuat enamel pada bitmap memori yang diinisialisasi sebagai hitam tanpa topeng transparansi atau alfa sebelum memasukkannya ke jendela terminal.

Oh. Sixel adalah hal yang sangat keren.

Saya telah memutuskan bahwa saya membutuhkan itu. MEMBUTUHKAN.

Saya akan dengan senang hati meninjau PR :)

Tangkap wawancara Build 2019 hari ini yang menyebutkan permintaan ini. Saya masih mempertahankan bahwa Xorg pada sixel salah . Jadi _sangat salah_.

Demo ffmpeg-sixel "Steve Ballmer Sells CS50" tidak pernah bosan. Harus dikatakan, itu sedikit mengecewakan video yang tidak memiliki suara (suara benar-benar membuat video ). Konsol sudah memiliki suara, tentu saja. Mereka benar-benar berbunyi bip. Preseden ditetapkan. Apa yang kita benar-benar _butuhkan_ adalah urutan CSI baru untuk klip karya yang disisipkan dengan bingkai, amirite?

Ken, saya benar-benar pantas menerima ini karena menyebut Sixels;)

Dari: notifikasi [email protected]
Dikirim: Rabu, 8 Mei 2019 16:31:31
Kepada: microsoft/Terminal
Cc: Berlangganan
Subjek: Re: [microsoft/Terminal] Dukungan grafis Sixel (#448)

Tertangkap Build 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%2BVRlbPgpwJWtPZ hari ini meminta wawancara ini Saya masih berpendapat bahwa Xorg pada sixel salah 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%2BwCnn0z70FkI9lDcus1nMXAcKz Jadi sangat sangat salah.

The ffmpeg-sixel https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsaitoha%2FFFmpeg-SIXEL&data=01%7C01%7Cduhowett%40microsoft.com%7C81f48be19f374691cd3408dfcbbd407Cd408df47686%cd3408df %7C1&sdata=G%2F9mvw1EdADkwChSbHZ%2FI54k9xvXagV%2FxD9VbJtyw7g%3D&reserved=0 Demo "Steve Ballmer Menjual CS50" https://nam06.safelinks.protection.outlook.com/?url=https%2F 2Fwatch% 3Fv% 3D7z6lo4aq6zc% 26feature% 3Dyoutu.be & data = 01% 7C01% 7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 & SDATA = 6IVwBHs6% 2F43rXdk6GabiSUpTFS86xUGB6bubfkS3ea0% 3D & dicadangkan = 0 tidak pernah mendapat tho lelah. Harus bilang, agak mengecewakan videonya kurang suara (suaranya bikin video banget 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&sdataKdcAZQsD5xKdcAZQsD5xUKmm1ICN5 Konsol sudah memiliki suara, tentu saja. Mereka benar-benar berbunyi bip. Preseden ditetapkan. Yang benar-benar kita butuhkan adalah urutan CSI baru 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 & dicadangkan = 0 untuk opus https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FOpus_ (format_audio_)&data=01%7C01%7Cduhowett%40microsoft.com%7C81f48be19f374665cd3408d6d40d4dc6%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=XOq6Acz4%2B7gLRklip

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di 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 & dicadangkan = 0 , atau mematikan benang https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. com% 2Fnotifications% 2Funsubscribe-auth% 2FADNHLGXQOYKINZMIBKTB4LTPUNPFHANCNFSM4HLENFOQ & data = 01% 7C01% 7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 & SDATA =% 2F4pMmm7bvPa% 2BbFmE1gyN8% 2BoTZDKJyRksBrkJpDh% 2BLug% 3D & dilindungi = 0 .

Terkait: #120

Membutuhkan.

LOL Saya sedang menonton streaming dan saya hanya berpikir "ini bos saya menugaskan saya bekerja langsung di depan penonton studio".

Harap jadikan ini prioritas untuk v1.0!

Animasi 3d bisa v1.5

ya Tuhan

Mengangkat permintaan ini, Sixels akan menjadi hal yang luar biasa untuk dimiliki di Terminal.

Akhir pekan ini saya selesai mengimplementasikan dukungan sixel read untuk perpustakaan TUI berbasis Java berlisensi MIT saya, dan ternyata sangat mudah. Kode untuk mengonversi string data sixel ke gambar bitmap ada di sini , dan kode klien untuk kelas Sixel ada di sini .

Saya telah melakukan sangat sedikit untuk kinerja pada decoder. Namun saat menggunakan backend Swing, performanya masih OK, seperti terlihat di sini . (Gambar ular terlihat buruk hanya karena byzanz menggunakan palet yang buruk untuk membuat gif demo.) Saya sedikit terkejut betapa cepatnya gambar itu muncul. Sangat adil untuk mengatakan bahwa bagian "decode sixel menjadi bitmap" adalah bagian yang mudah, bagian yang sulit adalah "tempelkan data gambar ke dalam sel teks, dan ketika itu ada, blitkan gambar ke layar daripada karakter".

Hanya ingin menyebutkannya kepada orang lain yang tertarik dengan dukungan terminal untuk sixel, dan berharap itu bisa membantu Anda.

Saya akan memilih jika orang lain menulis klien notebook Jupyter;)

Kami sudah memiliki contoh dukungan Sixel di mintty yang ditulis dalam C (vice java). Satu-satunya hal yang diperlukan adalah refactor ke C++ (setidaknya untuk dukungan awal). Masih selalu bagus untuk melihat bagaimana itu diterapkan di proyek lain.

Kami sudah memiliki contoh dukungan Sixel di mintty yang ditulis dalam C (vice java). Satu-satunya hal yang diperlukan adalah refactor ke C++ (setidaknya untuk dukungan awal). Masih selalu bagus untuk melihat bagaimana itu diterapkan di proyek lain.

Ada masalah dengan lisensi mintty (GPLv3 atau lebih baru)?

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

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

Dari tautan itu:

Kode sixel (sixel.c) dilisensikan di bawah GPL seperti minty dengan
izin dari penulisnya (kmiya@culti)

Jika Anda mentransliterasi kode yang tepat ke C++, karya turunannya perlu dilisensikan GPLv3 atau lebih baru, sesuai ketentuannya, atau tidak didistribusikan sama sekali. (Seseorang juga dapat bertanya kepada kmiya @culti apakah mereka bersedia menawarkan sixel.c di bawah lisensi yang berbeda, atau jika pernah tersedia di bawah sesuatu yang lain, temukan salinan dari sumber itu.)

Saya tidak tahu apa yang dapat diterima atau tidak untuk dimasukkan dalam Terminal Windows -- pandangan sekilas saya ke Terminal Windows mengatakan itu adalah lisensi MIT, jadi tergantung pada bagaimana itu ditautkan/dimuat menggunakan keturunan langsung dari GPLv3+ sixel.c mintty dapat memimpin untuk masalah lisensi.

Bagaimanapun, maaf mengganggu proyek orang lain di sini, kembali ke gua sekarang ...

Ada widget emulator terminal sederhana berkemampuan sixel yang ditulis dalam C/C++ untuk Windows/Linux, dan ia memiliki kelas SixelRenderer yang dapat Anda gunakan, (meskipun memerlukan beberapa pengoptimalan), dan ia memiliki lisensi BSD-3. Bisa dibilang kelemahan terbesarnya adalah ia ditulis untuk kerangka kerja C++ tertentu. Namun, kode IMO the SixelRenderer dapat diterjemahkan dengan sedikit usaha. (Saya tahu ini karena saya penulisnya. :))

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

Saat menerapkan Sixel, penting untuk menguji dengan gambar yang mengandung transparansi.
Transparansi dapat dicapai dengan menggambar piksel dengan warna berbeda tetapi tidak menggambar beberapa piksel dalam salah satu warna Sixel, membiarkan warna latar belakang seperti itu.
Saya percaya ini adalah satu-satunya cara untuk menggambar Sixels non-persegi panjang dengan benar, dan akan sangat bagus dengan transparansi akrilik latar belakang di Terminal Windows baru.

Pengujian menggunakan WSL dengan Ubuntu misalnya, dalam mlterm gambar tersebut dirender dengan benar sebagai memiliki topeng transparansi dan warna latar belakang disimpan, sedangkan di xterm -ti vt340, piksel yang tidak tersentuh digambar hitam, meskipun latar belakangnya putih, yang tampaknya menyiratkan mereka membuat enamel pada bitmap memori yang diinisialisasi sebagai hitam tanpa topeng transparansi atau alfa sebelum memasukkannya ke jendela terminal.

Hmm. VT340 i'm in front of honors parameter P2 di DCS P1 ; P2 ; P3 ; urutan q yang memulai urutan SIXEL. Xterm, di sisi lain, tampaknya mengabaikannya. Tetapi jika Anda menggunakan urutan atribut raster ( " Pan ; Pad ; Ph ; Pv ) dan memberikan tinggi dan lebar, itu akan menghapus latar belakang sehingga Anda mendapatkan piksel hitam.

saya sedang berpikir untuk mendapatkan uji coba gratis dari emulator ttwin dan memeriksa bagaimana perilakunya berbeda dari VT340 dan Xterm yang bertindak sebagai VT340.

Tapi... +1 untuk ide mendukung SIXEL secara umum dan +10 untuk ide membuat tes kompatibilitas.

Kami dapat menambahkan dukungan untuk iTerm2 Inline Images Protocol begitu kami berada di sana... Setidaknya itu akan lebih mudah diterapkan, hanya perlu jalur ke gambar dan melakukan semuanya sendiri.

Satu keraguan yang saya miliki dengan kedua sistem adalah, apa yang terjadi dengan aligment? Jika lebar atau tinggi gambar adalah kelipatan dari lebar atau tinggi karakter, semuanya baik-baik saja, tetapi jika tidak, haruskah bantalan ditambahkan hanya di sisi bawah dan kanan, atau haruskah gambar dipusatkan dengan menambahkan bantalan ke semua sisi?

Hai, inilah beberapa tautan yang relevan untuk penelitian:

• "Dasar-dasar untuk Protokol Gambar yang Baik " di terminal-wg (dan diskusi sebelumnya yang ditautkan )
• utas besar ini tentang dukungan sixel

Kami dapat menambahkan dukungan untuk iTerm2 Inline Images Protocol begitu kami berada di sana... Setidaknya itu akan lebih mudah diterapkan, hanya perlu jalur ke gambar dan melakukan semuanya sendiri.

Itu mungkin harus menjadi tugas yang berbeda. Sixel dan ReGIS secara eksplisit untuk data grafis atau karakter dalam pita. Saya tidak mengatakan itu ide yang buruk, saya hanya mengatakan itu harus diperlakukan sebagai fitur yang berbeda.

Satu keraguan yang saya miliki dengan kedua sistem adalah, apa yang terjadi dengan aligment? Jika lebar atau tinggi gambar adalah kelipatan dari lebar atau tinggi karakter, semuanya baik-baik saja, tetapi jika tidak, haruskah bantalan ditambahkan hanya di sisi bawah dan kanan, atau haruskah gambar dipusatkan dengan menambahkan bantalan ke semua sisi?

Penjajaran data grafis Sixel dan ReGIS dijelaskan (kurang baik) dalam berbagai manual. Gambar sixel disejajarkan pada batas sel karakter. Jika Anda menginginkan batas hitam di sekitar gambar, Anda harus menambahkan sendiri piksel hitam itu; tidak ada konsep apapun seperti margin atau padding HTML. Setiap baris data sixel menggambarkan garis setinggi enam piksel. Jika Anda mencoba menyelaraskan data gambar sixel dengan karakter teks pada emulator terminal, ini bisa membuat frustasi karena perangkat lunak yang menghasilkan data sixel mungkin tidak mengetahui berapa piksel tinggi setiap mesin terbang karakter. Jika Anda memiliki xterm jadul, Anda dapat melihat ini dengan memulainya dalam mode vt340, menentukan ukuran font yang berbeda (untuk memberi Anda ukuran sel karakter yang berbeda) dan kemudian mencetak beberapa data sixel yang mencoba menyelaraskan data gambar dengan teks data. (Berikut adalah file pengujian sederhana yang terlihat benar ketika saya memberi tahu server font untuk menggunakan 96DPI dan saya menetapkan font 15 titik. Memodifikasi ukuran font menyebabkan gambar semakin tidak selaras dengan teks. https://Gist.github. com/OhMeadhbh/3d63f8b8aa4080d4de40586ffff819de )

Vt340s asli tidak memiliki masalah ini karena (tentu saja) Anda tidak dapat menentukan ukuran font saat menyalakan terminal.

Hal lain yang dapat Anda lihat dari gambar itu, yang tidak dijelaskan dengan baik dalam dokumentasi sixel adalah bahwa mencetak sebaris data sixel membentuk "margin kiri virtual" untuk data gambar. Jika Anda melakukan persamaan moral dari CR atau CRLF menggunakan karakter '$' atau '-', baris berikutnya dicetak relatif terhadap margin kiri virtual ini, bukan margin kiri nyata di sisi kiri terminal.

Semoga ini membantu.

Akhirnya scroll ke belakang untuk baca ini. Maaf atas balasan yang terlambat.

Pengujian menggunakan WSL dengan Ubuntu misalnya, dalam mlterm gambar tersebut dirender dengan benar sebagai memiliki topeng transparansi dan warna latar belakang disimpan, sedangkan di xterm -ti vt340, piksel yang tidak tersentuh digambar hitam, meskipun latar belakangnya putih, yang tampaknya menyiratkan mereka membuat enamel pada bitmap memori yang diinisialisasi sebagai hitam tanpa topeng transparansi atau alfa sebelum memasukkannya ke jendela terminal.

Seharusnya tidak terlalu sulit untuk mendukung transparansi di xterm. Saya telah menggali kode untuk alasan lain. Saya khawatir seseorang, di suatu tempat tergantung pada perilaku Xterm ini, jadi saya sarankan untuk meletakkannya di belakang bendera kompatibilitas, yang juga harus langsung. Tapi kemudian ada pertanyaan tentang nilai default. Apa yang harus menjadi default? Hitam atau transparan.

Tahukah kita apa yang dilakukan VT240, 241, 330, dan 340 yang asli? Bisakah saya menyarankan untuk mencoba dengan setia mewakili pengalaman VT yang sebenarnya?sebagai perilaku default? Anda dapat mengujinya dengan mencetak karakter spasi terbalik, lalu melapisi grafik enamel di atasnya dan melihat warna apa yang ditampilkan piksel yang tidak ditentukan.

Saya tidak tahu bahwa saya terlalu peduli apa default untuk terminal msft selama ada kemampuan berperilaku seperti Xterm meniru VT340. Kode yang saya tulis untuk melakukan logline melalui ssh di terminal semacam mengasumsikan perilaku "piksel yang tidak ditentukan berwarna hitam" yang dijelaskan di atas. Saya harus menulis ulang kode itu jika kami membuat perubahan ini.

Jika Anda mencoba menyelaraskan data gambar sixel dengan karakter teks pada emulator terminal, ini bisa membuat frustasi karena perangkat lunak yang menghasilkan data sixel mungkin tidak mengetahui berapa piksel tinggi setiap mesin terbang karakter.

Vt340s asli tidak memiliki masalah ini karena (tentu saja) Anda tidak dapat menentukan ukuran font saat menyalakan terminal.

Apakah ada alasan mengapa emulator terminal tidak bisa begitu saja menskalakan gambar agar sama persis dengan perilaku terminal DEC asli? Jadi jika tinggi garis pada VT340 adalah 20 piksel, maka gambar dengan tinggi 200 piksel harus mencakup tepat 10 baris, terlepas dari ukuran fontnya. Bagi saya itu satu-satunya cara Anda bisa tetap cukup kompatibel dengan perangkat lunak lawas, yang merupakan inti dari emulator terminal.

Saya dapat memahami keinginan untuk memperluas perilaku itu untuk membuat gambar pada resolusi yang lebih tinggi, tetapi saya pikir itu harus menjadi ekstensi opsional (atau cukup gunakan salah satu format berpemilik yang ada). Jadi idealnya saya ingin default untuk Sixel sedekat mungkin dengan apa yang akan Anda dapatkan di terminal DEC yang sebenarnya.

Hai, inilah beberapa tautan yang relevan untuk penelitian:
"Dasar-dasar untuk Protokol Gambar yang Baik" di terminal-wg

Sixel rusak karena tidak dapat didukung oleh tmux dengan panel berdampingan.

Butuh beberapa pekerjaan (sebenarnya banyak pekerjaan ), tetapi dengan sixel seseorang dapat melakukan hampir semua trik "gambar di terminal" yang dapat digambar:

• Gambar bertopeng per sel berlapis di terminal: https://jexer.sourceforge.io/images/sixel_many_images.png

• Jendela terminal mengambang (multipleks) di terminal yang menggunakan sixel untuk dukungan lebar ganda gaya VT100: https://jexer.sourceforge.io/screenshots/jexer_sixel_in_sixel.png

• terminal ubin "tmux-style" dengan gambar: https://gitlab.com/klamonte/jexer/-/wikis/uploads/7603381f82414ef9ae214bfcf759c064/example_tilingwm2_1.png

• Sesi terminal bersama multi-kepala dengan ukuran sel teks berbeda yang menunjukkan plot yang sama: https://jexer.sourceforge.io/screenshots/multiscreen_2b.png

• Penggunaan sixel untuk merender CJK dan emoji yang tidak ada di font terminal utama: https://jexer.sourceforge.io/screenshots/xterm_sixel_cjk.png

Saya telah menyertakan beberapa komentar lain di utas protokol "baik" yang dirujuk yang mungkin menarik.

Jika tidak ada yang lain, sixel adalah batu loncatan yang baik untuk mengerjakan infrastruktur sisi terminal dari gambar-dan-teks campuran. Berbicara dari pengalaman langsung, sisi terminal (menyimpan/menampilkan gambar) sekitar 1/4 sekeras sisi multiplexer/aplikasi (tmux/mc et al).

sixels memang solusi ideal untuk grafik in-band (misalnya melalui ssh): karena didukung oleh banyak alat yang ada, mereka siap digunakan untuk tujuan praktis seperti merencanakan masalah sinkronisasi stempel waktu saat bepergian.

Seperti yang diilustrasikan oleh therealkenc dan dijelaskan lebih lanjut oleh klamonte di 640292222 semuanya dapat ditangani dengan enamel, bahkan gambar berdampingan, tetapi membutuhkan beberapa pekerjaan.

Beberapa waktu yang lalu saya bekerja dengan beberapa orang lain pada mode fallback untuk tmux, menggunakan grafik unicode tingkat lanjut untuk mewakili gambar sixel di terminal yang tidak mendukung sixel.

Ini sedikit seperti seni ANSII otomatis, mengambil keuntungan dari karakter blok khusus yang ada di sebagian besar font: representasi unicode warna yang setara ini dapat diganti dengan sixel, kemudian ditimpa oleh gambar sixel yang sebenarnya (atau tidak!). Itu juga akan memecahkan masalah menyimpan semua gambar sixel untuk digulir kembali, dengan menggantinya dengan placeholder unicode kesetiaan rendah (misalnya untuk menghemat memori), dan memiliki placeholder untuk gambar sixel ketika mereka tidak dapat ditampilkan karena alasan apa pun.

Kode adalah domain publik. Ini dapat segera digunakan sebagai langkah pertama menuju dukungan sixel:

• mendeteksi ketika urutan sixels ditransmisikan, kemudian menghitung penggantian teks unicode

• tampilkan urutan unicode ini, yang sudah didukung oleh Terminal Windows

• kemudian, ketika sixels diimplementasikan, render di atas urutan sixel.

Apakah Anda tertarik?

BTW saya mengenali di sini plot gnuplot x^2 sin dan 10 sin(x) saya yang familier, saya senang itu memberikan beberapa inspirasi

Tolong.

@DHowett Apakah acac350 merupakan langkah pertama untuk benar-benar merender grafik sixel? Saya mendapatkan permintaan untuk dukungan sixel di Microsoft Terminal dari orang-orang yang menggunakan ssh dan ingin melihat direktori gambar menggunakan program lsix saya.

Agak. Kami sekarang memiliki kemampuan untuk menangani urutan DCS yang masuk. Kami belum menghubungkan penangan apa pun, tetapi memiliki infrastruktur untuk melakukannya cukup penting. :senyum:

Berikut beberapa pembaruan. Saya memiliki cabang yang bekerja di sini . Tangkapan layar awal terlihat seperti ini:

Bertentangan dengan apa yang awalnya saya pikirkan, bagian tersulit dari rendering gambar sixel sebenarnya adalah lapisan conpty. Gambar sixel seharusnya menjadi objek sebaris. Render gambar sixel tergantung pada ukuran rendering karakter. Namun karena lapisan conpty ekstra kita sebenarnya tidak bisa mendapatkan ukuran rendering karakter saat memproses urutan sixel. Ini terdengar sangat abstrak dan tidak jelas. Siapa pun yang tertarik dengan ini dapat memeriksa cabang saya dan melihat bagaimana hal itu dilakukan.

Secara keseluruhan, lapisan conpty membuatnya sangat sulit untuk menangani pengguliran dan pengubahan ukuran gambar sixel. Di cabang saya ini berfungsi jika Anda hanya perlu menampilkannya. Tetapi pengguliran dan pengubahan ukuran benar-benar rusak.

Belum terlihat tetapi dapatkah Anda menggunakan mode pass-through untuk diterapkan di Terminal itu sendiri? Saya masih akan menambahkannya di OpenConsole tetapi sepertinya berbagi kode tidak mungkin. Karena Terminal Windows perlu dipisahkan dari OpenConsole di beberapa titik, Anda sebaiknya menduplikasi kode untuk keduanya. Juga apakah Anda mendasarkannya pada PR Anda dan j4james untuk parameter? Itu mungkin akan membantu juga.

@WSLUser Terima kasih atas perhatiannya. Tangkapan layar ini sebenarnya dari sekitar sebulan yang lalu, ketika parameter fantastis PR dari j4james bahkan tidak ada. Pekerjaan saya sepenuhnya di dalam Terminal Windows, bukan conhost. Saya menunjukkan PR ini kepada tim Konsol secara internal dan membuat beberapa kemajuan sejak saat itu. Tapi saya macet karena masalah conpty.

Ya, saya akan menghapus master dan menambahkan https://github.com/Microsoft/terminal/pull/7578 dan https://github.com/Microsoft/terminal/pull/7799 . Dari sana, mungkin lihat apa yang hilang di ConPTY untuk mode pass-through. Saya ingin tahu Mintty menggunakan pass-through untuk mode ConPTY.

Saya ingin tahu Mintty menggunakan pass-through untuk mode ConPTY.

Cukup yakin mintty tidak menggunakan conpty sama sekali

Trik di sini dengan conpty adalah bahwa konsol (conpty) perlu mengetahui tentang sel yang diisi dengan konten sixel, agar tidak secara tidak sengaja menghapus konten itu dari Terminal yang terhubung. Mungkin conpty dapat tercerahkan untuk mengabaikan sel lukisan dengan grafik sizel, dan anggap saja Terminal yang terhubung akan membiarkan sel-sel itu sendirian.

Itu mungkin mengacaukan beberapa pengoptimalan kami (seperti kami tidak dapat menghapus baris yang memiliki data sixel), tetapi ini mungkin awal yang cukup baik

\

Mungkin conpty dapat tercerahkan untuk mengabaikan sel lukisan dengan grafik sizel, dan anggap saja Terminal yang terhubung akan membiarkan sel-sel itu sendirian.

Ini juga merupakan rencana awal saya, dan ini mungkin merupakan solusi terbaik dengan arsitektur conpty saat ini, tetapi ada sejumlah komplikasi.

1. Bagaimana ini akan berinteraksi dengan streaming DCS (yang menurut saya belum ada solusinya). Saya berasumsi kita akan memerlukan semacam konsep aliran terpisah yang meneruskan aliran byte ke conpty pada saat yang sama ketika dikirim ke buffer conhost, tetapi sepertinya itu akan menambahkan banyak overhead yang tidak perlu ke proses.
2. Ini hanya akan berfungsi jika Anda mengetahui ukuran sel piksel dari terminal conpty. Saya telah menyebutkan sebelumnya, saya pikir solusi terbaik untuk Sixel adalah mencocokkan ukuran sel dari terminal VT asli, dan jika kami melakukan itu, ini tidak akan menjadi masalah. Namun, sejauh yang saya ketahui, tidak ada emulator terminal lain yang melakukan itu, jadi itu tidak akan berfungsi dengan orang lain.

Masalah kedua yang diangkat @j4james menjadi lebih rumit dengan pertimbangan font yang berbeda, ukuran font dan ukuran font yang berbeda. Jadi secara umum saya pikir ada 3 aspek dari masalah ini:

• Pertama conpty perlu tahu tentang sel yang diisi dengan konten sixel, Tanpa ini, backing buffer di conpty dan drawing buffer di WT pasti akan tidak sinkron.
• Untuk melakukan itu, conpty perlu mengetahui ukuran sel piksel dalam konteks gambar, yang ditangani oleh lapisan gambar di WT. Ada kesenjangan besar antara conpty dan DXRenderer yang sebenarnya, yang membuat ini menjadi tugas yang sulit.
• Selain itu, ketika font atau ukuran font berubah, idealnya gambar sixel juga harus berubah.
• Dan akhirnya berurusan dengan hal-hal lain seperti panel, buffer alternatif, gambar diferensial, pengguliran, dll.

Masalah kedua yang diangkat @j4james menjadi lebih rumit dengan pertimbangan font yang berbeda, ukuran font dan ukuran font yang berbeda. Jadi secara umum saya pikir ada 3 aspek dari masalah ini:

Untuk memperjelas, maksud saya adalah bahwa semua itu tidak akan menjadi masalah jika kita sama persis dengan perilaku VT340, jadi gambar 10x20 piksel akan menempati tepat satu sel karakter, terlepas dari ukuran font. Ini hanya masalah jika kita ingin mencocokkan perilaku emulator terminal lain, dan itu selalu bisa menjadi opsi yang tersisa untuk nanti. Masih akan ada komplikasi dengan pendekatan ini, tetapi menurut saya pribadi mereka tidak terlalu mengkhawatirkan.

Kekhawatiran saya yang lebih besar adalah bahwa Anda tampaknya mengabaikan masalah streaming DCS, yang saya harapkan dapat mengubah arsitektur solusi secara mendasar. Langkah-langkah yang ingin saya lihat adalah: 1. Selesaikan #7316; 2. Menyetujui solusi untuk ukuran piksel sel; 3. Dapatkan sesuatu yang berfungsi di conhost; 4. Setelah semua komplikasi diselesaikan di conhost, baru kemudian pertimbangkan bagaimana kita membuatnya bekerja di atas conpty.

Maaf telah meninggalkan masalah streaming DCS. Dalam implementasi saya saat ini, saya hanya menyimpan seluruh string dan meneruskannya ke mesin. Ini memperkenalkan masalah kinerja ketika urutannya lebih besar. Tapi setidaknya itu berhasil. Jadi komentar saya di atas sebagian besar didasarkan pada itu.

Tapi Anda benar. Masalah streaming DCS sebenarnya adalah prioritas utama jika orang lain ingin mengotori ini.

Outlook untuk iOS https://aka.ms/o0ukef

Per diskusi di https://github.com/microsoft/terminal/issues/57 , saya pikir conpty tidak peduli dengan font sama sekali?

wrt mengubah ukuran Saya pikir cara paling alami untuk melakukannya adalah dengan "menjangkarkan" gambar ke dalam sel karakter setelah gambar tiba, dan menghitung ulang ukuran gambar berdasarkan geometri jangkar. Hal lain akan menyebabkan inkonsistensi dalam sel gambar vs. karakter.

@yatli Ya. Itu juga yang membuat masalah ini rumit.

Gambar 10x20 piksel akan menempati tepat satu sel karakter

Sayangnya ini salah, setidaknya untuk pengaturan font saya saat ini.

Perbaiki saya jika saya salah, tetapi untuk tampilan gambar piksel yang sempurna, saya pikir kita perlu memperhatikan font.

@skyline75489 tolong lihat komentar saya yang diperbarui tentang "jangkar"

Struktur data sel perlu diperbarui sebagai char | sixel anchor

Jangkar sixel harus berisi informasi tentang:

• Pointer ke objek gambar
• Wilayah sel char yang ditempatinya, dalam bilangan mengambang (misalnya 5,2 baris x 7,8 cols)

Itu ide yang bagus tetapi detail implementasi membunuh saya, karena terjemahan tambahan di lapisan conpty. Untuk menghindari spamming orang dengan email, jangan ragu untuk menghubungi saya di Teams @yatli jika Anda tertarik.

Gambar 10x20 piksel akan menempati tepat satu sel karakter

Sayangnya ini salah, setidaknya untuk pengaturan font saya saat ini.

Apa yang saya sarankan adalah bahwa Anda harus membuat kasus itu. Jika Anda membuat gambar 10x20 piksel dan menampilkannya pada terminal DEC VT320 nyata, itu akan mengambil tepat satu karakter (setidaknya dalam mode 80 kolom). Jadi jika kita mencoba meniru terminal itu, maka kita harus melakukan hal yang sama. Jika font Anda saat ini berukuran 30x60, maka Anda perlu memperbesar gambar. Jika font Anda lebih kecil, maka Anda memperkecil gambar.

Ini menjamin bahwa Anda dapat menampilkan gambar Sixel pada ukuran font apa pun dan selalu mendapatkan tata letak yang sama. Jika Anda ingin itu menutupi area tertentu dari layar, atau Anda ingin menggambar perbatasan di sekitarnya dengan karakter teks, Anda tahu persis berapa banyak ruang yang akan ditempati gambar.

Perbaiki saya jika saya salah, tetapi untuk tampilan gambar piksel yang sempurna, saya pikir kita perlu memperhatikan font.

Memang benar bahwa Anda tidak akan mendapatkan gambar "piksel sempurna" dengan cara ini, tetapi menurut saya itu bukan tujuan utama. Banyak komputer modern memiliki tampilan dpi tinggi di mana merupakan hal yang rutin untuk memperbesar gambar, jadi ini bukanlah konsep yang aneh. Dan jika kita ingin menjaga agar tata letak tetap konsisten saat pengguna mengubah ukuran fontnya, kita tetap harus menskalakan gambar di beberapa titik, jadi sebaiknya Anda melakukannya dari awal dan mendapatkan semua manfaat yang dapat diprediksi. ukuran.

Dan tentu saja manfaat lain dari melakukan hal-hal dengan cara ini adalah bahwa hal itu dapat diimplementasikan secara layak melalui conpty. Saya tidak melihat bagaimana Anda dapat membuat conpty berfungsi jika area yang ditempati oleh gambar bergantung pada ukuran font, yang mungkin tidak Anda ketahui.

Saya tidak akan berpura-pura pendekatan ini tidak akan memiliki kerugian, tapi saya pikir positif lebih besar daripada negatif.

Bagaimana jika font memiliki rasio aspek yang berbeda dari 10:20?

Bagaimana jika font memiliki rasio aspek yang berbeda dari 10:20?

Bolehkah saya menyarankan membaca diskusi panjang ini - dan agak "brutal" - tentang masalah umum mengenai gambar sebaris di emulator terminal .

Ini dapat memberi Anda gambaran umum.

salam Hormat

Bagaimana jika font memiliki rasio aspek yang berbeda dari 10:20?

Gambarnya mungkin sedikit melebar atau terjepit, tapi saya rasa itu bukan akhir dunia.

Biarkan saya menunjukkan dengan contoh dunia nyata. Bayangkan saya adalah penjahat Bond, dan saya memiliki sistem keamanan lama yang menggunakan VT340 sebagai frontend. Sekarang karena virus corona, saya terkunci dan bekerja dari rumah, jadi saya masuk ke sistem dari jarak jauh dengan Terminal Windows. Jika kami benar-benar cocok dengan VT340, ini tidak masalah - terminal terlihat seperti ini:

Tapi mungkin saya lebih suka font dengan rasio aspek yang aneh. Jadi mari kita lihat seperti apa _Miriam Fixed_, yang lebih lebar dari kebanyakan. Citra Bond sekarang terlihat agak terjepit, tetapi dia masih mudah dikenali.

Alternatifnya adalah menggunakan gambar piksel sempurna (saat ini tidak layak dengan conpty, tapi mari kita berpura-pura sebentar). Bond tidak lagi terlihat kaku, tetapi sekarang gambarnya hanya sebagian kecil dari ukuran yang diharapkan. Dan semakin tinggi resolusi monitor Anda, semakin buruk tampilannya.

Mungkin ini masalah preferensi pribadi, tetapi saya tahu saya pasti akan memilih opsi 1 daripada opsi 2.

Perhatikan juga bahwa tidak ada alasan kami tidak memiliki opsi untuk mengubah perilaku yang tepat ketika rasio aspek font tidak 1:2. Salah satu pilihannya adalah dengan memusatkan gambar di dalam sel yang diharapkan akan ditempati. Atau kita dapat memperluas gambar sehingga menutupi seluruh area, tetapi klip tepi yang melebihi batas. Salah satu dari pilihan ini akan lebih baik daripada rendering piksel yang tepat menurut saya.

Mungkin ini masalah preferensi pribadi, tetapi saya tahu saya pasti akan memilih opsi 1 daripada opsi 2.

Saya juga, hanya saja akan lebih baik untuk mengetahui font memiliki rasio aspek yang berbeda, sehingga gambar dapat menyesuaikan sendiri dan mempertahankan yang benar.

Salah satu pilihannya adalah dengan memusatkan gambar di dalam sel yang diharapkan akan ditempati. Atau kita dapat memperluas gambar sehingga menutupi seluruh area, tetapi klip tepi yang melebihi batas

Saya pikir lebih baik untuk memusatkan mereka.

Mungkin saya salah baca thread ini. Apakah kita benar-benar berbicara tentang terminal memalsukan 10:20 karakter untuk gambar sixel? Saya pikir itu akan menyebabkan banyak masalah seperti distorsi Bond. Melakukannya dengan cara yang benar mungkin lebih sulit, tetapi, menurut pendapat saya, terminal modern harus agnostik font dan menyerahkannya kepada pemrogram aplikasi untuk menangani sixels dan sel karakter.

Dengan menggunakan escape sequence, program yang dijalankan pengguna dapat menentukan ukuran sel karakter dalam piksel dan memutuskan bagaimana menangani distorsi secara cerdas untuk aplikasi tersebut. Program melihat gambar yang saya gunakan bekerja persis seperti itu. Saat saya mengubah keluarga atau ukuran font, thumbnail yang ditampilkan diperbarui agar selalu setinggi lima baris teks. Lebar diskalakan secara proporsional untuk gambar, kecuali jika lebih besar dari maksimum tertentu (dalam hal ini, agak besar). Dengan mendasarkan ukuran gambar pada sel karakter, ia bekerja secara otomatis pada layar DPI tinggi.

Sementara VT340 adalah tujuan mulia untuk ditiru, memperbaiki resolusi sel karakter pada 10:20 (dan dengan demikian membatasi resolusi untuk seluruh layar) adalah sebuah kesalahan. VT340 hanyalah salah satu dari beberapa implementasi sixel, jadi ukuran fontnya belum tentu lebih benar.

Memaksa 10:20 juga akan menyebabkan kludges jelek. (Misalnya, bagaimana menanggapi permintaan untuk ukuran jendela terminal dalam piksel. Katakan yang sebenarnya, menganggap mereka akan memposisikan jendela di layar? Atau, selalu kembalikan 800x480, dengan anggapan pengguna menskalakan gambar untuk keluaran sixel? )

Apakah kita benar-benar berbicara tentang terminal memalsukan 10:20 karakter untuk gambar sixel?

Ya.

terminal modern harus font agnostic

Proposal ini adalah font agnostik. Aplikasi tidak perlu tahu apa-apa tentang font. Itulah intinya.

Dengan menggunakan escape sequence, program yang dijalankan pengguna dapat menentukan ukuran sel karakter dalam piksel dan memutuskan bagaimana menangani distorsi secara cerdas untuk aplikasi tersebut.

Saya tidak yakin metode apa yang Anda gunakan, tetapi cara saya melihat ini dilakukan sebelumnya adalah dengan kueri XTerm berpemilik untuk mendapatkan ukuran piksel jendela, dan kueri lain untuk mendapatkan ukuran sel jendela, dan kemudian menggunakannya data untuk menghitung ukuran piksel sel yang sebenarnya. Kelemahan dari pendekatan semacam itu adalah:

1. Ini milik, jadi tidak akan berfungsi pada terminal nyata, atau emulator terminal apa pun yang sama persis dengan terminal nyata.
2. Jika pengguna mengubah ukuran font mereka saat aplikasi Anda berjalan, maka perhitungan Anda tidak lagi benar, dan gambar akan ditampilkan pada ukuran yang salah (kecuali jika Anda terus menghitung ulang ukuran font yang tampaknya tidak praktis).
3. Jika pengguna memiliki tampilan resolusi tinggi, dan/atau ukuran font besar, Anda terpaksa mengirim gambar besar untuk mencoba dan mencocokkan resolusi itu. Mempertimbangkan betapa tidak efisiennya Sixel untuk memulai, itu dapat menghasilkan banyak bandwidth.

Yang mengatakan, saya mengerti bahwa ini adalah mode yang mungkin ingin digunakan beberapa orang, dan saya pikir kita setidaknya harus memiliki opsi untuk mendukungnya suatu hari nanti (untuk alasan yang dibahas di atas, ini tidak mungkin saat ini). Tapi menurut saya, ini bukan pendekatan terbaik untuk Sixel.

Saya memiliki 300+ VT340 di pembangkit listrik tenaga nuklir yang pada akhirnya saya ingin
mengganti.

Ada paket emulasi terminal komersial yang bisa kita gunakan, tapi saya pikir
semua kecuali satu telah EOL'd.

Kami telah mengganti beberapa dari mereka dengan PC Linux yang menjalankan XTerm (atau kurang
sering, Win10 + Hummingbird + WSL menjalankan XTerm), karena memiliki
implementasi sixel open source setengah jalan yang layak dan semacam buruk, tapi
implementasi ReGIS open source.

Kemungkinan kami akan menulis perangkat lunak baru untuk bagian ini
sistem yang menghasilkan aliran oktet sixel adalah NIL.

Jika tujuan Anda adalah mengirim grafik melalui aliran oktet sebaris, di sana
adalah pilihan lain. Tetapi jika Anda ingin mendukung grafik sixel, Anda harus
mendukung grafik sixel dengan cara yang setengah mirip dengan sebelumnya
implementasi. Sayangnya, ini berarti Anda harus meniru
perilaku sistem teladan (yaitu VT240, VT241, VT330 dan VT340
terminal) bahkan ketika harus mengintegrasikan grafik dengan teks.

Ini adalah mock-up dari jenis hal yang saya bicarakan. Itu akan sangat
bagus jika ada implementasi Sixel baru yang mempertahankan kompatibilitas dengan yang ada
implementasi sehingga gambar tidak keluar dari tepi layar atau hanya
mengisi setengah layar.

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

terminal modern harus font agnostic

Proposal ini adalah font agnostik. Aplikasi tidak perlu tahu apa-apa tentang font. Itulah intinya.

Maksud saya _terminal_ harus font agnostik daripada memaksakan 10:20 pada setiap font. Aplikasi harus dapat mengetahui ukuran font yang sebenarnya, jika diinginkan, karena aplikasilah yang mengetahui domain dari apa yang coba ditampilkan dan dapat menemukan cara terbaik untuk menyajikan teks dan grafik secara bersamaan.

Dengan menggunakan escape sequence, program yang dijalankan pengguna dapat menentukan ukuran sel karakter dalam piksel dan memutuskan bagaimana menangani distorsi secara cerdas untuk aplikasi tersebut.

Saya tidak yakin metode apa yang Anda gunakan, tetapi cara saya melihat ini dilakukan sebelumnya adalah dengan kueri XTerm berpemilik untuk mendapatkan ukuran piksel jendela, dan kueri lain untuk mendapatkan ukuran sel jendela, dan kemudian menggunakannya data untuk menghitung ukuran piksel sel yang sebenarnya.

Yup, kurang lebih seperti itu. Ada juga permintaan untuk langsung mendapatkan ukuran sel karakter, tapi saya rasa itu tidak didukung secara luas seperti hanya mendapatkan ukuran layar dan membaginya dengan BARIS dan KOLOM.

Kelemahan dari pendekatan semacam itu adalah:

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

Itu bukan sisi negatifnya. Ini hanya berarti program harus kembali melakukan apa yang seharusnya dilakukan: anggaplah $TERM=="VT340" berarti sel karakter 10:20, "VT240" berarti 10:10, "mskermit" berarti 8:8, dan seterusnya.

Juga, ini bukan urutan kepemilikan xterm. Mendapatkan ukuran layar disebut escape sequence "dtterm", tetapi sebenarnya pertama kali diimplementasikan di SunView (SunOS, 1986). Saya percaya itu kemudian didokumentasikan dalam Manual Pemrograman PHIGS (1992). Coba kirim "\e[14t" ke beberapa emulator terminal dan Anda akan melihatnya diimplementasikan secara luas.

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).

Ini bukan masalah. Program hanya menjebak SIGWINCH dan hanya menghitung ulang jika jendela benar-benar berubah.

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.

Ya, sixel sangat tidak efisien. Tetapi pada komputer modern, mengirim gambar layar penuh cukup berguna, bahkan melalui ssh. Apakah Terminal Microsoft memiliki semacam batasan baudrate?

Omong-omong, saya percaya sixel memang memiliki mode "DPI tinggi" di mana setiap titik digandakan lebar dan tinggi. Saya belum pernah menggunakannya dan saya tidak berpikir xterm bahkan mengimplementasikannya, tapi mungkin itu akan mengurangi kekhawatiran tentang bandwidth.

Yang mengatakan, saya mengerti bahwa ini adalah mode yang mungkin ingin digunakan beberapa orang, dan saya pikir kita setidaknya harus memiliki opsi untuk mendukungnya suatu hari nanti (untuk alasan yang dibahas di atas, ini tidak mungkin saat ini).

"Mode" ini hanya menyelaraskan karakter dan grafik seperti yang dilakukan berbagai terminal sixel historis dan emulator saat ini. Saya akui, saya tidak mengerti mengapa tidak mungkin melakukan hal yang sama di Microsoft Terminal. Jika Anda mengatakan kludge 10:20 ini adalah yang terbaik yang dapat dilakukan, saya akan percaya bahwa Anda benar dan terima kasih telah melakukannya. Gambar yang terdistorsi jauh lebih baik daripada tidak sama sekali.

Dengan menggunakan escape sequence, program yang dijalankan pengguna dapat menentukan ukuran sel karakter dalam piksel dan memutuskan bagaimana menangani distorsi secara cerdas untuk aplikasi tersebut.

@hackerb9 , apa urutan pelarian yang sebenarnya untuk mendapatkan dimensi font?

Urutan XTerm yang relevan dapat ditemukan di sini: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html -- cari XTWINOPS.

Selain itu, di Unix Anda biasanya bisa mendapatkan ukuran piksel internal terminal bersama dengan ukuran sel menggunakan ioctl TIOCGWINSZ. Dengan openssh ini juga berfungsi dari jarak jauh.

Sama seperti titik data, cabang sixel untuk libvte mengambil rute agnostik ukuran sel yang dibicarakan @hackerb9 . Ini memperlakukan data sixel yang masuk sebagai "piksel sempurna" dan mengubah skala gambar yang diterima sebelumnya di seluruh tingkat zoom dan ukuran font untuk menutupi tingkat sel yang konsisten. Ketika digabungkan, implementasi ini akan tersedia untuk sebagian besar emulator terminal Linux, termasuk Terminal GNOME, Terminal XFCE, Terminator, dll. Secara dangkal ini tampaknya dapat dioperasikan dengan setidaknya XTerm dan mlterm.

Karena libvte merekam ukuran sel virtual per gambar, akan mudah untuk membuat ini berfungsi dengan ukuran sel 10x20 virtual tetap juga untuk interoperasi. Namun, kami membutuhkan cara agar program dapat mengomunikasikan rasio piksel:sel yang diharapkan ke terminal (misalnya dengan memperluas parameter DCS). Itu bisa sangat berguna secara umum, karena itu juga akan menyediakan bentuk kontrol kepadatan piksel di lingkungan yang dibatasi bandwidth, seperti yang Anda sentuh di atas.

Selain itu, di Unix Anda biasanya bisa mendapatkan ukuran piksel internal terminal bersama dengan ukuran sel menggunakan ioctl TIOCGWINSZ. Dengan openssh ini juga berfungsi dari jarak jauh.

Konsol Linux selalu mengembalikan 0... mereka harus memperbaikinya, tetapi tampaknya tidak mau juga :-/