Skip to content
This repository has been archived by the owner on Jan 2, 2023. It is now read-only.

Update WebKit Engine #4652

Open
YvesR opened this issue Mar 30, 2020 · 20 comments
Open

Update WebKit Engine #4652

YvesR opened this issue Mar 30, 2020 · 20 comments
Labels
Milestone

Comments

@YvesR
Copy link

YvesR commented Mar 30, 2020

Description
Hello @ashkulz , id like to contact you, but your user profile has no email address provided.
We do you wkhtmltopdf and we do need a new webkit engine inside. It looks like the current one is few years old.

Now we can fork this and try it our own or better solution is probably get in contact with you to figure something out together (possible support bidget wise as well if needed).

Please get in contact with me so we can discuss, thank you.
Kind regards, Yves

@Sicos1977
Copy link

Why not use Chrome? It has a headless option and is always up to date. Something like this --> https://github.com/Sicos1977/ChromeHtmlToPdf for example. Somebody also has made a fork that runs on Linux

@YvesR
Copy link
Author

YvesR commented Mar 30, 2020

@Sicos1977 because this is a different approach which is much slower. v0.12 is made with QT; has header, footer and page support and is very fast. Doing this with your approach I think we will do have a lot of work and also not sure if we can make this with same performance as well...

@Sicos1977
Copy link

Sicos1977 commented Mar 30, 2020

It's not that I'm here to promote the tool that I've made. I made ChromeHtmlToPdf because I used to use wkHtmlToPdf and ran into all kind of problems due to the lack of updates on it:

  • No HTML5 support
  • Old render engine
  • All kind of weird errors (like no support for gray PNG files)

Chrome also has header page and footer support...
I can't say anything according to the speed because I don't know what you call fast. But I'm using Chrome for about a year now and for simple pages it is done in less than half a second.

You can also just keep Chrome in memory if starting and stopping it is to slow.

@YvesR
Copy link
Author

YvesR commented Mar 30, 2020

@Sicos1977 I do appreciate your help and info, no doubt. Will check it out. We just run this and change it again will start a lot of work from scratch again. Hope we get an answer to clarify from @ashkulz . If he don't then there is not much of a choice anyway.

@ashkulz
Copy link
Member

ashkulz commented Mar 31, 2020

@YvesR: work on Qt/WebKit (which wkhtmltopdf depends on and uses) stopped for a number of years. You can support this effort, which is a majority of the work -- the wkhtmltopdf-specific stuff is in #3217.

From a usability standpoint, @Sicos1977 isn't too far off -- using Chrome via Puppeteer or some other headless wrapper is probably the best choice at this point. However, I'm not happy with the Chrome monoculture that's happened and hope to work/revive on this project again, but I haven't found the time 🤷‍♂

@YvesR
Copy link
Author

YvesR commented Mar 31, 2020

@ashkulz Thank you for your answer. The approach to use Qt/WebKit is my current favorite atm, but I am not that deep inside this development task.

  • Is it even possible to update the Engine in this project?
  • So far I understand you made a couple of changes there and now need to find the time to port this changes to latest version of Qt/WebKit?

@Sicos1977
Copy link

ChromeHtmlToPdf now also runs on Linux and macOS

https://github.com/Sicos1977/ChromeHtmlToPdf/releases/download/2.0/ChromeHtmlTopdf.zip

@pjg
Copy link

pjg commented May 7, 2020

I think the biggest drawback of using Chrome to render PDFs is its lack of DPI support, i.e. it will always render at at "web" DPI, equal to about 720px, which produces something close to a mobile view of a webpage. Using a high DPI in wkhtmltopdf makes for a much better PDF output.

@YvesR
Copy link
Author

YvesR commented May 7, 2020

Not only that, we biggest difference is still a lean and fast engine as a simple exe that creates my pdf, including many feature support. Maybe Chrome solution can do this, too all meanwhile... but the current solution works like a charm, only issue is that the webkit engine meanwhile is to old and lack some css support.

@thalisvilela
Copy link

I'm facing a huge problem, started developing an application using wkhtmltoimage, everything was great, until the project developed a little further, and the final html layout started to become complex, wkhtml couldn't render the pages properly, so we switched to Chrome/Puppeteer, and although the pages render flawlessly, the performance... oh boy... we can't release the product with the kind of performance we get with Puppeteer. It's a deadend.

@Sicos1977
Copy link

Sicos1977 commented May 7, 2020

Try my solution, I use it on a production system and it takes about half a second to convert a standard page to PDF

https://github.com/Sicos1977/ChromeHtmlToPdf

https://github.com/Sicos1977/ChromeHtmlToPdf/releases/download/2.0.11/ChromeHtmlToPdf_211.zip

Just keep Chrome open to avoid startup time (although it starts very fast) and keep feeding it pages

@Sicos1977
Copy link

Not only that, we biggest difference is still a lean and fast engine as a simple exe that creates my pdf, including many feature support. Maybe Chrome solution can do this, too all meanwhile... but the current solution works like a charm, only issue is that the webkit engine meanwhile is to old and lack some css support.

Another problem is also that the webkit engine doesn't get updated anymore, it is a dead end. I also used wkHtmlPdf for years until I came to that point that it had to many problems and so I created ChromeHtmlToPdf

@thalisvilela
Copy link

@Sicos1977 , is it possible to render html to image using your library?

@Sicos1977
Copy link

Sicos1977 commented May 7, 2020

Isnt it called ChromeHtmlToPdf ?? :-) ... yes it can render HTML to PDF with the use of Chrome.

I build it as an replacement for wkHtmlToPdf. The only thing that I still didn't include is the option to render HTML to Image, that is something that is still on my todo list.

@tbruckmaier
Copy link

tbruckmaier commented May 7, 2020

And for everyone on linux / preferring a nodejs solution there is https://github.com/dataverity/chromehtml2pdf

@Sicos1977
Copy link

@thalisvilela Any luck with solving your problem with ChromeHtmlToPdf?

@thalisvilela
Copy link

@Sicos1977 , i've told the project manager that we need serious horse power at the application backend. As we have a lot of things goin on under the hood, prior to generating the output, we have to perform several layout calculations and image processing (all javascript), on top of that, we run TensorFlow powered face recognition algorithms, and then more layout calculations. So, there's no way we can make it happen just with the performance gains of switching the rendering library. Raw horse power is what we need now. Optimizations will come later. Thanks for the response.

@stephenreay
Copy link

Not to crap on all the discussion about chrome or anything... @ashkulz I realise you probably meant contributions of code, but would financial contribution to pay for someone’s time be helpful here?

@YvesR
Copy link
Author

YvesR commented May 20, 2020

Not to crap on all the discussion about chrome or anything... @ashkulz I realise you probably meant contributions of code, but would financial contribution to pay for someone’s time be helpful here?

I mentioned the same, maybe not clear enough. I am also willing do financial contribution if this is a case

@ashkulz
Copy link
Member

ashkulz commented Jun 11, 2020

I've created a project status page on the website, which goes over this in more detail. The situation is a bit complex, and I've tried to write it down in detail as much as possible (although it's very likely I've made mistakes).

Due to family/work commitments, I don't think I can take financial contributions ... please support QtWebKit, progress over there will be a motivating factor to actually complete the 0.13 upgrade.

@ashkulz ashkulz added this to the 0.13.x milestone Jun 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

No branches or pull requests

7 participants