Комментарии 11
Браузер делает PDF файл в 3 раза больше чем wkhtmltopdf.
Так и не понял что не понравилось заказчику по этой фразе
Отправляем заказчику и получаем ответ, что отображаемое заключение должно полностью совпадать с PDF один в один
Один в один в Хроме? Покажите в Firefox, будет один в один с wkhtmltopdf .
Браузер делает PDF файл в 3 раза больше чем wkhtmltopdf.
Спасибо за замечание, действительно так. Chrome выдал почти вдвое больше размер по сравнению с wkhtmltopdf.
Один в один в Хроме? Покажите в Firefox, будет один в один с wkhtmltopdf .
Отображение в chrome и firefox должно быть идентично, а результат в PDF должен полностью совпадать с отображением в chrome и firefox.
Так и не понял что не понравилось заказчику по этой фразе
С помощью wkhtmltopdf на основе шаблона для генерации PDF и данных получался отличный PDF, но он отличался внешним видом от того, что видел пользователь: немного цвет другой, сдвинулся текст, перенос в другом месте и т.п. Это оказалось критичным.
Может сперва делать pdf, а потом показывать?
Во-первых, тогда пользователю придется ждать пока сгенерируется PDF на сервере.
Во-вторых, пользователю необходимо сразу видеть какой он получит результат
Так может вам с другой стороны надо было подойти и сделать просмотрщик HTML на основе QT webview и там же кнопку для сохранения в PDF, а не мучать попу с консольными утилитами. У нас html2pdf используется, чтобы генерить PDF в количестве 70К штук и рассылать клиентам. А у вас там пользователь ручками всё делает, так зачем вам вообще эти серверные решения?
// Create webview and load html source
QWebView webview;
webview.setHtml(htmlinput);
// Create PDF
webview.print(&printer);
Как именно? На сервере рендерить и отображать юзеру страницу для редактирования, или просто предпросмотр PDF сделать, или виджет какой-то? Мне непонятно, что именно предлагаете.
На ПК пользователя должен оставаться всё тот же фронт на React и Ant Design.
Ок, допустим откажемся от всех либ фронта, главное, чтобы отображалось как html,css, js в браузере и было возможно реализовать редактирование страницы меньшими затратами на разработку. как это сделать?
Так пускай у себя на компьютере и печатают из браузера. Посмотрел страницу и напечатал у себя на компьютере в PDF. Или им отключили кнопку печати из браузера? Где они смотрят свои html, css, js ?
Да, им отключили кнопку. PDF открывается по ссылке на него. Ссылку предоставляет бэк.
Потребовалась обязательная генерация PDF на сервере
Хранение сгенерированного PDF не требовалось и некоторое время это устраивало заказчика, до тех пор, пока не появилось требование генерировать PDF на стороне сервера.
Смысл отключать кнопку, если весь тот же функционал предоставляется? Извращения какие-то описываете. Не дай бог заказчика с шизой.
Заказчик сам не всегда знает что он хочет и что он захочет через месяц.
У меня была похожая задача лет 7 назад. Клиенту понравился отчёт, который я рисовал на страничке в браузере и ему захотелось скачать его в pdf одной кнопкой. Ну ок, самое простое - через API печати браузера делаем на фронте pdf и даём скачать. Клиент доволен.
Через неделю приходит - хочет чтобы была кнопка "отправить этот pdf по email другому юзеру (начальнику)". Хмм, чтож ты сразу не сказал, старый хрен.. Ок, в принципе сделать pdf мы уже можем - пусть фронт отправляет этот pdf на бэк, а тот его в письмо цепляет. Клиент доволен.
Черзе неделю приходит, говорит - у тебя уже всё же для этого сделано - мне неохота кнопку самому жать, пусть этот отчёт отправляется автоматически в 2 часа ночи..
Понятно что в 2 часа ночи никакой браузер кнопку сам не нажмёт. Нормального headless-Chrome и puppeter в докере 7 лет назад не было.. Наорал на диван, и сел переписывать всё на бэкенде на питоне. А там почти вся страница генерировалась браузером, около 1к строк на жабьем скрипте, графики и таблицы, кастомный css.. В итоге всё переделал, за код мне стыдно до сих пор.
От jsPDF к Chrome: решение сложной задачи рендеринга PDF с таблицами