If you're interested in archiving/PDF'ing a large list of links (e.g. your browser bookmarks or Pocket list), check out https://github.com/pirate/bookmark-archiver
URL to PDF Microservice
41–50 of 95 posts
Re: URL to PDF Microservice
#42Unfortunately, the "sensible defaults" don't seem to check input URLs correctly and allow file:// URLs. Just try ?url=file:///etc/passwd on the demo instance. That seems to be a quite common issue with services like this built on generic libraries.
Oh wow, that's a bit embarrassing :) The urls are now restricted to http and https only. Thanks for noticing!
I am not at a computer noe, so I can’t test it, but do you take redirects into account? I hope you are not just whitelisting the initial URL, but also any URL’s it redirects to. If you don’t already, you should probably just disable redirects in whatever library you use.
Re: URL to PDF Microservice
#43I wonder how scalable the service is... At least with PhantomJS I felt like my system would begin to lockup if there were too many instances rendering at the same time (and it didn't appear to be an issue of too little memory). Nonetheless, this looks promising.
You need to fire a new chrome headless process every time you create a PDF, its not scalable but it works. I wonder if this part of chrome could be easily extracted as a C++ library.
I've looked and it's not easy. There are different ways you can wrap the internals of chrome but really, it's hard to (and officially not recommended, from memory) pull out just a subset to work with.
Re: URL to PDF Microservice
#44I was playing around with Puppeteer the other day and was wondering if it was possible to render a web page to a single page PDF (a page with fixed width and variable height). Basically like creating screenshot without losing the text information. This would solve a lot problems such as sticky elements hiding text like in this example [1]. [1]: https://url-to-pdf-api.herokuapp.com/api/render?url=https://...
That's a good idea! You can achieve this by adding e.g. &pdf.width=1000px&pdf.height=10000px parameters. Sometimes you can get rid of the sticky headers with &emulateScreenMedia=false parameter if the page has well implemented @media print rules in CSS. We decided to use page.emulateMedia('screen') with Puppeteer to make PDFs look more like the actual web page by default. Pages which use lazy loading for images may l…
I bet that breaks on infinite scroll pages ?
Re: URL to PDF Microservice
#45Earlier quoted context omitted.
I've moved all my pdf to client side. Less security and processing on the server. http://pdfmake.org/#/gettingstarted
Is there a browser support matrix somewhere? This looks real promising but we need to support IE9. :(
Also consider non-Western languages (CJK, Russian, Arabic). My team got bit by this when we discovered we couldn't render emoji's client-side.
Re: URL to PDF Microservice
#46Partially off topic: does anybody know of a hosted solution that turns a pdf into an html page, and hosts the output html (optionally, also hosts the pdf, with a downloadable link).
Re: URL to PDF Microservice
#47Partially off topic: does anybody know of a hosted solution that turns a pdf into an html page, and hosts the output html (optionally, also hosts the pdf, with a downloadable link).
https://mozilla.github.io/pdf.js/ would probably be what you would need to build your own. I think you can also use just Google drive to make something like this.
Not sure of more straight forward hosting options
Re: URL to PDF Microservice
#48Took a quick skim of the README. I have a general question for these web-to-PDF services. Is the priority to honor the page styles as set forth in a print.css-type file? Or is it to be as close as a screenshot as possible of a webpage, which is what I think the majority of laypeople would expect.
One of the small things I've recently let myself be bothered by is how divergent HTML/browser snapshots from web.archive.org, archive.is, and Google cache can be, even for relatively simple pages. I've already given up on trying to make (not even sure if it's a good idea) HTML look nice as PDFs.
Re: URL to PDF Microservice
#49Took a quick skim of the README. I have a general question for these web-to-PDF services. Is the priority to honor the page styles as set forth in a print.css-type file? Or is it to be as close as a screenshot as possible of a webpage, which is what I think the majority of laypeople would expect. One of the small things I've recently let myself be bothered by is how divergent HTML/browser snapshots from web.archive.o…
This service seems to be targeted at producing controlled artefacts from your application (e.g. invoices) where you know what CSS is in use. If you wanted to capture the original design of the page you can use headless Chrome to capture screenshots automatically (https://medium.com/@dschnr/using-headless-chrome-as-an-autom...). Perhaps headless Chrome can also save the HTML plus assets, or some other archive format that would be interactive.
Edit: this seems to be a take on saving the HTML plus assets - https://github.com/pirate/bookmark-archiver.
Re: URL to PDF Microservice
#50It looks like chrome's javascript interface exposes options that the command line doesn't. Or else I'm overlooking something, because I couldn't find a way to to hide the header and footer (which shows the date, title, url, and page number) using the command line. But this project does hide the header and footer. I can't use an externally hosted service like this because some of my URLs are non-public. So when the us…
Just in case you missed it, you can clone the git repo for this project and use it inside your network. I'm playing with it now that way.
Right now, I'm using wkhtmltopdf which supports custom headers and footers and I'm mulling over how to do the same with this solution.