Terminal: Solicitud de función: soporte de gráficos sixel

Al implementar Sixel, es importante probar con imágenes que contengan transparencia.
La transparencia se puede lograr dibujando píxeles de diferentes colores pero no dibujando algunos píxeles en ninguno de los colores de Sixel, dejando el color de fondo como tal.
Creo que esta es la única forma de dibujar correctamente Sixels no rectangulares, y sería especialmente bueno con la transparencia acrílica de fondo en la nueva Terminal de Windows.

Al probar usando WSL con Ubuntu, por ejemplo, en mlterm tales imágenes se representan correctamente con una máscara de transparencia y se mantiene el color de fondo, mientras que en xterm -ti vt340, los píxeles intactos se dibujan en negro, aunque el fondo es blanco, lo que parece implican que representan seiseles en un mapa de bits de memoria inicializado como negro sin máscara de transparencia o alfa antes de enviarlos a la ventana del terminal.

Oh. Sixel es algo muy bueno.

He decidido que necesito eso. NECESITAR.

Con mucho gusto revisaré un PR :)

Capté la entrevista de Build 2019 hoy que mencionó esta solicitud. Todavía mantengo que Xorg en sixel está mal . Así que _muy, muy mal_.

Sin embargo, la demostración de ffmpeg-sixel "Steve Ballmer Sells CS50 " nunca se cansa. Debo decir que es un poco decepcionante que el video carezca de sonido (el sonido realmente hace el video ). Las consolas ya tienen sonido, naturalmente. Ellos totalmente bip. Conjunto de precedentes. Lo que realmente _necesitamos_ es una nueva secuencia CSI para los clips de obra intercalados con los fotogramas, ¿amirite?

Ken, realmente merezco esto por mencionar a Sixels;)

De: [email protected]
Enviado: miércoles, 8 de mayo de 2019 4:31:31 p. m.
A: Microsoft/Terminal
CC: Suscrito
Asunto: Re: [microsoft/Terminal] Soporte de gráficos Sixel (#448)

Atrapé la compilación 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%2BVRlbPgpwJWtPZSGGHc%3 entrevistaD&reservado=0 hoy que entrevista D&reservado=0 hoy. Todavía mantengo que Xorg en sixel es simplemente incorrecto

El 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 Demostración de "Steve Ballmer vende CS50" https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com% 2Fwatch% 3Fv% 3D7z6lo4aq6zc% 26feature% 3Dyoutu.be y datos = 01% 7C01% 7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 y sdata = 6IVwBHs6% 2F43rXdk6GabiSUpTFS86xUGB6bubfkS3ea0% 3D y reservado = 0 nunca llega aunque cansado. Debo decir que es un poco decepcionante que el video carezca de sonido (el sonido realmente hace que el video sea https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv 3DEl2mr5aS8y0% y datos = 01% 7C01% 7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 y sdata = Mm1ICN5KcgrP5YmdAZsUCzUKbVQDtxFE1qAEpkhKiZk% 3D y reservado = 0 ). Las consolas ya tienen sonido, naturalmente. Ellos totalmente bip. Conjunto de precedentes. Lo que realmente necesitamos es una nueva secuencia CSI https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FANSI_escape_code%23CSI_sequences&data=01%7C01%7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 y sdata = 29pJq5661TXtnn2huLyUMgebTyYMEhTKXpAm19jzqHU% 3D y reservado = 0 para el Opus https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FOpus_ (audio_format) y datos = 01% 7C01% 7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 y sdata = XOq6Acz4% 2B7gQeTKQBQ2fYJPnoLvx6vUjmLRhgOX1eDo% 3D y reservado = 0 clips intercalados con los marcos, amirite?

—
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en 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 y sdata = pnXPvsuGF7l5mQfU2htzFwJnqZjEuW4zNuh1HaBJnKM% 3D y reservado = 0 , o silenciar el hilo https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. com% 2Fnotifications% 2Funsubscribe-auth% 2FADNHLGXQOYKINZMIBKTB4LTPUNPFHANCNFSM4HLENFOQ y datos = 01% 7C01% 7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 y sdata =% 2F4pMmm7bvPa% 2BbFmE1gyN8% 2BoTZDKJyRksBrkJpDh% 2BLug% 3D y reservado = 0 .

Relacionado: #120

Necesitar.

LOL Estaba viendo la transmisión y pensé "aquí está mi jefe asignándome trabajo en vivo frente a una audiencia de estudio".

¡Haga de esto una prioridad para v1.0!

Las animaciones 3d pueden ser v1.5 😛

Dios mío

Al votar a favor de esta solicitud, sería increíble tener Sixels en la Terminal.

Este fin de semana terminé de implementar el soporte de lectura de sixel para mi biblioteca TUI basada en Java con licencia del MIT, y fue sorprendentemente sencillo. El código para convertir una cadena de datos de Sixel en una imagen de mapa de bits está aquí , y el código de cliente para la clase Sixel está aquí .

He hecho muy poco por el rendimiento en el decodificador. Pero cuando se usa el backend de Swing, el rendimiento sigue siendo correcto, como se ve aquí . (La imagen de la serpiente se ve mal solo porque byzanz usó una paleta deficiente para crear el gif de demostración). Me sorprendió un poco lo rápido que se unió. Es muy justo decir que la parte "decodificar seisel en mapa de bits" es la parte fácil, la parte difícil es "pegar datos de imagen en una celda de texto, y cuando eso está presente, proyectar la imagen en la pantalla en lugar del carácter".

Solo quiero mencionarlo a otras personas interesadas en el soporte de terminal para sixel, y espero que pueda ayudarlo.

Votaré si alguien más escribe un cliente de cuaderno Jupyter;)

Ya tenemos un ejemplo de soporte de Sixel en mintty que está escrito en C (vice java). Lo único que se necesita es un refactor a C++ (al menos para el soporte inicial). Siempre es bueno ver cómo se ha implementado en otros proyectos.

Ya tenemos un ejemplo de soporte de Sixel en mintty que está escrito en C (vice java). Lo único que se necesita es un refactor a C++ (al menos para el soporte inicial). Siempre es bueno ver cómo se ha implementado en otros proyectos.

¿Algún problema con la licencia de Mintty (GPLv3 o posterior)?

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

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

Desde ese enlace:

El código Sixel (sixel.c) se vuelve a licenciar bajo GPL como mintty con el
permiso de su autor (kmiya@culti)

Si translitera ese código exacto a C++, el trabajo derivado deberá tener una licencia GPLv3 o posterior, según sus términos, o no distribuirse en absoluto. (También se podría preguntar a kmiya @culti si están dispuestos a ofrecer sixel.c bajo una licencia diferente, o si alguna vez estuvo disponible bajo otra licencia, busque una copia de esa fuente).

No sé qué es aceptable o no incluir en la Terminal de Windows: mi vistazo rápido a la Terminal de Windows dice que tiene licencia MIT, por lo que, dependiendo de cómo se vincule/cargue usando un descendiente directo de GPLv3+ de mintty, sixel.c podría generar a un problema de licencia.

De todos modos, lamento estar molestando el proyecto de otra persona aquí, volviendo a la cueva ahora...

Hay un widget de emulador de terminal humilde con capacidad para sixel escrito en C/C++ para Windows/Linux, y tiene una clase SixelRenderer que puede usar (aunque necesita algo de optimización), y tiene una licencia BSD-3. Podría decirse que su mayor inconveniente es que está escrito para un marco C++ específico. Aún así, en mi opinión, el código de SixelRenderer se puede traducir con poco esfuerzo. (Lo sé porque soy su autor. :))

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

Al implementar Sixel, es importante probar con imágenes que contengan transparencia.
La transparencia se puede lograr dibujando píxeles de diferentes colores pero no dibujando algunos píxeles en ninguno de los colores de Sixel, dejando el color de fondo como tal.
Creo que esta es la única forma de dibujar correctamente Sixels no rectangulares, y sería especialmente bueno con la transparencia acrílica de fondo en la nueva Terminal de Windows.

Al probar usando WSL con Ubuntu, por ejemplo, en mlterm tales imágenes se representan correctamente con una máscara de transparencia y se mantiene el color de fondo, mientras que en xterm -ti vt340, los píxeles intactos se dibujan en negro, aunque el fondo es blanco, lo que parece implican que representan seiseles en un mapa de bits de memoria inicializado como negro sin máscara de transparencia o alfa antes de enviarlos a la ventana del terminal.

mmm. el VT340 que tengo delante respeta el parámetro P2 en el DCS P1; P2; P3; q secuencia que inicia la secuencia SIXEL. Xterm, por otro lado, parece ignorarlo. Pero si usa la secuencia de atributos de trama ( " Pan ; Pad ; Ph ; Pv ) y le da una altura y un ancho, borrará el fondo para que obtenga un píxel negro.

Estaba pensando en obtener la versión de prueba gratuita del emulador ttwin y ver cómo difiere su comportamiento del VT340 y el Xterm actuando como un VT340.

Pero... +1 por la idea de apoyar a SIXEL en general y +10 por la idea de hacer pruebas de compatibilidad.

Podríamos agregar soporte para el Protocolo de imágenes en línea iTerm2 una vez que estemos allí... Al menos debería ser más fácil de implementar, solo necesita una ruta a la imagen y hace todo por sí solo.

Una duda que tengo con ambos sistemas es, ¿qué pasa con la alineación? Si el ancho o la altura de las imágenes son un múltiplo del ancho o la altura de los caracteres, todo está bien, pero si no, ¿se debe agregar un relleno solo en los lados inferior y derecho, o se debe centrar la imagen agregando relleno en todos los lados?

Hola, aquí hay algunos enlaces relevantes para la investigación:

• "Conceptos básicos para un buen protocolo de imagen" en terminal-wg (y una discusión anterior vinculada )
• este hilo masivo sobre el soporte de sixel

Podríamos agregar soporte para el Protocolo de imágenes en línea iTerm2 una vez que estemos allí... Al menos debería ser más fácil de implementar, solo necesita una ruta a la imagen y hace todo por sí solo.

Eso probablemente debería ser una tarea diferente. Sixel y ReGIS son explícitamente para datos gráficos o de caracteres en banda. No digo que sea una mala idea, solo digo que debe tratarse como una característica diferente.

Una duda que tengo con ambos sistemas es, ¿qué pasa con la alineación? Si el ancho o la altura de las imágenes son un múltiplo del ancho o la altura de los caracteres, todo está bien, pero si no, ¿se debe agregar un relleno solo en los lados inferior y derecho, o se debe centrar la imagen agregando relleno en todos los lados?

La alineación de los datos gráficos de Sixel y ReGIS se describe (deficientemente) en varios manuales. Las imágenes Sixel se alinean en los límites de las celdas de los caracteres. Si desea un borde negro alrededor de una imagen, debe agregar esos píxeles negros usted mismo; no existe el concepto de nada como el margen o el relleno de HTML. Cada línea de datos de seisel describe una franja de seis píxeles de alto. Si está tratando de alinear datos de imágenes de seisel con caracteres de texto en un emulador de terminal, esto puede ser frustrante ya que el software que genera los datos de seisel puede no saber cuántos píxeles de altura tiene cada glifo de carácter. Si tiene a mano un xterm de la vieja escuela, puede ver esto iniciándolo en modo vt340, especificando diferentes tamaños de fuente (para darle diferentes tamaños de celda de caracteres) y luego imprimiendo algunos datos de seisel que intentan alinear los datos de la imagen con el texto. datos. (Aquí hay un archivo de prueba simple que parece correcto cuando le digo al servidor de fuentes que use 96 DPI y especifico una fuente de 15 puntos. La modificación del tamaño de la fuente hace que las imágenes se desalineen cada vez más con el texto. https://gist.github. com/OhMeadhbh/3d63f8b8aa4080d4de40586ffff819de )

Los vt340 originales no tenían este problema porque (por supuesto) no podía especificar un tamaño de fuente al encender la terminal.

La otra cosa que puede ver en esa imagen, que no está bien descrita en la documentación de sixel, es que imprimir una línea de datos de sixel establece un "margen izquierdo virtual" para los datos de la imagen. Si hace el equivalente moral de un CR o CRLF usando los caracteres '$' o '-', la siguiente línea se imprime en relación con este margen izquierdo virtual, no con el margen izquierdo real en el lado izquierdo de la terminal.

Espero que esto ayude.

Finalmente retrocediendo para leer esto. Lo siento por la respuesta tardía.

Al probar usando WSL con Ubuntu, por ejemplo, en mlterm tales imágenes se representan correctamente con una máscara de transparencia y se mantiene el color de fondo, mientras que en xterm -ti vt340, los píxeles intactos se dibujan en negro, aunque el fondo es blanco, lo que parece implican que representan seiseles en un mapa de bits de memoria inicializado como negro sin máscara de transparencia o alfa antes de enviarlos a la ventana del terminal.

No debería ser demasiado difícil admitir la transparencia en xterm. He estado investigando el código por otras razones. Me temo que alguien, en algún lugar, depende de este comportamiento de Xterm, por lo que recomendaría ponerlo detrás de un indicador de compatibilidad, que también debería ser sencillo. Pero luego está la cuestión del valor predeterminado. ¿Cuál debería ser el valor predeterminado? Negro o transparente.

¿Sabemos qué hicieron los VT240, 241, 330 y 340 originales? ¿Podría sugerir tratar de representar fielmente la experiencia de un VT real?como el comportamiento predeterminado? Puede probar esto imprimiendo caracteres de espacio invertido, luego superponiendo gráficos de seisel sobre ellos y viendo de qué color se representan los píxeles no especificados.

No sé si me importa demasiado cuál es el valor predeterminado para el terminal msft siempre que exista la capacidad de comportarse como Xterm emulando un VT340. El código que he escrito para hacer loglines sobre ssh en la terminal asume el comportamiento de "píxeles no especificados son negros" descrito anteriormente. Tendría que reescribir ese código si hacemos este cambio.

Si está tratando de alinear datos de imágenes de seisel con caracteres de texto en un emulador de terminal, esto puede ser frustrante ya que el software que genera los datos de seisel puede no saber cuántos píxeles de altura tiene cada glifo de carácter.

Los vt340 originales no tenían este problema porque (por supuesto) no podía especificar un tamaño de fuente al encender la terminal.

¿Hay alguna razón por la que un emulador de terminal no pueda simplemente escalar la imagen para que coincida exactamente con el comportamiento de los terminales DEC originales? Entonces, si la altura de la línea en un VT340 era de 20 píxeles, una imagen de 200 píxeles de altura debería cubrir exactamente 10 líneas, independientemente del tamaño de la fuente. Me parece que esa es la única forma en que podría seguir siendo razonablemente compatible con el software heredado, que es el objetivo de un emulador de terminal.

Puedo entender querer extender ese comportamiento para renderizar imágenes a una resolución más alta, pero creo que debería ser una extensión opcional (o simplemente usar uno de los formatos propietarios existentes). Entonces, idealmente, me gustaría que el valor predeterminado de Sixel fuera lo más cercano posible a lo que habría obtenido en una terminal DEC real.

Hola, aquí hay algunos enlaces relevantes para la investigación:
"Conceptos básicos para un buen protocolo de imagen" en terminal-wg

Sixel no funciona porque tmux no puede admitirlo con paneles uno al lado del otro.

Tomó algo de trabajo (en realidad, mucho trabajo ), pero con Sixel uno puede realizar casi todos los trucos de "imágenes en una terminal" que uno puede imaginar:

• Imágenes en capas por celda enmascaradas en una terminal: https://jexer.sourceforge.io/images/sixel_many_images.png

• Una ventana de terminal flotante (multiplexada) en una terminal que usa sixel para soporte de ancho doble estilo VT100: https://jexer.sourceforge.io/screenshots/jexer_sixel_in_sixel.png

• Terminales en mosaico "estilo tmux" con imágenes: https://gitlab.com/klamonte/jexer/-/wikis/uploads/7603381f82414ef9ae214bfcf759c064/example_tilingwm2_1.png

• Sesión de terminal compartida de varios encabezados con diferentes tamaños de celdas de texto que muestran el mismo gráfico: https://jexer.sourceforge.io/screenshots/multiscreen_2b.png

• El uso de sixel para representar CJK y emoji que no están presentes en la fuente de la terminal principal: https://jexer.sourceforge.io/screenshots/xterm_sixel_cjk.png

He incluido algunos otros comentarios en el hilo de protocolo "bueno" al que se hace referencia que podrían ser de interés.

Por lo menos, sixel es un buen trampolín para desarrollar la infraestructura del lado terminal de imágenes y texto mixtos. Hablando desde la experiencia directa, el lado del terminal (almacenamiento/visualización de imágenes) es aproximadamente 1/4 tan difícil como el lado del multiplexor/aplicación (tmux/mc et al).

Los sixels son, de hecho, la solución ideal para gráficos en banda (por ejemplo, sobre ssh): como son compatibles con muchas herramientas existentes, están listos para usar con fines prácticos, como trazar problemas de sincronización de marcas de tiempo sobre la marcha.

Como lo ilustra therealkenc y lo explica con más detalle klamonte en 640292222, todo se puede manejar con seiseles, incluso imágenes una al lado de la otra, pero requiere algo de trabajo.

Hace un tiempo estaba trabajando con otras personas en un modo alternativo para tmux, usando gráficos unicode avanzados para representar imágenes sixel en terminales que no admiten sixel.

Es un poco como el arte ANSII automatizado, aprovechando los caracteres de bloque especiales que están presentes en la mayoría de las fuentes: esta representación unicode de color equivalente podría sustituirse por los seiseles, y luego sobrescribirse con la imagen real de seiseles (¡o no!). También resolvería el problema de mantener todas las imágenes de seisel para desplazarse hacia atrás, sustituyéndolas con marcadores de posición Unicode de baja fidelidad (por ejemplo, para ahorrar memoria) y tener marcadores de posición para imágenes de seisel cuando no se pueden mostrar por cualquier motivo.

El código era de dominio público. Podría usarse inmediatamente como un primer paso hacia el soporte de sixel:

• detectar cuándo se transmite la secuencia de seisels, luego calcular el reemplazo de texto Unicode

• muestra esta secuencia unicode, que ya es compatible con Windows Terminal

• más tarde, cuando se implementen los seiseles, represente encima de la secuencia de seiseles.

¿Estarías interesado?

Por cierto, reconozco aquí mi familiar gnuplot x^2 sin y 10 sin(x) plots . Estoy feliz de que haya proporcionado algo de inspiración 😄

Por favor.

@DHowett ¿Es acac350 un primer paso para renderizar gráficos de seisel? Recibo solicitudes de soporte para sixel en Microsoft Terminal de gente que usa ssh y quiere ver directorios de imágenes usando mi programa lsix .

más o menos Ahora tenemos la capacidad de manejar secuencias DCS entrantes. Todavía no hemos conectado a ningún controlador, pero tener la infraestructura para hacerlo era muy importante. :sonreír:

Aquí hay algunas actualizaciones. Tengo una sucursal de trabajo aquí . Una captura de pantalla temprana se ve así:

Al contrario de lo que pensé originalmente, la parte más difícil de renderizar imágenes de seisel es en realidad la capa de contenido. Se supone que las imágenes de Sixel son objetos en línea. La representación de imágenes de seisel depende del tamaño de representación de un carácter. Sin embargo, debido a la capa de contenido adicional, en realidad no podemos obtener el tamaño de representación de un carácter al procesar secuencias de seisel. Esto suena muy abstracto y vago. Cualquiera que esté interesado en esto puede pasar por mi sucursal y ver cómo se hace.

En general, la capa de contenido hace que sea muy difícil manejar el desplazamiento y el cambio de tamaño de las imágenes de seisel. En mi sucursal funciona si solo necesitas mostrarlo. Pero tanto el desplazamiento como el cambio de tamaño están completamente rotos.

Todavía no miré, pero ¿puede usar el modo de transferencia para implementar en la Terminal? Todavía lo agregaría en OpenConsole, pero parece que no es posible compartir el código. Dado que Windows Terminal debe desacoplarse de OpenConsole en algún momento, es mejor que simplemente duplique el código para ambos. ¿También te estás basando en los parámetros tuyos y de relaciones públicas de j4james? Eso probablemente también ayudaría.

@WSLUser Gracias por la atención. Esta captura de pantalla es en realidad de hace aproximadamente un mes, cuando los fantásticos parámetros PR de j4james ni siquiera existían. Mi trabajo está completamente dentro de Windows Terminal, no conhost. Le mostré este PR al equipo de la consola internamente y logré algunos avances desde entonces. Pero estoy atascado por el problema de conpty.

Sí, cambiaría la base del maestro y agregaría https://github.com/microsoft/terminal/pull/7578 y https://github.com/microsoft/terminal/pull/7799. A partir de ahí, tal vez vea lo que falta en ConPTY para el modo de transferencia. Me pregunto si Mintty está usando transferencia para el modo ConPTY.

Me pregunto si Mintty está usando transferencia para el modo ConPTY.

Bastante seguro de que mintty no está usando conpty en absoluto 😜

El truco aquí con conpty es que la consola (conpty) necesitará conocer las celdas que están llenas con contenido de seisel, para no borrar accidentalmente ese contenido de la Terminal conectada. Tal vez se podría iluminar a Conpty para ignorar pintar celdas con gráficos de tamaño, y simplemente asumir que la Terminal conectada dejará esas celdas en paz.

Eso podría estropear algunas de nuestras optimizaciones (como que no podemos borrar filas de línea que tienen datos de seis), pero podría ser un buen comienzo

\

Tal vez se podría iluminar a Conpty para ignorar pintar celdas con gráficos de tamaño, y simplemente asumir que la Terminal conectada dejará esas celdas en paz.

Este también había sido mi plan original, y bien puede ser la mejor solución con la arquitectura de condominio actual, pero hay una serie de complicaciones.

1. ¿Cómo interactuaría esto con la transmisión de DCS (que no creo que tengamos una solución todavía). Supongo que necesitaríamos algún tipo de concepto de flujo dividido que pasara el flujo de bytes a conpty al mismo tiempo que se envía al búfer conhost, pero parece que agregaría una gran cantidad de sobrecarga innecesaria al proceso.
2. Esto solo funcionaría si conoce el tamaño de celda de píxel del terminal de conpty. He mencionado antes que creo que la mejor solución para Sixel es hacer coincidir el tamaño de celda de los terminales VT originales, y si lo hiciéramos, esto no sería un problema. Sin embargo, que yo sepa, ningún otro emulador de terminal hace eso, por lo que no funcionaría con nadie más.

El segundo problema que mencionó @j4james se vuelve aún más complicado con la consideración de diferentes fuentes, diferentes tamaños de fuente y el cambio de tamaño de fuente. Entonces, en general, creo que hay 3 aspectos del problema:

• Primero, conpty necesitará saber acerca de las celdas que están llenas con contenido de seisel. Sin esto, el búfer de respaldo en conpty y el búfer de dibujo en WT estarán inevitablemente desincronizados.
• Para hacer eso, conpty necesitará conocer el tamaño de celda de píxeles en el contexto de dibujo, que es manejado por la capa de dibujo en WT. Hay una gran brecha entre conpty y el DXRenderer real, lo que hace que esta sea una tarea difícil.
• Además, cuando cambia la fuente o el tamaño de la fuente, idealmente la imagen de seisel debería cambiar correspondientemente.
• Y finalmente tratar con otras cosas como el panel, el búfer alternativo, el dibujo diferencial, el desplazamiento, etc.

El segundo problema que mencionó @j4james se vuelve aún más complicado con la consideración de diferentes fuentes, diferentes tamaños de fuente y el cambio de tamaño de fuente. Entonces, en general, creo que hay 3 aspectos del problema:

Para que quede claro, mi punto era que nada de eso sería un problema si coincidiéramos exactamente con el comportamiento de un VT340, por lo que una imagen de 10x20 píxeles ocuparía exactamente una celda de carácter, independientemente del tamaño de la fuente. Solo es un problema si queremos igualar el comportamiento de otros emuladores de terminal, y esa siempre podría ser una opción que se deje para más adelante. Todavía habría complicaciones con este enfoque, pero personalmente creo que son menos preocupantes.

Mi mayor preocupación es que parece estar ignorando el problema de transmisión de DCS, que espero que pueda cambiar fundamentalmente la arquitectura de la solución. Los pasos que me gustaría haber visto son: 1. Resolver #7316; 2. Acordar una solución para el tamaño de píxel de la celda; 3. Haz que algo funcione en conhost; 4. Una vez que todas las complicaciones estén resueltas en conhost, solo entonces considere cómo hacemos que funcione sobre conpty.

Perdón por dejar el tema de transmisión de DCS. En mi implementación actual, solo almaceno la cadena completa y la paso al motor. Esto introduce un problema de rendimiento cuando la secuencia es más grande. Pero al menos funciona. Así que mis comentarios anteriores se basan en gran medida en ello.

Pero tienes razón. El problema de transmisión de DCS es en realidad la máxima prioridad si alguien más quiere ensuciarse las manos con esto.

获取 Outlook para iOS https://aka.ms/o0ukef

Según la discusión en https://github.com/microsoft/terminal/issues/57 , pensé que a conpty no le importan las fuentes en absoluto.

wrt cambiar el tamaño Creo que la forma más natural de hacerlo es "anclar" la imagen en celdas de caracteres una vez que llega la imagen, y volver a calcular el tamaño de la imagen en función de la geometría del ancla. Cualquier otra cosa causará inconsistencias en la imagen frente a las celdas de caracteres.

@yatli Sí. Eso es también lo que complica el asunto.

La imagen de 10x20 píxeles ocuparía exactamente una celda de carácter

Desafortunadamente, esto es incorrecto, al menos para mi configuración de fuente actual.

Corríjame si me equivoco, pero para una visualización de imagen perfecta en píxeles, creo que debemos preocuparnos por las fuentes.

@skyline75489 por favor vea mi comentario actualizado sobre el "ancla"

La estructura de datos de la celda debe actualizarse como char | sixel anchor

El ancla sixel debe contener información sobre:

• Un puntero al objeto de imagen.
• La región de la celda char que ocupa, en números flotantes (por ejemplo, 5,2 líneas x 7,8 columnas)

Es una buena idea, pero los detalles de implementación me estaban matando debido a la traducción adicional en la capa de contenido. Para evitar enviar spam a las personas con el correo electrónico, no dude en comunicarse conmigo en Teams @yatli si está interesado.

La imagen de 10x20 píxeles ocuparía exactamente una celda de carácter

Desafortunadamente, esto es incorrecto, al menos para mi configuración de fuente actual.

Lo que estoy sugiriendo es que deberías hacer que ese sea el caso. Si crea una imagen de 10x20 píxeles y la envía a un terminal DEC VT320 real, tomará exactamente un carácter (al menos en el modo de 80 columnas). Entonces, si estamos tratando de emular ese terminal, entonces deberíamos estar haciendo lo mismo. Si su fuente actual es de 30x60, entonces necesita escalar la imagen. Si su fuente es más pequeña, entonces reduce la escala de la imagen.

Esto garantiza que puede generar una imagen Sixel en cualquier tamaño de fuente y obtener siempre el mismo diseño. Si desea que cubra un área determinada de la pantalla, o si desea dibujar un borde alrededor con caracteres de texto, sabe exactamente cuánto espacio ocupará la imagen.

Corríjame si me equivoco, pero para una visualización de imagen perfecta en píxeles, creo que debemos preocuparnos por las fuentes.

Es cierto que no vas a obtener imágenes "perfectas en píxeles" de esta manera, pero no creo que ese deba ser el objetivo principal. Muchas computadoras modernas tienen pantallas de alto dpi donde es rutinario que las imágenes se amplíen, por lo que no es que este sea un concepto extraño. Y si queremos mantener la consistencia del diseño cuando el usuario cambia el tamaño de la fuente, tendremos que escalar la imagen en algún momento de todos modos, por lo que también puede hacerlo desde el principio y obtener todos los beneficios de un formato predecible. Talla.

Y, por supuesto, el otro beneficio de hacer las cosas de esta manera es que podría implementarse de forma factible en el condominio. No veo cómo puede hacer que conpty funcione si el área ocupada por la imagen depende del tamaño de fuente, que posiblemente no pueda saber.

No voy a pretender que este enfoque no tenga inconvenientes, pero creo que los aspectos positivos superan a los negativos.

¿Qué pasa si la fuente tiene una relación de aspecto diferente a 10:20?

¿Qué pasa si la fuente tiene una relación de aspecto diferente a 10:20?

Sugiero leer esta discusión larga, y algo "brutal", sobre los problemas generales relacionados con las imágenes en línea en los emuladores de terminal .

Puede darte una idea general.

Atentamente

¿Qué pasa si la fuente tiene una relación de aspecto diferente a 10:20?

La imagen puede estar un poco estirada o aplastada, pero no creo que sea el fin del mundo.

Permítanme demostrar con un ejemplo del mundo real. Imagina que soy un villano de Bond y tengo un viejo sistema de seguridad que usa un VT340 como frontend. Ahora, debido al coronavirus, estoy encerrado y trabajando desde casa, así que estoy iniciando sesión en el sistema de forma remota con Windows Terminal. Si hacemos coincidir exactamente el VT340, no hay problema: el terminal se ve así:

Pero tal vez prefiero las fuentes con una relación de aspecto extraña. Entonces, veamos cómo se vería con _Miriam Fixed_, que es más ancha que la mayoría. La imagen de Bond ahora se ve un poco aplastada, pero aún es fácilmente reconocible.

La alternativa sería ir con una imagen de píxeles perfectos (actualmente no es factible con conpty, pero supongamos por un segundo). Bond ya no se ve aplastado, pero ahora la imagen es solo una fracción del tamaño que se esperaba. Y cuanto mayor sea la resolución de su monitor, peor se verá.

Tal vez esto sea una cuestión de preferencia personal, pero sé que definitivamente elegiría la opción 1 sobre la opción 2.

También tenga en cuenta que no hay ninguna razón por la que no podamos tener opciones para modificar el comportamiento exacto cuando la relación de aspecto de la fuente no es 1:2. Una opción podría ser centrar la imagen dentro de las celdas que se esperaba que ocupara. O podríamos expandir la imagen para que cubra el área completa, pero recortar los bordes que desbordan los límites. En mi opinión, cualquiera de estas opciones sería mejor que una representación exacta de píxeles.

Tal vez esto sea una cuestión de preferencia personal, pero sé que definitivamente elegiría la opción 1 sobre la opción 2.

Yo también, solo que sería mejor saber que la fuente tiene una relación de aspecto diferente, para que la imagen pueda ajustarse y mantener la correcta.

Una opción podría ser centrar la imagen dentro de las celdas que se esperaba que ocupara. O podríamos expandir la imagen para que cubra el área completa, pero recortar los bordes que desbordan los límites.

Creo que es mejor centrarlos.

Tal vez estoy leyendo mal este hilo. ¿De verdad estamos hablando de que el terminal falsifica 10:20 caracteres para una imagen de seis? Creo que eso causará muchos problemas como la distorsión de Bond. Hacerlo de la manera correcta puede ser más difícil, pero, en mi humilde opinión, una terminal moderna debe ser independiente de las fuentes y dejar que los programadores de aplicaciones se encarguen de los seisels y las celdas de caracteres.

Usando secuencias de escape, un programa ejecutado por el usuario puede determinar el tamaño de la celda del carácter en píxeles y decidir cómo manejar de manera inteligente la distorsión para esa aplicación. El programa de visualización de imágenes que uso funciona exactamente así. A medida que cambio la familia de fuentes o el tamaño, la miniatura que se muestra se actualiza para tener siempre exactamente cinco líneas de texto de alto. El ancho se escala proporcionalmente para la imagen, a menos que sea más grande que un cierto máximo (en este caso, bastante grande). Al basar el tamaño de la imagen en la celda del carácter, funciona automáticamente en pantallas de alto DPI.

Si bien el VT340 es un objetivo noble para emular, fijar la resolución de la celda de caracteres a las 10:20 (y, por lo tanto, limitar la resolución para toda la pantalla) es un error. El VT340 fue solo una de varias implementaciones de sixel, por lo que su tamaño de fuente no es necesariamente más correcto.

Forzar las 10:20 también conducirá a errores desagradables. (Por ejemplo, cómo responder a una solicitud del tamaño de la ventana de la terminal en píxeles. Decir la verdad, ¿suponiendo que colocarán ventanas en la pantalla? ¿O devolver siempre 800x480, suponiendo que el usuario está escalando imágenes para salida de seis? )

¿De verdad estamos hablando de que el terminal falsifica 10:20 caracteres para una imagen de seis?

Si.

una terminal moderna debe ser independiente de la fuente

Esta propuesta es independiente de las fuentes. La aplicación no necesita saber nada sobre la fuente. Ese es todo el punto.

Usando secuencias de escape, un programa ejecutado por el usuario puede determinar el tamaño de la celda del carácter en píxeles y decidir cómo manejar de manera inteligente la distorsión para esa aplicación.

No estoy exactamente seguro de qué método está usando, pero la forma en que lo he visto hacer antes es con una consulta XTerm patentada para obtener el tamaño de píxel de la ventana y otra consulta para obtener el tamaño de celda de la ventana, y luego usar eso datos para calcular el tamaño real de píxel de la celda. Las desventajas de tal enfoque son:

1. Es propietario, por lo que no funcionaría en una terminal real o en cualquier emulador de terminal que coincidiera exactamente con una terminal real.
2. Si el usuario cambia el tamaño de fuente mientras se ejecuta su aplicación, sus cálculos ya no serán correctos y las imágenes se representarán con el tamaño incorrecto (a menos que esté recalculando continuamente el tamaño de fuente, lo que parece poco práctico).
3. Si el usuario tiene una pantalla de alta resolución y/o un tamaño de fuente grande, se ve obligado a enviar una imagen enorme para intentar igualar esa resolución. Teniendo en cuenta lo ineficiente que es Sixel para empezar, eso puede representar una gran cantidad de ancho de banda.

Dicho esto, entiendo que este es un modo que algunas personas pueden desear usar, y creo que al menos deberíamos tener una opción para admitirlo algún día (por las razones discutidas anteriormente, esto simplemente no es posible en este momento). Pero en mi opinión, este no es el mejor enfoque para Sixel.

Tengo más de 300 VT340 en plantas de energía nuclear que me gustaría eventualmente
reemplazar.

Hay paquetes comerciales de emulación de terminal que podríamos usar, pero creo
todos menos uno han sido EoL'd.

Hemos reemplazado algunos de ellos con PC con Linux que ejecutan XTerm (o menos
con frecuencia, Win10 + Hummingbird + WSL ejecutando XTerm), porque tiene un
implementación de sixel de código abierto medio decente y una especie de mala, pero
Implementación de ReGIS de código abierto.

La probabilidad de que estemos escribiendo nuevo software para la parte de este
sistema que genera el flujo de octetos de seis es NIL.

Si su objetivo es enviar gráficos a través de un flujo de octetos en línea, hay
son otras opciones. Pero si desea admitir gráficos Sixel, debe
Admite gráficos Sixel de una manera que es medio similar a la anterior
implementaciones. Esto, desafortunadamente, significa que debe emular el
comportamiento de los sistemas ejemplares (es decir, VT240, VT241, VT330 y VT340
terminales) incluso cuando se trata de integrar gráficos con texto.

Esta es una maqueta del tipo de cosas de las que estoy hablando. sería muy
bueno si alguna nueva implementación de Sixel mantiene la compatibilidad con las existentes
implementaciones para que las imágenes no se salgan del borde de la pantalla o solo
llenar la mitad de la pantalla.

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

una terminal moderna debe ser independiente de la fuente

Esta propuesta es independiente de las fuentes. La aplicación no necesita saber nada sobre la fuente. Ese es todo el punto.

Quise decir que la _terminal_ debería ser independiente de la fuente en lugar de imponer 10:20 en cada fuente. La aplicación debería poder saber el tamaño real de la fuente, si así lo desea, ya que es la aplicación la que conoce el dominio de lo que intenta mostrar y puede descubrir la mejor manera de presentar texto y gráficos juntos.

Usando secuencias de escape, un programa ejecutado por el usuario puede determinar el tamaño de la celda del carácter en píxeles y decidir cómo manejar de manera inteligente la distorsión para esa aplicación.

No estoy exactamente seguro de qué método está usando, pero la forma en que lo he visto hacer antes es con una consulta XTerm patentada para obtener el tamaño de píxel de la ventana y otra consulta para obtener el tamaño de celda de la ventana, y luego usar eso datos para calcular el tamaño real de píxel de la celda.

Sí, eso es correcto. También hay una consulta para obtener directamente el tamaño de la celda del carácter, pero no creo que sea tan compatible como simplemente obtener el tamaño de la pantalla y dividir por FILAS y COLUMNAS.

Las desventajas de tal enfoque son:

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

Eso no es un inconveniente. Solo significa que el programa tiene que volver a hacer lo que hubiera hecho de todos modos: suponga que $TERM=="VT340" significa que las celdas de caracteres son 10:20, "VT240" significa 10:10, "mskermit" significa 8:8, y así.

Además, no es una secuencia propietaria de xterm. Obtener el tamaño de la pantalla se denomina secuencia de escape "dtterm", pero en realidad se implementó por primera vez en SunView (SunOS, 1986). Creo que más tarde se documentó en el Manual de programación de PHIGS (1992). Intente enviar "\e[14t" a algunos emuladores de terminal y verá que está ampliamente implementado.

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

Esto no es un problema. El programa simplemente atrapa SIGWINCH y solo vuelve a calcular si la ventana realmente ha cambiado.

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.

Sí, sixel es extremadamente ineficiente. Pero en las computadoras modernas, el envío de imágenes a pantalla completa es bastante útil, incluso a través de ssh. ¿Microsoft Terminal tiene algún tipo de limitación de velocidad en baudios?

Por cierto, creo que Sixel tiene un modo de "alto DPI" en el que cada punto se duplica en ancho y alto. Nunca lo he usado y no creo que xterm lo implemente, pero tal vez eso aliviaría las preocupaciones sobre el ancho de banda.

Dicho esto, entiendo que este es un modo que algunas personas pueden desear usar, y creo que al menos deberíamos tener una opción para admitirlo algún día (por las razones discutidas anteriormente, esto simplemente no es posible en este momento).

Este "modo" simplemente tiene caracteres y gráficos alineados al igual que lo hicieron los diversos terminales Sixel históricos y los emuladores actuales. Lo admito, no entiendo por qué no es posible hacer lo mismo en Microsoft Terminal. Si dice que este truco de las 10:20 es lo mejor que se puede hacer, confío en que tiene razón y gracias por hacerlo. Una imagen distorsionada es mucho mejor que nada.

Usando secuencias de escape, un programa ejecutado por el usuario puede determinar el tamaño de la celda del carácter en píxeles y decidir cómo manejar de manera inteligente la distorsión para esa aplicación.

@ hackerb9 , ¿cuál es la secuencia de escape real para obtener las dimensiones de la fuente?

Las secuencias XTerm relevantes se pueden encontrar aquí: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html -- busque XTWINOPS.

Además, en Unix normalmente puede obtener el tamaño de píxel interno de la terminal junto con el tamaño de la celda usando TIOCGWINSZ ioctl. Con openssh esto también funciona de forma remota.

Solo como un punto de datos, la rama sixel para libvte está tomando la ruta independiente del tamaño de celda de la que habla @hackerb9 . Trata los datos de seisel entrantes como "píxeles perfectos" y cambia la escala de las imágenes recibidas previamente en niveles de zoom y tamaños de fuente para cubrir una extensión de celda constante. Cuando se fusione, esta implementación estará disponible para una gran parte de los emuladores de terminales de Linux, incluidos GNOME Terminal, XFCE Terminal, Terminator, etc. Superficialmente, esto parece ser interoperable con al menos XTerm y mlterm.

Dado que libvte registra un tamaño de celda virtual por imagen, sería trivial hacer que esto funcione también con un tamaño de celda virtual fijo de 10x20 para la interoperación. Sin embargo, necesitaríamos una forma para que los programas comuniquen sus proporciones esperadas de píxel:celda a la terminal (por ejemplo, extendiendo los parámetros DCS). Eso podría ser muy útil en general, ya que también proporcionaría una forma de control de densidad de píxeles en entornos con restricciones de ancho de banda, como mencionaste anteriormente.

Además, en Unix normalmente puede obtener el tamaño de píxel interno de la terminal junto con el tamaño de la celda usando TIOCGWINSZ ioctl. Con openssh esto también funciona de forma remota.

La consola de Linux siempre devuelve 0... Sin embargo, deberían arreglar eso, pero parece que tampoco están dispuestos :-/