When I generate htmlhelp documentation, resulting chm file shows pretty useless as I get several popup dialogs for unsupported js functions, linked as bokeh plots, on every page there is a plot.
Choosing qthelp, also generates js bokeh plots, while qthelp does not seem to try to render these.
I would expect similar behavior with devhelp.
Also js bokeh plots are generated for epub.
So I was thinking about trying to output png from bokeh plot for use in help file, which I’ll then link to open bokeh js html in browser. But it seems that there is actually no such function exposed for rendering image, but just a save button to manually output bokeh plots.
Bokeh does not currently support headless (programmatic) generation of images. The primary motivation for creating Bokeh was to enable interactive visualizations inside browsers. There is a long standing open feature request to add static image generation:
Static image support is certainly something we would like to add, however as you can see from the extensive discussion there, it is a decidedly non-trivial task, and there are many other competing priorities, and limited resources. Because of the intrinsic JavaScript dependence, the only reasonable configuration for building the documentation is "make html". This could probably be made more explicit, and I have created an issue to do just that:
It's possible once there are static images that other docs build targets could become supported, but I expect it would take a motivated new contributor to make that happen. The docs build is large and complicated and updating it would be a real effort. The project needs are completely satisfied by HTML docs, so it is unlikely that adding other targets that have narrow usage could ever become a high priority for our very limited resources.
When I generate htmlhelp documentation, resulting chm file shows pretty useless as I get several popup dialogs for unsupported js functions, linked as bokeh plots, on every page there is a plot.
Choosing qthelp, also generates js bokeh plots, while qthelp does not seem to try to render these.
I would expect similar behavior with devhelp.
Also js bokeh plots are generated for epub.
So I was thinking about trying to output png from bokeh plot for use in help file, which I'll then link to open bokeh js html in browser. But it seems that there is actually no such function exposed for rendering image, but just a save button to manually output bokeh plots.
In the meantime I tried wkhtmltoimage (from wkhtmltopdf) but couldnt make it wait for bokeh with any available switch.
Then I tried phantomjs, edited resterize.js to wait for 2000ms and finally I got the image.
Maybe bokeh-plot directive can be extended, and maybe it’s not worth the effort, but I’ll try in next couple of days and report back if I succeed in automating doc generation for narrow used formats
Cheers
···
On Monday, June 13, 2016 at 1:21:36 AM UTC+2, Bryan Van de ven wrote:
Bokeh does not currently support headless (programmatic) generation of images. The primary motivation for creating Bokeh was to enable interactive visualizations inside browsers. There is a long standing open feature request to add static image generation:
Static image support is certainly something we would like to add, however as you can see from the extensive discussion there, it is a decidedly non-trivial task, and there are many other competing priorities, and limited resources. Because of the intrinsic JavaScript dependence, the only reasonable configuration for building the documentation is “make html”. This could probably be made more explicit, and I have created an issue to do just that:
It’s possible once there are static images that other docs build targets could become supported, but I expect it would take a motivated new contributor to make that happen. The docs build is large and complicated and updating it would be a real effort. The project needs are completely satisfied by HTML docs, so it is unlikely that adding other targets that have narrow usage could ever become a high priority for our very limited resources.
