Terminal: Запрос функции: поддержка графики sixel

При внедрении Sixel важно тестировать изображения, содержащие прозрачность.
Прозрачности можно добиться, рисуя пиксели разных цветов, но не рисуя некоторые пиксели каким-либо из цветов Sixel, оставив фоновый цвет таким, каким он есть.
Я считаю, что это единственный способ правильно рисовать непрямоугольные шестиугольники, и это было бы особенно хорошо с фоновой акриловой прозрачностью в новом терминале Windows.

Тестирование с использованием WSL с Ubuntu, например, в mlterm такие изображения правильно отображаются как имеющие маску прозрачности, а цвет фона сохраняется, в то время как в xterm -ti vt340 нетронутые пиксели отображаются черным, даже если фон белый, что кажется подразумевают, что они визуализируют шесть элементов на растровом изображении памяти, инициализированном как черный, без маски прозрачности или альфы, прежде чем переносить их в окно терминала.

Ох. Sixel - очень крутая штука.

Я решил, что мне это нужно. НУЖНО.

С удовольствием рассмотрю PR :)

Поймал сегодня интервью Build 2019 , в котором упоминался этот запрос. Я все еще утверждаю, что Xorg на sixel просто неверен . Так что _очень-очень неправильно_.

Демонстрация ffmpeg-sixel "Steve Ballmer Sells CS50" никогда не надоедает. Должен сказать, немного разочаровывает видео без звука (звук действительно делает видео ). У консолей уже есть звук, естественно. Они вообще пищат. Установлен прецедент. Что нам действительно _нужно_ , так это новая последовательность CSI для опусных клипов, чередующихся с кадрами, amirite?

Кен, я действительно заслужил это за упоминание Sixels;)

От: [email protected]
Отправлено: среда, 8 мая 2019 г., 16:31:31
Кому: Microsoft/терминал
Копия: подписан
Тема: Re: [microsoft/Terminal] Поддержка графики Sixel (#448)

Caught the Build 2019 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmybuild.techcommunity.microsoft.com%2Fhome%23top-anchor&data=01%7C01%7Cduhowett%40microsoft.com %7C81f48be19f374665cd3408d6d40d4dc6%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=i8rfPCaN%2FxqdF%2F4qRtdN2Py4%2BVRlbPgpwJWtPZSGGHc%0D&reserved . Я по-прежнему утверждаю, что Xorg на sixel просто неверен https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FWSL%2Fissues%2F1099%23issuecomment-248513013&data=01 %7C01%7Cduhowett%40microsoft.com%7C81f48be19f374665cd3408d6d40d4dc6%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=J%2BwCnn0z70FkI9lDcus1nMXcDz1P0ArzL%2BwCnn0z70FkI9lDcus1nMXcDz1P0ArzL%2BwCnn0z70FkI9lDcus1nMXcDz1P0ArzL%2B Так очень очень неправильно.

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 Демо "Стив Балмер продает CS50" https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com% 2Fwatch% 3Fv% 3D7z6lo4aq6zc% 26feature% 3Dyoutu.be и данные = 01% 7C01% 7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 & SData = 6IVwBHs6% 2F43rXdk6GabiSUpTFS86xUGB6bubfkS3ea0% 3D & зарезервирован = 0 никогда не устает Тхо. Должен сказать, немного разочаровывает отсутствие звука в видео (звук действительно украшает видео https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv % 3DEl2mr5aS8y0 & данные = 01% 7C01% 7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 & SData = Mm1ICN5KcgrP5YmdAZsUCzUKbVQDtxFE1qAEpkhKiZk% 3D & зарезервирован = 0 ). У консолей уже есть звук, естественно. Они вообще пищат. Установлен прецедент. Что нам действительно нужно, так это новая последовательность CSI https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FANSI_escape_code%23CSI_sequences&data=01%7C01%7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 & SData = 29pJq5661TXtnn2huLyUMgebTyYMEhTKXpAm19jzqHU% 3D & зарезервирован = 0 для Opus https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FOpus_ (audio_format) и данные = 01% 7C01% 7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 & SData = XOq6Acz4% 2B7gQeTKQBQ2fYJPnoLvx6vUjmLRhgOX1eDo% 3D & зарезервированные = 0 клипы перемежающиеся с кадрами, amirite?

—
Вы получаете это, потому что подписаны на эту тему.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FTerminal%2Fissues%2F448%23issuecomment-490688164&data=01 % 7C01% 7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 & SData = pnXPvsuGF7l5mQfU2htzFwJnqZjEuW4zNuh1HaBJnKM% 3D & зарезервирован = 0 , или приглушить нить https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. ком% 2Fnotifications% 2Funsubscribe-AUTH% 2FADNHLGXQOYKINZMIBKTB4LTPUNPFHANCNFSM4HLENFOQ & данные = 01% 7C01% 7Cduhowett% 40microsoft.com% 7C81f48be19f374665cd3408d6d40d4dc6% 7C72f988bf86f141af91ab2d7cd011db47% 7C1 & SData =% 2F4pMmm7bvPa% 2BbFmE1gyN8% 2BoTZDKJyRksBrkJpDh% 2BLug% 3D & зарезервирован = 0 .

Связанный: #120

Нужно.

LOL Я смотрел стрим и подумал про себя: «Вот мой босс поручает мне работать в прямом эфире перед аудиторией в студии».

Пожалуйста, сделайте это приоритетом для версии 1.0!

3D-анимация может быть v1.5 😛

мой Бог

Проголосовав за этот запрос, Sixels было бы замечательно иметь в Терминале.

В эти выходные я закончил реализовывать поддержку чтения sixel для моей библиотеки TUI на основе Java под лицензией MIT, и это оказалось на удивление просто. Код для преобразования строки данных sixel в растровое изображение находится здесь , а клиентский код для класса Sixel — здесь .

Я сделал очень мало для производительности на декодере. Но при использовании бэкенда Swing производительность по-прежнему в порядке, как видно здесь . (Изображение змеи выглядит плохо только потому, что Byzanz использовал плохую палитру для создания демонстрационной GIF-анимации.) Я был немного ошеломлен тем, как быстро все получилось. Очень справедливо сказать, что часть «декодировать sixel в растровое изображение» является легкой частью, а трудная часть - это «вставить данные изображения в текстовую ячейку, и когда это присутствует, выведите изображение на экран, а не символ».

Просто хочу упомянуть об этом другим людям, заинтересованным в терминальной поддержке sixel, и надеюсь, что это поможет вам.

Я проголосую, если кто-то еще напишет клиент для ноутбуков Jupyter;)

