eechema Plot/Export to SVG closes polylines incorrectly (lp:#1840769)

[Original report](https://bugs.launchpad.net/bugs/1840769) created by **follower (78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3jabxlrqbgszpjpwcmvkbcvq9spp6z3w5j1m33k06tlsfszeuscyt241h-launchpad-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x334n7di44o65qze67n1wneepmidnuwnde1rqcbpgdf70gtqq2x9thj5tlcsac)**
```
The patch
https://git.launchpad.net/kicad/patch/?id=37741048cef0d1623d90eeed43bf537de375e938
for the issue https://bugs.launchpad.net/kicad/+bug/1813964 appears to have
created a new bug where now polylines are closed even when they shouldn't
be.

I encountered this issue plotting an SVG of this project schematic:
https://github.com/bobbarnes1981/mod_synth/tree/3c8d33dbccd27c43dd53195eee7b6646931202e2/mod_synth_seq/schematic


An earlier KiCad version (5.0) plotted the schematic correctly:

```
Application: kicad
Version: (5.0.0-3-g5ebb6b6), release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.30.0 SecureTransport zlib/1.2.5
Platform: Mac OS X (Darwin 13.4.0 x86_64), 64 bit, Little endian, wxMac
Build Info:
    wxWidgets: 3.0.4 (UTF-8,STL containers,compatible with 2.8)
    Boost: 1.67.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.51.0
    Compiler: Clang 8.0.0 with C++ ABI 1002
Build settings:
    USE_WX_GRAPHICS_CONTEXT=ON
    USE_WX_OVERLAY=ON
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=OFF
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
```

I first encountered the incorrect rendering with KiCad version 5.1.2 (which
also had another black & white SVG plotting bug):

```
Application: kicad
Version: 5.1.2-f72e74a~84~ubuntu16.04.1, release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.59.0 mbedTLS/2.8.0 zlib/1.2.11
Platform: Linux 4.15.0-55-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.58.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.47.0
    Compiler: GCC 5.4.0 with C++ ABI 1009

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
```

I tested yesterday with a nightly version of KiCad and verified that the
incorrect SVG plotting still occurs (though the other black & white
plotting SVG bug I encountered appears to have been fixed):

```
Application: Eeschema
Version: 6.0.0-unknown-8f58300~100~ubuntu18.04.1, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1
(+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Platform: Linux 4.15.0-55-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
    Boost: 1.65.1
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.58.0
    Compiler: GCC 7.4.0 with C++ ABI 1011

Build settings:
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
```

Here is a partial diff between the correct plot in version 5.0 and the
incorrect plot in 5.1.2 (note the addition of the "Z"):

```
@ @ -10467,19 +11446,23@ @
 <g style="fill:#000000; fill-opacity:0.0;
 stroke:#000000; stroke-width:100; stroke-opacity:1;
 stroke-linecap:round; stroke-linejoin:round;">
-<polyline fill="none;"
-points="91500,14250
+<path style="fill:#000000; fill-opacity:0.0;
+stroke:#000000; stroke-width:100; stroke-opacity:1;
+stroke-linecap:round; stroke-linejoin:round;fill:none"
+d="M 91500,14250
 91750,14500
 92000,14250
 92500,14250
-" />
-<polyline fill="none;"
-points="92500,13250
+Z" />
+<path style="fill:#000000; fill-opacity:0.0;
+stroke:#000000; stroke-width:100; stroke-opacity:1;
+stroke-linecap:round; stroke-linejoin:round;fill:none"
+d="M 92500,13250
 91250,13250
 91250,14250
 91000,14500
 90750,14250
-" />
+Z" />
 </g>
```


This example SVG file patch results in a correct plotting (for that portion
of the component):

```
--- /<path>/mod_synth_seq--kicad-linux-nightly--bw-without-title-border--
half-buggy.svg        2019-08-19 23:31:55.000000000 +1200
+++ /<path>/mod_synth_seq--kicad-linux-nightly--bw-without-title-border--
half-buggy--edit.svg  2019-08-20 23:48:01.000000000 +1200
@ @ -11462,7 +11462,7@ @
 91250,14250
 91000,14500
 90750,14250
-Z" />
+" />
 </g>
 <g style="fill:#000000; fill-opacity:0.0;
 stroke:#000000; stroke-width:60; stroke-opacity:1;
```

Note that the code patch in question removed a conditional check
(potentially due to the fact that the later "Close/(fill) the path" comment
didn't really reflect what the last piece of code was doing):

```
@ @ -492,16 +505,7@ @ void SVG_PLOTTER::PlotPoly( const
std::vector<wxPoint>& aCornerList,
         fprintf( outputFile, "%d,%d\n", (int) pos.x, (int) pos.y );
     }

-    // ensure the shape is closed, for filled shapes (that are closed
polygons):
-    // (svg does not close automatically a polygon
-    if( aCornerList.front() != aCornerList.back() && aFill != NO_FILL )
-    {
-        pos = userToDeviceCoordinates( aCornerList.front() );
-        fprintf( outputFile, "%d,%d\n", (int) pos.x, (int) pos.y );
-    }
-
-    // Close/(fill) the path
-    fprintf( outputFile, "\" /> \n" );
+    fprintf( outputFile, "Z\" /> \n" );
 }
```

I'm guessing but haven't verified that moving the output of the "Z" back
inside the original conditional may fix the issue--but I don't know if that
would have any unintended consequences elsewhere.
```
Original tags: eeschema export plot svg

Story points: 6.0