Регрессионная проверка шрифта: как сравнить две сборки

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

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

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

Хороший набор покрывает несколько слоёв:

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

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

Запишите условия теста: название файла, приложение, операционную систему, размер текста, межстрочный интервал, масштаб просмотра и формат экспорта. Если на одном снимке новая версия показана при 100%, а старая — при увеличении 125%, сравнение формы становится ненадёжным. Для экранной проверки отключите случайное авто-масштабирование окна; для печатной — используйте один и тот же размер страницы и настройки принтера или PDF.

В паспорте эталона хватит короткой записи: «Сборка 1.4.2; проверена в редакторе макетов; файл сохранён отдельно; контрольная страница — дата; выявленных блокирующих проблем нет». Это не заменяет журнал изменений, а фиксирует, с какой именно версией сопоставляется следующая.

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

Примеры подбирайте по назначению гарнитуры. Для дневника подойдут дата, заголовок записи и несколько строк обычного текста; для настольной игры — названия карточек, номера и короткие команды; для подписи — имя, фамилия и узкие строки. Важно использовать один и тот же текст до и после изменения. Если заменить контрольную фразу между сборками, вы потеряете общий знаменатель.

Добавьте в набор проблемные сочетания, найденные на прошлых проверках. Например, если в фамилиях часто встречается пара букв с тесным соединением, оставьте её в контрольном наборе даже после исправления. Старые дефекты полезны как постоянные тесты: они не должны возвращаться вместе с новой правкой.

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

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

Проверяйте изменения слоями, в одном порядке:

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

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

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

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

Ведите таблицу сравнения с четырьмя полями: место, эталон, новая версия, решение. Вместо «стало теснее» запишите: «в строке с датой 12.09 расстояние после запятой уменьшилось; проверить боковое поле и сравнить на кегле макета». Такая запись помогает воспроизвести проблему и не смешивает впечатление с диагнозом.

Присвойте находке один из статусов:

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

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

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

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

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

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

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

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

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

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

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

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

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

Регрессионная проверка делает выпуск шрифта предсказуемее: вы сравниваете одну и ту же контрольную страницу, прежние макеты и итоговый экспорт, а не полагаетесь на память. Сохраните базовую сборку, объясните ожидаемые изменения и закрепите обнаруженные ошибки как постоянные тесты. Когда нужно быстро создать или дополнить рукописную гарнитуру, начните с Fontgenerator: https://fontgenerator.ru/.