Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

URL to PDF Microservice

github.com

Post reply on HN
Print view View original

21–30 of 95 posts

Re: URL to PDF Microservice

#21

Post by simion314 »

placebo wrote: post #19

Cool. Nice to learn of another option. What would be the advantages of using this over wkhtmltopdf ( https://wkhtmltopdf.org ) ?

I am testing pupeter/headless chrome, pdf export stil has some bugs, I hit an issue with page sizing and I am stil using wkhtmltopdf for now, the bug is present in main Chrome save as PDF. Chrome has better font rendering and it knows to embed the web fonts into the pdf where in wkhtmltopdf I have to do it manually.

Link to size bug: https://github.com/GoogleChrome/puppeteer/issues/666

Re: URL to PDF Microservice

#22

Post by bitdeveloper »

@kimmobru, would you happen to know how this would handle printing a multipage table to PDF? Specifically, I'm hoping for repeating headers per page, and not having any problems with rows printing half on one page, and half on the next page. I would love to replace a paid solution we use which handles this use cases with something based on headless chrome.

Re: URL to PDF Microservice

#23

Post by kimmobru »

placebo wrote: post #19

Cool. Nice to learn of another option. What would be the advantages of using this over wkhtmltopdf ( https://wkhtmltopdf.org ) ?

Thanks for the comment! I haven't personally used wkhtmltopdf much, but I like having Chrome as the rendering engine. In theory at least, debugging the PDFs can be done with desktop Chrome's print preview. I don't know about wkhtmltopdf, but url-to-pdf-api supports dynamic single-page apps, which can be beneficial depending on the use case.

Headless Chrome is quite new so it still has some bugs, but I have a hunch that it will in the end have most reliable and expected render results.

Re: URL to PDF Microservice

#25

Post by kimmobru »

renke1 wrote: post #15

I 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 look incorrect when rendered. &scrollPage=true parameter may help with this. It scrolls the page to the bottom before rendering the PDF.

Using these options make the PDF better: https://url-to-pdf-api.herokuapp.com/api/render?url=https://...

Re: URL to PDF Microservice

#26

Post by kimmobru »

aantix wrote: post #2

I 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.

Scaling is a challenge definitely. Rendering image-heavy sites requires quite a lot of RAM. But as others have stated, the good news are you can quite easily scale this horizontally by adding more servers. There's no shared state between the server instances behind a load balancer.

There's also room for improvement in how efficiently a single server instance can render PDFs. The API doesn't yet support resource pooling, this would make reusing the same Chrome process (with e.g. 4 tabs) possible. The implementation requires careful consideration since in that model it's possible to accidentally share content from previous requests to the new requesters.

Re: URL to PDF Microservice

#27

Post by misterbwong »

hobofan wrote: post #16
Scarbutt wrote: post #14

Earlier quoted context omitted.

But its no scalable, making it serverless just makes scalable at a huge cost.

You are contradicting yourself. It is scalable. It scales linearly (and for practical purposes indefinitely) with the amount of money you spend on AWS Lambda. It might not have a nice constant factor, but it is scalable.

This is just pedantic. Anything can be scalable using that definition. Heck, I could hire a 3rd world worker to manually draw the PDF's, scan them to PDF using a scanner, and put them on a server and it would "scale linearly with the amount of money I spend" on labor.

Re: URL to PDF Microservice

#28

Post by adrianpike »

homero wrote: post #13
erdbeerkaese wrote: post #6

Unfortunately, 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.

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. :(

Re: URL to PDF Microservice

#30

Post by hex1848 »

I am using PhantomJS for a similar project running on AWS Lambda - running into all sorts of rendering bugs / crashes. Wanted to make the switch to puppeteer, but as of now it requires a higher version of NodeJS than what Lambda supports. Was in the process of looking at Docker containers for my service, anyone have any thoughts on Heroku vs Docker?
Post reply on HN