-
Notifications
You must be signed in to change notification settings - Fork 646
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for using headless chrome instead of wkhtmltopdf. #733
base: master
Are you sure you want to change the base?
Conversation
Hi @erikaxel, any chance you can rebase to the latest master and fix the CI problem?, it looks like the problem is here:
|
dc99ae3
to
a70b987
Compare
Rebased, and checks green. |
Thanks @erikaxel, I used your solution with Elastic Beanstalk and added a new config to setup the puppeteer executablePath on launch options, you can see it here morellan@576c041 It was easier for me to deploy it on AWS Elastic Beanstalk Amazon AMI using a custom executable path. |
Is there any hope for this feature? We're considering using grover (which uses headless Chrome via puppeteer), but that comes with a boatload of Node dependencies which we would love to avoid. |
5417c09
to
d49a0ba
Compare
@unixmonkey Hi, I rebased this on the latest changes so it doesn't have merge conflicts anymore. PS: We are using this in production and have for the last couple of years, so it is quite stable. However, the code is perhaps not the most beautiful so let me know if you would like to get it in shape to actually be merged into this project. |
@erikaxel how satisfied are you with switch from the wkhtmltopdf to puppeter? Researching to migrate also. |
We are very happy with this. wkhtmltopdf is using such an old version of the renderer and with puppeteer we get the latest version whenever we want. We have used two versions, first we used one where we included Chrome in our docker build and then ran puppeteer locally. This fix does this and we used it for along time. Downside is that your image becomes quite a bit larger because of Chrome. So we have recently pulled this out and is serving it as an internal microservice instead, sending HTML, running puppetter and returning the PDF. |
I am not sure if this is the fully working compatible code. But its very disappointing that this feature is still not merged or doesn't have similar update for using other than wkhtmltopdf. Or if there really is a way to use something other than wkhtmltopdf, it should be documented and also let us know here. |
I'm not the primary maintainer of this library at this point, which is certainly obvious for anyone who has been involved. However, I want to chime in here. Part of what makes maintaining this gem more taxing than one would think is fielding questions that are primarily about @imlunek I hear you on being disappointed. However, we have not felt prepared to field questions about I am currently considering the possibility of forking WickedPDF to create a gem that is the same API as WickedPDF but uses puppeteer, or hell maybe I fork WickedPDF and bring this PR over. The reason for forking would be so that no one who is currently very involved here feels like they have to also answer questions about Puppeteer (unless they for some reason want to). No decisions made. Just wanted to give an update. I intend to let this PR remain open indefinitely so that it is visible for those who might want it now. |
Hi,
This pull request is a WIP and a starter for discussion on how wicked_pdf can support headless chrome in addition to wkhtmltopdf.
This might be useful to people since wkhtmltopdf has stagnated and is using a very old version of webkit.
We use this code in production, so it is battle tested, but probably needs some cleanup and documentation before it can be merged.
I also previously did a version with phantomjs #619 but since phantomjs is also abandoned, this pull request supersedes it. However, many of the discussions in the previous pull is probably also relevant here.
Any comments more than welcome!