Дизайн-софт без Adobe: чем закрыть задачи команды и что хранить на сервере

MAATRIX

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

Растровая графика: чем закрыть задачи фоторедактора

Основная рабочая лошадка — GIMP. Слои, маски, кривые, коррекция цвета, пакетная обработка через Script-Fu — весь базовый набор фоторедактора на месте, и для 80% повседневных задач (ретушь, коллажи, подготовка изображений под сайт или соцсети) разница с привычным интерфейсом упирается только в непривычное расположение инструментов. Открывает PSD, сохраняет в PSD — но честно: слои со смарт-объектами, часть стилей слоя и некоторые режимы наложения при открытии в GIMP интерпретируются иначе или теряются. Файл с сложной многоуровневой композицией из другого редактора стоит открыть и визуально сверить с оригиналом, прежде чем отдавать в печать или публикацию — расхождения бывают тонкие и не всегда бросаются в глаза сразу.

Слабое место GIMP исторически — работа с CMYK для полиграфии: из коробки редактор работает в RGB, для профессиональной цветоделения нужен плагин (Separate+) и ручная настройка ICC-профилей. Это рабочий, но не такой прямой путь, как в специализированном софте — закладывайте время на освоение, если у вас печатный, а не веб-поток задач.

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

Photopea — веб-редактор, открывающийся прямо в браузере без установки, с интерфейсом, нарочно похожим на Photoshop, и с прямым открытием PSD/AI/XD файлов. Удобен как временное решение для быстрой правки без установки софта на новую машину или для сотрудника на удалёнке без прав администратора. Обработка изображения выполняется на стороне браузера пользователя, но проект — закрытый сервис стороннего разработчика, развернуть его на своём сервере нельзя, и это стоит учитывать, если для команды принципиально не выгружать рабочие файлы за пределы своей инфраструктуры даже потенциально.

Отдельная категория — Affinity Photo: коммерческий редактор с разовой покупкой лицензии вместо подписки, по возможностям ближе всего к привычному пакету из всех перечисленных, включая приличную поддержку PSD и CMYK. Это не бесплатное решение и не всегда просто оплатить из России в моменте — но если цель именно закрыть подписочную модель, а не перейти на open source, для команды это может быть более быстрым по адаптации вариантом, чем GIMP. Точную стоимость и актуальные способы оплаты уточняйте на момент покупки — они меняются чаще, чем хотелось бы.

Векторная графика и вёрстка: замена иллюстратору и вёрстке макетов

Для векторной графики стандартный ответ — Inkscape. Родной формат — SVG, что само по себе плюс для веба и иконок: файлы открываются в браузере, легко версионируются как текст (SVG — это XML). Импорт AI-файлов работает через встроенный конвертер на базе PDF-совместимости старых версий формата — простая векторная графика переносится нормально, сложные документы с множеством эффектов, градиентных сеток и текстовых стилей требуют ручной проверки и доработки после импорта. Для работы «с нуля» в Inkscape Inkscape — полноценный инструмент, для миграции архива готовых AI-файлов — рассчитывайте на выборочную переверстку части из них, а не автоматический стопроцентный перенос.

Для вёрстки многостраничных документов (буклеты, каталоги, книги, макеты под печать) — Scribus. Мастер-страницы, стили абзацев, вывод в PDF/X для типографии, работа с CMYK и цветопробой — базовый набор верстальщика на месте. Честный минус: типографский движок Scribus заметно проще, чем у специализированных программ вёрстки — сложные многоколоночные раскладки с автоматическим перетеканием текста и продвинутой типографикой (кернинг пар, оптические поля) требуют больше ручной подгонки. Для рекламных листовок и простых каталогов это не критично, для книжной вёрстки с высокими требованиями к типографике — закладывайте больше времени на финальную полировку.

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

Пакетная конвертация файлов из командной строки экономит часы при миграции архива:

# Пакетно переконвертировать все SVG в PNG нужного разрешения
for f in *.svg; do
  inkscape "$f" --export-type=png --export-dpi=300 -o "${f%.svg}.png"
done

# Пакетный экспорт Scribus-документов в PDF/X-1a для типографии
scribus -g -py export_pdfx.py --pdf-x1a *.sla

Честная оценка: где альтернативы закрывают задачу полностью, а где нет

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

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

