Особенности автоматизации дизайна
Каждый из нас часто встречается с автоматизацией полиграфии, хотя и не замечает этого. Например, таблички с номерами домов, расписания на остановках, карты метро — это всё сделано с помощью автоматизации.
Создание шаблонов в дизайне происходит через генератор и массивы данных. Например, чтобы сделать расписание, нужно взять время, шаблонный дизайн и добавить в генератор. В результате получится целая пачка расписания для разных остановок. Звучит просто, но на деле есть несколько особенностей, которые нужно учитывать, потому что полиграфия и диджитал сильно отличаются друг от друга. Я выделил три группы:
- Цветовая схема. В диджитале все работают в RGB и получают яркие контрастные картинки благодаря светящимся экранам. У полиграфии цветовая схема CMYK и изображение переносится на бумагу.
- Кривые. Если вы дизайнер в диджитале, можете работать в растре, но для печати все изображения и тексты нужно перевести в кривые, чтобы грани были чёткими и не поплыли при печати.
- Выравнивание. В диджитале макеты выравнивают по площади, и у каждого элемента есть кегельная площадка, куда он помещается. Мы видим тексты с отступами, и нам это привычно. В полиграфии макеты выравнивают по формам букв, чтобы между ними не было много свободного пространства.
В диджитале или веб-дизайне такие моменты сложно решать. Можно вводить коэффициенты для шрифтов, но только вы рассчитаете их для одного шрифта, появляется другой, и приходится всё пересчитывать. Поэтому нужна автоматизация.
Сначала я пытался генерировать автоматизации во Flash-, SVG-, JS- и PHP-библиотеках, но из полиграфий всё равно звонили и просили прислать новый PDF, где всё будет в кривых. Из-за этого пришлось переходить на современные решения.
Первым шагом к успеху стала работа в Adobe Illustrator и InDesign — я понял, что там можно писать скрипты, которые неплохо автоматизируют рутину. Например, они помогали сглаживать градиенты, переносить точки на картах, накладывать маски и делать другие простые задачи. Я увлёкся этой темой, создал канал и старался популяризировать скрипты.
Скрипты в продуктах Adobe мне подходили, пока я не начал выходить в веб, не научился писать плагины и не столкнулся с ограничениями пакета этих программ:
- Старый язык программирования. В программы Adobe невозможно доставить данные, потому что у них JavaScript 1999 года и там ничего нет.
- Нет выхода в интернет. Чтобы работать в Adobe, нужно, чтобы все данные хранились в текстовых таблицах где-то рядом с вашим файлом, в текстовых таблицах, а не в облаке, например.
- Нужна лицензия. Допустим, в команде работает 10 верстальщиков — на каждого нужно покупать отдельную лицензию, что довольно накладно. А если пользоваться одной учётной записью, повышается вероятность ошибок.
При этом веб, который я считаю отлично интегрированным, тоже имел свои проблемы. Например, можно легко получить и выгрузить данные, но они чаще всего отображались криво. Просто посмотрите, во что превращается нормальный PDF-файл после выгрузки.
Все эти сложности привели к тому, что пришлось искать своё решение.
Изобретение своих инструментов
Чтобы сделать автоматизацию по-настоящему качественной, мне пришлось изобретать велосипед. Я взял лучшее из Adobe и веба: вывел функциональность Adobe Illustrator и InDesign в веб для доступа к возможностям Сети. Вторым шагом я должен был переизобрести колесо. В случае с дизайном их два: рисование векторных форм и рисование текста.
Приведу пример, почему сложно рисовать текст. Однажды мы с командой дизайн-кода Екатеринбурга делали указатели для центра города. Вот такие.
Зелёные полосы — это статичные переменные макета. Красные — то, что там нужно было рассчитывать. Дело в том, что текст на русском языке мог быть в одну строчку, а на английском — в две, и наоборот. Нам нужно было добиться того, чтобы всё выравнивание происходило автоматически.
Если бы за эту работу сел верстальщик, он бы начал руками двигать текст, уменьшать, увеличивать, появились бы ошибки, работа бы шла медленно.
Нам нужно было всё делать быстро, поэтому мы разработали такой алгоритм:
1. Собирали данные в JSON — в этом документе собирали всю информацию, которая была нужна по каждому объекту. JSON оказался удобным решением ещё и потому, что там можно было пользоваться лигатурами. Это иконки, которые есть в шрифтах на ту или иную комбинацию букв. Например, в нашем шрифте комбинация chu вызывала иконку церкви.
2. Сформировали лигатуры. Мы проверили, что есть в шрифте на разные комбинации клавиш, и создали библиотеку лигатур. Благодаря этому у нас появились формы, которые можно обсчитать для перевода в кривые.
3. Перевели всё в кривые. Мы построили математическую модель элемента — кривые Безье, чтобы шрифт и лигатуры стали кривыми.
4. Выполнили кернинг. Мы проверили межбуквенные расстояния и убедились, что между буквами не было ничего лишнего. Например, в вебе нормально, когда ни одна буква не заходит под другую. В полиграфии это выглядит неряшливо. Сравните варианты ниже.
Если делать всё это руками, процесс занимает колоссально много времени. А в коде это всего несколько строчек и миллисекунды. В результате у нас получилась математическая модель, которая быстро расставляет всё по местам и умеет создавать:
- Параграфы из разных стилей
- Иконки из лигатуры шрифта
- Двухцветные логотипы
- Векторные формы
А ещё модель умеет подгонять размеры символов под размеры экрана. Достаточно указать шесть точек, например, справа, скрипт автоматически их найдёт и подгонит размеры. Вот пример.
В результате моей работы получился отдельный движок — я назвал его JP. Он очень большой — на скриншоте ниже содержимое одной только папки Service.
Две трети скриптов в движке математические и нужны для того, чтобы получить ширину текста, расстояние, обсчитать группы, стеки, загрузить шрифты в разных форматах, в том числе те, что выгружаются из Adobe Illustrator.
При этом шаблоны наших документов — в JSON. Это просто документ, в котором вы можете указать параметры файла, шрифты, позиции блоков, якорные объекты, смещение, точки выравнивания и так далее. В результате вы получите макет в PDF. Вот как выглядит шаблон в JSON.
Кроме того, движок умеет сам генерировать веб-формы, чтобы не рисовать бесконечные формы ввода. Покажу на примере финских указателей. Вот как выглядит код для веб-формы.
А это результат, который видит пользователь.
А ещё в движке есть контроллеры — это что-то вроде JavaScript для HTML. Они нужны для сложных случаев, которые не опишешь в шаблоне. Например, если есть динамические параметры или нужно проверить смещение элементов при определённых условиях. Вот как контроллер выглядит в коде.
Возможности в автоматизации
Благодаря движку JP удалось отойти от макетов, из которых создается PDF-файл, и сразу генерировать его из данных. Мы избежали избытка дефолтных стилей, которые обычно создаются из HTML + CSS. Конвертировать шрифты в кривые стало в несколько раз проще, а ещё движок легко встроить в приложения, которые работают на JavaScript. Вот схема, по которой это работает.
Движок умеет проверять готовый PDF-файл на ошибки — это сильно ускоряет работу и позволяет избежать лишних итераций правок. Это особенно важно при больших объёмах данных.
Сейчас у нас в разработке продукт, который называется Autocraft. Это инфопланирование, которое целиком построено на базе веба. Например, у вас есть карта или план, на которых надо расположить информацию. Autocraft позволяет сделать макеты динамическими, чтобы аналитику было удобно расставлять навигацию, добавлять тексты и другие элементы.
Схема выглядит довольно громоздко, на самом деле в ней чётко разделены роли, поэтому члены команды не мешают друг другу работать.
Помните, я рассказывал о навигации в Екатеринбурге? У нас была задача сделать таблички для 240 столбов. Благодаря автоматизации дизайна, вся работа потребовала 12 часов и силы одного сотрудника.