Terminal: Feature Request: Sixel-Grafikunterstützung

Bei der Implementierung von Sixel ist es wichtig, mit Bildern zu testen, die Transparenz enthalten.
Transparenz kann erreicht werden, indem Pixel in verschiedenen Farben gezeichnet werden, aber einige Pixel nicht in einer der Sixel-Farben gezeichnet werden, wodurch die Hintergrundfarbe unverändert bleibt.
Ich glaube, dies ist die einzige Möglichkeit, nicht rechteckige Sixels richtig zu zeichnen, und wäre besonders schön mit der Hintergrund-Acryltransparenz im neuen Windows Terminal.

Beim Testen mit WSL mit Ubuntu zum Beispiel werden in mlterm solche Bilder richtig mit einer Transparenzmaske gerendert und die Hintergrundfarbe wird beibehalten, während in xterm -ti vt340 unberührte Pixel schwarz gezeichnet werden, obwohl der Hintergrund weiß ist, was so scheint implizieren, dass sie Sechsel auf einer Speicherbitmap rendern, die als Schwarz ohne Transparenzmaske oder Alpha initialisiert wurde, bevor sie in das Terminalfenster geblottet werden.

Oh. Sixel ist sehr cooles Zeug.

Ich habe entschieden, dass ich das brauche. BRAUCHEN.

Ich werde gerne eine PR überprüfen :)

Ich habe heute das Build 2019- Interview gesehen, in dem diese Anfrage erwähnt wurde. Ich behaupte immer noch, dass Xorg auf Sixel einfach falsch ist. Also _sehr falsch_.

Die ffmpeg-Sixel-Demo " Steve Ballmer Sells CS50" wird jedoch nie müde. Ich muss sagen, es ist ein wenig enttäuschend, dass dem Video der Ton fehlt (der Ton macht das Video wirklich aus). Konsolen haben natürlich schon Ton. Sie piepen total. Präzedenzfall. Was wir wirklich _brauchen_, ist eine neue CSI-Sequenz für die Opus -Clips, die mit den Frames verschachtelt ist, Amirite?

Ken, ich verdiene das wirklich für die Erwähnung von Sixels;)

Von: therealkenc [email protected]
Gesendet: Mittwoch, 8. Mai 2019 16:31:31 Uhr
An: Microsoft/Terminal
CC: Abonniert
Betreff: Re: [microsoft/Terminal] Sixel-Grafikunterstützung (#448)

Build 2019 erfasst 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%2BVRlbPgpwJWtPZSGGHc%3Dthat&reserved=0 Erwähnung dieses Interviews heute. Ich behaupte immer noch, dass Xorg auf Sixel einfach falsch ist 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%2BwCnn0z70FkI9lDcus1nMXcKz1P0ArL5%o.Doz%2.Du&Bmreserved= Also sehr sehr falsch.

Die ffmpeg-Sixel https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsaitoha%2FFFmpeg-SIXEL&data=01%7C01%7Cduhowett%40microsoft.com%7C81f48be19f374665cd3408d6d40d4dc6%7C72f988bf86f141af91ab2d7cd011db47 %7C1&sdata=G%2F9mvw1EdADkwChSbHZ%2FI54k9xvXagV%2FxD9VbJtyw7g%3D&reserved=0 „Steve Ballmer verkauft CS50“-Demo https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com% 2Fwatch% 3Fv% 3D7z6lo4aq6zc% 26feature% 3Dyoutu.be & data = 01% 7C01% 7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 & sdata = 6IVwBHs6% 2F43rXdk6GabiSUpTFS86xUGB6bubfkS3ea0% 3D & reserviert = 0 nie müde tho bekommt. Ich muss sagen, es ist ein wenig enttäuschend, dass dem Video der Ton fehlt (der Ton macht das Video wirklich 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 = Mm1ICN5KcgrP5YmdAZsUCzUKbVQDtxFE1qAEpkhKiZk% 3D & reserviert = 0 ). Konsolen haben natürlich schon Ton. Sie piepen total. Präzedenzfall. Was wir wirklich brauchen, ist eine neue CSI-Sequenz 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 & reserviert = 0 für das Opus 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% 2B7gQeTKQBQ2fYJPnoLvx6vUjmLRhgOX1eDo% 3D & reserviert = 0 verschachtelt Clips mit dem Rahmen, amirite?

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FTerminal%2Fissues%2F448%23issuecomment-490688164&data=01 an 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 & reserviert = 0 .

Verwandte: #120

Brauchen.

LOL Ich habe mir den Stream angesehen und dachte mir nur: "Hier ist mein Chef, der mir Arbeit vor einem Studiopublikum zuweist".

Bitte machen Sie dies zu einer Priorität für v1.0!

3D-Animationen können v1.5 sein 😛

OMG

Wenn man dieser Bitte zustimmt, wäre Sixels so eine tolle Sache, die man im Terminal haben könnte.

Dieses Wochenende habe ich die Implementierung der Sixel-Leseunterstützung für meine MIT-lizenzierte Java-basierte TUI-Bibliothek abgeschlossen, und es war überraschend einfach. Der Code zum Konvertieren einer Reihe von Sixel-Daten in ein Bitmap-Bild ist hier , und der Client-Code für die Sixel-Klasse ist hier .

Ich habe sehr wenig für die Leistung des Decoders getan. Aber wenn Sie das Swing-Backend verwenden, ist die Leistung immer noch in Ordnung, wie hier zu sehen ist. (Das Schlangenbild sieht nur deshalb schlecht aus, weil byzanz eine schlechte Palette verwendet hat, um das Demo-GIF zu erstellen.) Ich war etwas überrascht, wie schnell es zusammenkam. Es ist sehr fair zu sagen, dass der Teil "Sixel in Bitmap decodieren" der einfache Teil ist, der schwierige Teil ist das "Bilddaten in eine Textzelle stecken, und wenn das vorhanden ist, das Bild auf den Bildschirm und nicht das Zeichen blitten".

Ich möchte es nur anderen Leuten gegenüber erwähnen, die an Terminalunterstützung für Sixel interessiert sind, und hoffen, dass es Ihnen helfen könnte.

Ich werde positiv abstimmen, wenn jemand anderes einen Jupyter-Notebook-Client schreibt;)

