Все статьи
24 сентября 2026 г.8 мин чтения

Почему variable font неверно называет начертания после экспорта

Почему variable font неверно называет начертания после экспорта

Если variable font экспортирован, но в приложении его начертания называются неожиданно, проблема может быть не в значениях осей, а в том, как файл описывает эти значения для меню шрифтов. В таблицах fvar, STAT и name хранятся взаимосвязанные данные: координаты вариаций и их подписи. Разберите их вместе, затем проверьте готовый файл в целевых приложениях.

Как подпись попадает в меню шрифтов

У переменного шрифта есть непрерывный диапазон вариантов, например веса от Light до Black или ширины от узкой до широкой. Приложение может дать пользователю ползунок, выбрать произвольное значение или показать несколько готовых позиций с короткими названиями — например Regular, Medium и Bold.

Таблица fvar объявляет доступные оси, их минимальные, начальные и максимальные значения, а также может содержать список именованных экземпляров. Такой экземпляр — заранее выбранное сочетание координат, которому автор дал имя. Это удобная точка входа в диапазон, но не отдельный статический файл и не полный список всех возможных значений.

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

В актуальной спецификации OpenType Microsoft указывает, что variable font должен иметь записи осей в STAT для каждой оси fvar с совпадающими name ID. Для именованных экземпляров данные двух таблиц также должны соответствовать. Спецификация рекомендует предоставлять значения STAT для элементов подсемейства, которые нужны для представления именованных экземпляров. Подробности приведены в официальных разделах fvar и STAT.

Какие симптомы указывают на несогласованные подписи

Проверьте файл, если после экспорта обнаружилось что-то из этого:

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

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

Спланируйте ожидаемый список

До проверки файла решите, какие подписи вообще должны быть видны. Запишите название семейства и короткий перечень полезных остановок: например, Regular для повседневного текста, Medium для подзаголовков и Bold для акцента. Если ось ширины тоже важна, добавьте только те сочетания, которые действительно нужны в меню. Бесконечный диапазон не означает, что каждому значению следует придумывать отдельное имя.

Составьте небольшую таблицу: имя варианта, значение каждой оси, желаемое отображаемое название и ожидаемый сценарий. Например: «Medium», wght 500, wdth 100, для промежуточного выделения. Конкретные координаты зависят от вашего файла; пример не является универсальной рекомендацией выставлять именно такое значение.

Отдельно согласуйте семейную модель. В OpenType используются разные name ID для традиционной модели семейство/подсемейство и для типографического семейства с большим количеством стилей. Нельзя механически записать одно и то же название во все поля: приложения могут обращаться к разным наборам имен. Если файл обновляет существующее семейство, сохраняйте намеренную связь с его соседними статическими начертаниями и не переименовывайте всё семейство случайно.

Проверьте таблицы экспортированного файла

Экспортируйте копию с однозначным именем файла и сохраните исходный проект. Для диагностического просмотра подойдёт fontTools TTX: команда умеет выгружать отдельные таблицы шрифта в XML. Например, можно запросить fvar, STAT и name отдельно:

`ttx -t fvar -t STAT -t name -o variable-names.ttx variable-font.ttf`

Сверьте полученные данные с редактором шрифта и своим списком ожидаемых вариантов. Ищите четыре вещи:

  1. Все нужные оси присутствуют в fvar и имеют ожидаемые теги, диапазон и значение по умолчанию.
  2. Каждый нужный именованный экземпляр содержит набор координат, который соответствует задуманному варианту, а не случайной комбинации.
  3. Подписи осей и вариантов ссылаются на существующие строки name; в name нет опечатки, устаревшего имени или языковой строки, которую вы не планировали оставлять.
  4. Записи STAT покрывают стилевые признаки, нужные для отображения вариантов; соответствия осей и имён согласованы с fvar.

Не редактируйте XML вручную только потому, что нашли в нём знакомое слово. Таблицы содержат структурированные записи, name ID и координаты, и ошибка может ухудшить файл. Если используете TTX для правки, работайте с копией, проверьте правила конкретного поля по спецификации и после повторной компиляции снова прочитайте получившийся файл. Документация fontTools TTX объясняет выбор отдельных таблиц ключом `-t` и чтение/сборку OpenType-файлов.

Сравните файл до и после экспорта

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

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

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

Проверьте реальные приложения

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

Выберите минимум два сценария: редактор, которым пользуется автор, и одно приложение из реального рабочего процесса получателя. Если font-файл будет использоваться в вебе, проверьте его в браузере с тем CSS-кодом, который предполагается для сайта. Там пользователь может видеть диапазон оси, но меню готовых имён создаёт сам интерфейс сайта; это не обязательно то же самое, что меню desktop-приложения.

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

Чек-лист перед передачей файла

  • Имена нужных остановок и их координаты записаны до экспорта.
  • Проверен именно бинарный файл, отправляемый получателю.
  • fvar содержит оси и именованные варианты согласно плану.
  • Подписи name ID существуют и написаны единообразно.
  • STAT содержит согласованные стилевые данные для применяемых осей и вариантов.
  • Временная копия установлена под уникальным именем, старые версии не подменяют файл.
  • Начертания проверены в приложениях из реального сценария.
  • Зафиксированы приложения, версии файлов и известные различия отображения.

Частые ошибки

**Считать каждый вариант оси отдельным именем.** Именованный экземпляр — выбранная автором точка в пространстве координат. Не нужно перечислять каждое возможное значение, если приложение даёт пользователю менять ось.

**Исправить только запись fvar.** Интерфейс может опираться на STAT и строки name. Согласуйте значения и подписи во взаимосвязанных таблицах, затем снова проверьте бинарный экспорт.

**Проверять рабочий проект, а не TTF.** Экспортёр может преобразовать или пропустить часть данных. Инспектируйте получившийся файл после сборки.

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

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

**Оставлять тестовую копию установленной.** Старый или дублирующий файл способен запутать проверку и передаваемый комплект. После теста удалите временные копии и проверьте чистую установку финального файла.

Вопросы и ответы

Чем именованный экземпляр отличается от статического начертания?

Именованный экземпляр — точка с заданными координатами внутри variable font, которую приложение может предложить как готовый выбор. Статический файл — отдельный шрифтовой файл со своим контуром. Имя экземпляра само по себе не означает, что отдельный TTF был экспортирован.

Зачем variable font нужны одновременно fvar и STAT?

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

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

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

Почему в браузере и редакторе разные списки начертаний?

Программы могут по-разному строить интерфейс вокруг variable font. В браузере диапазон часто задаётся CSS, а отдельный список названий может формироваться кодом страницы. Сравнивайте файл и способ выбора варианта отдельно.

Можно ли исправить подписи после экспорта без исходника?

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

Как проверить, что приложение загрузило новую версию?

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

Итог

Если variable font показывает неожиданное имя, проверяйте не одну ось, а цепочку fvar → STAT → name и готовый бинарный файл. Список нужных начертаний, выгрузка таблиц и повторяемая проверка в рабочих приложениях позволяют отличить дефект экспорта от особенности конкретного меню. Для создания исходной рукописной гарнитуры можно начать с шаблона на Fontgenerator, а перед передачей variable font проверить его подписи и структуру.