#2032 svg term and replot

[Anonymous]

Hello!

The svg terminal does not produce correct SVG files with the replot command.
Example:

set encoding utf8
set term svg size 640,384 enhanced
set output "out.svg"
plot sin(x), cos(x)

works OK, whareas:

[...]
plot sin(x)
replot cos(x)

produces a wrong SVG file with two "instances" of the root

Regards,
Rafal

[Ethan Merritt]

An svg file contains only one page, just as a png or jpeg file contains only one picture.
If you need to place multiple plots on a single page, set the "multiplot" documentation.

[Rafal]

Hello again!

My case doesn't require the multiplot feature. I only need two (or more) curves to be plotted on one graph. I normally use the 'replot' command for this. And the resulting svg file contains several root <svg> tags in one document, which makes the whole XML invalid. Attached is an example of such a file.

On the contrary, when I save the picture from a wxt terminal to svg, I get a correct file but here all the labels and numbers are saved not as text but as glyph paths, which makes it impossible to further edit them in the svg file.

[Karl Ratzsch]

If you (re)set the output file just before the last "replot", it comes out all right. "replot" doesn't just add to the existing plot, but recreates everything (at least in the output) from scratch.

[Bastian Märkisch]

The recommended way having multiple functions or datsets in one plot is to specify them in a single command.

plot sin(x), cos(x)

Note that you can break long lines with a backslash.

[Bastian Märkisch]

I suppose we could add  a seek command to the svg terminal as is done in other places to get a cleaner behaviour. That would overwrite the previous plot.

[Ethan Merritt]

It would not be sufficient to use fseek/lseek because this does not remove the previous contents of the file. If the second output stream is shorter than the first one it leaves a corrupt output file on close because the tail of the original contents is still there. Adding ftruncate to solve this is problematic and non-portable because it would mix stream-based and fd-based IO operations.

The only existing terminal which uses fseek at the beginning of a plot is emf. It suffers from the same problem of not removing the original file contents, but since emf writes an explicit size in the header records at the end of a plot the file is still usable even though it contains garbage at the end. This doesn't work for most other terminal types.

[Bastian Märkisch]

Actually, there are some terminals which use fseek in that case: emf.trm, pstricks.trm , lua.trm, tkcanvas.trm. The last two do the sequence fseek / fflush / ftruncate. So I presume we could at least try. If it doesn't work on some platforms, we would still end up with broken output. FWIW, it works as intended on Windows with Mingw64.