21–30 of 51 posts
Can anyone recommend an equally good opposite (HTML to PDF)? wkhtmltopdf [0] is probably the most popular, but it's also ridiculously buggy. 0: https://code.google.com/p/wkhtmltopdf/
I didn't see any mention of tables in the doc. Does this means it's outside of the "good enough" range? Table extraction would be a great feature.
Features about recognition would be planned in the future, usually PDF viewers do not recognize too many things, do they? :)
Earlier quoted context omitted.
You don't want to rely on the computing power at the client side, do you? :)
I guess one possible setup would be pdf.js running on server-side and having its output captured. One advantage of this, from what I can see, is that there would probably be fewer external dependencies than this setup.
It would be definitely interesting in that way, but in that case it may not be worth it to rewrite everything in JS.
Promising start. Hopefully performance improves with each release.
This works and displays correctly, but is unbearably slow on iPad 2 whereas the PDF loads instantly. What is the point then or does it work a lot better in desktop browsers?
The OSX Quartz graphic layer (also used in iOS) uses PDF internally as graphic object model. It is no surprise iOS handles rendering PDF's so quickly and so well and without the need for an third party app, it always has from the release of the first iPhone. This is also why print to PDF is built in on OSX.
Can anyone recommend an equally good opposite (HTML to PDF)? wkhtmltopdf [0] is probably the most popular, but it's also ridiculously buggy. 0: https://code.google.com/p/wkhtmltopdf/
http://phantomjs.org/ is the best so far in my experience since it handles all the client side javascript properly. The PDF's it outputs are full vector not just rasters, it the same engine used in Chrome to view PDF's and print web pages from my understanding.
It is definitely the best solution I've found so far. The outputted HTML / CSS / images look almost identical to the source PDF. That being said, there are a few issues still:
* One Gigantic (600kb) CSS file from a single PDF
* Hundreds of individual fonts
* HTML semantics are non-existent
These are all relatively easy to fix, I believe. I have found my own solutions to most of the issues in post-processing.
Kudos to you, coolwanglu. Also, I'd like to get in touch with you about lending a hand to fix some of the issues I've encountered.
Thanks for a cool piece of software!
Earlier quoted context omitted.
The OSX Quartz graphic layer (also used in iOS) uses PDF internally as graphic object model. It is no surprise iOS handles rendering PDF's so quickly and so well and without the need for an third party app, it always has from the release of the first iPhone. This is also why print to PDF is built in on OSX.
I thought it was postscript internally?
Earlier quoted context omitted.
I thought it was postscript internally?
NeXT and NeWS were Display Postscript. OS X / Quartz is PDF.
PDF the file format adds many, many things to that (forms, encryption, DRM, notes, a JavaScript engine, reflow information, etc)