Wir haben bereits ein Beispiel für Sixel-Unterstützung in mintty , das in C (vice java) geschrieben ist. Das Einzige, was benötigt wird, ist ein Refactoring auf C++ (zumindest für die anfängliche Unterstützung). Trotzdem immer wieder schön zu sehen, wie es in anderen Projekten umgesetzt wurde.

Wir haben bereits ein Beispiel für Sixel-Unterstützung in mintty , das in C (vice java) geschrieben ist. Das Einzige, was benötigt wird, ist ein Refactoring auf C++ (zumindest für die anfängliche Unterstützung). Trotzdem immer wieder schön zu sehen, wie es in anderen Projekten umgesetzt wurde.

Irgendwelche Probleme mit der Lizenz von mintty (GPLv3 oder höher)?

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

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

Von diesem Link:

Sixel-Code (sixel.c) wird unter GPL relizensiert wie mintty mit der
Erlaubnis des Autors (kmiya@culti)

Wenn Sie genau diesen Code in C++ transliterieren, müsste das abgeleitete Werk gemäß den Bedingungen unter GPLv3 oder höher lizenziert oder überhaupt nicht vertrieben werden. (Man könnte auch kmiya @culti fragen, ob sie bereit sind, sixel.c unter einer anderen Lizenz anzubieten, oder ob es einmal unter einer anderen Lizenz verfügbar war, um eine Kopie von dieser Quelle zu finden.)

Ich weiß nicht, was für die Aufnahme in Windows Terminal akzeptabel ist oder nicht - mein kurzer Blick auf Windows Terminal sagt, dass es MIT-lizenziert ist, also je nachdem, wie es mit einem direkten Nachkommen von minttys GPLv3 + sixel.c verknüpft/geladen wird, könnte dies dazu führen zu einem Lizenzproblem.

Wie auch immer, tut mir leid, dass ich hier das Projekt von jemand anderem störe und jetzt zurück in die Höhle gehe ...

Es gibt ein Sixel-fähiges, bescheidenes Terminal-Emulator-Widget, das in C/C++ für Windows/Linux geschrieben ist, und es hat eine SixelRenderer-Klasse, die Sie verwenden können (obwohl es etwas Optimierung benötigt), und es hat eine BSD-3-Lizenz. Der wohl größte Nachteil ist, dass es für ein bestimmtes C++-Framework geschrieben wurde. Dennoch ist der Code des SixelRenderers meiner Meinung nach mit wenig Aufwand übersetzbar. (Ich weiß das, weil ich der Autor bin. :) )

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

Bei der Implementierung von Sixel ist es wichtig, mit Bildern zu testen, die Transparenz enthalten.
Transparenz kann erreicht werden, indem Pixel in verschiedenen Farben gezeichnet werden, aber einige Pixel nicht in einer der Sixel-Farben gezeichnet werden, wodurch die Hintergrundfarbe unverändert bleibt.
Ich glaube, dies ist die einzige Möglichkeit, nicht rechteckige Sixels richtig zu zeichnen, und wäre besonders schön mit der Hintergrund-Acryltransparenz im neuen Windows Terminal.

Beim Testen mit WSL mit Ubuntu zum Beispiel werden in mlterm solche Bilder richtig mit einer Transparenzmaske gerendert und die Hintergrundfarbe wird beibehalten, während in xterm -ti vt340 unberührte Pixel schwarz gezeichnet werden, obwohl der Hintergrund weiß ist, was so scheint implizieren, dass sie Sechsel auf einer Speicherbitmap rendern, die als Schwarz ohne Transparenzmaske oder Alpha initialisiert wurde, bevor sie in das Terminalfenster geblottet werden.

