Export to PDF does not work

[rattkin]

Export to pdf with DW2PDF Plugin does not work. Instead of image, this is displayed:

Printing works OK.

[andyboeh]

The diagram is rendered using JavaScript in your web browser, while the PDF created by dw2pdf is rendered on the server using mPDF. Therefore, only the base64 encoded diagram is shown.

[rattkin]

What can i do to be able to export the diagram? I need it in the PDF!

[jdehaan]

I tried to dig in the problem but it really seems not so easy to solve. I think I understood quite well what the problem is, it's exactly what you describe. In order to solve it we would "simply" (lol...) need a way to render the bpmnio into a picture or (SVG if supported by PDF) on the server side. This seems to be a kind of headache.
I tried to use dw2pdf in the past but it misses so many things (or other plugin miss things..) so it almost never generates a proper result if the pages make use of many plugin features. I had trouble to get rendered pages with the wrap plugin. This is really a very simple plugin and have also trouble... There is also a ticket for pdf issue in wrap plugin filed.
I understand the need to bring stuff to paper or downloadable content to hand it out to people having no access to the wiki. I am still learning a lot regarding web development. If a solution appears in order to run javascript within dokuwiki on the server then there is a good chance to get it to work.
Unfortunately due to my workload do not expect this to be implemented timely...

[andyboeh]

One possibility would be using the editor patch: bpmnio-js provides rendering to SVG and, IIRC, also PNG. During editing, we could upload the rendered picture to a cache file. However, as soon as you change the bpmn syntax directly, the picture is lost.

I tried to find a bpmn rendering library for PHP, but couldn't find a good one. Another possibility would be some kind of node.js plugin for DokuWiki that allows server-sided rendering. I'm aware of a php-based node.js interface, but that requires Linux to be running on the server. I quite like the idea of a node.js plugin for DokuWiki as that would solve some rendering issues for other plugins as well - it's a hack, though.

[jdehaan]

I do not know if integrating node.js is a hack, it sounds to me more like the perfect solution. To have a clean rendering the server side should behave as close as possible like the client side rendering. In normal mode the client would do the job, for pdf rendering the server. Unfortunately I am not yet an expert in these topics. I try to get help in order to get more hints on how to do this.

[jdehaan]

-> https://www.dokuwiki.org/plugin:dw2pdf:exportsupport

[jdehaan]

Plan

Recommendation: implement dw2pdf export as a cached SVG fallback, not true server-side rendering. The plugin already renders diagrams in the browser and the bundled BPMN/DMN libraries already expose saveSVG, so the most realistic first version is to export SVG after a normal page render, store it by content hash, and let the existing dw2pdf branch use that cached SVG instead of the current placeholder in bpmnio.php.

1. Replace the dw2pdf placeholder path in bpmnio.php with a real fallback lookup based on a deterministic hash of the diagram XML plus type.
2. Extend the successful render flow in bpmnio_render.js so BPMN and DMN DRD diagrams call saveSVG after import and post the SVG back to the plugin.
3. Add one small server-side cache-save endpoint in editor.php or a dedicated new action file, with minimal validation for hash, type, and SVG payload.
4. Make the dw2pdf renderer emit the cached SVG, preferably inline SVG and otherwise an img fallback, and emit a short plain-text message when no cache exists.
5. Keep cache invalidation simple by using content-addressed filenames, so changed XML automatically gets a new cache key.
6. Add focused tests in syntax_plugin_bpmnio_bpmnio.test.php and action_plugin_bpmnio_editor.test.php for cache hit, cache miss, and request validation.
7. Document the limitation in README.md: PDF export works once the page has been rendered in a browser at least once; it is not full server-side rendering.

This is the simplest approach that fits the current architecture and avoids dragging Node or another renderer into a PHP plugin. The main limitation is first-view dependency, but that tradeoff is much smaller than the complexity of building always-server-rendered export.