Кернинг пропал после экспорта: проверяем таблицы шрифта

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

Кернинг — это поправка расстояния для конкретного сочетания глифов. Например, правые стороны «А» и «Т» образуют заметную пустоту, которую можно уменьшить парной настройкой. Это не то же самое, что изменить боковые поля самой буквы: межбуквенная пара должна сработать только в нужном соседстве, не сдвигая эту же букву во всех остальных словах.

В OpenType парные настройки могут быть записаны в таблице kern — более старом механизме для парного кернинга — или в GPOS, где позиционирование задаётся функциями OpenType Layout. В GPOS кернинг связан с функцией kern; у неё могут быть более гибкие lookup-структуры. Спецификация Microsoft описывает kern как таблицу парных значений, а GPOS — как систему для позиционирования одного или нескольких глифов.

Отсюда появляется причина, почему одинаковые пары ведут себя неодинаково после экспорта. Редактор может показывать собственные данные проекта, экспортировать их в GPOS, kern или в обе структуры. Приложение-читатель может использовать только один путь или не включать требуемую функцию в выбранном сценарии набора. Поэтому надпись «кернинг настроен» в исходнике ещё не подтверждает, что поправки дошли до конкретного документа.

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

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

Спецификация OpenType содержит важный нюанс: шрифты с CFF-контурами не используют legacy-таблицу kern и должны предоставлять кернинг через GPOS. Это не ошибка такого шрифта и не означает, что кернинга в нём нет. Если целевой старый конвейер ожидает только kern, результат может отличаться; проверьте требования приложения и проведите реальный тест, прежде чем решать, что нужно менять формат шрифта.

Составьте короткую строку из пар, для которых вы действительно настраивали расстояние, и нейтральных контрольных сочетаний. Например: «ТА ТА», «АУ АУ», «ТО ТО», плюс обычное слово без заметной парной коррекции. Не ограничивайтесь только парой AV: для кириллического шрифта проверяйте кириллические пары, а при смешанном наборе — латиницу и знаки, которые войдут в работу.

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

Проверьте три контрольных сценария: набор на экране; сохранение и повторное открытие документа; экспорт в итоговый формат, например PDF или печатный файл. Внедрённый шрифт и локально установленный шрифт — разные источники. Если в сохранённом документе шрифт заменён или внедрённая копия отличается, тест на исходной машине не гарантирует тот же результат у получателя.

Откройте итоговый файл в редакторе шрифтов или инструменте просмотра таблиц. Сверьте наличие GPOS и kern, а затем проверьте содержимое именно нужной функции. Для FontTools можно вывести список таблиц командой ttx -l имя-файла.ttf; чтобы изучить таблицу, инструмент умеет преобразовывать данные в XML. Сам список отвечает только на вопрос «есть ли таблица»: он ещё не доказывает, что конкретная пара включена и что приложение прочтёт её в нужном режиме.

В GPOS проверяйте функцию kern и пары/классы, в которые попадают нужные глифы. В kern смотрите наличие нужной пары и знак поправки. Значения часто задаются через группы или классы, поэтому отсутствие буквального имени пары не всегда означает, что её нет: пара может покрываться правилом для классов. Сверьте идентификаторы глифов, а не только похожее визуальное название: после изменения cmap или набора знаков можно проверять не тот глиф, который вводится в приложении.

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

Сначала выясните, какие механизмы поддерживает адресат. Для нового приложения обычно важна работа с OpenType Layout и GPOS; в старом окружении может оказаться полезной legacy-совместимость, если программа действительно опирается на kern. Microsoft рекомендует при отсутствии ограничений legacy-среды записывать кернинг в GPOS-функцию kern, а не полагаться на таблицу kern. Эта рекомендация не означает, что надо автоматически удалить старую таблицу из файла, если конкретному получателю требуется обратная совместимость.

Не включайте сразу все опции «на всякий случай». Если приложение обрабатывает и GPOS, и kern, дублирование данных может привести к неожиданному результату в зависимости от правил движка. Microsoft специфицирует, как OpenType Layout engine выбирает GPOS kern lookups и старую kern-таблицу, но сторонние программы могут иметь собственное поведение или ограничения. Сверьте рекомендации редактора шрифтов и документацию конечного ПО.

Создайте отдельные варианты экспорта только тогда, когда у получателей разные требования. Например, комплект может содержать основной файл для современных макетов и проверенную legacy-версию для конкретного производственного процесса. Дайте файлам ясные имена и приложите краткую инструкцию с версиями программ. Не называйте один файл «правильным», а другой «неправильным»: это разные технические компромиссы для разных сред.

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

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

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

Дизайнер завершил рукописный шрифт и настроил пары «ТА», «АТ» и «УА». В редакторе они выглядят сбалансированно, но в старой верстальной программе строка разрежена. Вместо увеличения поправок дизайнер проверяет настройки документа и выясняет, что расширенный OpenType-кернинг выключен. После включения пары отображаются, но итоговая PDF всё равно использует локальную копию шрифта с другим временем сборки.

Дизайнер сравнивает список таблиц двух файлов: в передаваемом PDF использована версия без новых GPOS-данных. Он экспортирует шрифт под новым версионным именем, устанавливает его по инструкции, перезапускает приложение и повторяет тест. Теперь экран и PDF показывают ожидаемые пары. В комплект он кладёт именно проверенные файлы и указывает, какая версия использовалась при тесте.

Другой возможный исход: в шрифте с CFF-контурами нет legacy kern, но пары находятся в GPOS. Если старая программа не читает GPOS, понадобится отдельный совместимый путь или замена/обновление приложения. Не всякая конвертация решит это автоматически: сначала проверьте, какой формат данных понимает программа и можно ли экспортировать требуемую структуру без потери других функций.

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

Ориентироваться на расширение TTF или OTF. Расширение не сообщает, в какой таблице записаны пары. Смотрите структуру файла и функциональные записи.

Проверять только `kern`. Современный OpenType-кернинг часто находится в GPOS; для CFF-контуров это обязательный путь по спецификации. Отсутствие kern само по себе не доказывает отсутствие пар.

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

Сравнивать только скриншоты. Скриншот не показывает версию шрифта, параметры набора и внедрение в документ. Записывайте конфигурацию и проверяйте сохранённый результат.

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

Нет. Пары могут быть описаны в GPOS, и именно там могут находиться данные для OpenType Layout. Проверьте таблицу GPOS, функцию kern и конкретные глифы, прежде чем считать кернинг утраченным.

Спецификация Microsoft указывает, что для CFF-контуров legacy-таблица kern не поддерживается и кернинг должен задаваться через GPOS. Поэтому проверка только таблицы kern даст неполную картину.

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

Убедитесь, что в GPOS есть функция kern, нужный lookup и подходящие глифы либо классы. Затем проверьте настройки OpenType в приложении, выбранное начертание и фактическую версию установленного файла.

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

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

Передайте файлы, прошедшие проверку в целевой программе, и короткую заметку с версией приложения, ОС и проверенными начертаниями. Если для разных конвейеров нужны разные версии, объясните назначение каждой.

Когда кернинг пропадает после экспорта, сначала выясните, где хранятся парные данные и какой механизм читает целевая программа. Сверьте GPOS и kern, проверьте контрольные пары в документе и итоговом PDF. Если вы собираете рукописный шрифт в Fontgenerator, протестируйте экспорт в том приложении и сценарии, для которых готовите файл.

Источники: спецификация Microsoft для таблицы kern, спецификация Microsoft для GPOS, рекомендации Microsoft по обработке GPOS и kern, документация FontTools TTX.