Hmm. der VT340, vor dem ich stehe, ehrt den P2-Parameter im DCS P1; P2 ; P3 ; q Sequenz, die die SIXEL-Sequenz initiiert. Xterm hingegen scheint es zu ignorieren. Wenn Sie jedoch die Rasterattributsequenz verwenden (" Pan ; Pad ; Ph ; Pv ) und ihr eine Höhe und Breite zuweisen, wird der Hintergrund gelöscht, sodass Sie ein schwarzes Pixel erhalten.

Ich habe darüber nachgedacht, die kostenlose Testversion des ttwin-Emulators zu bekommen und herauszufinden, wie sich sein Verhalten vom VT340 und dem Xterm unterscheidet, der als VT340 fungiert.

Aber ... +1 für die Idee, SIXEL im Allgemeinen zu unterstützen, und +10 für die Idee, Kompatibilitätstests zu entwickeln.

Wir könnten Unterstützung für das iTerm2 Inline Images Protocol hinzufügen, sobald wir dort sind ... Zumindest sollte es einfacher zu implementieren sein, es braucht nur einen Pfad zum Bild und macht alles selbst.

Ein Zweifel, den ich bei beiden Systemen habe, ist, was passiert mit der Ausrichtung? Wenn die Bildbreite oder -höhe ein Vielfaches der Zeichenbreite oder -höhe ist, ist alles in Ordnung, aber wenn nicht, sollte eine Auffüllung nur an der unteren und rechten Seite hinzugefügt werden, oder sollte das Bild zentriert werden, indem an allen Seiten eine Auffüllung hinzugefügt wird?

Hey, hier sind einige relevante Links für die Recherche:

• "Grundlagen für ein gutes Bildprotokoll" auf terminal-wg (und eine verlinkte frühere Diskussion )
• dieser massive Thread über Sixel-Unterstützung

Wir könnten Unterstützung für das iTerm2 Inline Images Protocol hinzufügen, sobald wir dort sind ... Zumindest sollte es einfacher zu implementieren sein, es braucht nur einen Pfad zum Bild und macht alles selbst.

Das sollte wohl eine andere Aufgabe sein. Sixel und ReGIS sind explizit für In-Band-Grafik- oder Zeichendaten. Ich sage nicht, dass es eine schlechte Idee ist, ich sage nur, dass es als ein anderes Feature behandelt werden sollte.

Ein Zweifel, den ich bei beiden Systemen habe, ist, was passiert mit der Ausrichtung? Wenn die Bildbreite oder -höhe ein Vielfaches der Zeichenbreite oder -höhe ist, ist alles in Ordnung, aber wenn nicht, sollte eine Auffüllung nur an der unteren und rechten Seite hinzugefügt werden, oder sollte das Bild zentriert werden, indem an allen Seiten eine Auffüllung hinzugefügt wird?

Die Ausrichtung von Sixel- und ReGIS-Grafikdaten ist in verschiedenen Handbüchern (dürftig) beschrieben. Sixel-Bilder werden an Zeichenzellengrenzen ausgerichtet. Wenn Sie einen schwarzen Rand um ein Bild wünschen, müssen Sie diese schwarzen Pixel selbst hinzufügen; Es gibt kein Konzept für irgendetwas wie den Rand oder die Auffüllung von HTML. Jede Zeile von Sixel-Daten beschreibt einen sechs Pixel hohen Streifen. Wenn Sie versuchen, Sixel-Bilddaten mit Textzeichen auf einem Terminalemulator auszurichten, kann dies frustrierend sein, da die Software, die die Sixel-Daten generiert, möglicherweise nicht weiß, wie viele Pixel hoch jede Zeichenglyphe ist. Wenn Sie ein xterm der alten Schule zur Hand haben, können Sie dies sehen, indem Sie es im vt340-Modus starten, verschiedene Schriftgrößen angeben (um Ihnen unterschiedliche Zeichenzellengrößen zu geben) und dann einige Sixel-Daten ausdrucken, die versuchen, Bilddaten mit Text auszurichten Daten. (Hier ist eine einfache Testdatei, die richtig aussieht, wenn ich dem Font-Server mitteile, 96 DPI zu verwenden, und ich eine 15-Punkt-Schriftart festlege. Das Ändern der Schriftgröße führt dazu, dass Bilder zunehmend nicht mehr mit dem Text ausgerichtet sind. https://gist.github. com/OhMeadhbh/3d63f8b8aa4080d4de40586ffff819de )

Die ursprünglichen vt340s hatten dieses Problem nicht, weil Sie (natürlich) beim Einschalten des Terminals keine Schriftgröße angeben konnten.

Die andere Sache, die Sie aus diesem Bild sehen können, die in der Sixel-Dokumentation nicht gut beschrieben ist, ist, dass das Drucken einer Zeile von Sixel-Daten einen "virtuellen linken Rand" für die Bilddaten einrichtet. Wenn Sie das moralische Äquivalent eines CR oder CRLF mit den Zeichen '$' oder '-' ausführen, wird die nächste Zeile relativ zu diesem virtuellen linken Rand gedruckt, nicht zum echten linken Rand auf der linken Seite des Terminals.

Hoffe das hilft.

Schließlich scrollen Sie zurück, um dies zu lesen. Sorry für die späte Antwort.

Beim Testen mit WSL mit Ubuntu zum Beispiel werden in mlterm solche Bilder richtig mit einer Transparenzmaske gerendert und die Hintergrundfarbe wird beibehalten, während in xterm -ti vt340 unberührte Pixel schwarz gezeichnet werden, obwohl der Hintergrund weiß ist, was so scheint implizieren, dass sie Sechsel auf einer Speicherbitmap rendern, die als Schwarz ohne Transparenzmaske oder Alpha initialisiert wurde, bevor sie in das Terminalfenster geblottet werden.

Es sollte nicht allzu schwer sein, Transparenz in xterm zu unterstützen. Ich habe aus anderen Gründen im Code herumgegraben. Ich befürchte, dass irgendjemand irgendwo von diesem Verhalten von Xterm abhängt, also würde ich empfehlen, es hinter ein Kompatibilitäts-Flag zu setzen, was auch einfach sein sollte. Aber dann ist da noch die Frage nach dem Standardwert. Was sollte die Voreinstellung sein? Schwarz oder transparent.

Wissen wir, was die ursprünglichen VT240, 241, 330 und 340 gemacht haben? Könnte ich vorschlagen, zu versuchen, die Erfahrung eines tatsächlichen VT getreu darzustellenals Standardverhalten? Sie können dies testen, indem Sie invertierte Leerzeichen drucken, dann sechselige Grafiken darüber schichten und sehen, in welcher Farbe nicht angegebene Pixel wiedergegeben werden.

Ich weiß nicht, ob es mich zu sehr interessiert, was die Standardeinstellung für das msft-Terminal ist, solange es die Möglichkeit gibt, sich wie Xterm zu verhalten, das einen VT340 emuliert. Der Code, den ich geschrieben habe, um Loglines über ssh im Terminal auszuführen, geht von dem oben beschriebenen Verhalten "nicht spezifizierte Pixel sind schwarz" aus. Ich müsste diesen Code neu schreiben, wenn wir diese Änderung vornehmen.

Wenn Sie versuchen, Sixel-Bilddaten mit Textzeichen auf einem Terminalemulator auszurichten, kann dies frustrierend sein, da die Software, die die Sixel-Daten generiert, möglicherweise nicht weiß, wie viele Pixel hoch jede Zeichenglyphe ist.

Die ursprünglichen vt340s hatten dieses Problem nicht, weil Sie (natürlich) beim Einschalten des Terminals keine Schriftgröße angeben konnten.

Gibt es einen Grund, warum ein Terminalemulator das Bild nicht einfach so skalieren konnte, dass es genau dem Verhalten der ursprünglichen DEC-Terminals entspricht? Wenn also die Zeilenhöhe auf einem VT340 20 Pixel betrug, sollte ein Bild mit einer Höhe von 200 Pixel genau 10 Zeilen abdecken, unabhängig von der Schriftgröße. Das scheint mir die einzige Möglichkeit zu sein, mit Legacy-Software einigermaßen kompatibel zu bleiben, was in gewisser Weise der Punkt eines Terminalemulators ist.

Ich kann verstehen, dass ich dieses Verhalten erweitern möchte, um Bilder mit einer höheren Auflösung zu rendern, aber das sollte meiner Meinung nach eine optionale Erweiterung sein (oder einfach eines der vorhandenen proprietären Formate verwenden). Idealerweise möchte ich, dass die Standardeinstellung für Sixel so nah wie möglich an dem liegt, was Sie auf einem tatsächlichen DEC-Terminal erhalten hätten.

Hey, hier sind einige relevante Links für die Recherche:
"Grundlagen für ein gutes Bildprotokoll" auf terminal-wg

Sixel ist kaputt, weil es von tmux mit Side-by-Side-Fenstern nicht unterstützt werden kann.

Es hat einige Arbeit gekostet (eigentlich viel Arbeit ), aber mit Sixel kann man fast alle "Bilder in einem Terminal"-Tricks ausführen, die man sich vorstellen kann:

• Layered pro Zelle maskierte Bilder in einem Terminal: https://jexer.sourceforge.io/images/sixel_many_images.png

• Ein schwebendes (gemultiplextes) Terminalfenster in einem Terminal, das Sixel für die Unterstützung doppelter Breite im VT100-Stil verwendet: https://jexer.sourceforge.io/screenshots/jexer_sixel_in_sixel.png

• Gekachelte Terminals im "tmux-Stil" mit Bildern: https://gitlab.com/klamonte/jexer/-/wikis/uploads/7603381f82414ef9ae214bfcf759c064/example_tilingwm2_1.png

• Gemeinsam genutzte Terminalsitzung mit mehreren Köpfen und unterschiedlichen Textzellengrößen, die denselben Plot zeigen: https://jexer.sourceforge.io/screenshots/multiscreen_2b.png

• Die Verwendung von Sixel zum Rendern von CJK und Emoji, die nicht in der Schriftart des Hauptterminals vorhanden sind: https://jexer.sourceforge.io/screenshots/xterm_sixel_cjk.png

Ich habe einige andere Bemerkungen in den referenzierten "guten" Protokollthread aufgenommen, die von Interesse sein könnten.

Sixel ist nicht zuletzt ein gutes Sprungbrett, um die terminalseitige Infrastruktur aus gemischten Bildern und Texten auszuarbeiten. Aus direkter Erfahrung sprechend, ist die Endgeräteseite (Speichern/Anzeigen von Bildern) etwa 1/4 so schwer wie die Multiplexer-/Anwendungsseite (tmux/mc et al.).

sixels sind in der Tat die ideale Lösung für In-Band-Grafiken (z. B. über ssh): Da sie von vielen vorhandenen Tools unterstützt werden, können sie für praktische Zwecke wie das Plotten von Zeitstempel-Synchronisierungsproblemen unterwegs verwendet werden.

Wie von therealkenc illustriert und von klamonte in 640292222 weiter erklärt, kann alles mit Sixels gehandhabt werden, sogar Bilder nebeneinander, aber es erfordert etwas Arbeit.

Vor einiger Zeit habe ich mit ein paar anderen Leuten an einem Fallback-Modus für tmux gearbeitet, bei dem erweiterte Unicode-Grafiken verwendet wurden, um Sixel-Bilder in Terminals darzustellen, die Sixel nicht unterstützen.

Es ist ein bisschen wie automatisierte ANSII-Kunst, die spezielle Blockzeichen nutzt, die in den meisten Schriftarten vorhanden sind: Diese äquivalente farbige Unicode-Darstellung könnte die Sechsel ersetzen und später durch das tatsächliche Sechsel-Bild überschrieben werden (oder nicht!). Es würde auch das Problem lösen, alle Sixel-Bilder zum Zurückscrollen aufzubewahren, indem sie durch Low-Fidelity-Unicode-Platzhalter ersetzt werden (z. B. um Speicherplatz zu sparen) und Platzhalter für Sixel-Bilder haben, wenn sie aus irgendeinem Grund nicht angezeigt werden können.

Der Code war gemeinfrei. Es könnte als erster Schritt in Richtung Sixel-Support sofort nutzbar sein:

• Erkenne, wenn die Sixels-Sequenz übertragen wird, und berechne dann die Unicode-Textersetzung

• zeigt diese Unicode-Sequenz an, die bereits von Windows Terminal unterstützt wird

• Später, wenn Sechsel implementiert sind, wird die Sechsel-Sequenz darüber gerendert.

Wären Sie interessiert?

Übrigens erkenne ich hier meine vertrauten Plots gnuplot x^2 sin und 10 sin(x) wieder. Ich freue mich, dass sie etwas Inspiration geliefert haben 😄

Bitte.

@DHowett Ist acac350 ein erster Schritt zum tatsächlichen Rendern von Sixel-Grafiken? Ich erhalte Anfragen für Sixel-Unterstützung in Microsoft Terminal von Leuten, die ssh verwenden und Verzeichnisse von Bildern mit meinem lsix- Programm anzeigen möchten.

Sortiert. Wir haben jetzt die Möglichkeit, eingehende DCS-Sequenzen zu verarbeiten. Wir haben noch keine Handler angeschlossen, aber die Infrastruktur dafür zu haben, war ziemlich wichtig. :Lächeln:

Hier sind einige Neuigkeiten. Ich habe hier einen funktionierenden Zweig. Ein früher Screenshot sieht so aus:

Im Gegensatz zu dem, was ich ursprünglich dachte, ist der schwierigste Teil beim Rendern von Sixel-Bildern tatsächlich die Conpty-Ebene. Sixel-Bilder sollen Inline-Objekte sein. Die Wiedergabe von Sixel-Bildern hängt von der Wiedergabegröße eines Zeichens ab. Aufgrund der zusätzlichen Conpty-Schicht können wir jedoch bei der Verarbeitung von Sixel-Sequenzen nicht die Rendering-Größe eines Zeichens erhalten. Das klingt sehr abstrakt und vage. Jeder, der daran interessiert ist, kann in meiner Filiale vorbeischauen und sehen, wie es gemacht wird.

Insgesamt macht es die Conpty-Schicht sehr schwierig, das Scrollen und die Größenänderung von Sixel-Bildern zu handhaben. In meiner Branche funktioniert es, wenn Sie es nur anzeigen müssen. Aber sowohl das Scrollen als auch die Größenänderung sind völlig kaputt.

Ich habe noch nicht nachgesehen, aber können Sie den Pass-Through-Modus verwenden, um ihn in Terminal selbst zu implementieren? Ich würde es immer noch in OpenConsole hinzufügen, aber es klingt so, als wäre das Teilen von Code nicht möglich. Da Windows Terminal irgendwann von OpenConsole entkoppelt werden muss, duplizieren Sie am besten einfach den Code für beide. Basieren Sie es auch auf Ihren und j4james PRs für Parameter? Das würde wahrscheinlich auch helfen.

@WSLUser Danke für die Aufmerksamkeit. Dieser Screenshot ist eigentlich von vor etwa einem Monat, als die fantastischen Parameter PR von j4james noch nicht einmal existierten. Meine Arbeit findet vollständig innerhalb von Windows Terminal statt, nicht in conhost. Ich habe diese PR dem Konsolenteam intern gezeigt und seitdem einige Fortschritte gemacht. Aber ich stecke wegen des Conpty-Problems fest.

Ja, ich würde vom Master rebasen und https://github.com/microsoft/terminal/pull/7578 und https://github.com/microsoft/terminal/pull/7799 hinzufügen. Sehen Sie von dort aus vielleicht, was in ConPTY für den Pass-Through-Modus fehlt. Ich frage mich, ob Mintty Pass-Through für den ConPTY-Modus verwendet.

Ich frage mich, ob Mintty Pass-Through für den ConPTY-Modus verwendet.

Ich bin mir ziemlich sicher, dass mintty conpty überhaupt nicht verwendet 😜

Der Trick bei conpty besteht darin, dass die Konsole (conpty) die Zellen kennen muss, die mit Sixel-Inhalten gefüllt sind, um diesen Inhalt nicht versehentlich aus dem angeschlossenen Terminal zu löschen. Vielleicht könnte conpty aufgeklärt werden, das Malen von Zellen mit großen Grafiken zu ignorieren und einfach davon auszugehen, dass das angeschlossene Terminal diese Zellen in Ruhe lässt.

Das könnte einige unserer Optimierungen durcheinander bringen (z. B. können wir Zeilen mit Sixel-Daten nicht löschen), aber es könnte ein guter Anfang sein

\

Vielleicht könnte conpty aufgeklärt werden, das Malen von Zellen mit großen Grafiken zu ignorieren und einfach davon auszugehen, dass das angeschlossene Terminal diese Zellen in Ruhe lässt.

Dies war auch mein ursprünglicher Plan, und es ist möglicherweise die beste Lösung mit der aktuellen Conpty-Architektur, aber es gibt eine Reihe von Komplikationen.

1. Wie würde dies mit dem DCS-Streaming interagieren (wofür wir meiner Meinung nach noch nicht einmal eine Lösung haben). Ich nehme an, wir bräuchten eine Art Split-Stream-Konzept, das den Byte-Stream gleichzeitig an conpty weiterleitet, während er an den Conhost-Puffer gesendet wird, aber das scheint dem Prozess eine Menge unnötigen Overhead hinzuzufügen.
2. Dies würde nur funktionieren, wenn Sie die Pixelzellengröße des Conpty-Terminals kennen. Ich habe bereits erwähnt, dass die beste Lösung für Sixel darin besteht, die Zellengröße der ursprünglichen VT-Terminals anzupassen, und wenn wir das tun würden, wäre dies kein Problem. Soweit mir bekannt ist, tun dies jedoch keine anderen Terminalemulatoren, sodass es mit niemand anderem funktionieren würde.

Das zweite Problem, das @j4james angesprochen hat, wird noch komplizierter, wenn unterschiedliche Schriftarten, unterschiedliche Schriftgrößen und Schriftgrößenänderungen berücksichtigt werden. Also im Allgemeinen denke ich, dass es 3 Aspekte des Problems gibt:

• Zuerst muss conpty wissen, welche Zellen mit Sixel-Inhalten gefüllt sind. Ohne dies werden der Hintergrundpuffer in conpty und der Zeichnungspuffer in WT unweigerlich nicht synchron sein.
• Dazu muss conpty die Pixelzellengröße im Zeichnungskontext kennen, was von der Zeichnungsebene in WT gehandhabt wird. Es gibt eine große Lücke zwischen conpty und dem eigentlichen DXRenderer, was dies zu einer schwierigen Aufgabe macht.
• Außerdem sollte sich idealerweise das Sixel-Bild entsprechend ändern, wenn sich die Schriftart oder die Schriftgröße ändert.
• Und schließlich mit anderen Dingen wie Bereich, alternativem Puffer, differenziellem Zeichnen, Scrollen usw. umgehen.

Das zweite Problem, das @j4james angesprochen hat, wird noch komplizierter, wenn unterschiedliche Schriftarten, unterschiedliche Schriftgrößen und Schriftgrößenänderungen berücksichtigt werden. Also im Allgemeinen denke ich, dass es 3 Aspekte des Problems gibt:

Nur um es klar zu sagen, mein Punkt war, dass nichts davon ein Problem wäre, wenn wir das Verhalten eines VT340 genau abgleichen würden, sodass ein 10x20-Pixel-Bild genau eine Zeichenzelle einnehmen würde, unabhängig von der Schriftgröße. Es ist nur ein Problem, wenn wir das Verhalten anderer Terminalemulatoren anpassen möchten, und das könnte immer eine Option sein, die für später übrig bleibt. Es würde immer noch Komplikationen mit diesem Ansatz geben, aber ich persönlich denke, dass sie weniger besorgniserregend sind.

Meine größere Sorge ist, dass Sie das DCS-Streaming-Problem zu ignorieren scheinen, von dem ich erwarte, dass es die Architektur der Lösung grundlegend verändern könnte. Die Schritte, die ich gerne gesehen hätte, sind: 1. Auflösung #7316; 2. Vereinbaren Sie eine Lösung für die Zellpixelgröße; 3. Etwas in Conhost zum Laufen bringen; 4. Sobald alle Komplikationen in conhost ausgearbeitet sind, überlegen Sie erst dann, wie wir es über conpty zum Laufen bringen.

Tut mir leid, dass ich das DCS-Streaming-Problem verlassen habe. In meiner aktuellen Implementierung speichere ich einfach den gesamten String und übergebe ihn an die Engine. Dies führt zu Leistungsproblemen, wenn die Sequenz größer ist. Aber zumindest funktioniert es. Meine obigen Kommentare basieren also weitgehend darauf.

Aber Sie haben Recht. Das DCS-Streaming-Problem hat eigentlich die höchste Priorität, wenn sich jemand anderes die Hände schmutzig machen möchte.

Verwenden Sie Outlook für iOS https://aka.ms/o0ukef

Per Diskussion in https://github.com/microsoft/terminal/issues/57 dachte ich, conpty kümmert sich überhaupt nicht um Schriftarten?

bzgl. Größenänderung Ich denke, der natürlichste Weg, dies zu tun, besteht darin, das Bild in Zeichenzellen zu "verankern", sobald das Bild ankommt, und die Bildgröße basierend auf der Ankergeometrie neu zu berechnen. Alles andere führt zu Inkonsistenzen zwischen Bild- und Zeichenzellen.

@yatli Ja. Das macht das Thema auch knifflig.

Ein 10x20-Pixel-Bild würde genau eine Zeichenzelle einnehmen

Das ist leider falsch, zumindest für meine aktuelle Schrifteinstellung.

Korrigieren Sie mich, wenn ich falsch liege, aber für eine pixelgenaue Bildanzeige müssen wir uns meiner Meinung nach um Schriftarten kümmern.

@skyline75489 Bitte sehen Sie sich meinen aktualisierten Kommentar zum "Anker" an

Die Zelldatenstruktur muss als char | sixel anchor aktualisiert werden

Der Sixel-Anker sollte Informationen enthalten über:

• Ein Zeiger auf das Bildobjekt
• Der belegte Zellbereich in Fließkommazahlen (z. B. 5,2 Zeilen x 7,8 Spalten)

Es ist eine gute Idee, aber die Implementierungsdetails haben mich aufgrund der zusätzlichen Übersetzung in der Conpty-Schicht umgebracht. Um zu vermeiden, dass Leute E-Mails zuspammen, können Sie mich bei Interesse gerne unter Teams @yatli erreichen.

Ein 10x20-Pixel-Bild würde genau eine Zeichenzelle einnehmen

Das ist leider falsch, zumindest für meine aktuelle Schrifteinstellung.

Was ich vorschlage, ist, dass Sie das in die Tat umsetzen sollten. Wenn Sie ein 10x20-Pixel-Bild erstellen und es auf einem echten DEC VT320-Terminal ausgeben, dauert es genau ein Zeichen (zumindest im 80-Spalten-Modus). Wenn wir also versuchen, dieses Terminal zu emulieren, sollten wir dasselbe tun. Wenn Ihre aktuelle Schriftart 30 x 60 ist, müssen Sie das Bild vergrößern. Wenn Ihre Schriftart kleiner ist, skalieren Sie das Bild nach unten.

Das garantiert, dass Sie ein Sixel-Bild in jeder Schriftgröße ausgeben können und immer das gleiche Layout erhalten. Wenn Sie möchten, dass es einen bestimmten Bereich des Bildschirms abdeckt, oder wenn Sie einen Rahmen mit Textzeichen darum ziehen möchten, wissen Sie genau, wie viel Platz das Bild einnehmen wird.

Korrigieren Sie mich, wenn ich falsch liege, aber für eine pixelgenaue Bildanzeige müssen wir uns meiner Meinung nach um Schriftarten kümmern.

Es ist wahr, dass Sie auf diese Weise keine "pixelgenauen" Bilder erhalten, aber ich denke nicht, dass dies das primäre Ziel sein sollte. Viele moderne Computer haben High-dpi-Displays, auf denen Bilder routinemäßig hochskaliert werden. Es ist also nicht so, dass dies ein seltsames Konzept ist. Und wenn wir das Layout konsistent halten wollen, wenn der Benutzer seine Schriftgröße ändert, müssen wir das Bild sowieso irgendwann skalieren, also können Sie es genauso gut von Anfang an tun und alle Vorteile einer Vorhersagbarkeit nutzen Größe.

Und natürlich ist der andere Vorteil, Dinge auf diese Weise zu tun, dass sie über conpty implementiert werden könnten. Ich sehe nicht, wie Sie conpty zum Laufen bringen können, wenn der vom Bild eingenommene Bereich von der Schriftgröße abhängt, die Sie möglicherweise nicht wissen können.

Ich werde nicht so tun, als hätte dieser Ansatz keine Nachteile, aber ich denke, dass die positiven Aspekte die negativen überwiegen.

Was ist, wenn die Schriftart ein anderes Seitenverhältnis als 10:20 hat?

Was ist, wenn die Schriftart ein anderes Seitenverhältnis als 10:20 hat?

Darf ich vorschlagen, diese lange - und etwas "brutale" - Diskussion über die allgemeinen Probleme bezüglich der Inline-Bilder in Terminal-Emulatoren zu lesen.

Es kann Ihnen die allgemeine Vorstellung vermitteln.

Mit freundlichen Grüßen

Was ist, wenn die Schriftart ein anderes Seitenverhältnis als 10:20 hat?

Das Bild mag etwas gestreckt oder gestaucht sein, aber ich glaube nicht, dass das das Ende der Welt ist.

Lassen Sie mich das anhand eines realen Beispiels demonstrieren. Stellen Sie sich vor, ich bin ein Bond-Bösewicht und habe ein altes Sicherheitssystem mit einem VT340 als Frontend. Jetzt bin ich wegen des Coronavirus gesperrt und arbeite von zu Hause aus, also melde ich mich remote mit Windows Terminal am System an. Wenn wir den VT340 genau abgleichen, ist das kein Problem - das Terminal sieht so aus:

Aber vielleicht bevorzuge ich Schriftarten mit einem seltsamen Seitenverhältnis. Mal sehen, wie es mit _Miriam Fixed_ aussehen würde, die breiter als die meisten anderen ist. Das Bild von Bond sieht jetzt etwas zerquetscht aus, aber er ist immer noch gut erkennbar.

Die Alternative wäre ein pixelgenaues Bild (derzeit mit conpty nicht machbar, aber lasst uns für eine Sekunde so tun). Bond sieht nicht mehr zerquetscht aus, aber jetzt hat das Bild nur noch einen Bruchteil der erwarteten Größe. Und je höher die Auflösung Ihres Monitors ist, desto schlimmer wird das aussehen.

Vielleicht ist dies eine Frage der persönlichen Präferenz, aber ich weiß, dass ich definitiv Option 1 gegenüber Option 2 wählen würde.

Beachten Sie auch, dass es keinen Grund gibt, dass wir keine Optionen haben könnten, um das genaue Verhalten zu optimieren, wenn das Seitenverhältnis der Schriftart nicht 1:2 ist. Eine Option könnte darin bestehen, das Bild innerhalb der Zellen zu zentrieren, die es einnehmen sollte. Oder wir könnten das Bild so erweitern, dass es den gesamten Bereich abdeckt, aber die Ränder beschneiden, die über die Grenzen hinausgehen. Jede dieser Optionen wäre meiner Meinung nach besser als ein exaktes Pixel-Rendering.

Vielleicht ist dies eine Frage der persönlichen Präferenz, aber ich weiß, dass ich definitiv Option 1 gegenüber Option 2 wählen würde.

Ich auch, nur wäre es besser zu wissen, dass die Schriftart ein anderes Seitenverhältnis hat, damit sich das Bild selbst anpassen und das richtige beibehalten kann.

Eine Option könnte darin bestehen, das Bild innerhalb der Zellen zu zentrieren, die es einnehmen sollte. Oder wir könnten das Bild so erweitern, dass es den gesamten Bereich abdeckt, aber die Ränder beschneiden, die über die Grenzen hinausgehen

Ich denke, es ist besser, sie zu zentrieren.

Vielleicht lese ich diesen Thread falsch. Reden wir tatsächlich über das Terminal, das 10:20-Zeichen für das Sixel-Bild vortäuscht? Ich denke, das wird viele Probleme wie die Bond-Verzerrung verursachen. Es richtig zu machen mag schwieriger sein, aber meiner bescheidenen Meinung nach sollte ein modernes Terminal schriftartunabhängig sein und es den Anwendungsprogrammierern überlassen, mit Sechseln und Zeichenzellen umzugehen.

Unter Verwendung von Escape-Sequenzen kann ein vom Benutzer ausgeführtes Programm die Zeichenzellengröße in Pixeln bestimmen und entscheiden, wie mit Verzerrungen für diese Anwendung intelligent umgegangen wird. Das von mir verwendete Bildbetrachtungsprogramm funktioniert genau so. Wenn ich die Schriftfamilie oder -größe ändere, werden die angezeigten Miniaturansichten immer genau fünf Textzeilen hoch. Die Breite wird für das Bild proportional skaliert, es sei denn, sie wäre größer als ein bestimmtes (in diesem Fall ziemlich großes) Maximum. Indem die Bildgröße auf der Zeichenzelle basiert, funktioniert es automatisch auf Bildschirmen mit hoher DPI.

Während der VT340 ein edles Ziel ist, das es zu emulieren gilt, ist es ein Fehler, die Zeichenzellenauflösung auf 10:20 festzulegen (und damit die Auflösung für den gesamten Bildschirm zu begrenzen). Der VT340 war nur eine von mehreren Sixel-Implementierungen, daher ist seine Schriftgröße nicht unbedingt korrekter.

Das Erzwingen von 10:20 wird auch zu hässlichen Kludges führen. (Zum Beispiel, wie man auf eine Anfrage nach der Größe des Terminalfensters in Pixeln antwortet. Sagen Sie die Wahrheit, vorausgesetzt, sie positionieren Fenster auf dem Bildschirm? Oder geben Sie immer 800 x 480 zurück, vorausgesetzt, der Benutzer skaliert Bilder für die Sixel-Ausgabe? )

Reden wir tatsächlich über das Terminal, das 10:20-Zeichen für das Sixel-Bild vortäuscht?

Jawohl.

Ein modernes Terminal sollte schriftartunabhängig sein

Dieser Vorschlag ist schriftartunabhängig. Die Anwendung muss nichts über die Schriftart wissen. Das ist der springende Punkt.

Unter Verwendung von Escape-Sequenzen kann ein vom Benutzer ausgeführtes Programm die Zeichenzellengröße in Pixeln bestimmen und entscheiden, wie mit Verzerrungen für diese Anwendung intelligent umgegangen wird.

Ich bin mir nicht ganz sicher, welche Methode Sie verwenden, aber ich habe dies zuvor mit einer proprietären XTerm-Abfrage zum Abrufen der Fensterpixelgröße und einer weiteren Abfrage zum Abrufen der Fensterzellengröße und deren Verwendung gesehen Daten, um die tatsächliche Pixelgröße der Zelle zu berechnen. Die Nachteile eines solchen Ansatzes sind:

1. Es ist proprietär, würde also nicht auf einem echten Terminal oder einem Terminal-Emulator funktionieren, der genau zu einem echten Terminal passt.
2. Wenn der Benutzer seine Schriftgröße ändert, während Ihre Anwendung ausgeführt wird, sind Ihre Berechnungen nicht mehr korrekt und Bilder werden in der falschen Größe gerendert (es sei denn, Sie berechnen die Schriftgröße ständig neu, was unpraktisch erscheint).
3. Wenn der Benutzer ein hochauflösendes Display und/oder eine große Schriftgröße hat, sind Sie gezwungen, ein riesiges Bild durchzusenden, um zu versuchen, diese Auflösung zu erreichen. Wenn man bedenkt, wie ineffizient Sixel zu Beginn ist, kann das eine Menge Bandbreite bedeuten.

Allerdings verstehe ich, dass dies ein Modus ist, den einige Leute vielleicht verwenden möchten, und ich denke, wir sollten zumindest die Möglichkeit haben, ihn eines Tages zu unterstützen (aus den oben genannten Gründen ist dies im Moment einfach nicht möglich). Aber meiner Meinung nach ist das nicht der beste Ansatz für Sixel.

Ich habe mehr als 300 VT340 in Kernkraftwerken, die ich irgendwann haben möchte
ersetzen.

Es gibt kommerzielle Terminalemulationspakete, die wir verwenden könnten, aber ich denke
alle bis auf einen wurden EoL'd.

Wir haben einige von ihnen durch Linux-PCs ersetzt, auf denen XTerm (oder weniger) ausgeführt wird
häufig Win10 + Hummingbird + WSL mit XTerm), weil es a
halbwegs anständige Open-Source-Sixel-Implementierung und irgendwie schlecht, aber
Open-Source-ReGIS-Implementierung.

Die Wahrscheinlichkeit, dass wir für diesen Teil neue Software schreiben werden
System, das den Sechsel-Oktett-Strom erzeugt, ist NIL.

Wenn Ihr Ziel darin besteht, Grafiken über einen Inline-Oktett-Stream zu senden, dort
sind andere Optionen. Aber wenn Sie Sixel-Grafiken unterstützen wollen, sollten Sie das tun
unterstützt Sixel-Grafiken auf eine Weise, die der vorherigen halbwegs ähnlich ist
Implementierungen. Dies bedeutet leider, dass Sie dem nacheifern sollten
Verhalten von Beispielsystemen (dh VT240, VT241, VT330 und VT340
Terminals), auch wenn es darum geht, Grafiken mit Text zu integrieren.

Dies ist ein Mock-up von der Art von Dingen, von denen ich spreche. Es wäre sehr
schön, wenn eine neue Sixel-Implementierung die Kompatibilität mit der bestehenden beibehält
Implementierungen, damit Bilder nicht oder nur über den Bildschirmrand laufen
den halben Bildschirm füllen.

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

Ein modernes Terminal sollte schriftartunabhängig sein

Dieser Vorschlag ist schriftartunabhängig. Die Anwendung muss nichts über die Schriftart wissen. Das ist der springende Punkt.

Ich meinte, dass das _Terminal_ schriftartunabhängig sein sollte, anstatt 10:20 für jede Schriftart aufzuerlegen. Die Anwendung sollte in der Lage sein, die tatsächliche Schriftgröße zu kennen, wenn sie dies wünscht, da die Anwendung den Bereich dessen, was sie anzuzeigen versucht, kennt und den besten Weg finden kann, Text und Grafiken zusammen darzustellen.

Unter Verwendung von Escape-Sequenzen kann ein vom Benutzer ausgeführtes Programm die Zeichenzellengröße in Pixeln bestimmen und entscheiden, wie mit Verzerrungen für diese Anwendung intelligent umgegangen wird.

Ich bin mir nicht ganz sicher, welche Methode Sie verwenden, aber ich habe dies zuvor mit einer proprietären XTerm-Abfrage zum Abrufen der Fensterpixelgröße und einer weiteren Abfrage zum Abrufen der Fensterzellengröße und deren Verwendung gesehen Daten, um die tatsächliche Pixelgröße der Zelle zu berechnen.

Ja, das ist ungefähr richtig. Es gibt auch eine Abfrage, um die Größe der Zeichenzelle direkt abzurufen, aber ich glaube nicht, dass dies so weit verbreitet ist wie das Abrufen der Bildschirmgröße und das Teilen durch ZEILEN und SPALTEN.

Die Nachteile eines solchen Ansatzes sind:

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

Das ist kein Nachteil. Es bedeutet nur, dass das Programm auf das zurückgreifen muss, was es ohnehin getan hätte: Angenommen, $TERM=="VT340" bedeutet, dass Zeichenzellen 10:20 sind, "VT240" bedeutet 10:10, "mskermit" bedeutet 8:8, und so weiter.

Außerdem ist es keine proprietäre xterm-Sequenz. Das Abrufen der Bildschirmgröße wird als "dtterm"-Escape-Sequenz bezeichnet, wurde jedoch zuerst in SunView (SunOS, 1986) implementiert. Ich glaube, es wurde später im PHIGS Programming Manual (1992) dokumentiert. Versuchen Sie, "\e[14t" an ein paar Terminal-Emulatoren zu senden, und Sie werden sehen, dass es weit verbreitet ist.

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

Das ist kein Problem. Das Programm fängt SIGWINCH einfach ab und berechnet nur dann neu, wenn sich das Fenster tatsächlich geändert hat.

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.

Ja, Sixel ist extrem ineffizient. Aber auf modernen Computern ist das Senden von Vollbildbildern durchaus brauchbar, sogar über ssh. Hat das Microsoft-Terminal eine Art Baudratenbeschränkung?

Übrigens glaube ich, dass Sixel einen "High DPI" -Modus hat, bei dem jeder Punkt in Breite und Höhe verdoppelt wird. Ich habe es nie benutzt und ich glaube nicht, dass xterm es implementiert, aber vielleicht würde das Bedenken hinsichtlich der Bandbreite zerstreuen.

Allerdings verstehe ich, dass dies ein Modus ist, den einige Leute vielleicht verwenden möchten, und ich denke, wir sollten zumindest die Möglichkeit haben, ihn eines Tages zu unterstützen (aus den oben genannten Gründen ist dies im Moment einfach nicht möglich).

Dieser "Modus" besteht einfach darin, dass Zeichen und Grafiken so ausgerichtet sind, wie es die verschiedenen historischen Sixel-Terminals und aktuelle Emulatoren getan haben. Ich gebe zu, ich verstehe nicht, warum es in Microsoft Terminal nicht möglich ist, dasselbe zu tun. Wenn Sie sagen, dass dieser 10:20-Kludge das Beste ist, was getan werden kann, vertraue ich darauf, dass Sie Recht haben, und danke Ihnen dafür. Ein verzerrtes Bild ist viel besser als nichts.

Unter Verwendung von Escape-Sequenzen kann ein vom Benutzer ausgeführtes Programm die Zeichenzellengröße in Pixeln bestimmen und entscheiden, wie mit Verzerrungen für diese Anwendung intelligent umgegangen wird.

@hackerb9 , was ist die eigentliche Escape-Sequenz, um die Schriftabmessungen zu erhalten?

Die relevanten XTerm-Sequenzen finden Sie hier: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html – suchen Sie nach XTWINOPS.

Darüber hinaus können Sie unter Unix normalerweise die interne Pixelgröße des Terminals zusammen mit der Zellengröße mit dem IOCTWINSZ-ioctl abrufen. Mit openssh funktioniert das auch aus der Ferne.

Genauso wie ein Datenpunkt nimmt der Sixel-Zweig für libvte den von der Zellgröße unabhängigen Weg, von dem @hackerb9 spricht. Es behandelt eingehende Sixel-Daten als "pixelgenau" und skaliert zuvor empfangene Bilder über Zoomstufen und Schriftgrößen neu, um eine konsistente Zellausdehnung abzudecken. Nach der Zusammenführung wird diese Implementierung für einen großen Teil der Linux-Terminalemulatoren verfügbar sein, einschließlich GNOME Terminal, XFCE Terminal, Terminator usw. Oberflächlich betrachtet scheint dies zumindest mit XTerm und mlterm interoperabel zu sein.

Da libvte eine virtuelle Zellengröße pro Image aufzeichnet, wäre es trivial, dies für die Interoperation auch mit einer festen virtuellen 10x20-Zellengröße zum Laufen zu bringen. Allerdings bräuchten wir eine Möglichkeit für Programme, ihre erwarteten Pixel:Zellen- Verhältnisse an das Terminal zu kommunizieren (z. B. durch Erweitern der DCS-Parameter). Das könnte im Allgemeinen sehr nützlich sein, da es auch eine Form der Pixeldichtesteuerung in Umgebungen mit eingeschränkter Bandbreite bieten würde, wie Sie oben angesprochen haben.

Darüber hinaus können Sie unter Unix normalerweise die interne Pixelgröße des Terminals zusammen mit der Zellengröße mit dem IOCTWINSZ-ioctl abrufen. Mit openssh funktioniert das auch aus der Ferne.

Die Linux-Konsole gibt immer 0 zurück ... das sollten sie aber beheben, scheinen aber auch nicht bereit zu sein :-/