Forums | Mahara Community
10 November 2010, 6:59
Forum to discuss the proposed inclusion of PDF Export.
10 November 2010, 9:12
I would be interested in seeing more of the technical implementation details for this. For example, why do you not see it appearing on the export screen (which currently gives the options of exporting views and artefacts as html or leap2a, which comes from the list of active export plugins).
Also, using the export plugin API, you don't have to have a new option to enable/disable this. You can use the normal way to disable plugins, and you can use the check_plugin_sanity hook to check for the dependency probably (you may need to add export_check_plugin_sanity method in the base export class, like artefact has).
10 November 2010, 9:35
Thanks for that. The export API information is very useful and will help with the wkhtmltopdf dependency.
We do see the this as being available on the export screen as you suggest and this is in the specification as part of the second paragraph in the 'Implementation' section. We were thinking that the user could export from there and also from the bottom of the view itself next to the 'Print' option.
I realise that on the view itself isn't something that the other export types have available but for PDF export this seems appropriate. If a tutor, for example, wanted to download a PDF export of a students view themselves (access rights permitting of course) then it is available and because it won't offer any more information that can't already be 'downloaded' via a standard print on the view allowing non-view owners this ability wouldn't be exposing any extra information. Though there might be some interest/argument for having this particular option turned on and off at some level?
10 November 2010, 9:44
I think these sorts of changes should make their way into the export API actually. It potentially also makes sense to export a view as plain HTML.
In the general case, when the API is too naïve, the solution is probably to change it (as long as it makes sense for the other plugins).
Maybe there should be another export API method called something like nonowners_can_export and leap2a wouldn't allow it but maybe the other two could (or it could be configurable per-plugin).
10 November 2010, 14:57
Thanks for opening that forum. One thing I wanted to add was that the PDF export should make URLs visible. I haven't tried the tool you propose. If it makes links clickable in the output then we wouldn't necessarily need any plain URLs. However, this might come in handy for external content.
E.g. If I print a PDF and only see the first screen from a YouTube video or a slideshare presentation, how am I going to find them again? Thus, at least these URLs should be resolved and put somewhere, e.g. at the bottom of the page as footnotes or something like that.
I second listing PDF export on Export page but also on individual views -> Is just easier if you are on the view to click "Print as PDF". ;-)
10 November 2010, 22:29
One thing that stands out about wkhtmltopdf from the description of the Debian package is this:
"This program requires an X11 server to run."
If this is actually the case (I haven't checked), have you thought about providing other HTML -> PDF tools as alternatives? I don't think that many production servers will have an xserver running on them.
11 November 2010, 5:54
That is true, although there are several work arounds and in some brief initial testing using Xvfb appears the simplest way to work around this. However this needs to be tested more and does create another pre-requisite.
I'm also interested in investigating how Drupal implements their wkhtmltopdf support in more depth:
11 November 2010, 6:01
Worth looking at being able to support interfaces to multiple 3rd party programs though.
A post by Account deleted was deleted
12 September 2011, 8:37
is there a chance to get this soon? In some interviews my users requested an option to export their views into PDF files and I would like to fulfill that request.
How far is the plugin development process?