JsPDF - HTML5 PDF generator | Hacker News Reader

JsPDF - HTML5 PDF generator

parall.ax

191 pointssmanuel67 comments

Heh - This was first posted to hacker news over 1500 days ago. https://news.ycombinator.com/item?id=574854

It has definitely been posted to HN numerous times in the past. However, it seems the reason it was posted again this time is because the jsPDF website had a major design revamp.

At least, it looks very different from when I last used it ~6 months ago.

Cannot get it to work for me. It shows only a blank page, both in the in-page viewer, and the saved document locally. I am on a linux Mint 15 and Firefox 23

It's the same in Firefox Nightly 26.

Same for FF 23.0.1 on Windows something or other.

Same on Chrome 24, using Ubuntu. I just copied the Download like directly and will play with it later. http://parall.ax/parallax/downloads/jsPDF-0.9.0rc2.zip

The version at http://mrrio.github.io/jsPDF/ works for me in FF23.

This is pretty awesome, but I think something that could PDF an html page would be much more valuable. Currently I have to use some wkhtmltopdf server-side trickery.

Use PhantomJS to Create PDFs from HTML: https://coderwall.com/p/5vmo1g

Thank you for the lead - looks good. I found this, which goes into a bit more details for the Rails folks (like me):

http://big-elephants.com/2012-12/pdf-rendering-with-phantomj...

Looks very promising. Open to suggestions if others have better PDF-generating solutions!

What they don't tell you is that this method takes a long time and generates huge files unless you used a patched version of qt. I've been meaning to write a blog post on this.

Please do.

PhantomJS uses the same mechanism that wkhtmltopdf uses (headless webkit) and thus requires the 'server-side trickery' mentioned by the parent.

Also, the correct link is http://phantomjs.org/

I've used PrinceXML in the past and it worked well: http://www.princexml.com/

For use on the web you'll need a server license, though, which is $3800 for one machine. Fine if it's a business with revenue, but pretty steep for side projects or free services.

(There's also a free version for non-commercial users, but it's really only usable for evaluation, because it adds a PrinceXML logo to the generated PDFs.)

We offer our database publishing software as open source (http://speedata.github.io/publisher/index.html). It is used in many commercial environments as a better alternative to XSL-FO. Our software allows much more flexible layouts. That said: english documentation is still behind and we are lacking nice show cases. If you need more info, just contact me.

IIRC it's one of the few big applications written with Mercury functional logic language.

Last time I had to generate pdf's, I just generated latex markup and then rendered it to pdf.

You could look into something like http://prawn.majesticseacreature.com/ though.

The nice thing about HTML is that it does layout for you. If you have to generate PDF yourself you have to do the layout, in particular sizing tables is a huge pain...

Latex also does the layout for you. Thats the entire point :).

Also, it is surprisingly fast.

It's a new layout, though.

Yes and one better suited for PDFs I would think: PDF files are a sequence of pages, and LaTeX pours a little effort into choosing page breaks, when I print HTML pages from a browser, the division into pages seems to done with the greedy algorithm.

The only thing that bothers be about LaTeX (or PDF readers?) is that I can't copy and paste cleanly from the document. Many glyphs get tied together, white space is lost, code doesn't come out cleanly, etc.

Thats mostly a PDF/viewer problem. PDF is not really meant for C&P.

Concerning quality of the PDF document, LaTeX very good in relation to other creators.

I absolutely agree in terms of quality.

For being a universal document format, it's very frustrating that PDF readers don't make using them easier.

Looking at http://en.wikibooks.org/wiki/LaTeX/Tables I see that the column width needs to be specified to avoid text overflow. HTML does much better job, automatically fitting a table to desired width.

It's not as easy to lay things out nicely when you have things of an unknown length that could spread out to multiple pages with HTML as with pretty much any other method.

I was using LaTeX => PDF generation, but because I don't do it all the time I found it cumbersome and confusing at times.

Prawn seems to have come a long way since I used it last - and has addressed all the limitations that pushed me towards LaTeX in the first place.

Definitely worth looking at Prawn again in my opinion.

The version of this I used had basic HTML Rendering in it. I believe that the author (@mrRio) was going to do more on that. It looks, for the moment, that they've stopped mentioning the HTML rendering though, so maybe that was too tricky.

Maybe the prior HTML rendering functions are still in the source. I think it's worth downloading and checking.

Another option is WeasyPrint — although it is rather slow.

wkhtmltopdf to me is very unstable and crashes quite often.

How have you found it?

It's been pretty flawless for me. I'm running the 64 bit 0.11.0 static RC1. Like another post said though, it's really a pain to handle page breaks, page numbers, headers/footers etc. But for straight HTML page -> PDF it's really good.

> Currently I have to use some wkhtmltopdf server-side trickery.

I've used wkhtmltopdf, but lately I've discovered that Chrome does a pretty good job if you print a page, then specify print-to-file to a PDF destination.

That's probably the same rendering engine as wkhtmltopdf; the wk stands for webkit.

