Что писать в журнале изменений шрифта: знаки, версии и последствия для макета

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

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

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

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

У каждой записи должна быть устойчивая связь с конкретным файлом. Укажите обозначение версии, дату сборки, имя файла и короткую причину выпуска. Название файла полезно сохранить буквально: moj-shrift_v0-4.ttf и moj-shrift_v0-4-test.ttf могут выглядеть похоже, но относиться к разным сборкам. Если внутри проекта уже принят способ нумерации, продолжайте его; менять схему посреди работы без объяснения не нужно.

Затем перечислите изменения по категориям. Для рукописного шрифта это могут быть:

Важно отделять факт от оценки. «Исправлена строчная д: нижняя петля стала открытее» сообщает, что поменялось. «Шрифт стал профессиональнее» не объясняет ни правку, ни проверку. Для изменения ширины полезно написать, что именно было сделано и где может появиться сдвиг строки. Если причина пока гипотеза, обозначьте её как гипотезу, не выдавая за доказанную.

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

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

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

Для изменения, которое не должно затронуть существующую вёрстку, тоже полезна заметка. Напишите, что правка локальна, затем укажите, как вы это проверили. Например: «Уточнён контур прописной Ж; ширина и боковые поля не менялись. Сверены тестовые слова с предыдущей сборкой». Такая запись объясняет, на каком основании команду не просят пересматривать все страницы.

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

1. Зафиксируйте исходную сборку. Сохраните имя предыдущего файла и его обозначение. Если источник неясен, сначала сравните доступные файлы и не называйте первый попавшийся «предыдущей версией». 2. Сгруппируйте правки. Разделите изменения формы, метрик, набора символов и экспорта. Это помогает не смешать видимые изменения с техническими. 3. Напишите наблюдаемый результат. Назовите буквы, пары или свойства файла; избегайте слов «лучше», «чище» и «аккуратнее» без пояснения. 4. Отметьте область проверки. Укажите контрольные слова, строку или список знаков, на которых оценивали результат. Это не обязательно должна быть длинная тестовая страница. 5. Опишите вероятный эффект и действие. Скажите, что пересмотреть: переносы, отдельные сочетания, набор новых букв или подключение файла. 6. Добавьте известное ограничение. Если часть набора ещё не проверена либо проблема осталась, укажите это рядом с изменением, а не прячьте в общей сноске. 7. Сверьте заметку с экспортом. Проверьте, что описанные правки действительно попали в приложенный файл, а имя и версия в записи совпадают с ним.

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

Ниже — шаблон, который удобно копировать для каждой сборки:

Пример: «Сборка 0.6, primer-0-6.ttf, 24 сентября. У строчной ж раскрыто соединение центральных штрихов; ширина знака не менялась. Правка нужна, потому что в плотных словах просвет терялся на мелком размере. Проверены слова “снежный”, “оживает” и строка из 40 знаков при размере, используемом в макете. В существующих заголовках достаточно посмотреть эти сочетания; полный набор дополнительных букв в этой сборке не менялся».

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

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

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

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

Если на один пункт нельзя ответить, запишите это прямо. Например: «Боковые поля не сравнивались» — лучше, чем неявно создать впечатление, что метрики точно остались прежними.

«Исправлено много букв». Читателю всё равно приходится самому сравнивать файлы. Перечислите хотя бы группы знаков и одну-две заметные правки.

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

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

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

Умолчание о непроверенной части. Отсутствие упоминания не означает, что всё протестировано. Явная граница проверки помогает выбрать безопасную задачу для следующего просмотра.

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

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

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

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

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

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

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

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