Нам принесли файл. Обычный альбом чертежей из AutoCAD — так делают тысячи проектировщиков каждый день. Один нюанс: весил он 122 мегабайта — почта не пропускала вложение, в СЭД не грузился, лимит 50 МБ. И отдельная беда, не та же самая: открывался он страница за страницей, курсор с песочными часами, вентилятор ноутбука на взлетном режиме. Вес и скорость — разные болезни, хотя тут они пришли вместе. Мы не стали гадать, а вскрыли файл и посмотрели, что внутри по байтам.
Разобрали PDF на составляющие объекты — так же, как это делает ридер, рисуя страницу. Внутри оказалось 113 098 растровых картинок: не векторных линий, не текста — маленьких плиток с масками прозрачности, сложенных как мозаика. Важная деталь: в исходном DWG нет ни одной растровой картинки. Чертеж целиком векторный. AutoCAD сам, печатая файл, превратил чистую геометрию в россыпь из ста тринадцати тысяч кусочков растра. PDF из автокада много весит не потому, что кто-то вставил фотографию котлована, — а потому что AutoCAD по дороге к PDF незаметно раскрошил вектор на растровую пыль.
Дальше — три причины, откуда эта пыль взялась. Не альтернативные, а складываются, как три протечки в одной трубе.
Полупрозрачная заливка поверх чертежа — обычное дело: выделить зону работ, показать контур пристройки поверх здания. В AutoCAD это выглядит красиво: нижний слой просвечивает. Но вектор — это команда «залей область цветом X», а не «залей, но чтобы на 40% было видно то, что снизу»: смешение цветов — операция про пиксели, а не геометрию. Поэтому AutoCAD «расплющивает» (flattening) прозрачные объекты в растр прямо на печати — и режет его на плитки, потому что один огромный растр PDF-движки переваривают плохо. Отсюда сто тринадцать тысяч фрагментов вместо одного.
Доказательство рядом: соседние листы того же альбома без прозрачности весят по 0,9 МБ. Тот же AutoCAD, те же настройки — лист с прозрачностью раздувается в 130 с лишним раз. Это системное поведение: у Autodesk есть собственные статьи базы знаний про огромные PDF и зависание печати из-за flattening прозрачности.
Штриховка ANSI31 — параллельные диагональные линии, стандартный «металл в разрезе». У нее есть масштаб: чем меньше число, тем чаще линии. В нормальном чертеже это примерно один-два. В нашем файле масштаб был 0,05 — в двадцать раз плотнее нормы.
Представьте, что нужно заштриховать футбольное поле. Малярным валиком — несколько движений. Штриховкой с масштабом 0,05 — как школьной линейкой, проводя линию через каждые полсантиметра: поле то же, а действий в тысячи раз больше.
Мы замерили: на одной странице альбома — 833 тысячи отдельных линий (в пике до 1,3 миллиона отрезков). Рядом — плотные GRAVEL, AR-SAND, AR-CONC (гравий, песок, бетон) на десятках квадратных метров, каждая — миллионы отрезков, которые PDF обязан перечислить и хранить. AutoCAD даже предупреждает диалогом о «штриховке большой плотности» — но это легко пропустить, не зная, во что оно выльется.
В файле — 72 000 объектов, которые PDF обязан хранить и индексировать. Среди них 14 367 сплайнов — кривых, которые появляются при ручной обводке топосъемки: чем неаккуратнее обвели, тем больше точек у кривой. Плюс битые SHX-шрифты — ссылки на шрифты, разъехавшиеся с тем, что установлено у автора. По весу это скромнее первых двух причин, но добавляет неряшливости.
Вместе три причины превращают чистый вектор в текстовый суп из сотен тысяч фрагментов, часть из которых — растр.
Первое, что делает человек с тяжелым PDF, — гуглит «сжать pdf чертеж без потери качества». iLovePDF, Smallpdf, PDF24 работают по одному принципу: находят внутри PDF растровые картинки и пережимают их. Но причина веса — не «плохо сжатая фотография», а миллионы векторных отрезков и десятки тысяч мелких плиток прозрачности, которые и так крошечные. Векторные линии компрессор вообще не трогает — это не его профиль. Файл теряет пару процентов — pdf чертеж тормозит как тормозил.
Форумы вроде форума Autodesk десять лет советуют один набор рецептов, и у каждого — свой подвох:
| Совет | Подвох |
|---|---|
| Понизить DPI при печати | Текст и тонкие линии превращаются в кашу |
| Отключить прозрачность и перепечатать | Нужен исходный DWG и понимание, какие слои трогать |
| DWG → DWF → PDF | Лишний шаг, непредсказуемый результат |
| «Печатать как изображение» | Мыло при масштабировании, вес не уходит |
| Искать «плохую» штриховку через PURGE/AUDIT | Часы ручной детективной работы |
Показательный случай с форума Autodesk: файл на 312 МБ, перепробовали весь список — DPI, штриховки, PURGE — получили 237 МБ. Печатать все равно не получалось. В комментарии — буквально «начальник сходит с ума». Типичный итог борьбы с симптомом вместо причины.
Поворотный момент: все советы выше требуют исходный DWG и понимание, какие слои трогать. А тяжелый PDF на практике достается не автору чертежа — у него DWG под рукой. Достается получателям: сметчику без AutoCAD, которому нужно посчитать объемы; руководителю проекта с лимитом вложения в почте; заказчику на слабом ноутбуке в переговорке. У всех — только PDF и ноль возможностей вернуться к исходнику. Не печатается большой pdf — а исходника нет и не будет.
Именно для этого случая мы и делаем cutpdf.ru: сервис анализирует готовый PDF и лечит найденные причины веса, не трогая внешний вид чертежа. Векторный потоп из штриховки превращается в аккуратный снимок области, штриховки-гиганты — в плоскую заливку там, где глаз все равно не различит линии. Фотографии пережимаются без потери читаемости, технический мусор от CAD-экспорта вычищается. Механику внутри раскрывать не будем — важен результат.
Результат на реальном альбоме: 192 листа, было 286 МБ — стало 127 МБ. Самая тяжелая страница, раньше открывавшаяся минуту-другую, теперь открывается за 0,24 секунды. До 20 МБ — бесплатно.
Иногда вылеченный файл весит больше исходного. Это не баг: мы лечим не мегабайты, а то, из-за чего файл тормозит, — количество объектов, которые ридер пересчитывает при открытии страницы. Снимок сложной штриховки может занимать чуть больше места, чем сжатая до предела картинка, но открывается мгновенно — пересчитывать там нечего. Если цель — пройти лимит вложения, вес все равно падает в разы. Но если цель — чтобы сметчик пролистал альбом без зависаний, важны не мегабайты на счетчике, а секунды до отрисовки. Мы решаем именно вторую задачу — попутно обычно решая и первую. Подробный разбор скорости с замерами — в статье «Вес — ничто, скорость — все».
Итог. 122 МБ у одного чертежа против 0,9 МБ у соседнего листа — не «AutoCAD плохой» и не «проектировщик накосячил». Это побочный эффект того, как редактор печатает прозрачность и плотные штриховки: удобная для вас картинка превращается в неудобную для компьютера гору фрагментов. Компрессоры эту гору не видят — ищут не то. Форумные советы видят, но требуют доступа к исходнику, которого чаще всего нет именно у того, кому файл тяжелее всего достается.