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

Когда конструкторскому бюро требуется выпустить сотни комплектов разнокалиберных чертежей, процесс превращается в рутинный ад. Я, Сергей Багров, продолжаю рассказывать о своем опыте разработки корпоративного софта — на этот раз о создании распределенной системы пакетной печати PDF-файлов для локальной сети предприятия. О том, как превратить ручной труд в полный автомат и сократить время подготовки документации на 75%, читайте в этом материале.

Введение в задачу и первые ограничения

Инженерная документация кардинально отличается от стандартных офисных файлов. Один документ может объединять от десятка до тысячи страниц, причем внутри одного файла соседствуют форматы A4, A3, A2, A1 и составные листы. Часть чертежей должна выводиться в цвете, а часть — исключительно в монохромном режиме.

Классический подход «AS IS» требовал от инженера вручную анализировать каждый лист, группировать страницы по параметрам, настраивать драйверы и отправлять их на разные принтеры и плоттеры. Чтобы исключить человеческий фактор, я поставил цель: создать pipeline, который на вход принимает «тяжелый» PDF, а на выходе выдает полностью отсортированные по устройствам распечатанные комплекты.

Требования и инфраструктура проекта

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

Главным требованием бизнеса стала предельная простота для инженера: указать путь к файлу на файловом сервере и нажать единственную «большую красную кнопку» отправить. Все остальные решения — от определения формата и цветности до выбора конкретного плоттера — система обязана была принимать самостоятельно.

Эволюция архитектуры: от простого MVP к сервисам

Первая версия системы представляла собой монолитное SPA на базе Django, развернутое через IIS. Для извлечения страниц применялась библиотека PyPDF2, а для растеризации — связка ImageMagick и Ghostscript с последующей обработкой в Pillow. Это позволило решить задачу в кратчайшие сроки, однако на больших чертежах генплана формата A2*3 монолит начал чрезмерно нагружать память и процессор.

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

Оптимизация и переход на MuPDF

Чтобы ускорить конвертацию тяжелых инженерных чертежей и снизить аппетиты к ресурсам, я провел сравнительный тест популярных библиотек. Замеры показали, что переход на MuPDF (через Python-обертку fitz) дает колоссальный прирост производительности. Она справляется с задачей в несколько раз быстрее аналогов и существенно экономит процессорное время на сложных графических макетах.

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

Алгоритмы анализа страниц и отправки на печать

Каждая страница документа последовательно проходит несколько этапов:

• Извлечение объекта страницы и ее точных физических размеров из типографских пунктов в миллиметры.
• Создание растрового представления в виде массива пикселей с заданным разрешением 300 DPI.
• Анализ цветности с помощью вычисления дисперсии значений цветовых каналов RGB для определения наличия цветных элементов.
• Сопоставление параметров с конфигурационной таблицей и автоматический выбор целевого устройства через WinAPI.

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