Широко ли заполнена таблица GSUB шрифтами TrueType?

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

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

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


person Josh Alexander    schedule 23.03.2020    source источник
comment
Таблицы GSUB перемещают глифы (вы не упоминаете об этом, но это не кодовые точки Unicode), поэтому они могут работать только с фактическими глифами в том же самом шрифте. Вся концепция дизайна функций OpenType заключается в том, что они определяются этим шрифтом и исключительно для этого шрифта. Не может быть правила GSUB, которое заменяет глиф на другой, не принадлежащий шрифту. Вместо этого это указывало бы на недопустимый шрифт.   -  person Jongware    schedule 24.03.2020
comment
@Mike'Pomax'Kamermans, спасибо, это действительно помогло прояснить некоторые вещи. Я читал спецификацию, особенно касающуюся данных ScriptList, но в основном это беспокойство возникало из-за того, что я не знал, что входит в настоящую разработку и создание шрифта. Меня удивило, что каждый шрифт во многих случаях должен обеспечивать то, что по сути является дублирующими правилами, поэтому приветствуется, что мне не нужно самому иметь дело с такими глобальными правилами.   -  person Josh Alexander    schedule 24.03.2020
comment
@Mike'Pomax'Kamermans: извините :) Я имел в виду метафизическое перемещение глифов - я имел в виду только внутри шрифта. Действительно, GSUB только заменяет глифы, а GPOS более физически перемещает их.   -  person Jongware    schedule 24.03.2020


Ответы (2)


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

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

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

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

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

person Mike 'Pomax' Kamermans    schedule 24.03.2020
comment
Комментарии выше о том, что GSUB обеспечивает замену глифов и что замены могут выполняться только для глифа в том же шрифте — эти комментарии верны. Однако другие ключевые аспекты в комментариях и в этом ответе неверны. Пожалуйста, посмотрите ответ, который я предоставил. - person Peter Constable; 27.03.2020

Неверно сказать, что шрифт OpenType является полностью автономной программой для набора текста, и что «формирователь текста может только «делать то, что указано шрифтом»». Особенно для шрифтов, таких как арабский или деванагари, существует очень важная логика, общая для всех шрифтов, которая реализована в формирователе текста.

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

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

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

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

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

person Peter Constable    schedule 26.03.2020
comment
Когда я говорю полностью автономный, я имею в виду такой же полностью автономный, как и игровой ПЗУ: конечно, интерпретатор (шейпер шрифтов, аппаратный эмулятор консоли и т. д.) должен выполнять много сложной работы, но все они фактически должны делать это одинаково (даже не в коде, а в результате), если мы хотим назвать их правильными шейперами/эмуляторами/и т.д. Естественно, в шейпере есть много кода, который применяет функции шрифта, но он не может добавить свои собственные правила GSUB (плюс, как это сделать? Идентификаторы глифов даже не согласованы между разными поколениями одного и того же шрифта) - person Mike 'Pomax' Kamermans; 27.03.2020
comment
Поиски GSUB определяют действия по замене с использованием идентификаторов глифов, специфичных для шрифта, а реализация формирования может генерировать другие замены глифов, поскольку у нее нет знаний о шрифтах. Если это то, что вы имеете в виду, то это правильно. - person Peter Constable; 27.03.2020
comment
Однако, прочитав ваши комментарии в ответ на вопрос Джоша, мне показалось, что все, что нужно сделать реализации рендеринга, - это проанализировать таблицы поиска в шрифте и выполнить указанные замены, и это неверно: механизм рендеринга должен делать кластерный анализ, переупорядочивание глифов в кластере, применение определенных функций к определенным поддиапазонам, а затем обработка поиска, вызванного функциями. И то, как все это должно быть сделано, может отличаться от одного сценария к другому. Джошу важно понимать это, если он хочет реализовать свой собственный рендерер. - person Peter Constable; 27.03.2020
comment
полностью автономная программа набора текста более уместно применялась бы к данным шрифтов Apple AAT и SIL Graphite. Оба они используют единую, действительно общую среду выполнения, и вся логика формирования полностью автономна внутри самого шрифта. Но ни один из них не поддерживается так широко в программном обеспечении или инструментах разработки шрифтов, как OpenType. - person Peter Constable; 27.03.2020
comment
хороший момент, я забыл удалить эти комментарии после написания ответа. Я предполагаю, что основная проблема заключается в том, что это звучит так, как будто вы думаете о программе как о чем-то отличном от того, о чем я думаю, поэтому я, вероятно, должен сделать это более нюансированным. Для меня программное обеспечение, которое интерпретируется, уже является полной программой, с дополнительной логикой, исходящей от интерпретатора (интерпретатор python/js, формирователь текста, эмулятор и т. д.), просто заданной для run, которая программа. Это будет чертовски сложно, но эта сложность просто необходима для правильного выполнения программы (в соответствии со спецификациями и соглашениями). - person Mike 'Pomax' Kamermans; 28.03.2020