Как проверить экспорт шрифта с помощью FontBakery

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

FontBakery — набор автоматических проверок для файлов шрифтов и материалов проекта. В профиле universal собраны проверки OpenType, основанные на общих практиках шрифтового сообщества. Среди примеров в документации — согласованность версий и названий нескольких файлов семейства, корректность некоторых метаданных, записи осей вариативного шрифта и техническое устройство контуров. Полный перечень зависит от выбранного профиля и версии инструмента; его можно посмотреть в описании профиля Universal и списке проверок OpenType.

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

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

Сохраните финальный экспорт в отдельной папке, например release/, и не смешивайте его с резервными копиями и старой версией. Если вы выпускаете Regular и Bold как два самостоятельных файла, положите рядом оба. Если нужен только один файл, проверяйте его отдельно. Так будет понятно, какой именно артефакт породил замечание.

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

Установите FontBakery по официальной инструкции для своей операционной системы. После установки проверьте, что доступна команда fontbakery, и запросите справку: fontbakery -h. Если команда не найдена, причина обычно в среде Python или в том, куда установщик поместил исполняемый файл; сначала исправьте это, а не меняйте сам шрифт.

Для первого технического прохода по обычному OpenType-экспорту запустите общий профиль, применив его к конкретным файлам в папке релиза:

cd release fontbakery check-universal *.ttf

В macOS и Linux оболочка обычно раскрывает *.ttf в список файлов до запуска программы. Если вы используете OTF или сомневаетесь в том, какие расширения поддерживает установленная версия, сначала посмотрите справку выбранного профиля. Не полагайтесь на предположение, что любой пример команды автоматически подходит для всех типов файлов.

Профиль Universal предназначен для общих практик проверки шрифтов. check-googlefonts, check-adobefonts и другие именованные профили связаны с требованиями конкретных программ или организаций. Такой профиль уместен, если вы готовите проект именно для соответствующего процесса приёма. Для частного рукописного шрифта он может показать правила публикации каталога, которые не являются дефектами вашей задумки.

Если вы намерены передать файл клиенту, уточните требования получателя: форматы, набор начертаний, именование, поддерживаемую лицензию и тесты приёмки. Затем используйте проверки профиля как дополнительный технический экран, а не как автоматическую сертификацию. Документация инструмента перечисляет разные подкоманды и объясняет, что универсальный и vendor-профили решают разные задачи (руководство по CLI).

Одного текста в терминале недостаточно, если предстоит исправлять несколько замечаний или сравнивать версии. Сохраните машиночитаемый отчёт рядом с выпуском:

fontbakery check-universal --json fontbakery-report.json *.ttf

Для диагностики можно включить подробный вывод:

fontbakery check-universal --verbose *.ttf

Параметры JSON-отчёта и подробного режима описаны в руководстве по командной строке. Храните отчёт с той же сборкой, к которой он относится. Если перезаписать бинарник после проверки, прежний отчёт уже не подтверждает новое состояние файла.

В отчёте найдите имя проверки, статус и пояснение к результату. Не пытайтесь сначала «починить всё красное»: сначала выясните, что именно проверка ожидала, какой файл проверялся и относится ли правило к вашей задаче. Название проверки удобно использовать для поиска её официального описания. У FontBakery есть каталог документации проверок; он помогает перейти от короткого идентификатора к объяснению причины.

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

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

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

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

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

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

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

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

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

Начните с check-universal: он ориентирован на общие практики для OpenType. Профиль Google Fonts, Adobe Fonts или другой выбирайте, когда готовите файлы для соответствующего каталога или процесса.

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

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

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

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

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