Хранение больших файлов проекта на своём сервере

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

Рабочий вариант — файловое хранилище на своём VPS, которое команда монтирует и синхронизирует как обычную папку, без ручной загрузки через веб-интерфейс каждый раз. Практическая связка — Nextcloud: клиент на компьютер каждого дизайнера, общие папки проекта с правами доступа, десктопное приложение синхронизирует изменения в фоне. Пошаговая установка на VPS с HTTPS и настройкой под большие файлы разобрана отдельно: как установить и настроить Nextcloud на VPS.

Для дизайн-файлов из коробки лимиты веб-сервера и PHP обычно занижены под типичный офисный документ, а не под рабочий PSD на несколько гигабайт — их нужно поднять явно и в nginx, и в PHP:

# /etc/nginx/sites-available/nextcloud
client_max_body_size 10G;
client_body_timeout 3600s;

; /etc/php/8.3/fpm/php.ini
upload_max_filesize = 10G
post_max_size = 10G
memory_limit = 1G
max_execution_time = 3600

Дисковое пространство под проект дизайн-команды растёт быстрее, чем кажется на старте — закладывайте NVMe-диск с запасом минимум в 2–3 раза от текущего объёма архива и планируйте расширение диска заранее, а не в момент, когда сервер сообщает «место закончилось» посреди сдачи макетов клиенту.

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

Версионирование дизайн-файлов без отдельного PDM

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

Для дизайн-команды на практике работают два уровня:

• Встроенная история версий Nextcloud/Seafile. Каждое сохранение файла через синхронизацию автоматически создаёт версию, откат делается из интерфейса за пару кликов, без звонка администратору. Ограничение по умолчанию — глубина хранения версий по времени и месту на диске, это настраивается в конфиге (versions_retention_obligation в Nextcloud), но не бесконечно — для критичных вех проекта (сдача клиенту, финальный релиз) стоит отдельно сохранять помеченную копию, а не полагаться только на автоматическую историю.
• Регулярный снапшот-бэкап поверх хранилища. История версий в файловом хранилище — не замена бэкапу: если база данных хранилища повреждена или диск отказал целиком, история версий пропадает вместе с текущими файлами. Отдельный снапшот на BorgBackup или Restic, отправляемый за пределы того же физического сервера, — обязательная страховка сверху, а не опция.

Git с Git LFS для бинарных дизайн-файлов теоретически возможен, но на практике имеет смысл только если команда и так уже привычна к git — порог входа для дизайнера, который никогда не работал с коммитами и мёрдж-конфликтами, выше пользы от такого решения. Специализированный PDM/DAM для дизайн-архива оправдан на масштабе десятков людей и тысяч ассетов — для команды в несколько человек это избыточно и по деньгам, и по времени на внедрение.

Синхронизация между членами команды без облака вендора

Если Nextcloud или Seafile закрывают хранение с правами доступа и версиями через центральный сервер, для другого сценария — прямой обмен рабочими файлами между двумя-тремя дизайнерами без похода через веб-интерфейс каждый раз — удобнее Syncthing: децентрализованная синхронизация без центрального хранилища вообще, каждая машина синхронизируется напрямую с другими по защищённому каналу. Установка на VPS как постоянно доступного узла для обмена между людьми, которые не всегда онлайн одновременно, разобрана отдельно: как установить и настроить Syncthing на VPS.

Разница на практике: Nextcloud — это общая папка с правами доступа, историей версий из коробки и веб-интерфейсом для тех, у кого нет десктопного клиента под рукой. Syncthing — это синхронизация «точка-точка» без единого хранилища, где нужен ручной контроль конфликтов: если два человека одновременно правят один и тот же PSD офлайн, при следующей синхронизации Syncthing создаст файл с припиской .sync-conflict-... вместо файла оригинала — программа сама не решает, чья правка правильная, это остаётся на человеке. Для рабочих файлов дизайна, где параллельная правка одного файла — обычное дело, стоит договориться о простом правиле: кто открыл файл — сообщает в чат команды, пока не открыл замок. Для игнорирования временных файлов редакторов в конфиге Syncthing стоит сразу прописать паттерны:

# .stignore в корне синхронизируемой папки
*.psd~
*~lock*
.~lock.*#
Thumbs.db
.DS_Store

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

Частые вопросы