Xterm.js: Поддержка лигатур шрифтов

Я думаю, что нас не интересуют обычные лигатуры (на самом деле, было бы плохо включать лигатуры для li и т.п.), но для таких вещей, как == , !== , => и так далее. Вот хороший список лигатур, поддерживаемых моноширинным шрифтом fira code:
https://github.com/tonsky/FiraCode/blob/master/showcases/all_ligatures.png

Что будет, если половина лигатуры будет другого цвета? Как бы вы с этим справились?

@LoganDark работает ли это даже с обычными лигатурами? Или они разделены, когда они разного цвета?

Нет и нет.

Интересно, можно ли вытащить код рендеринга из txtjs, поскольку они выяснили, как рендерить лигатуры, хотя я думаю, что они вручную рисуют текст. http://txtjs.com/examples/Text/ligatures.html

@devsnek Я не думаю, что проблема заключается в визуализации текста. Проблема заключается в том, чтобы знать, какие символы соединяются, чтобы их можно было нарисовать вместе (в настоящее время «==» отображается как «=» и «=», а не «==»).

@Tyriar не

@devsnek: да, но каждая ячейка в сетке рисуется индивидуально, за некоторыми исключениями (смайлы, широкие символы Unicode). Лигатуры нужно как-то включать в этот список. Посмотрите https://github.com/sourcelair/xterm.js/pull/938 для получения дополнительной информации.

@devsnek ЭТО ТЫ

отказ от ответственности: полностью не по теме, просто случайный комментарий

@LoganDark работает ли это даже с обычными лигатурами? Или они разделены, когда они разного цвета?

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

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

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

Разноцветные лигатуры @LoganDark выглядели бы странно, и не было бы четкого способа их раскрасить, ИМО.

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

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

Теперь, когда Hyper выпустила стабильную версию 2.0.0, возможно, обходные пути лигатуры нуждаются в более высоком приоритете.

ссылка https://github.com/zeit/hyper/issues/914#issuecomment -361034148

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

1. Сопоставьте выбранное семейство шрифтов с файлом / буфером, содержащим фактические данные шрифта (otf / ttf / woff / etc)
2. Проанализируйте данные из таблицы GSUB шрифта и преобразуйте их в разумный набор правил для замены глифов.
3. Передайте какую-то карту или функцию сопоставления в xterm, чтобы определить, что отображать для данной последовательности символов

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

• Я не могу найти способ получить данные шрифта с помощью API-интерфейсов браузера, поэтому это не будет работать как прямая функция xterm.js, но, скорее всего, как отдельный пакет / расширение с крючком, предоставляемым xterm.js

• Сопоставление CSS font-family имени шрифта с его файлом шрифта в Windows болезненно, но кажется выполнимым. Пока что единственный способ, который я нашел, - это получить все в %WINDIR%\Fonts и проанализировать каждый найденный файл (спойлер: это очень медленно). Еще не пробовал другие платформы. (Примечание: я также попытался извлечь имя из реестра, но для некоторых шрифтов, например, шрифтов ботаников, имена не совпадают. Они используют «предпочтительное» семейство и подсемейство, которые не указаны в имени реестра. но используется в css font-family . Если вам интересно, ключ реестра находится в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts )

• Существует библиотека под названием opentype.js, которая выполняет полный анализ таблиц шрифтов OpenType и даже имеет функцию font.stringToGlyphs(str) которая обрабатывает основные лигатуры, но лигатуры для кода Fira (и несколько, если не все другие распространенные лигатурные шрифты) используйте функцию, называемую контекстными альтернативами, которая еще не поддерживается opentype.js (указана в разделе « Запланировано» ). Необходимая таблица GSUB анализируется для вас в JSON, поэтому теоретически все, что не хватает, - это интерпретация данных таблицы.

• Лигатуры Fira Code (и, я думаю, другие) фактически заменяют исходные глифы равным количеством глифов, а не одним очень широким (для сохранения свойств моноширинного шрифта). Для такой строки, как ==> , шрифт в конечном итоге скажет вам заменить его двумя символами «LIG» (по сути, пустым пространством), за которыми следует фактический глиф для лигатуры, который технически все еще является одним моноширинным широкий характер. Несмотря на то, что он якобы имеет одну ширину, путь последнего символа выходит за пределы левой стороны ограничивающего прямоугольника персонажа, чтобы покрыть пространство, занимаемое двумя символами LIG перед ним. См. Наглядное изображение ниже (0 и 600 - стороны рамки персонажа). Я не знаю, усложняет ли это задачу рендерера или его нужно будет преобразовать перед передачей в xterm.js, но кое-что нужно знать.

• Еще одна проблема - это определение того, когда следует повторно оценить лигатуру. Например, если я наберу = четыре раза подряд, желаемое поведение будет заключаться в том, чтобы я увидел одно равенство, затем двойное равенство лигатуры, затем тройное равенство лигатуры, затем четыре отдельных знака равенства. На самом деле есть сопоставления в правилах контекстных альтернатив для очистки лигатуры (то есть, если текущий ввод - '=', а предыдущие три символа - '===', не переназначайте его вообще), но мы бы получили чтобы выяснить, как применять эти правила.

• OpenType сложен. По общему признанию, я не эксперт по рендерингу шрифтов, но количество возможных вариантов, которые приводят к различным типам рендеринга, довольно обширно. Я думаю, что без встроенной библиотеки, которая выполняет отображение за нас, наиболее разумный способ атаковать это постепенно. Fira Code специально использует Chaining Context Substitution Format 3 , но я уверен, что есть и другие популярные шрифты, в которых используются другие. Поскольку у каждого из них немного разная семантика, вероятно, имеет смысл начать с одного и двигаться дальше.

@princjef Спасибо, что поделились своими исследованиями, действительно, очень полезно! Пару дней назад я тоже размышлял над этой темой и пришел к следующему выводу:

• Обнаружение лигатур в веб-шрифтах с использованием встроенного API кажется невозможным (как вы описываете)
• Есть определенные лигатуры, которые не имеют смысла в терминале, даже если шрифт поддерживает их (например, li )
• Существует очень небольшое подмножество лигатур, которые имеют смысл поддерживать, а именно большинство лигатур Fira Code.
• Добавление поддержки для рисования и очистки символа, который занимает несколько ячеек, очень сложно реализовать с помощью нашего текущего подхода к визуализации на основе одного символа (CharAtlas).

TBH, я не думаю, что стоит прилагать усилия для поддержки лигатур в текущем состоянии 😔

@mofux Я на самом деле думаю, что нашел (несколько приятный) способ получить лигатуры для рендеринга в xterm.js, подойдя к нему под другим углом. Я как-то пропустил тот холст, который будет автоматически отображать лигатуры для вас в моих первоначальных исследованиях. Поддержка лигатур сводится к тому, чтобы соответствующие символы отображались вместе.

С этой целью я настроил средство визуализации текста, чтобы отображать символы с одинаковыми атрибутами (fg, bg и т. Д.) Как единую группу. Это не совсем точно отобразит все лигатуры (и может отобразить некоторые, которых не должно быть), но он должен отобразить лигатуру везде, где кто-то ожидал бы ее увидеть. Вот скриншот NeoVIM в демонстрационном приложении с использованием кода Fira (показан в Firefox, также работает в Chrome, но не в Edge):

Филиал здесь, если люди хотят взглянуть: https://github.com/princjef/xterm.js/tree/ligature-support

Пара замечаний по этому поводу:

• Я не проводил никаких тестов, но держу пари, что это не будет хорошо для производительности. Группируя все символы одного стиля вместе, атлас символов в основном выкидывается в окно, даже в тех местах, где нет лигатур (поскольку мы не знаем, где они будут / не будут). Когда я визуализирую несколько символов вместе, я просто устанавливаю код символа на Infinity чтобы избежать кеширования.
• Вероятно, есть некоторые крайние случаи, связанные с шириной символов и перекрытием, с которыми я неправильно разбираюсь. На данный момент это в основном проверка концепции.

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

Сложность заключается в том, что отображение лигатуры зависит не только от символов, замененных лигатурой, но и от их контекста. Например, '=== 1' должен отображать три знака равенства как лигатуру, а '====' должен отображать те же три знака равенства как отдельные символы. Нет никаких ограничений на размер этого контекста, поэтому было бы сложно и, вероятно, подвержено ошибкам определить правила рендеринга лигатуры только по ее выходным данным.

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

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