У нас уже есть пример поддержки Sixel в mintty , написанный на C (vice java). Единственное, что нужно, это рефакторинг для C++ (по крайней мере, для первоначальной поддержки). Тем не менее всегда приятно видеть, как это было реализовано в других проектах.

У нас уже есть пример поддержки Sixel в mintty , написанный на C (vice java). Единственное, что нужно, это рефакторинг для C++ (по крайней мере, для первоначальной поддержки). Тем не менее всегда приятно видеть, как это было реализовано в других проектах.

Есть ли проблемы с лицензией mintty (GPLv3 или новее)?

https://github.com/mintty/mintty/blob/master/ЛИЦЕНЗИЯ

https://github.com/mintty/mintty/blob/master/ЛИЦЕНЗИЯ

Из этой ссылки:

Код Sixel (sixel.c) перелицензируется под лицензией GPL, как и mintty с
разрешение автора (kmiya@culti)

Если вы транслитерируете этот точный код на C++, производная работа должна быть лицензирована GPLv3 или более поздней версии, в соответствии с ее условиями, или вообще не распространяться. (Можно также спросить у kmiya @culti , готовы ли они предложить sixel.c под другой лицензией, или если он когда-то был доступен под чем-то другим, найдите копию из этого источника.)

Я не знаю, что приемлемо или нет для включения в Windows Terminal — мой быстрый взгляд на Windows Terminal говорит, что он лицензирован MIT, поэтому в зависимости от того, как он связан/загружен с использованием прямого потомка mintty GPLv3+, sixel.c может привести к к вопросу о лицензии.

В любом случае, извините, что беспокою чужой проект, возвращаюсь в пещеру...

Существует скромный виджет эмулятора терминала с поддержкой sixel, написанный на C/C++ для Windows/Linux, и у него есть класс SixelRenderer, который вы можете использовать (хотя он нуждается в некоторой оптимизации), и он имеет лицензию BSD-3. Возможно, его самым большим недостатком является то, что он написан для конкретной среды C++. Тем не менее, IMO код SixelRenderer можно перевести без особых усилий. (Я знаю это, потому что я его автор. :) )

https://github.com/ismail-yilmaz/upp-components/tree/master/CtrlLib/Терминал

При внедрении Sixel важно тестировать изображения, содержащие прозрачность.
Прозрачности можно добиться, рисуя пиксели разных цветов, но не рисуя некоторые пиксели каким-либо из цветов Sixel, оставив фоновый цвет таким, каким он есть.
Я считаю, что это единственный способ правильно рисовать непрямоугольные шестиугольники, и это было бы особенно хорошо с фоновой акриловой прозрачностью в новом терминале Windows.

Тестирование с использованием WSL с Ubuntu, например, в mlterm такие изображения правильно отображаются как имеющие маску прозрачности, а цвет фона сохраняется, в то время как в xterm -ti vt340 нетронутые пиксели отображаются черным, даже если фон белый, что кажется подразумевают, что они визуализируют шесть элементов на растровом изображении памяти, инициализированном как черный, без маски прозрачности или альфы, прежде чем переносить их в окно терминала.

Хм. VT340, находящийся передо мной, учитывает параметр P2 в DCS P1; П2 ; Р3 ; последовательность q, которая инициирует последовательность SIXEL. Xterm, с другой стороны, похоже, игнорирует это. Но если вы используете последовательность растровых атрибутов (« Pan ; Pad ; Ph ; Pv ) и задаете для нее высоту и ширину, фон очистится, и вы получите черный пиксель.

я думал о том, чтобы получить бесплатную пробную версию эмулятора twin и проверить, как его поведение отличается от VT340 и Xterm, действующего как VT340.

Но... +1 за идею поддержки SIXEL в целом и +10 за идею проведения тестов на совместимость.

