If you look at http://code.google.com/p/wkhtmltopdf/wiki/IntegrationWithPhp the integration is done the other way around: pass an HTML file to the command line and recover the output. So there is no need for the tool to have access to the session.
It’s hard to see how converting HTML to PDF could ever be a proper solution, at most a quick-and-dirty one. The paged layout in PDF requires very different layout solutions than HTML. Using a PDF report generator is probably the only proper solution and many people seem to be doing it that way.
If we want to turn to wild ideas, it would be possible use Vaadin API for report generation. Vaadin is, after all, a kind of a document rendering API, if you leave the user interaction out. You’d just need an XML-based terminal adapter and probably some special paged layout components. That would make data binding easy and you could even reuse some of the UI code of an application. Actually, the old Toolkit 4 was a bit closer to that, with XSLT style sheet based themes for rendering the output from the XML UIDL. Just output UIDL → FO → PDF.
DOM to PDF would be interesting. Vaadin is a DOM manipulation API on the client (via GWT, of course). The key idea for 80% of the situations is NOT to have to do anything other than writing the original code – all I want is a reasonable printable version. I’m willing to tweak CSS, not willing to curse at XSLT for a couple days.
I may take a look at wkhtmltopdf as it could be a fit for our closer needs. Few customers want PDFs (bigger and non-native to the web, and the data inside is impossible for a human to determine without actually rendering it with a viewer), but we do a have few that would like a PDF for use in other systems. We have the HTML, so it could work.
I agree that a DOM to PDF would be great.
While I agree there may be issues with a “proper solution,” I think most people would be okay with the idea of whatever a browser renders and then prints to paper (or print-to-PDF which is also available) as being the resulting PDF is fine. Yes, you can’t get all of the power of PDF, but our customers don’t care about that, just that they have a PDF “image” – in fact, a regular image also suffices as a PDF replacement for quite a few.
Of course, this is off-topic to Vaadin, so sorry about that, but it’s great to hear from the community about any solutions they’ve come across, like wkhtmltopdf. The question for us is how easily can we integrate Java servlets with this tool as we don’t do high/batch volumes, so absolute performance shouldn’t be an big issue.
UPDATED:
Did take a look at wkhtmltopdf and it runs well on Linux (and presumably Windows and OSX too) and does one of the best jobs I’ve seen for “printing” HTML to PDF. It even did a nice job of taking several HTML files and producing a single PDF.
Yes, but how to get the actual HTML of a vaadin “page” from server side? You had to catch the HTML code sent to the client and all following JSON commands and manipulate that HTML like the client’s browser does… not an easy job.
You whould be able to do that by making a simple widget that takes the “document.body.innerHTML” from the DOM, when requested from the server-side in a variable, and sends it back to the server with updateVariable().
If you don’t want to make a custom widget, you could probably do it with JavaScript and getWindow().executeJavaScript(). You can “return” the result by writing it to a TextField, for example. You can find the TextField element by setting its ID with setDebugId() as done in
this post
.
Well, a widget would nevertheless be a more “proper” solution. If you or somebody else does it, perhaps post it as an add-on in Directory?
Ahh… never thought about that. I guess printing what-the-user-sees should be quite easy than. I’ll try that 
Well yeah, I have a bit trouble understanding that doing “Print → Print to File → Output format PDF → OK” is really so hard? …wait, it does work that way for everybody, doesn’t it? :blink:
Or are there some other use cases for outputting the UI to PDF?
The printable report is often very similar to, but not quite, the screen version.
In many cases, you will have a scrollable table on the actual UI, but you would like all rows in the printable version.
Some kludgery setting most extensible things to have undefined height, capturing the HTML, removing background colors and doing other “printable-version” stuff would often work nicely.
Ok, yes, but isn’t that something that only the application can do? It needs to have “show printable page” logic, where it rebuilds the view using the printable settings and possibly sets another theme. And then, lets the user hit the browser’s print button (or calls print() automatically).
What I don’t understand is that why does this make it necessary to generate a PDF on the server-side and not just let the user do the printing when the printable version is displayed? What’s the benefit of the PDF generation? Well, except for the case that the user doesn’t want to print but to have a PDF for archival or email and the browser/OS doesn’t support printing to PDF.
Yes, it is indeed something only the application can do; but it is much, much easier than rebuilding a page in a PDF library.
In my neck of the woods, patient laboratory results as selected by a nurse or doctor sometimes need to be printed as a report, and printing the HTML just doesn’t cut it. The main reason is that printing a web page is often extremely ugly, for example in your FavoritePainInTheNeck browser, lines are often split over two pages.
Ok, the oddities of the FavoritePainInTheNeck browser sound like a good reason. :mellow:
I would also mention that users - at least many of our users - would consider going “Print → Print to File → Output format PDF → OK” too technical and difficult. “Press Application Print Button → PDF” is exactly what they would want.
That is, if it were practical and feasible; I do not believe it is, or ever likely to be, at least not in a generic sense : I maintain that an application and a printed document are fundamentally two different things.
Cheers,
Charles
There wasn’t a ready screen dumper add-on and the widget was so simple to make that I wrote it quickly and threw it
in Directory
. It seems to work for me at least. Oh, and
here’s the demo
. If it helps somebody with the PDF generation, great. I believe it could have some other uses as well.
Very nice !
Can this add-on be used only with a specific layout instead of the complete screen??..
thanks!!
What about using DynamicJasper ? it has PDF output feature among others. It is working fine under Vaadin…
http://dynamicjasper.com/features/
It doesn’t work well.