Версия шрифта 1.1 или 2.0: как оценить масштаб изменений

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

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

После первого релиза особенно легко называть каждую правку «следующей версией». Но тогда 1.0.1 после исправления одного хвоста выглядит так же важно, как 2.0 после изменения ширины строчных букв и межбуквенных расстояний. Полезнее связывать число с ожидаемым влиянием на работу пользователя. Сначала определите, кто использует файл: только вы, несколько дизайнеров или уже утверждённые документы и макеты. Чем дороже повторная проверка, тем яснее нужно сообщать о возможных последствиях.

Запишите номер в виде X.Y.Z, например 1.4.2. Договоритесь, что первая цифра обозначает крупный шаг, вторая — совместимое расширение, третья — исправление. Эта схема не обещает машинной совместимости и не заменяет проверку документа. Она даёт команде понятный язык, которым можно описывать изменения в карточке релиза, имени файла и сообщении коллеге.

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

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

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

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

Допустим, после первой сборки вы добавили знаки, которых не хватало для фамилий и названий: «№», «Ё» в прописном виде или несколько букв для другого языка. Основная форма и метрики прежнего набора остались, но появилась новая возможность. Это понятный случай повысить средний разряд, например с 1.2.3 до 1.3.0. Перед передачей проверьте, что добавленные символы доступны в нужном тексте, а новые слова не подменяются системным шрифтом.

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

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

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

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

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

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

Примените договорённость X.Y.Z к наблюдаемым последствиям. Если команда спорит между двумя вариантами, выберите тот, который точнее предупреждает получателя о проверках. Затем одной фразой объясните номер: «1.3.0 — добавлена поддержка ещё нескольких знаков; основная ширина набора сохранена».

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

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

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

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

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

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

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

Обычно удобно начать с 1.0.0 или 1.0 — выберите число, соответствующее принятой схеме. Это первая версия, которую вы готовы передавать как рабочую. Черновики и пробные сборки до неё можно обозначать отдельно, чтобы не смешивать тестирование с релизами.

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

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