How to export SVGs files with "BOKEH_RESOURCES=server"?

Community Support
1

I cannot export svg files because the process is stuck trying to load the file from temporary file that is stored in this path:

file:///C:\Users\UserName\AppData\Local\Temp\bokehkh29timo.html

This problem happens with the environment variables: BOKEH_RESOURCES=server-dev and BOKEH_RESOURCES=server. The bokeh script url looks OK in the temp file:

http://localhost:5006/static/js/bokeh.min.js

The bokeh.min.js script is loaded fine when I place the url in the browser. But when I export the svg and the html file is created in the temp folder, the script url cannot be loaded anymore.

The instruction when the stops the execution is this one

    web_driver.get("file:///" + tmp.path)

With BOKEH_RESOURCES=cdn or BOKEH_RESOURCES=inline (value by default) works well.

Is this wrong or it works as expected? Am I missing anything? Is there a way to change the resources dynamically just to export them with the inline bokeh script and workaround this?

from os import environ
if 'BOKEH_RESOURCES' in environ:
    print('BOKEH RESOURCES: {}'.format(environ['BOKEH_RESOURCES']))

import numpy as np
from bokeh.plotting import figure
from bokeh.io import curdoc, export_svgs
from bokeh.models import Button
from bokeh.layouts import column

N = 10
x = np.random.random(size=N) * 10
y = np.random.random(size=N) * 10
radii = np.random.random(size=N) * 1.5

p = figure(
    x_axis_label='X axis',
    y_axis_label='Y axis',
    title='Random plot',
    tools="crosshair,pan,wheel_zoom,reset,save",
    output_backend = 'webgl',
)

p.scatter(
    x=x,
    y=y,
    radius=radii,
    fill_color='red',
    fill_alpha=0.6,
    line_color=None
)

def export_svg_file():
    print('Exporting plot.svg...')
    p.output_backend = "svg"
    export_svgs(p, filename="plot.svg")
    # p.output_backend = "webgl"

bt = Button(
    label="Export SVG",
    button_type="success",
    width=50
)

bt.on_click(export_svg_file)

curdoc().add_root(column(children=[bt, p]))
2

I’m confused as to why you would want to do this? The output of export_svg is an SVG file which has no reference to BokehJS resources at all. What is the rationale for trying to control how BokehJS resources are loaded in a temporary, intermediate HTML file that is not part of the final output?[1]

If this was a script generating also regular standalone output alongside the SVGs, then perhaps there is an obscure use case for setting BOKEH_RESOURCES=server, in which case the SVG export should probably be made to ignore the setting. But a Bokeh server app is always going to load BokehJS resources from the Bokeh server itself (without jumping through alot of hoops) so there is no reason to ever set BOKEH_RESOURCES for Bokeh server apps.

  1. The fact that there is an HTML file at all is purely an implementation detail. It entirely conceivable that SVG export could be rewritten to not create or use an intermediate HTML file at all. It should not be relied on, and how it works should not be relied on. ↩︎

3

Also, your code works for me on master. Looking at the actual SVG export code path, it is already supposed to always use INLINE resources. But there were some issues discovered in a recent PR where the built-in INLINE and CDN objects could get modified in ways that led to surprises (such as this!) That was fixed as part of the PR.

So SVG exports will always use INLINE resources in the tmp HTML (as they should), and Bokeh server app sessions will always load BokehJS from the server itself (as they always have). So definitely with the next release, there is no reason to set BOKEH_RESOURCES here. I am not sure why there would be now, either.

1 Like
4

Thanks Bryan for the detailed explanation. I have just tried with the latest version and works well with any resource (I was trying with the 1.3.4). Anyway I won’t set BOKEH_RESOURCES=server anymore as you recommend.

I asked the question only because I could not understand why the bokeh.js suddenly became unaccessible in the auxiliar HTML and I thought that something was wrong.

5

Well, arguably the previous behavior in that did not fix INLINE resources for exports was a bug :slight_smile: