How to specify encoding for SVG background rendering?

[jri]

Rendering SVG node background images does work in principle (the white background and the text "Node" are rendered as SVG <rect> and <text>respectively):

https://jsfiddle.net/u7asnwdp/6/

But if a SVG <text> element contains an Umlaut (e.g. ä ö ü) SVG rendering breaks completely (here the red background is a result of Cytoscape style 'background-color': 'red'):

https://jsfiddle.net/jri_/hrxp965e/

Apparently this is an error in the Cytoscape SVG rendering code.

That pure SVG (without Cytoscape involved) has no problem with rendering Umlaute is shown here:

https://jsfiddle.net/jri_/26cr7q1e/1/

[jri]

Sorry, only now I've realized that I can use unicode numbers. This works properly:

<text>N&#x00f6;de</text>

Do I have to transform my DB text content before rendering?

Or is there any way to specify the encoding at rendering time, like

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg>...</svg>

I tried that in Cytoscape but it does not work:
https://jsfiddle.net/jri_/hrxp965e/1/

(Note: jsfiddle's result html has <meta http-equiv="content-type" content="text/html; charset=UTF-8">)

[jri]

Sorry again. Now I've tried ISO encoding, and it works!

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<svg>...</svg>

https://jsfiddle.net/jri_/hrxp965e/2/

What puzzles me is that source entered/rendered at the JSFiddle site is apparently encoded in UTF-8 but properly rendered only when ISO-8859-1 is specified as XML encoding (see above).

https://jsfiddle.net/jri_/fkmvs6qL/

[jri]

There are browser differences too.

This works in Safari, and Firefox, but not in Chrome:

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<svg>...</svg>

https://jsfiddle.net/jri_/hrxp965e/3/

[maxkfranz]

If it's working in some browsers and not others, then it's a bug in the way that the particular browser draws an svg image to canvas. Browsers seem to have differences in how they render svg to canvas as compared to how they render svg in the html dom.

A few years ago, even basic svg in the dom had many bugs and differences between the browsers. Maybe it's a bit better now, but unreliable browser support for svg is one of the reasons cyjs uses canvas.

There's not much that can be done on the cyjs end to remedy that. So it's probably best to file bugs in the issue trackers for the offending browsers.

This is the most reliable way of using svg data uri images that we've found:

'background-image': 'data:image/svg+xml;charset=utf-8,' + encodeURIComponent(svg)

This way you can explicitly specify the encoding --- in both the url and the svg itself just in case the browser ignores one --- and encodeURIComponent() handles non-ascii characters. Maybe that will work better for you. Even if it does, I think it still makes sense to report bugs in browser issue trackers. The browsers shouldn't treat proper support for European languages as an afterthought.

[maxkfranz]

It seems to work in this case: https://jsfiddle.net/hrxp965e/4/

[jri]

'background-image': 'data:image/svg+xml;charset=utf-8,' + encodeURIComponent(svg)

Indeed, not using Base64 encoding and encode with encodeURIComponent instead solves the problem!

This way it works in all my browsers (Safari, Firefox, Chrome) even without specifying charset in the data URL and without the XML declaration (<?xml version="1.0" encoding="..."?>), provided the source file contains a proper <meta charset="..."> header (in case of ISO-8859-1 even that header is not necessary).

This was a very helpful hint!
Thank you very much!
:-)

This issue can be closed.

You're right, we should file browser bug reports.