В вс, 22 апреля 2018 г., 16:21 Джефф Принсипи [email protected] написал:

Сложность в том, что рендеринг лигатуры зависит от
не только на символы, заменяемые лигатурой, но и на их контекст.
Например, '=== 1' должно отображать три знака равенства как лигатуру, но
'====' должно отображать одни и те же три знака равенства как отдельные символы.
Нет ограничений на размер этого контекста, поэтому было бы сложно и
Вероятно, подвержены ошибкам при определении правил визуализации лигатуры
только с его выхода.

Более надежный (но менее переносимый) подход - иметь подсказки о
диапазоны лигатур, предоставляемые отдельной функцией, которая знает шрифт
метаданные. Тогда все, кроме диапазонов, предоставленных внешней функцией
могут быть отображены с использованием атласа, в то время как указанные группы могут использовать
подход, подобный приведенному выше. Определение мест замен
учитывая, что строка текста должна быть довольно быстрой, но есть некоторые проблемы, которые я
подробно описано ранее (в основном скорость / надежность поиска нужного шрифта на
инициализация и сложность обработки контекстных альтернатив OpenType).

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/xtermjs/xterm.js/issues/958#issuecomment-383420281 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAKyryMlayIQijY32GpWBmpvCUi13Wfbks5trRBigaJpZM4PRej6
.

@princjef Вау, за вашими правками так легко следить, и кажется, что xterm может поддерживать лигатуры с помощью средства визуализации. Уловка состоит в том, чтобы просто выяснить, как сопоставить правила. Это вселяет в меня надежду.

@princjef отличное расследование!

Я не могу найти способ получить данные шрифта с помощью API-интерфейсов браузера, поэтому это не будет работать как прямая функция xterm.js, но, скорее всего, как отдельный пакет / расширение с крючком, предоставляемым xterm.js

@princjef Я вижу возможную поддержку лигатур как:

• some-magical-package : Модуль собственного узла извлекает информацию о собственном шрифте, сопоставляя строки веб-шрифтов с файлами, если это возможно. Это можно сделать в AsyncWorker чтобы уменьшить падение производительности. Ничего страшного, если это делается лениво и при первом запуске сканирование и обновление занимает несколько секунд.

• xtermjs/xterm-ligature-support : надстройка, которая зависит от узла и использует some-magical-package для получения и кеширования информации о шрифте. Этот аддон может выполнять сканирование всякий раз, когда в каталоге шрифтов обнаруживаются нераспознанные шрифты, и удалять шрифты при их удалении. Я ожидаю что-то вроде этого как грубый API:

  /** Returns a list of characters to be drawn together */
  export function getLigatures(fontFamily: string): string[] { ... }
  

Есть определенные лигатуры, которые не имеют смысла в терминале, даже если шрифт поддерживает их (например, li)

@mofux Я не уверен, что нам нужно об этом беспокоиться? Если пользователь запрашивает лигатуры, не должны ли мы отображать их все?

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

@mofux Мы должны иметь возможность довольно легко добавить функцию для рисования набора смежных символов вместе.

@princjef : Я не проводил никаких тестов, но скажется на производительности.

@wavebeem : Было бы разумно иметь настройку для включения лигатур, которая записывает на терминал целую строку за раз?

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

Также что касается производительности, я, вероятно, буду работать над добавлением резервной опции рендеринга DOM в ближайшие месяцы, поскольку слишком много вещей, которые могут пойти не так с поддержкой GPU в Chromium. См. Https://github.com/xtermjs/xterm.js/issues/1360. В этом режиме лигатуры будут работать "из коробки".

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

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

@Tyriar Я думаю, что общий дизайн, который вы описали, имеет смысл. Мы _могут_ обойтись тем, что не зависит от нативного кода для поиска шрифтов в some-magical-package , но это определенно будет зависеть от платформы / файловой системы. Я начал играть с синтаксическим анализом замен контекстных альтернатив, но трудно сказать, сколько еще потребуется, чтобы сделать это правильно.

Я также думаю, что нам понадобится немного другой интерфейс, чем some-magical-package :

export function getSubstitutionRanges(fontFamily: string, text: string): Promise<[number, number][]>;

Правила определения самих лигатур сложны и довольно глубоко встроены в сам шрифт. Вместо того, чтобы передавать сами данные шрифта и возлагать бремя их интерпретации на xterm.js, я бы оставил это другой библиотеке, и она сообщала xterm.js, какие символы должны отображаться вместе. Аспекты просмотра вперед / назад в контексте также усложняют синтаксический анализ. Например, «===» соответствует лигатуре, но не в том случае, если за ней следует другой знак равенства.

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

Единственная реальная проблема заключается в применении к нему разнородных стилей.

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

Возможно, нам удастся избежать наказания за то, что не зависит от нативного кода.

👍

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

@princjef это звучит даже лучше, чем меньше xterm.js нужно сделать в этой области, тем лучше.

Единственная реальная проблема заключается в применении к нему разнородных стилей.

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

Со стороны шрифта это выглядит выполнимым. У меня есть код, который успешно анализирует все лигатуры кода Fira и предоставляет правильные диапазоны для комбинирования символов. Если у людей есть еще один или два шрифта, по которым они ищут поддержку, я могу попробовать проверить и их. До сих пор я реализовал только те типы замены, которые мне нужны для кода Fira, поэтому будет приветствоваться некоторое разнообразие для использования других типов замены.

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

@princjef Если вы хотите проверить другие шрифты, я использую Иосевку .

Хорошо, я создал пакет под названием font-ligatures (он же some-magical-package ) и некоторые связанные пакеты, чтобы мы могли эффективно найти правильный шрифт, а затем выяснить, где находятся лигатуры для данного ввода текста.

Некоторое время я потратил на оптимизацию процесса поиска шрифта. На Surface Pro 4 с ~ 150 шрифтами ttf / otf я могу получить метаданные шрифта для всех из них за 300-400 мс. В основном это связано с вводом-выводом, и его можно отбросить на задний план в течение первых нескольких циклов рендеринга, пока он загружается, но он должен быть достаточно быстрым, чтобы загружаться к моменту запуска pty и выдачи некоторого текста. После его загрузки мы можем запустить рендеринг для обновления любого текста, который может уже присутствовать. Это может повторяться всякий раз, когда изменяется шрифт, или мы можем кэшировать полный список в первый раз (я все равно получаю полный список в начале).

Что касается самого сопоставления лигатур, библиотека принимает строку и возвращает метаданные о лигатурах шрифтов, включая группы символов, которые должны отображаться вместе. CI включает тесты для каждой лигатуры в Fira Code, Iosevka и Monoid, поэтому я достаточно уверен, что он правильно обрабатывает выполняемые типы подстановки (хотя я уверен, что есть некоторые шрифты, которые используют другие типы, которые Я не реализовал).

Однако я не тратил времени на оптимизацию / настройку синтаксического анализа лигатур. Я провел несколько быстрых тестов, и похоже, что анализ лигатур занимает 2-20 мс для строки средней длины (читай: 1 строка). Есть еще много возможностей для оптимизации, поэтому сейчас я не особо беспокоюсь. В основном я хотел показать это, чтобы продемонстрировать интерфейс и позволить людям надрать шину, если они хотят.

Выглядит довольно круто @princjef! Что вы думаете о добавлении тестов в код Fira для 0xc0ffee , 0x1234 и 17x32 ? ( x превращается в знак времени на них)

@princjef круто !

Я провел несколько быстрых тестов, и похоже, что анализ лигатур занимает 2-20 мс для строки средней длины (читай: 1 строка)

Не могли бы вы указать мне на критический код, который это проверяет?

@ j-f1 Да, они тоже работают: https://github.com/princjef/font-ligatures/blob/master/src/index.spec.ts#L136 -L137

@Tyriar Я только что добавил базовый тест , с которым можно поиграться. шаблон вызова выглядит как node bench/lines.js <font-name> <input-text> [iterations] . Вы также можете передать многострочную строку или развернуть входной файл для текста, и он будет циклически перемещаться по строкам, чтобы избежать нереалистичных оптимизаций из-за многократного выполнения одного и того же ввода.

