Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Safari export fails with images #3567

Closed
TorsteinHonsi opened this issue Nov 6, 2014 · 2 comments
Closed

Safari export fails with images #3567

TorsteinHonsi opened this issue Nov 6, 2014 · 2 comments

Comments

@TorsteinHonsi
Copy link
Collaborator

Reproduction steps

  1. Open Safari on the Mac
  2. Go to http://jsfiddle.net/highcharts/n1h9rfc5/
  3. From the menu, click Download as PNG.

The reason for the failure is that Safari adds an inferred namespace tag, NS1 in front of the image's href attribute. Thereby our exporting clean-up fails on this line:

.replace(/ href=/g, ' xlink:href=')

Workaround

I'm not sure if this is a generic fix across all cases and browsers, but filtering out the NS1 prefix is possible like this: http://jsfiddle.net/highcharts/n1h9rfc5/1/ .

@saifelse
Copy link

The workaround suggest is pretty hacky, especially since the more href's you have, a new prefix is generated, i.e. NS1, NS2, NS3, etc. I believe this is resulting from serializing an SVG as if it were HTML. When an SVG is serialized as HTML, it can lose its namespaces... and it looks like newer versions of Safari will generate an arbitrary namespace.

See Parsing and Serializing Nodes:

An XML serialization differs from an HTML serialization in the following ways:

Elements and attributes will always be serialized such that their namespaceURI is preserved. In some cases this means that an existing prefix, prefix declaration attribute or default namespace declaration attribute might be dropped, substituted or changed. An HTML serialization does not attempt to preserve the namespaceURI.
...

With XMLSerializer, doing new XMLSerializer().serializeToString(svg) instead of container.innerHTML seems like it should do the trick.

@TorsteinHonsi
Copy link
Collaborator Author

@saifelse It that works it is awesome, it would probably make many of our regex replacements while postprocessing the innerHTML obsolete as well.

Unfortunately the NS1 namespace is still present: http://jsfiddle.net/n1h9rfc5/3/

Any idea?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants