Как сохранить исходный проект шрифта для следующей итерации

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

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

Минимальный комплект обычно состоит из четырёх частей:

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

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

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

Назовите базовую точку понятно: например, v1.0-approved или 2026-09-24-before-spacing-pass. Не используйте слова final, new и last без даты или номера: они перестают быть однозначными после двух-трёх итераций. В названии файла можно оставить короткий идентификатор проекта, а подробности держать в заметке, чтобы не создавать слишком длинные имена.

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

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

Пример структуры переносимой папки: my-font/; source/; references/; releases/; notes/

В source храните актуальный редактируемый проект и его обязательные зависимости. В references — исходные образцы, отсканированный шаблон и изображения, которые проект не включает внутрь. В releases — неизменяемые экспортированные файлы с версией в имени. В notes — журнал решений и контрольные примеры. Не дробите маленький проект на десятки папок; структура должна снижать поиск, а не требовать отдельной инструкции.

Проверьте пути к связанным файлам. Относительная ссылка, вроде ../references/scan.png, обычно переносится вместе с папкой проще, чем путь, завязанный на имя конкретного пользователя или локальный диск. Если редактор предлагает собрать проект или упаковать связанные изображения, воспользуйтесь этой функцией и откройте получившийся пакет в другом месте. Не предполагайте, что копирование одного главного файла перенесло вложенные ресурсы.

Для каждой версии выберите одну понятную точку правды. Если есть несколько параллельных веток — например, одна для кириллицы, другая для интервалов, — отметьте, какая из них стала основой следующей общей сборки. Не складывайте в source папки source-new, source-newest и source-final2: такие названия переносят неопределённость на будущего себя.

Короткая карточка версии помогает восстановить контекст без повторного исследования. Достаточно обычного текстового файла или таблицы с такими полями:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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