Мы могли бы добавить поддержку протокола встроенных изображений iTerm2, как только мы это сделаем... По крайней мере, его должно быть проще реализовать, ему нужен только путь к изображению, и он делает все сам.

У меня есть одно сомнение в отношении обеих систем: что происходит с выравниванием? Если ширина или высота изображения кратны ширине или высоте символов, все в порядке, но если нет, следует ли добавлять отступы только с нижней и правой сторон или следует центрировать изображение, добавляя отступы со всех сторон?

Привет, вот несколько релевантных ссылок для исследований:

• «Основы хорошего протокола изображения» на terminal-wg (и связанное ранее обсуждение )
• эта массивная ветка о поддержке sixel

Мы могли бы добавить поддержку протокола встроенных изображений iTerm2, как только мы это сделаем... По крайней мере, его должно быть проще реализовать, ему нужен только путь к изображению, и он делает все сам.

Вероятно, это должна быть другая задача. Sixel и ReGIS явно предназначены для внутриполосных графических или символьных данных. Я не говорю, что это плохая идея, я просто говорю, что это следует рассматривать как другую функцию.

У меня есть одно сомнение в отношении обеих систем: что происходит с выравниванием? Если ширина или высота изображения кратны ширине или высоте символов, все в порядке, но если нет, следует ли добавлять отступы только с нижней и правой сторон или следует центрировать изображение, добавляя отступы со всех сторон?

