Xterm.js: Prise en charge de la séquence d'échappement 1337 pour afficher des images en ligne

Cliquer sur le lien pour ouvrir l'image est possible via une API expérimentale pour le moment. C'est expérimental car il est susceptible de changer mais voici la syntaxe actuelle:

// Add a link for a particular regex and handle when it's clicked.
xterm.registerLinkMatcher(/\w\.png/, function (mouseEvent, imageFile) => {
  // imageFile is the text of the link
});

L'API devrait, espérons-le, être finalisée dans les prochaines versions.

Salut Daniel, merci pour votre réponse rapide! Vous vous demandez s'il existe un moyen d'afficher du HTML à la volée grâce à un ensemble de caractères de contrôle? Similaire à la façon dont DomTerm utilise les séquences «\ e] 72; \ a»?

https://lwn.net/Articles/670078/

De: Daniel Imms [email protected]
Répondre à: "sourcelair / xterm.js" [email protected]
Date: samedi 18 mars 2017 à 16:47
À: "sourcelair / xterm.js" [email protected]
Cc: cristynkells [email protected] , auteur [email protected]
Objet: Re: [sourcelair / xterm.js] comment afficher les images en ligne (# 614)

Cliquer sur le lien pour ouvrir l'image est possible via une API expérimentale pour le moment. C'est expérimental car il est susceptible de changer mais voici la syntaxe actuelle:

// Ajoute un lien pour une expression régulière particulière et gère le moment où on clique dessus.
xterm.registerLinkMatcher (/ \ w.png /, function (mouseEvent, imageFile) => {
// imageFile est le texte du lien
});
-
Vous recevez ceci parce que vous avez créé le fil.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désactivez le fil de discussion.

@cristynkells il n'y en a pas pour le moment, xterm standard ne supporte rien de tel, donc si nous voulions le supporter, il faudrait certainement qu'il soit dans un addon.

@Tyriar

il faudrait certainement que ce soit dans un addon

Est-ce soutenu aujourd'hui? Pour le moment, je ne vois pas comment cela peut être fait même avec un ajout. En gros, j'essaie d'étudier ce qu'il faudrait pour construire quelque chose avec des tracés en ligne (quelque chose que nous avons déjà dans d'autres IDE, PTVS, RTVS, Spyder, etc., par exemple https://ipython.org/ipython-doc/3/ interactive / qtconsole.html).

@DonJayamanne depuis ce problème, j'ai pris connaissance d'une norme que certains terminaux ont implémentée pour afficher les images. Pour cette raison, nous pourrions l'ajouter à la bibliothèque principale, c'est probablement une fonctionnalité assez lourde en termes de s'assurer que tout est correct, en particulier en ce qui concerne la bonne barre de défilement, car pour le moment, il n'y a pas de lignes de hauteur variable dans la fenêtre. .

implémenté pour l'affichage des terminaux

Oui, j'ai trouvé qu'iTerm faisait cela.

Merci d'être revenu.

Salut. J'ai ouvert un problème lié sur VSCode et redirigé ici. Je me demande si la prise en charge de la fonction d'image iTerm2 est une possibilité car elle peut être utilisée aussi facilement que cela,

printf "\n\033]1337;File=;inline=1:`cat a.png | base64`\a\n"`

Et je l'ai déjà utilisé sur un projet .

@ebraminio Si nous allons dessiner des graphiques et éventuellement un peu plus d'hypertexte, j'aimerais vraiment pouvoir spécifier les coordonnées où le rendre, pas seulement le vider aveuglément sous la position actuelle du curseur ... cochez # 1176.

@ztmr : Vous pouvez utiliser d'autres commandes termcap pour déplacer le curseur et afficher l'image où vous le souhaitez. C'est ce que je fais dans jplot pour redessiner l'image en place.

@rs : Oh, bien sûr, comment pourrais-je oublier CUP! : o)

Opps cela a été étiqueté incorrectement. Ce serait une excellente fonctionnalité pour laquelle obtenir une contribution, voici quelques-unes de mes réflexions:

• Avons-nous besoin d'un moyen enfichable pour prendre en charge les séquences d'échappement?
• Peut-être que cela devrait vivre dans un addon?
• Actuellement, chaque ligne a une longueur fixe, les images à afficher sont-elles également fixées sur cette grille ou la taille doit-elle être différente? Par exemple, avec une hauteur de ligne = 10px et une hauteur d'image = 15px, si l'image consomme 15px ou 20px sur le terminal). Si ce dernier, nous voudrons peut-être aborder https://github.com/xtermjs/xterm.js/issues/1140 en premier.

+1 pour les séquences d'échappement personnalisées. Le meilleur endroit pour commencer est d'implémenter les interfaces de sous-analyseur OSC et DCS, où le sous-analyseur personnalisé peut se connecter à l'analyseur principal. De plus, l'analyseur principal a encore quelques failles de code d'échappement et la bibliothèque de test doit encore être complétée pour couvrir toutes les séquences de base.

Btw DEC avait déjà quelques extensions de terminal pour le chargement des graphiques et des images (REGIS et SIXEL). Aucun indice si cela aurait beaucoup de sens de les implémenter, car le navigateur env de xterm.js a de bien meilleures capacités pour dessiner de telles choses.

SIXEL est pris en charge par certains programmes (gnuplot) et certains terminaux (mlterm, xterm), il existe même libsixel (https://github.com/saitoha/libsixel) pour une conversion facile. Semble ne pas être aussi mort que je le pensais ...

Incertain à propos de la commande OSC 1337, cela semble être pris en charge par iterm2 uniquement.

Edit: Voir également la console jupyter et https://github.com/liftoff/GateOne , ils sont tous deux capables d'afficher des graphiques, pas sûr s'ils le piratent autour / au-dessus du terminal à un niveau supérieur. Cela pourrait être une fonctionnalité supplémentaire intéressante pour xterm.js, toujours dans le doute si cela devrait faire partie du terminal lui-même, car cela soulève de nombreuses questions des données et de l'état à la représentation de la sortie.

De mon point de vue, le support Sixel serait bien pour une chose de style tableau de bord de surveillance. Pourrait facilement afficher des jauges et des éléments - il existe même des navigateurs, iirc, qui prennent en charge le rendu.

Voici une capture d'écran de la façon dont le placement / la sélection d'image fonctionne dans iterm2, pas encore totalement sûr du fonctionnement des marges.

Je pense que SIXEL est la voie à suivre pour les images, a également fait des progrès avec un premier analyseur SIXEL (https://github.com/jerch/node-sixel).
Une fois que nous sommes installés avec la nouvelle disposition du tampon et la retouche du marqueur / décorateur, cela devrait être simple à intégrer.

Alors que sixel est un "standard" (et je pense qu'il est souhaitable de le supporter), c'est un standard plutôt obsolète. Il n'est pas bien adapté au matériel, aux logiciels ou au flux de travail actuels. Très peu de gens en ont entendu parler et très peu d'émissions en produisent ou en consomment. Il est extrêmement inefficace pour les images photographiques (ne supporte pas bien de nombreuses couleurs), et il est limité aux images dont la hauteur est un multiple de 6.

Le concept (sinon nécessairement les spécificités) de la séquence d'échappement 1337 est beaucoup plus facile à utiliser pour la plupart des gens (et des programmes): un encodage en base64 des formats de fichiers image courants standard: png, gif, jpeg et éventuellement svg . Je pense que c'est la voie à suivre. La syntaxe 1337 est un peu maladroite (l'option inline défaut est 0 - hein?), Mais cela fonctionne. Existe-t-il une autre séquence d'échappement avec des fonctionnalités similaires utilisées par d'autres terminaux?

(Bien que DomTerm ne prenne pas en charge la séquence d'échappement 1337, il prend en charge la même idée, sauf que vous devez envelopper les données dans un élément <img> ou <svg> html. Ajout de la prise en charge de la séquence d'échappement 1337 devrait être trivial.)

@PerBothner Imho la partie ticky est # 1901, dès que nous avons résolu la question de savoir comment gérer la grille et la superposition pour les "boîtes étrangères", je ne vois aucune raison pour laquelle nous ne devrions pas supporter les formats d'image qui sont nativement pris en charge par le navigateur env. Mais pour cela, j'aimerais voir une discussion plus large (sur la plateforme de

Je suis entièrement d'accord avec le commentaire le plus récent de

J'ai créé un problème sur le terminal-wg de freedesktop.org pour essayer de standardiser "l'affichage d'image simple". J'espère que nous pourrons parvenir à un accord sur une séquence d'évacuation semi-portable appropriée. Peut-être la séquence d'échappement 1337 (bien qu'elle présente quelques problèmes); peut-être autre chose.

Je pense que cela peut être divisé en deux problèmes:

1. Gestion des séquences de code d'échappement arbitraires, en interne ou en externe (via API). C'est une fonctionnalité utile pour plus que de simples images, et elle est orthogonale au concept de ce qui est montré ou même de la façon dont il est montré. Il a juste besoin d'une API de rappel de fonction.

2. Hébergement de contenu DOM étranger, dans ce cas une image, mais un autre contenu a les mêmes propriétés: un élément DOM avec un x, y, w, h par rapport à une sous-grille de cellules de la grille de caractères du terminal

Les deux m'aideraient beaucoup, mais de différentes manières. Cela pourrait valoir la peine de créer deux nouveaux numéros pour chacun.

• Actuellement, chaque ligne a une longueur fixe, les images à afficher sont-elles également fixées sur cette grille ou la taille doit-elle être différente? Par exemple, avec une hauteur de ligne = 10px et une hauteur d'image = 15px, si l'image consomme 15px ou 20px sur le terminal). Dans ce dernier cas, nous voudrons peut-être aborder le # 1140 en premier.

J'ai juste supposé que l'image serait toujours 15px et que les 5px supplémentaires seraient vides, de sorte que l'image serait "superposée" sur les lignes. Étant donné que la largeur / hauteur de la cellule est si petite, je ne vois aucun inconvénient au léger espace de pixels gaspillé de cette solution.

Gestion des séquences de code d'échappement arbitraires, en interne ou en externe (via API). C'est une fonctionnalité utile pour plus que de simples images, et elle est orthogonale au concept de ce qui est montré ou même de la façon dont il est montré. Il a juste besoin d'une API de rappel de fonction.

Déjà fait:

https://github.com/xtermjs/xterm.js/blob/bd0d267d972a1aab4777cddecf9bf8196d7aa44f/typings/xterm.d.ts#L1060 -L1127

Mon commentaire est probablement un peu dépassé, @jerch a été le principal à regarder des images avec ceci, https://github.com/xtermjs/xterm.js/pull/2503 et https://gitlab.freedesktop.org / terminal-wg / spécifications / issues / 12

Ah oui, j'utilise même cette API. Oups, j'aurais dû m'en souvenir. Merci.

Je pense que ce serait cool de prendre en charge sixel ainsi que la séquence 1337 ... Je pense que tout ce qui est affiché devrait être potentiellement redimensionné s'il est trop large, et l'espace occupé à une hauteur de ligne complète.

Peut-être déjà possible avec l'extension, vous ne savez pas si les gestionnaires personnalisés peuvent s'accrocher à un ensemble donné de colonnes / lignes et la hauteur-largeur de l'un ou l'autre pour rendre personnalisé plusieurs lignes?

Entré dans cela après avoir découvert les formats sixel et remarqué qu'il n'est pas disponible dans les terminaux que j'utilise le plus (dont l'un est vs code).

@ tracker1 Voir # 2503 pour l'état de développement actuel.