Таблица GSUB широко заполнена в шрифтах TrueType?

Question

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

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

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

Answer 1

Неверно утверждать, что шрифт OpenType - это полностью автономная программа для набора текста, и что «формирователь текста получает только« выполнение в соответствии с инструкциями шрифта »». Специально для таких скриптов, как Arabi c или Devanagari, существует очень важная логика c, общая для всех шрифтов, которая реализована в формирователе текста.

Смысл в том, что поддержка чего-то вроде Arabi c не поддерживается все так же просто, как реализовать logi c для анализа таблиц GSUB и GPOS и применения поиска (действий) внутри. Это определенно не маленькое начинание, и я, конечно, буду искать существующие реализации для повторного использования.

Вы упоминаете, что решили не использовать Harfbuzz. Я рекомендую вам пересмотреть это.

Что мне неясно, так это то, насколько надежной можно считать таблицу GSUB. Другими словами, разумно ли ожидать, что, например, шрифт Arabi c должен содержать заполненную таблицу GSUB, содержащую замены, необходимые для сценария Arabi c?

Абсолютно! Шрифт Arabi c должен иметь таблицы 'GSUB', 'GPOS' и 'GDEF', чтобы правильно отображать текст Arabi c. Замена на сценарий / на несколько шрифтов невозможна, в принципе, не говоря уже о практике.

Некоторые ресурсы могут оказаться полезными - некоторые старые (сайт MS Typography был переиздан, поэтому даты - страницы не всегда) отражать первоначальную дату публикации), но содержание по-прежнему актуально. И хотя на Windows можно ссылаться, это относится к любому механизму компоновки OpenType.

• [Windows Обработка глифа для шрифтов OpenType, часть 1] (https://docs.microsoft.com/en-us/typography/opentype/processing-part1]
• Windows Обработка глифа для шрифтов OpenType, часть 2
• OpenType Spe c, Advanced Typographi c Расширения - OpenType Layout
  • Примечание: Это (к сожалению) не вызывает особой роли формирования движков.
• Разработка шрифтов OpenType для Arabi c Script
  • Это один скрипт-специфический c topi c, относящийся к Arabi c. Обратите внимание, в частности, на то, что нужно движку Arabi c для шейпинга делать.

Answer 2

Современный файл шрифтов OpenType фактически является полностью автономной программой для набора текста, и шейперу текста удается «выполнять все как указано шрифтом» (даже если для этого требуется целая куча сложностей со стороны шейпера), и так что есть предварительно запеченный список правил GSUB, которые связаны с формирователями, к которым обращаются за пределами того, что указывает шрифт.

Думайте о шрифте как об игре: пока вам нужен хороший эмулятор (текстовый формирователь), чтобы правильно Запустите игру (шрифт), и задача эмулятора - убедиться, что все сложные биты, такие как блиттинг, перестановка памяти и т. д. c. выполняется в нужное время, игра определяет, что произойдет. Аналогично, хороший формирователь текста будет иметь все (сложные) логики c для того, как интерпретировать данные OpenType и как обрабатывать их, в каком порядке, за сколько проходов и т. Д. c. но эти данные только из шрифта и больше нигде.

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

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

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