[SVG output] Adding image with URL or base64 url format creates invalid SVG

[istvanherbak]

Expected behaviour

The ouptut is a well formatted SVG.

Actual behaviour

Whenever the output type is SVG the result is an invalid SVG result.

The error is :

This page contains the following errors:
... Namespace prefix xlink for href on image is not defined
Below is a rendering of the page up to the first error.

Reproduction steps

Take the request_infile.json from the samples\http folder. Change the "type" from png to svg

[DendisPatrik]

Is any progress on this bug? Right now I'm not able to create svg chart.

[jszuminski]

This past 2 weeks we've been focusing on other bugs and features related to the Export Server. This issue is now, however, on the top of my backlog's list once I can reproduce it locally.

The file that was mentioned in the issue (samples/http/request_infile.json) was written for PhantomJS, not for Puppeteer and does not follow the proper export config structure.

Here's a proper export structure for the Puppeteer version of the Export Server: https://github.com/highcharts/node-export-server/tree/stable?tab=readme-ov-file#loading-default-json-config

Please follow this new convention and provide me with a minimal reproducible example (.json file) which would allow me to reproduce this issue locally and then provide a solution as soon as possible.

Thanks in advance!

[DendisPatrik]

Hi @jakubSzuminski thanks for info.
You can just try it on this example. If I switch type -> "png" it's working correctly. But with type = "svg" it shows me an error what @istvanherbak mentioned above.

example_svg.json

Thanks

[OleksandrNikitin]

Hello @jakubSzuminski

We have the same issue while trying to generate an SVG file via a POST request with the following payload (JSON) against the node-export-server (CLI) within the docker container.

There's no issue with generating a PNG file with the same payload.
The payload works as expected on the old node-export-server with (node-export-server: 2.0.24, node: v10.19.0, npm: 6.14.4, CLI)

payload.json

node --version
v18.18.2

npm --version
9.6.6

highcharts-export-server
3.0.3

puppeteer
21.6.0

chromium --version
Chromium 119.0.6045.159 Alpine Linux

ENTRYPOINT highcharts-export-server --enableServer 1

We don't use any extra\custom configs, arguments, or environment variables for node-export-server.

Thanks

[jszuminski]

Thanks @OleksandrNikitin! That will be really helpful. I will keep you posted on this issue (I will try to take care of it next week).

[DendisPatrik]

Hi @jakubSzuminski do you have any update for this issue?

[jszuminski]

Apologies for the delay, there's been many other issues that we struggled with here.

Could you please test out the current master branch? We're about to release v4.0.0 and we believe that it might have been solved (at least from what we've checked). I've run the following:

node ./bin/cli.js --infile request_infile.json --outfile chart.svg

and this is my request_infile.json:

{
    "chart": {
      "type": "column"
    },
    "title": {
      "text": "Styling axes"
    },
    "yAxis": [
      {
        "className": "highcharts-color-0",
        "title": {
          "text": "Primary axis"
        }
      },
      {
        "className": "highcharts-color-1",
        "opposite": true,
        "title": {
          "text": "Secondary axis"
        }
      }
    ],
    "series": [
      {
        "data": [1, 3, 2, 4]
      },
      {
        "data": [324, 124, 547, 221],
        "yAxis": 1
      }
    ]
}

and it gets exported as expected. Please keep in mind that the config structure has changed (https://github.com/highcharts/node-export-server?tab=readme-ov-file#default-json-config) and not everything which worked for v2 will work for v3+.

[DendisPatrik]

Hi @jszuminski I tried it for my case and it's working correctly. Thanks

[jszuminski]

Great, love to hear that!

[DendisPatrik]

@jszuminski I found that this issue still occurs again if I'm sending more data to render.

[jszuminski]

@DendisPatrik could you please reproduce it and share reproduction steps? It still works here and it seems to me that it has been fixed.

[jszuminski]

This is a duplicate of this: #547 and it has been solved here: #550