Выравнивание графических данных Sixel и ReGIS описано (плохо) в различных руководствах. Изображения Sixel выравниваются по границам символьных ячеек. Если вам нужна черная рамка вокруг изображения, вы должны добавить эти черные пиксели самостоятельно; нет ничего похожего на поля или отступы HTML. Каждая строка шестизначных данных описывает полосу высотой шесть пикселей. Если вы пытаетесь выровнять данные изображения sixel с текстовыми символами в эмуляторе терминала, это может вызвать разочарование, поскольку программное обеспечение, генерирующее данные sixel, может не знать, сколько пикселей в высоту имеет каждый глиф символа. Если у вас под рукой есть xterm старой школы, вы можете увидеть это, запустив его в режиме vt340, указав разные размеры шрифта (чтобы дать вам разные размеры символьных ячеек), а затем распечатав некоторые данные sixel, которые пытаются выровнять данные изображения с текстом. данные. (Вот простой тестовый файл, который выглядит правильно, когда я указываю серверу шрифтов использовать 96 точек на дюйм и указываю шрифт размером 15 пунктов. Изменение размера шрифта приводит к тому, что изображения все чаще выходят из выравнивания с текстом. https://gist.github. com/OhMeadhbh/3d63f8b8aa4080d4de40586ffff819de )

Оригинальные vt340s не имели этой проблемы, потому что (конечно) вы не могли указать размер шрифта при включении терминала.

Еще одна вещь, которую вы можете увидеть на этом изображении, которая не очень хорошо описана в документации sixel, заключается в том, что печать строки данных sixel устанавливает «виртуальное левое поле» для данных изображения. Если вы делаете моральный эквивалент CR или CRLF, используя символы «$» или «-», следующая строка печатается относительно этого виртуального левого поля, а не реального левого поля с левой стороны терминала.

Надеюсь это поможет.

Наконец-то прокрутил назад, чтобы прочитать это. Извините за запоздалый ответ.

Тестирование с использованием WSL с Ubuntu, например, в mlterm такие изображения правильно отображаются как имеющие маску прозрачности, а цвет фона сохраняется, в то время как в xterm -ti vt340 нетронутые пиксели отображаются черным, даже если фон белый, что кажется подразумевают, что они визуализируют шесть элементов на растровом изображении памяти, инициализированном как черный, без маски прозрачности или альфы, прежде чем переносить их в окно терминала.

Поддерживать прозрачность в xterm не должно быть слишком сложно. Я копался в коде по другим причинам. Я боюсь, что кто-то где-то зависит от такого поведения Xterm, поэтому порекомендовал бы поставить его за флагом совместимости, что также должно быть прямолинейным. Но тогда возникает вопрос о значении по умолчанию. Что должно быть по умолчанию? Черный или прозрачный.

Знаем ли мы, что делали оригинальные модели VT240, 241, 330 и 340? Могу ли я предложить попытаться точно представить опыт реального VT?как поведение по умолчанию? Вы можете проверить это, напечатав перевернутые символы пробела, а затем наложив на них шестигранную графику и посмотрев, какой цвет отображают неуказанные пиксели.

Я не знаю, слишком ли меня волнует, что по умолчанию для терминала msft, пока есть возможность вести себя как Xterm, эмулирующий VT340. Код, который я написал для создания логов через ssh в терминале, предполагает поведение «неуказанные пиксели черные», описанное выше. Мне придется переписать этот код, если мы внесем это изменение.

Если вы пытаетесь выровнять данные изображения sixel с текстовыми символами в эмуляторе терминала, это может вызвать разочарование, поскольку программное обеспечение, генерирующее данные sixel, может не знать, сколько пикселей в высоту имеет каждый глиф символа.

Оригинальные vt340s не имели этой проблемы, потому что (конечно) вы не могли указать размер шрифта при включении терминала.

Есть ли причина, по которой эмулятор терминала не может просто масштабировать изображение, чтобы оно точно соответствовало поведению исходных терминалов DEC? Таким образом, если высота строки на VT340 составляет 20 пикселей, то изображение высотой 200 пикселей должно занимать ровно 10 строк, независимо от размера шрифта. Мне кажется, что это единственный способ сохранить разумную совместимость с устаревшим программным обеспечением, что является своего рода точкой эмулятора терминала.

Я могу понять желание расширить это поведение для рендеринга изображений с более высоким разрешением, но я думаю, что это должно быть необязательным расширением (или просто использовать один из существующих проприетарных форматов). Так что в идеале я бы хотел, чтобы значение по умолчанию для Sixel было как можно ближе к тому, что вы получили бы на реальном терминале DEC.

Привет, вот несколько релевантных ссылок для исследований:
«Основы хорошего протокола изображения» на terminal-wg

Sixel не работает, потому что он не может поддерживаться tmux с параллельными панелями.

Это потребовало некоторой работы (на самом деле много работы ), но с sixel можно выполнить почти все трюки с «изображениями в терминале», которые можно изобразить:

• Многослойные изображения с масками для каждой ячейки в терминале: https://jexer.sourceforge.io/images/sixel_many_images.png

• Плавающее (мультиплексированное) окно терминала в терминале, который использует sixel для поддержки двойной ширины в стиле VT100: https://jexer.sourceforge.io/screenshots/jexer_sixel_in_sixel.png

• Мозаичные терминалы в стиле tmux с изображениями: https://gitlab.com/klamonte/jexer/-/wikis/uploads/7603381f82414ef9ae214bfcf759c064/example_tilingwm2_1.png

• Сеанс общего терминала с несколькими заголовками с разными размерами текстовых ячеек, показывающий один и тот же график: https://jexer.sourceforge.io/screenshots/multiscreen_2b.png

• Использование sixel для рендеринга CJK и эмодзи, которых нет в шрифте основного терминала: https://jexer.sourceforge.io/screenshots/xterm_sixel_cjk.png

Я включил некоторые другие замечания в упомянутую ветку "хорошего" протокола , которые могут представлять интерес.

По крайней мере, sixel — хороший трамплин для разработки инфраструктуры смешанных изображений и текста на стороне терминала. Говоря из непосредственного опыта, терминальная сторона (хранение/отображение изображений) примерно на 1/4 сложнее, чем сторона мультиплексора/приложения (tmux/mc и др.).

sixels действительно являются идеальным решением для внутриполосной графики (например, через ssh): поскольку они поддерживаются многими существующими инструментами, они готовы к использованию для практических целей , таких как отображение проблем синхронизации временных меток на ходу.

Как проиллюстрировано therealkenc и далее объяснено klamonte в 640292222, все можно обработать с помощью sixels, даже изображения рядом, но это требует некоторой работы.

Некоторое время назад я работал с несколькими другими людьми над резервным режимом для tmux, используя расширенную графику Unicode для представления изображений sixel в терминалах, которые не поддерживают sixel.

Это немного похоже на автоматизированное искусство ANSII, использующее преимущества специальных блочных символов, которые присутствуют в большинстве шрифтов: это эквивалентное цветовое представление Unicode может быть заменено на sixel, а затем перезаписано реальным изображением sixel (или нет!). Это также решило бы проблему сохранения всех изображений sixel для прокрутки назад, заменив их низкокачественными заполнителями Unicode (например, для экономии памяти) и имея заполнители для изображений sixel, когда они не могут отображаться по какой-либо причине.

Код был общественным достоянием. Его можно было бы сразу же использовать в качестве первого шага к поддержке sixel:

• определить, когда передается последовательность sixels, а затем вычислить замену текста Unicode

• отобразить эту последовательность юникода, которая уже поддерживается терминалом Windows

• позже, когда будут реализованы sixels, визуализируйте поверх последовательности sixel.

Вам было бы интересно?

Кстати, я узнаю здесь свои знакомые графики gnuplot x^2 sin и 10 sin(x) . Я рад, что это вдохновило меня 😄

Пожалуйста.

@DHowett Является ли acac350 первым шагом к реальному рендерингу графики sixel? Я получаю запросы на поддержку sixel в Microsoft Terminal от людей, использующих ssh и желающих просматривать каталоги изображений с помощью моей программы lsix .

Сорта. Теперь у нас есть возможность обрабатывать входящие последовательности DCS. Мы еще не подключили никаких обработчиков, но иметь для этого инфраструктуру было очень важно. :улыбка:

Вот некоторые обновления. У меня есть рабочая ветка здесь . Ранний скриншот выглядит так:

Вопреки тому, что я изначально думал, самой сложной частью рендеринга изображений sixel на самом деле является слой conpty. Изображения Sixel должны быть встроенными объектами. Рендеринг изображений sixel зависит от размера рендеринга персонажа. Однако из-за дополнительного содержательного слоя мы фактически не можем получить размер рендеринга символа при обработке шестизначных последовательностей. Это звучит очень абстрактно и расплывчато. Любой, кто заинтересован в этом, может проверить мою ветку и посмотреть, как это делается.

В целом, слой conpty очень затрудняет прокрутку и изменение размера изображений sixel. В моей ветке работает, если нужно только отобразить. Но и прокрутка, и изменение размера полностью сломаны.

Еще не смотрел, но можно ли использовать сквозной режим для реализации в самом Терминале? Я бы все равно добавил его в OpenConsole, но похоже, что совместное использование кода невозможно. Поскольку Windows Terminal в какой-то момент необходимо отделить от OpenConsole, лучше всего просто продублировать код для обоих. Кроме того, вы основываете это на своих и j4james PR для параметров? Это, наверное, тоже помогло бы.

@WSLUser Спасибо за внимание. Этот скриншот на самом деле сделан около месяца назад, когда фантастических параметров PR от j4james еще не существовало. Моя работа полностью находится внутри Windows Terminal, а не в conhost. Я показал этот PR команде консоли и с тех пор добился определенного прогресса. Но я застрял из-за проблемы с conpty.

Да, я бы перебазировал мастер и добавил https://github.com/microsoft/terminal/pull/7578 и https://github.com/microsoft/terminal/pull/7799. Оттуда, возможно, посмотрите, чего не хватает в ConPTY для сквозного режима. Интересно, Mintty использует сквозной режим для режима ConPTY.

Интересно, Mintty использует сквозной режим для режима ConPTY.

Почти уверен, что mintty вообще не использует conpty 😜

Хитрость здесь с conpty заключается в том, что консоли (conpty) необходимо знать о ячейках, которые заполнены содержимым sixel, чтобы случайно не удалить это содержимое из подключенного терминала. Возможно, conpty можно было бы просветить, чтобы игнорировать закрашивание ячеек с большой графикой и просто предположить, что подключенный Терминал оставит эти ячейки в покое.

Это может испортить некоторые из наших оптимизаций (например, мы не можем стереть строки с данными sixel), но это может быть достаточно хорошим началом.

\

Возможно, conpty можно было бы просветить, чтобы игнорировать закрашивание ячеек с большой графикой и просто предположить, что подключенный Терминал оставит эти ячейки в покое.

Это тоже был мой первоначальный план, и это вполне может быть лучшим решением с текущей архитектурой conpty, но есть ряд сложностей.

1. Как это будет взаимодействовать с потоковой передачей DCS (я не думаю, что у нас пока есть решение). Я предполагаю, что нам понадобится какая-то концепция разделенного потока, которая пропускала бы поток байтов через conpty одновременно с его отправкой в ​​буфер conhost, но похоже, что это добавит много ненужных накладных расходов в процесс.
2. Это будет работать только в том случае, если вы знаете размер ячейки терминала в пикселях. Я уже упоминал ранее, что считаю, что лучшим решением для Sixel является согласование размера ячейки с исходными терминалами VT, и если бы мы делали это, это не было бы проблемой. Однако, насколько мне известно, никакие другие эмуляторы терминала этого не делают, поэтому ни с кем другим это не сработает.

Вторая проблема , поднятая @j4james , становится еще более сложной с учетом разных шрифтов, разного размера шрифта и изменения размера шрифта. В общем, я думаю, что есть 3 аспекта проблемы:

• Во-первых, conpty должен знать о ячейках, которые заполнены содержимым sixel. Без этого резервный буфер в conpty и буфер рисования в WT неизбежно будут рассинхронизированы.
• Для этого conpty необходимо знать размер ячейки в пикселях в контексте рисования, который обрабатывается слоем рисования в WT. Существует огромный разрыв между conpty и фактическим DXRenderer, что делает эту задачу сложной.
• Кроме того, при изменении шрифта или размера шрифта, в идеале, шестигранное изображение должно измениться соответственно.
• И, наконец, займитесь другими вещами, такими как панель, альтернативный буфер, дифференциальное рисование, прокрутка и т. д.

Вторая проблема , поднятая @j4james , становится еще более сложной с учетом разных шрифтов, разного размера шрифта и изменения размера шрифта. В общем, я думаю, что есть 3 аспекта проблемы:

Просто чтобы внести ясность, моя точка зрения заключалась в том, что все это не было бы проблемой, если бы мы точно соответствовали поведению VT340, поэтому изображение размером 10x20 пикселей занимало бы ровно одну символьную ячейку, независимо от размера шрифта. Это проблема только в том случае, если мы хотим соответствовать поведению других эмуляторов терминала, и этот вариант всегда можно оставить на потом. С этим подходом все равно будут сложности, но я лично думаю, что они не вызывают беспокойства.

Меня больше беспокоит то, что вы, кажется, игнорируете проблему потоковой передачи DCS, которая, как я ожидаю, может коренным образом изменить архитектуру решения. Шаги, которые я хотел бы видеть: 1. Решение #7316; 2. Согласовать решение по размеру ячейки в пикселях; 3. Заставить что-то работать в конхосте; 4. Как только все сложности будут проработаны в conhost, только тогда подумайте, как мы заставим его работать над conpty.

Извините, что оставил проблему потоковой передачи DCS. В моей текущей реализации я просто сохраняю всю строку и передаю ее движку. Это приводит к проблемам с производительностью, когда последовательность больше. Но, по крайней мере, это работает. Так что мои комментарии выше во многом основаны на этом.

Но вы правы. Проблема потоковой передачи DCS на самом деле является главным приоритетом, если кто-то еще хочет замарать руки на этом.

获取 Outlook для iOS https://aka.ms/o0ukef

Согласно обсуждению в https://github.com/microsoft/terminal/issues/57 , я думал, что conpty вообще не заботится о шрифтах?

Что касается изменения размера, я думаю, что наиболее естественный способ сделать это - «привязать» изображение к символьным ячейкам после того, как изображение будет получено, и пересчитать размер изображения на основе геометрии привязки. Все остальное вызовет несоответствие между изображениями и символьными ячейками.

@ятли Да. Это также делает проблему сложной.

Изображение размером 10x20 пикселей будет занимать ровно одну символьную ячейку.

К сожалению, это неправильно, по крайней мере, для моих текущих настроек шрифта.

Поправьте меня, если я ошибаюсь, но для идеального отображения изображения в пикселях, я думаю, нам нужно позаботиться о шрифтах.

@skyline75489, пожалуйста, посмотрите мой обновленный комментарий о «якоре».

Структура данных ячейки должна быть обновлена ​​как char | sixel anchor

Якорь sixel должен содержать информацию о:

• Указатель на объект изображения
• Область символьной ячейки, которую он занимает, в числах с плавающей запятой (например, 5,2 строки x 7,8 столбца)

Это хорошая идея, но детали реализации убивали меня из-за дополнительного перевода в слое conpty. Чтобы не рассылать спам по электронной почте, свяжитесь со мной в Teams @yatli , если вы заинтересованы.

Изображение размером 10x20 пикселей будет занимать ровно одну символьную ячейку.

К сожалению, это неправильно, по крайней мере, для моих текущих настроек шрифта.

Я предлагаю вам сделать это так. Если вы создадите изображение размером 10x20 пикселей и выведете его на реальный терминал DEC VT320, оно займет ровно один символ (по крайней мере, в режиме 80 столбцов). Так что, если мы пытаемся эмулировать этот терминал, мы должны делать то же самое. Если ваш текущий шрифт имеет размер 30x60, вам необходимо увеличить масштаб изображения. Если ваш шрифт меньше, вы уменьшаете изображение.

Это гарантирует, что вы можете вывести изображение Sixel с любым размером шрифта и всегда получать один и тот же макет. Если вы хотите, чтобы оно покрывало определенную область экрана, или вы хотите нарисовать вокруг него рамку с текстовыми символами, вы точно знаете, сколько места займет изображение.

Поправьте меня, если я ошибаюсь, но для идеального отображения изображения в пикселях, я думаю, нам нужно позаботиться о шрифтах.

Это правда, что таким образом вы не получите изображения с идеальной точностью до пикселя, но я не думаю, что это должно быть основной целью. Многие современные компьютеры имеют дисплеи с высоким разрешением, где изображения масштабируются обычным образом, так что это не похоже на странную концепцию. И если мы хотим, чтобы макет оставался согласованным, когда пользователь меняет размер шрифта, нам в любом случае придется масштабировать изображение в какой-то момент, поэтому вы можете сделать это с самого начала и получить все преимущества предсказуемого размер.

И, конечно же, другим преимуществом такого подхода является то, что его можно реально реализовать поверх conpty. Я не понимаю, как вы можете заставить conpty работать, если область, занимаемая изображением, зависит от размера шрифта, который вы не можете знать.

Я не собираюсь делать вид, что у этого подхода нет недостатков, но я думаю, что плюсы перевешивают минусы.

Что делать, если шрифт имеет соотношение сторон, отличное от 10:20?

Что делать, если шрифт имеет соотношение сторон, отличное от 10:20?

Могу ли я предложить прочитать это длинное и несколько «жестокое» обсуждение общих проблем, связанных с встроенными изображениями в эмуляторах терминала .

Это может дать вам общее представление.

С наилучшими пожеланиями

Что делать, если шрифт имеет соотношение сторон, отличное от 10:20?

Изображение может быть немного растянутым или сжатым, но я не думаю, что это конец света.

Позвольте мне продемонстрировать на реальном примере. Представьте, что я злодей из Бонда, и у меня есть старая система безопасности, использующая VT340 в качестве внешнего интерфейса. Сейчас из-за коронавируса я нахожусь в изоляции и работаю из дома, поэтому я вхожу в систему удаленно с помощью Windows Terminal. Если мы точно подойдем к VT340, это не проблема — терминал выглядит так:

Но, возможно, я предпочитаю шрифты со странным соотношением сторон. Итак, давайте посмотрим, как это будет выглядеть с _Miriam Fixed_, которая шире большинства. Образ Бонда теперь выглядит немного сплюснутым, но его по-прежнему легко узнать.

В качестве альтернативы можно было бы использовать идеальное изображение с точностью до пикселя (в настоящее время это невозможно с conpty, но давайте притворимся на секунду). Бонд больше не выглядит сплющенным, но теперь изображение лишь в несколько раз меньше, чем ожидалось. И чем выше разрешение вашего монитора, тем хуже это будет выглядеть.

Возможно, это вопрос личных предпочтений, но я точно знаю, что предпочел бы вариант 1 варианту 2.

Также обратите внимание, что нет никаких причин, по которым у нас не могло бы быть опций для настройки точного поведения, когда соотношение сторон шрифта не равно 1: 2. Одним из вариантов может быть центрирование изображения в ячейках, которые оно должно занимать. Или мы могли бы расширить изображение так, чтобы оно покрывало всю область, но обрезать края, выходящие за границы. На мой взгляд, любой из этих вариантов будет лучше, чем точный пиксельный рендеринг.

Возможно, это вопрос личных предпочтений, но я точно знаю, что предпочел бы вариант 1 варианту 2.

Я тоже, только лучше знать, что шрифт имеет другое соотношение сторон, чтобы изображение могло подстроиться и сохранить правильное.

Одним из вариантов может быть центрирование изображения в ячейках, которые оно должно занимать. Или мы могли бы расширить изображение так, чтобы оно покрывало всю область, но обрезать края, выходящие за границы.

Я думаю, что лучше их центрировать.

Может я плохо читаю эту тему. Мы на самом деле говорим о том, что терминал подделывает символы 10:20 для изображения sixel? Я думаю, что это вызовет много проблем, таких как искажение Бонда. Сделать это правильно может быть сложнее, но, по моему скромному мнению, современный терминал должен быть независимым от шрифтов и оставлять на усмотрение программистов работу с шестерками и символьными ячейками.

Используя управляющие последовательности, запускаемая пользователем программа может определить размер ячейки символа в пикселях и решить, как разумно справиться с искажением для этого приложения. Программа просмотра изображений, которую я использую, работает именно так. Когда я меняю семейство или размер шрифта, отображаемая миниатюра всегда обновляется, и ее высота всегда составляет ровно пять строк текста. Ширина масштабируется пропорционально изображению, если только она не будет больше определенного (в данном случае достаточно большого) максимума. Основываясь на размере изображения на символьной ячейке, он автоматически работает на экранах с высоким разрешением.

В то время как VT340 является благородной целью для подражания, фиксация разрешения ячеек символов на уровне 10:20 (и, таким образом, ограничение разрешения для всего экрана) является ошибкой. VT340 был лишь одной из нескольких реализаций sixel, поэтому его размер шрифта не обязательно является более правильным.

Форсирование 10:20 также приведет к уродливым кладжам. (Например, как ответить на запрос размера окна терминала в пикселях. Сказать правду, предполагая, что они будут располагать окна на экране? Или всегда возвращать 800x480, предполагая, что пользователь масштабирует изображения для вывода sixel? )

Мы на самом деле говорим о том, что терминал подделывает символы 10:20 для изображения sixel?

да.

современный терминал не должен зависеть от шрифта

Это предложение не зависит от шрифта. Приложению не нужно ничего знать о шрифте. В этом весь смысл.

Используя управляющие последовательности, запускаемая пользователем программа может определить размер ячейки символа в пикселях и решить, как разумно справиться с искажением для этого приложения.

Я не совсем уверен, какой метод вы используете, но я видел, как это делалось раньше, с помощью проприетарного запроса XTerm для получения размера окна в пикселях и другого запроса для получения размера ячейки окна, а затем с использованием этого данные для расчета фактического размера ячейки в пикселях. Минусами такого подхода являются:

1. Он проприетарный, поэтому не будет работать на реальном терминале или любом эмуляторе терминала, который точно соответствует реальному терминалу.
2. Если пользователь изменит размер своего шрифта во время работы вашего приложения, ваши расчеты больше не будут правильными, и изображения будут отображаться с неправильным размером (если вы не постоянно пересчитываете размер шрифта, что кажется нецелесообразным).
3. Если у пользователя дисплей с высоким разрешением и/или большой размер шрифта, вам придется отправить большое изображение, чтобы попытаться соответствовать этому разрешению. Учитывая, насколько неэффективен Sixel с самого начала, это может привести к большой пропускной способности.

Тем не менее, я понимаю, что это режим, который некоторые люди могут захотеть использовать, и я думаю, что у нас должна быть хотя бы возможность поддерживать его однажды (по причинам, описанным выше, это просто невозможно в данный момент). Но на мой взгляд, это не лучший подход для Sixel.

У меня есть более 300 VT340 на атомных электростанциях, которые я хотел бы в конечном итоге
заменять.

Есть коммерческие пакеты эмуляции терминала, которые мы могли бы использовать, но я думаю
все, кроме одного, были EoL'd.

Мы заменили некоторые из них компьютерами с Linux, работающими под управлением XTerm (или менее
часто Win10 + Hummingbird + WSL с XTerm), поскольку он имеет
наполовину приличная реализация sixel с открытым исходным кодом и вроде как плохая, но
реализация ReGIS с открытым исходным кодом.

Вероятность того, что мы будем писать новое программное обеспечение для части этого
система, генерирующая поток из шести октетов, имеет значение NIL.

Если вашей целью является отправка графики через встроенный поток октетов,
есть другие варианты. Но если вы хотите поддерживать графику sixel, вам следует
поддерживать графику sixel, наполовину похожую на предыдущую
реализации. Это, к сожалению, означает, что вы должны подражать
поведение образцовых систем (т.е. VT240, VT241, VT330 и VT340
терминалы) даже когда речь идет об интеграции графики с текстом.

Это макет того, о чем я говорю. было бы очень
хорошо, если какая-либо новая реализация Sixel поддерживает совместимость с существующими
реализации, чтобы изображения не выходили за края экрана или только
заполнить половину экрана.

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

современный терминал не должен зависеть от шрифта

Это предложение не зависит от шрифта. Приложению не нужно ничего знать о шрифте. В этом весь смысл.

Я имел в виду, что _terminal_ должен быть независимым от шрифта, а не навязывать 10:20 для каждого шрифта. Приложение должно иметь возможность узнать фактический размер шрифта, если оно того пожелает, так как это приложение знает область того, что оно пытается показать, и может определить лучший способ представления текста и графики вместе.

Используя управляющие последовательности, запускаемая пользователем программа может определить размер ячейки символа в пикселях и решить, как разумно справиться с искажением для этого приложения.

Я не совсем уверен, какой метод вы используете, но я видел, как это делалось раньше, с помощью проприетарного запроса XTerm для получения размера окна в пикселях и другого запроса для получения размера ячейки окна, а затем с использованием этого данные для расчета фактического размера ячейки в пикселях.

Ага, примерно так. Существует также запрос для прямого получения размера символьной ячейки, но я не думаю, что он так широко поддерживается, как просто получение размера экрана и деление на СТРОКИ и СТОЛБЦЫ.

Минусами такого подхода являются:

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

Это не недостаток. Это всего лишь означает, что программа должна вернуться к тому, что она сделала бы в любом случае: предположим, $TERM=="VT340" означает, что символьные ячейки равны 10:20, "VT240" означает 10:10, "mskermit" означает 8:8, и так далее.

Кроме того, это не собственная последовательность xterm. Получение размера экрана называется escape-последовательностью "dtterm", но на самом деле она была впервые реализована в SunView (SunOS, 1986). Я полагаю, что позже это было задокументировано в Руководстве по программированию PHIGS (1992). Попробуйте отправить "\e[14t" на несколько эмуляторов терминала, и вы увидите, что это широко реализовано.

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

Это не проблема. Программа просто перехватывает SIGWINCH и пересчитывает только в том случае, если окно действительно изменилось.

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

Да, sixel крайне неэффективен. Но на современных компьютерах отправка полноэкранных изображений вполне пригодна даже по ssh. Есть ли у терминала Microsoft какое-то ограничение скорости передачи данных?

Кстати, я считаю, что у sixel есть режим «высокого разрешения», в котором каждая точка удваивается по ширине и высоте. Я никогда не использовал его, и я не думаю, что xterm даже реализует его, но, возможно, это уменьшит опасения по поводу пропускной способности.

Тем не менее, я понимаю, что это режим, который некоторые люди могут захотеть использовать, и я думаю, что у нас должна быть хотя бы возможность поддерживать его однажды (по причинам, описанным выше, это просто невозможно в данный момент).

Этот «режим» просто выравнивает символы и графику, как это делали различные исторические терминалы sixel и современные эмуляторы. Признаюсь, я не понимаю, почему нельзя сделать то же самое в Microsoft Terminal. Если вы скажете, что этот кладж 10:20 — лучшее, что можно сделать, я поверю, что вы правы, и поблагодарю вас за это. Искаженное изображение намного лучше, чем ничего.

Используя управляющие последовательности, запускаемая пользователем программа может определить размер ячейки символа в пикселях и решить, как разумно справиться с искажением для этого приложения.

@hackerb9 , какая на самом деле escape-последовательность для получения размеров шрифта?

Соответствующие последовательности XTerm можно найти здесь: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html — ищите XTWINOPS.

Кроме того, в Unix вы обычно можете получить внутренний размер терминала в пикселях вместе с размером ячейки, используя TIOCGWINSZ ioctl. С openssh это работает и удаленно.

Как точка данных, ветка sixel для libvte использует маршрут, не зависящий от размера ячейки, о котором говорит @hackerb9 . Он обрабатывает входящие данные sixel как «идеальные до пикселя» и масштабирует ранее полученные изображения с учетом уровней масштабирования и размеров шрифта, чтобы покрыть согласованный размер ячейки. После слияния эта реализация будет доступна для большей части эмуляторов терминалов Linux, включая терминал GNOME, терминал XFCE, Terminator и т. д. На первый взгляд кажется, что это совместимо, по крайней мере, с XTerm и mlterm.

Поскольку libvte записывает размер виртуальной ячейки для каждого изображения, было бы тривиально заставить эту работу работать с фиксированным размером виртуальной ячейки 10x20 для взаимодействия. Однако нам нужен способ, чтобы программы могли сообщать терминалу ожидаемое соотношение пикселей и ячеек (например, путем расширения параметров DCS). В общем, это может быть очень полезно, так как это также обеспечит форму контроля плотности пикселей в средах с ограниченной пропускной способностью, как вы упомянули выше.

Кроме того, в Unix вы обычно можете получить внутренний размер терминала в пикселях вместе с размером ячейки, используя TIOCGWINSZ ioctl. С openssh это работает и удаленно.

Консоль Linux всегда возвращает 0 ... они должны это исправить, но, похоже, тоже не хотят :-/