FishHook
А Django тут каким боком то?
В одной конторе часть их CRM сделана именно на Django. Некоторые их документы генеряться в html а потом идут на печать, при отправке большого массива на печать принтеры вырубаются через переполнение задания, для решения этой проблемы было решено конвертировать html в pdf (pdf-вювери встроенные в браузер берут контроль очереди печати на себя). Так как верстка документов очень специфическая с корректным конвертированием только один wkhtmltopdf и справляться, но его запуск конечно ресурсоемкий.
От я и пробую разные варианты.
daniel
Доброго времени суток!“Склеить” pdf в памяти (на лету - это как раз в ней родимой) возможно, но это довольно затратно для ресурсов.К примеру, умеет это http://pybrary.net/pyPdf/Я бы рекомендовал Вам вынести сборку pdf из http-response и создать очередь заданий с лимитированным количество одновременных процессов, дабы не перегрузить сервер подомными процессами. А ссылку выдавать или ajax'ом после build'а, или же высылать пользователю на email и пр.Спасибо.
Как то не очень хочется менять структуру проекта только для одной печати, хотя конечно самым логичным вариантом было бы использовать celery, но я решил генерить все таки в вюхе по одному документу на запрос, а запросы будут погружаться с помощью периодических запросов из javascript, посмотрю что получиться.
Singularity
Может просто затарить или zip ?
Конечно было б хорошо, но: если затарить то при открытии документа будет отображаться только первая страница, так как pdf имеет непростую структуру, но при zip конечно pdf-вювер не сможет отобразить. Просто как я понял (может и не правильно) PyPdf2 при склеивании pdf уж много в оперативку загружает.