Yes, that occurred to me, but the outcomes are different. The Chrome printing route produces better results.

HTMLtoPDF is so convenient until you need clean page breaks, page numbers, consistent header/footers etc..getting that right is extremely tedious with HTML so until now i always needed to revert back to a full blown (often expensive) PDF lib. Any1 has a better solution ?

Watching this under Firefox gives a nice JsPDF -> PDF.js homolinguistic loop.

Github link is missing on that page. https://github.com/MrRio/jsPDF

Previously hosted at JsPDF.Com. I'm not sure why it's moved, but I've used this library and can attest to its awesomeness. It seems really stable to me. I use it to create and print off 4 page employment applications.

Gotchas : 1 - It can be hard to get downloading working using the Flash shim (For IE9 and below). It is possible though. 2 - Images have to be Base64 encoded, and that can be a royal pain.

I'm not the worlds best developer by a long chalk, but I had this library wrapped in a reporting class in a couple of days, and I can now pretty easily just throw some JS Structures at it, and have the tabular data printed out with headers and footers. I wish I could share it.

You can use the data url of the image, I made a small test here: http://cuenca-stuff.s3.amazonaws.com/jpgtopdf/index.html

(I don't know if by "base64" you mean "data url", which usually encodes the raw data in base64...)

I much prefer wkhtmltopdf: https://wkhtmltopdf.googlecode.com/

It essentially allows you to make an HTML page and convert it to a PDF. It has powerful options around making footers, headers etc. The best part is you can run jQuery on it. It comes in handy when you don't know what the data will be like.

This is very interesting. Careful using only client-side technologies to generate PDFs though. What if down the line you get another user requirement, such as having a PDF generated and mailed to the user?

Assuming you are not using Node.js as a backend, that might pose a problem, and cause you to possibly maintain the logic for two separate PDF generators.

Wouldn't a TeX engine written in Ecmascript make more sense?

A Web2JS of sorts maybe...

Though I'm more inclined towards using XeTeX since it solves a lot of problems without gluing a whole new language (LuaTex anyone?) in there.

I believe someone posted a link to Speedata tool which uses LuaTeX. https://news.ycombinator.com/item?id=6273668

Have you heard of https://github.com/manuels/texlive.js ?

Small Typo: "A HTML5 client-side solution for generating PDFs". I think it should be "An HTML5 client-side solution for generating PDFs".

Fiercely off topic, but it depends on your pronunciation of "H"

Obligatory Mitchell & Webb http://www.youtube.com/watch?v=c3y0CD2CoCs

I've been using this library and I really like it. If only it could do svg, then embedding D3 charts would be a cinch. Keep up the good work, though.

Looks good, but the typesetting is a little off and I don't see any examples of paragraphs or line wrapping.

I built a PDF library for PHP many years ago and the hardest part was text, typesetting is a hard problem.

Looks good for exporting images and charts though.

Pretty useful, but didn't work on Firefox 23.0.1 here (just blank pdf).

On Chrome seems fine.

The version at http://mrrio.github.io/jsPDF/ works for me (on both Firefox and Chrome)

This is really good. Specially the real-time rendering as one changes the code. But it does not work with Unicode (I tried farsi) characters.

Why does most of things related to PDF do not work with unicode characters?

Why isn't the api compatible (or at least sympathetic with) 2D canvas? If it could do that, you'd be able to reuse so much code.

AFAIK there is not a free lib which approach the commercial pdf generators. page-layouting can be complex.

It's funny to see Firefox turn this back into HTML, CSS, and JavaScript with PDF.js...

Slightly off-topic, Pdf and Ps are just plain outdated for today. They're unreadable on small screens and for people with bad eyesight, and no one sane prints stuff out these days Html is better, but the real thing today is tablet apps. All docs should be published as interactive 10/7/5 inch apps. Books should also disappear and be replaced by that form factor. Scientific paper authors also need to realize this and replace latex with app programming and publish their work as apps.

Make documents available only as apps. This is a troll, right? You just gave us a very scary glimpse of the future.

Zinio and other magazine apps already do this. They're either encrypted SWFs or PDFs on the backend.

Yeah, but scientific papers? Isn't that just taking the human race a giant step backwards?

So paper is the final frontier?

Hundreds of years old tech is the optimum and 21st century tech like tablet computers is a step backwards for humanity?

Are you intentionally missing the point? The objection was with apps and encrypted SWFs/PDFs, not all "21st century tech".

OK .... looks like someone's in a bad mood

Well no other tech has been demonstrated to last for literally centuries, other than paper.

The advantages for PDF is printing. You can't just set correctly page margins and other things with plain HTML.

My point is - why is anyone printing anymore? Everyone can get their hands on a tablet these days

As far as I can tell no file viewer or eBook reader tries to make browsing through a large file as convenient as physical page flipping. Electronic reading does let you find specific phrases, or go to an exact page number but browsing is still very inconvenient.

Reply on news.ycombinator.com