Comments 32
опенсурс такой опенсурс. Плюсанул оба PR. А к мейтейнерам пробовали обращаться напрямую?
В бесплатном случае, скорее всего, — да, а при платной версии — зависит от условий.
Притом, никто и не скрывает, что бесплатное — это на свой страх и риск.
без этого api их оборудование в принципе неконкурентноспособно на рынке.
Если судь чисто по комменту — вы по каким то причинам с ними работаете. И видимо не вы одни. И похоже отток клиентов не такой, чтобы напрягаться и подтягивать. Т.е. формально они таки конкурентноспособны :)
За такие деньги дешевле реверс инженера взять который вам что нужно допишет
Ммм… Вы много знаете end-user коммерческого виндового софта к которому при покупке дадут исходники?
Попробовал распечатать локальный html-файл с картинками в Chrome. Фоновые картинки не подгрузились.
Где-то советуют использовать стили
body {
-webkit-print-color-adjust: exact !important;
print-color-adjust: exact !important;
}Но мне они не помогли. Задал явно формат:
@page {
size: A4 portrait;
}и заработало. Странно.
Могу ошибаться, но в wkhtmltopdf (как и в PhantomJS) используется древняя версия движка Webkit, еще та, что была до разделения на собственно Webkit и Blink (который сейчас в Chrome). Поэтому для печати лучше использовать Puppeteer или Playwright.
к wkhtmltopdf прилагается собственный форк Qt 4.8 с несколькими десятками изменений, внесённых специально для wkhtmltopdf.Похоже разработчики Qt так же проигнорировали багрепорты от разработчиков wkhtmltopdf. И они обиделись ;)
А как они WebKit обновляют, если там свой форк Qt4 и QtWebKit (зачем, вопрос отдельный), Qt4 официально не поддерживается давно (с 2015).
Переезжайте на puppeteer как можно скорее. Мы ловили разные баги, плоть до полного зависания определенных страниц.
Компиляция Linux-версий в Docker под Windows, скорее всего, невозможна в принципе
Да ладно?
Для командной строки Windows "../src\qt\configure" означает команду… с ключом /src\qt\configure — и естественно, что такая команда приводит к ошибке. Это значит, что удалённые вызовы os.path.abspath были не совсем лишними, и внутри def inside_vm(): придётся дважды обернуть использование src_dir в вызов os.path.abspath — при запуске qt/configure в самом начале сборки, и при запуске qmake в самом конце.
Вообще-то, достаточно заключить путь в двойные кавычки. Это, кстати, и после os.path.abspath надо обязательно делать, ведь в абсолютном пути могут быть пробелы.
Заставить (lib)webkit(gtk) печатать (в ps file) или экспортировать в pdf, безо всяких wkhtmltopdf, дело не абы какое сложное (сишный файлик со страницей кода)… Но зачем?
Когда есть куча способов прямо "иcкоропки", хоть тем же libre- или open-office:
soffice --convert-to --help
soffice --headless --norestore --writer --convert-to pdf --outdir "$target_path" *.htmlНу уж а модулей для всяких скриптовых чуть ли не десятки понаписаны, ну например WeasyPrint для python и тому подобные.
У офисов (у всех какие пробовал, включая MS) есть проблемы с импортом html, да и у библиотек — не основная их задача спеки там всякие соблюдать. По сути нужно отдельные диалекты html/css изучать, чтобы готовить печатные документы через них из html/css, чтобы использовать имеющийся опыт команды в веб-вёрстке. Или учить кого-то работать непосредственно с pdf или офиснім форматом каким-то.
Ну у меня несколько "обратная" статистика… Да, офисы не всегда корректно импортируют сложные html, но зато они заточены под печать и работу с докуменами, а браузерные движки (особливо старые, например как в wkhtmltopdf) не всегда хорошо отображают то для печати (или экспорта в pdf), игнорят страничную разметку или стили, и т.д.
В любом случае проще поправить стиль или html, чем прыгать с бубном вокруг wkhtmltopdf, причем держа в уме что танцы вероятно повторятся с выкатом следующей версии.
Если не получается с браузерными движками, то проще уже генерировать непосредственно odt, docx или pdf — через их модель непосредственно. wkhtmltopdf я тоже не люблю из-за старости. сhrome/ium headless — как только начинаются маты с wkhtmltopdf, а потом работа или с офисом непосредственно, или с его файлами, без прокладки в виде html/css
нам wkhtmltopdf не подошел из-за древности движка. если страничка генерится не только для печати, но и должна функционировать как интерактивный отчет, то без современного движка никак. chrome --headless --print-to-pdf, как вариант. создание pdf в 1000 страниц A4 c табличками и plotly графиками занимает ~8 минут. в нашем конкртеном случае это было приемлемо.
Бегите с этого ужаса. Я перевёл на openhtmltopdf от danfickle (https://github.com/danfickle/openhtmltopdf), скорость увеличилась в 200 раз.
Сколько времени потратили чтобы добиться результата?
Как починить все самому, если баг-репорты игнорируются: отлаживаю wkhtmltopdf под Windows