Бывает такое чувство, когда нужно сделать с PDF какую-то простейшую вещь — соединить два файла, повернуть страницу или сжать документ до вменяемого размера для почты — а под рукой только кривой онлайн-конвертер с рекламой кредитов и прыгающей кнопкой «скачать без вирусов»? И ты сидишь и думаешь: «Я что, зря учился? Неужели нельзя просто взять и решить эту задачу на своём же компьютере, не отправляя паспортные данные левому сайту?»

Вот ровно для этого чувства и существует Stirling PDF. Это очень жирный, открытый и, что самое важное, локальный PDF-комбайн. Вы поднимаете его как персональную программу, в браузере или на своём сервере, и получаете 50+ инструментов для работы с PDF — от разрезания и склейки до настоящей цифровой подписи и автоматической обработки через API. И это сейчас проект номер один на всём GitHub по теме PDF. Почти 83,5 тысячи звёзд — это не шутка.

Кому читать этот разбор: всем, кто хотя бы раз в месяц вынужден что-то делать с PDF-файлами и хочет управлять этим процессом сам, без облаков и подписок. Кому можно смело пропустить: если вы — счастливый обладатель Adobe Acrobat Pro и вас всё устраивает, или PDF для вас — это просто «можно открыть и прочитать», то новые инструменты вам не нужны.

Если просто

Представьте себе швейцарский нож, но все лезвия и отвёртки — это разные операции с PDF-файлами. Stirling PDF написан на Java (да-да, Java жива, и в данном случае это даже плюс, потому что зоопарк PDF-библиотек там огромен), и поставляется в первую очередь как Docker-контейнер. Это значит, что запустить его — вопрос одной команды и трёх минут, если у вас есть Docker.

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

Что это решает

У проекта Stirling PDF есть одна очень простая, но от этого не менее гениальная идея: забрать у пользователя головную боль, связанную с выбором PDF-инструмента, и отдать ему всё сразу в одной коробке.

Что именно забирают? Во-первых, страх утечки. Все эти сайты «сжать pdf за 2 секунды» — это почти всегда сервер где-то в далёком дата-центре, который спокойно читает ваши документы. Во-вторых, зоопарк утилит. Когда для поворота страницы вы качаете одну программу, для распознавания текста (OCR) — вторую, а для электронной подписи — пытаетесь разобраться в криптографических плагинах. Здесь всё это живёт в одном интерфейсе и с единым подходом. В-третьих, это автоматизация по цене порога входа для новичка. Позже объясню, почему это очень круто, а пока просто держите в уме: рутинные операции с PDF теперь можно встроить в скрипты без боли.

Как попробовать

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

docker run -p 8080:8080 docker.stirlingpdf.com/stirlingtools/stirling-pdf

После этого открываете браузер по адресу http://localhost:8080 и видите готовый комбайн. Если у вас Docker Desktop — то вы управитесь быстрее, чем прочитаете этот разбор. Без Docker есть вариант установить его как обычную Java-программу или скачать десктопный клиент с сайта stirling.com. Но, честно говоря, Docker тут — самый надёжный и простой путь, особенно если вы планируете использовать инструмент командой и дать доступ коллегам во внутренней сети.

Здесь очень важно сразу понять архитектурную хитрость. Поскольку вы запускаете это на себе (или на сервере вашей команды), вы получаете не просто набор кнопок в браузере, но и полноценный REST API для каждой из 50+ операций. Для разработчиков это означает, что можно написать скрипт на Python, Bash или прямо внутри CI/CD пайплайна, который, например, конвертирует отчёты из DOCX в PDF, накладывает водяной знак «Черновик» и склеивает их с титульной страницей — и всё это без подписки на внешний сервис.

3 сценария с примерами

Давайте без абстракций. Это работает в рутине и выглядит так.

Сценарий 1: Ежемесячный отчёт из десяти файлов

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

Как применить. Открываете веб-интерфейс на своём сервере. Сначала закидываете все файлы в инструмент «Слияние PDF» — он склеивает их в нужном порядке. Потом идёте в раздел «Поворот страниц» и буквально кликами правите ориентацию. Готовый документ пропускаете через «Сжатие», выбирая подходящий уровень качества (обычно «средний» сжимает радикально, но текст остаётся читаемым). И последний шаг — электронная подпись. Загружаете свой файл сертификата и подписываете документ, не выходя из системы. Результат: один файл, который не стыдно отправить клиенту и не страшно потерять по пути в почтовом сервере.

Сценарий 2: Бухгалтерия и сканы от руки

Задача. Бухгалтер просит прислать скан подписанного акта, но сканер в офисе выдаёт только JPG-файлы «весом» в мегабайт каждый. Вам нужно сделать из них один PDF, желательно с распознанным текстом, чтобы потом можно было искать документ по ключевым словам.

Как применить. Используете инструмент «Преобразование изображений в PDF». Загружаете все сканы, настраиваете порядок, качество и поля. На выходе — PDF. После этого идёте в раздел «OCR / Распознавание текста» и запускаете обработку. Теперь документ не просто картинка, в нём можно искать текст. Что получится: файл занимает в 4-5 раз меньше места, легко ищется на диске, а текст выглядит аккуратнее, потому что при сшивке можно было подчистить фон и выровнять яркость.

Сценарий 3: Автоматическая подготовка документов в CI/CD

Задача. У вас в репозитории веб-приложения лежит десяток Markdown-файлов с юридическими документами. Нужно, чтобы при каждом релизе они автоматически собирались в стилизованные PDF-файлы с логотипом компании в верхнем колонтитуле и водяным знаком «Версия 2.0».

Как применить. Вы пишете небольшой скрипт в GitHub Actions. На первом шаге через Pandoc конвертируете Markdown в PDF (Stirling умеет и это, но Pandoc быстрее в CLI). Дальше скрипт обращается к API вашего Stirling PDF, который крутится в вашей же инфраструктуре, и через вызов эндпоинта POST /api/v2/pdf/add-watermark накладывает ваш полупрозрачный знак. Вторым вызовом — добавляет колонтитулы. Что получится: юридические документы всегда актуальны, генерируются по кнопке «релиз», ни один человек не занимается ручным экспортом и не забывает обновить логотип. Ошибки ручного форматирования исчезают.

Где можно застрять

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

Второе — лицензия. Она указана как NOASSERTION, и в README честно написано «open-core». Это значит, что проект открыт частично. Все базовые PDF-инструменты, которые мы разобрали, бесплатны. Но есть платные уровни для энтерпрайза: расширенный SSO (единый вход для компаний), аудит, пайплайны для миллионов PDF-файлов, продвинутая поддержка. При этом код ядра открыт, и 50+ инструментов из коробки доступны без ограничений. Учитывая, что у проекта больше 80 тысяч звёзд и очень активное сообщество, я бы не ожидала здесь внезапного закрытия всех базовых функций, но если вы строите на этом завод по обработке документов, изучите их Server Plan внимательно.

Третье — порог для автоматизации. Чтобы писать скрипты, которые дёргают API, нужно немного понимать, что такое REST и как авторизоваться. Это не rocket science, но и не кнопка «сделать красиво

Что читать дальше

Материалы