Bug 975591 - invalid svg file may be generated (unmatched "</g>" tag)
Summary: invalid svg file may be generated (unmatched "</g>" tag)
Alias: None
Product: Fedora
Classification: Fedora
Component: gnuplot
Version: 18
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Frantisek Kluknavsky
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-06-18 20:38 UTC by Steve Tyler
Modified: 2013-11-08 09:54 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-11-08 09:54:30 UTC
Type: Bug

Attachments (Terms of Use)
test-svg-output-2.g test file (98 bytes, text/plain)
2013-06-18 20:40 UTC, Steve Tyler
no flags Details
test-svg-output-2.svg invalid svg file (12.71 KB, text/plain)
2013-06-18 20:43 UTC, Steve Tyler
no flags Details
test-svg-output-2.svg.PATCHED (12.71 KB, text/plain)
2013-06-18 20:48 UTC, Steve Tyler
no flags Details
w3c-svg-validation-errors-1.txt (1.19 KB, text/plain)
2013-06-23 21:35 UTC, Steve Tyler
no flags Details

Description Steve Tyler 2013-06-18 20:38:08 UTC
Description of problem:
The following test file generates invalid svg output. Specifically, there is an unmatched "</g>" tag in the second line from the end.

$ cat test-svg-output-2.g
# test-svg-output-2.g

set terminal svg
set output 'test-svg-output-2.svg'

plot x
replot 2*x

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. $ gnuplot test-svg-output-2.g
2. $ eog test-svg-output-2.svg
3. $ inkscape test-svg-output-2.svg

Actual results:
Both eog and inkscape report errors and do not display the plot:

$ eog test-svg-output-2.svg

(eog:4850): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Error domain 1 code 76 on line 174 column 5 of file:///home/XXX/test-svg-output-2.svg: Opening and ending tag mismatch: svg line 0 and g

(eog:4850): EOG-CRITICAL **: eog_list_store_length: assertion `EOG_IS_LIST_STORE (store)' failed

$ inkscape test-svg-output-2.svg
/home/XXX/test-svg-output-2.svg:174: parser error : Opening and ending tag mismatch: svg line 4 and g
/home/stephent/src/exp/gnuplot/test-svg-output-2.svg:175: parser error : Extra content at the end of the document

Expected results:
Plot is displayed without errors.

Additional info:

Comment 1 Steve Tyler 2013-06-18 20:40:11 UTC
Created attachment 762637 [details]
test-svg-output-2.g test file

Comment 2 Steve Tyler 2013-06-18 20:43:12 UTC
Created attachment 762638 [details]
test-svg-output-2.svg invalid svg file

Comment 3 Steve Tyler 2013-06-18 20:48:30 UTC
Created attachment 762639 [details]

Both eog and inkscape display this patched file as expected:

$ diff -u test-svg-output-2.svg test-svg-output-2.svg.PATCHED
--- test-svg-output-2.svg	2013-06-18 13:05:27.367037519 -0700
+++ test-svg-output-2.svg.PATCHED	2013-06-18 13:44:55.701392245 -0700
@@ -171,6 +171,7 @@
 <g style="fill:none; color:black; stroke:currentColor; stroke-width:1.00; stroke-linecap:butt; stroke-linejoin:miter">
 	<path  d='M45.6,16.7 L45.6,444.0 L575.0,444.0 L575.0,16.7 L45.6,16.7 Z  h0.01'/></g>

Comment 4 Steve Tyler 2013-06-23 21:35:20 UTC
Created attachment 764374 [details]

The gnuplot svg output also fails the W3C SVG validation test:

    Error Line 134, Column 9: ID "gnuplot_plot_1" already defined
    Error Line 174, Column 4: end tag for element "g" which is not open

Comment 5 Frantisek Kluknavsky 2013-11-07 11:04:14 UTC

Comment 6 Frantisek Kluknavsky 2013-11-08 09:54:30 UTC
To quote Ethan Merritt: "Confirmed.
The breakage seems to have occurred between 4.4.4 and 4.6.0.

On the other hand, this sequence of commands makes little sense for svg output. Unlike page-oriented formats (PostScript, PDF) or interactive displays that allow sequential inspection of plots (x11, wxt, qt), svg documents are not intended to hold more than one full-page display element. Even if the number of \<g>/\</g> pairings were correct, the 2 plots would lie on top of each other. The normal sequence would be to either reopen the output svg file (new "set output" command) before the "replot", or wrap both the 1st and 2nd plots in a multiplot sequence:
set multiplot layout 2,1
plot x
unset multiplot

So while I agree than producing a corrupt document is not helpful, fixing that will only reveal an underlying problem in the command sequence that produced it."

These solutions work in Fedora. Or maybe multiplot layout 1,1 instead of 2,1 if that is what you want to achieve.

Note You need to log in before you can comment on or make changes to this bug.