Когда я писал это, я заметил, что даже когда я использую несколько разных строк ввода, производительность после первого запуска все равно значительно увеличивается. Для ввода ~ 10 символов я вижу в среднем доли миллисекунды для Иосевки и чуть больше полмиллисекунды для Fira Code. Либо я поражаю особый случай, либо Турбореактивный двигатель творит чудеса. Он по-прежнему недостаточно эффективен, чтобы использовать его как есть, но в следующий раз я сосредоточусь на оптимизации производительности (в этот момент я, вероятно, также добавлю лучший тест, чтобы получить представление об улучшениях).

Пара заметок:

• Из-за того, как работают замены, я ожидаю, что время выполнения будет линейно масштабироваться с размером ввода, хотя я не проверял это
• Из-за количества лигатур и того, как работают замены, Fira Code требует гораздо больших усилий для синтаксического анализа, чем Iosevka или Monoid. Я регулярно вижу, что на создание кода Fira уходит в 5-10 раз больше времени, чем на Иосевку.
• Шрифты без лигатур работают намного быстрее и могут быть дополнительно оптимизированы. Если в шрифте нет контекстных альтернатив, я могу выполнить быстрый выход с пустым набором результатов (или мы можем просто обойти вызов на более высоком уровне).

Я начал отслеживать аспект производительности в проблеме в созданном мной пакете (https://github.com/princjef/font-ligatures/issues/2). Вот начальные числа, скопированные оттуда для нескольких конфигураций (все числа указаны в миллисекундах). Первые пять числовых столбцов относятся к строке ввода, а последние два - к символу. Предпоследний столбец - тот, которому я уделяю больше всего внимания. Я снимаю ~ 0,5 микросекунды на символ (0,0005 в миллисекундах):

ИМЯ | AVG | СТАНДОТКЛОН | 5% | 50% | 95% | AVG (CHAR) | СТАНДОТКЛОН (СИМВОЛ)
----------------------- | ------- | --------- | ------ | -------- | ------- | ------------- | ----------------
Код Fira: code.txt | 5.9570 | 12.6951 | 0,5270 | 5.1020 | 12.2330 | 0.1443531 | 0,2091743
Код Fira: noLigatures.txt | 12.1932 | 3.4402 | 8.1420 | 12.1205 | 15.5900 | 0.1321094 | 0,0334362
Иосевка: code.txt | 0,5571 | 1.4722 | 0,0485 | 0,3215 | 1.6155 | 0,0135005 | 0,0333483
Иосевка: noLigatures.txt | 0,7476 | 0,4230 | 0.4365 | 0.6030 | 1.7725 | 0.0080998 | 0,0044501
Моноид: code.txt | 0.8896 | 1.6637 | 0,0910 | 0,6625 | 1.9225 | 0,0215566 | 0,0482166
Моноид: noLigatures.txt | 1.6661 | 0,6935 | 1.0695 | 1.4450 | 2.6910 | 0.0180521 | 0,0071922
Ubuntu Mono: code.txt | 0,0402 | 0,3935 | 0,0080 | 0,0220 | 0,0605 | 0.0009735 | 0,0090228
Ubuntu Mono: noLigatures.txt | 0,0356 | 0,0644 | 0,0120 | 0,0280 | 0,0805 | 0.0003858 | 0,0006891

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

@Tyriar есть ли у вас предпочтения относительно того, где находится пакет xterm-ligature-support и как он туда попадает?

Похоже, вы думаете, что он должен находиться в xtermjs org (что мне кажется разумным), но у меня нет возможности создавать / отправлять в репозиторий в организации. Вы бы предпочли, чтобы я поместил его в репо под своим пользователем, которое будет перенесено в организацию, или вы хотите создать репо-заглушку, на которое я могу отправить PR?

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

@princjef Я создал https://github.com/xtermjs/xterm-ligature-support и предоставил вам доступ администратора. Я предполагаю, что вы видели, как работают другие аддоны, но это будет первый официальный внешний аддон. Поэтому используйте внутренние надстройки и https://github.com/CoderPad/xterm-webfont в качестве справочника для реализации 😄

Скоро проверю PR

Разместил обновление в репозитории vscode на этом https://github.com/microsoft/vscode/issues/34103 , вот оставшаяся работа, прежде чем мы сможем назвать это закрытым в xterm.js:

• Интегрируйте xtermjs / xterm-addon- ligatures в
• Подключите лигатуры к демонстрации
• Настройте тесты кукловода, которые проверяют на всех средствах визуализации (dom, canvas, webgl), что лигатуры работают.
• Максимально уменьшите зависимости

Всем спасибо за упорный труд! 😄 👍

Могу я спросить, @Tyriar , есть ли планы по поддержке веб-браузера?

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

Спасибо!

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

@Tyriar Спасибо за быстрый ответ!

Это прискорбно, но это было более приятно. Мы рассматриваем электронную версию, так что, возможно, она будет у нас как включенная функция 😄 Спасибо!

Хм, я думаю, это должно быть возможно, используя веб-шрифт и загружая те же файлы шрифтов (urgh) в области JS для извлечения данных лигатуры. Не уверен, что это возможно / стоит ли делать это таким образом, так как удаление лигатуры является довольно большой вмятиной в производительности. Не уверен в использовании памяти, файл шрифта может стать довольно большим, может быть, у @princjef есть некоторые цифры о поведении во время выполнения?

Прошло некоторое время с тех пор, как я изучал это, но я вспомнил, что не было встроенных API-интерфейсов для извлечения необработанной информации о шрифтах в браузере даже для веб-шрифтов.

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

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

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

Даже если извлечение информации о лигатуре было возможно, веб-API использует кодовые точки текста / символов, в то время как лигатуры внутри шрифта используют индексы глифов, зависящие от шрифта, которые нельзя передать непосредственно в веб-API для рисования.

@princjef Спасибо за внимание, это звучит слишком громоздко, имхо не стоит того, что он дает впоследствии.

@khaledhosny Идея заключалась в том, чтобы получить информацию о лигатуре из шрифтов в JS, все еще работая с

Обновите это, я просто объединил аддон лигатур в кодовую базу (https://github.com/xtermjs/xterm.js/pull/2847), он все еще может быть немного сломан, но трудно сказать без настройки интеграционных тестов ( https://github.com/xtermjs/xterm.js/issues/2896).

В настоящее время надстройка работает только в среде выполнения браузера + узла (например, в электронном), я выступил с предложением, которое, как я ожидаю, будет работать только в браузере, которое позволит нам отбросить зависимости узла и перенести это в VS Code (https: / /github.com/microsoft/vscode/issues/34103). Он помечен как "Требуется помощь", если кто-то хочет попробовать https://github.com/xtermjs/xterm.js/issues/2897.

Мы должны изучить возможность использования Font Access API (в настоящее время пробная версия) для надстройки лигатур.

Я использую ttyd, который использует терминал через Интернет и использует xterm.js. как вы видите на картинке ниже, значки загружаются неправильно. они видны в исходном терминале. но в сети они отсутствуют.

@UziTech Ого , выглядит потрясающе! Я думаю, что любая работа, проделанная в этой области, должна быть ориентирована на будущее, чтобы мы могли использовать ее с API доступа к шрифтам.

@UziTech @Tyriar @princjef
Я думаю, что код API доступа к шрифтам можно поместить в пакеты font-ligatures .
После определения того, находится ли процесс в браузере или в узле / электронном, он может решить, вызывать ли API доступа к шрифтам или использовать текущий метод.

Я создал хакерское доказательство концепции и запустил его в демонстрации на моей вилке (ветка localFonts)

Вы можете попробовать его после включения #font-access в chrome://flags (необходимо обновить один раз после разрешения доступа к шрифтам)

Я могу попробовать открыть PR, если вам это нравится.

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

В конечном итоге мы столкнемся с проблемами с этим решением, так как у проектов, которые предназначены только для Интернета, будут проблемы с объединением зависимостей узлов. У меня нет на это ответа, но я также думаю, что мы должны изменить значения по умолчанию (в конечном итоге?) И использовать по умолчанию доступ к шрифту, если обнаружение функции выполнено успешно, в противном случае - откат.

Также отличная работа, чтобы заставить его работать! Это круто 😍

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

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

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

@Tyriar, можем ли мы в обновлением в системе поиска шрифтов?

@UziTech [email protected] должен иметь это, я создал напоминание, чтобы обновить версию для 4.10 https://github.com/xtermjs/xterm.js/issues/3220

Я открыл pr princjef / font-ligatures # 22 как первый шаг к тому, чтобы это сделать.