<p dir="auto">Consider the following plot, which I created with version <code class="notranslate">1.5.dev1</code> (cloned and built in late January 2015):</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="import numpy as np
import matplotlib.pyplot as plt
data = np.arange(6).reshape(2, 3)
fig, sub = plt.subplots(1, 1, figsize=(4, 4))
bars = plt.bar(data[0], data[1])
_ = sub.set_ylim(1)
plt.savefig('test.svg')"><pre class="notranslate"><code class="notranslate">import numpy as np
import matplotlib.pyplot as plt
data = np.arange(6).reshape(2, 3)
fig, sub = plt.subplots(1, 1, figsize=(4, 4))
bars = plt.bar(data[0], data[1])
_ = sub.set_ylim(1)
plt.savefig('test.svg')
</code></pre></div>
<p dir="auto">If I open this SVG plot in firefox or in inkscape/inkview, it looks as expected. If I open it in the default Ubuntu image viewer (Eye of Gnome) or ImageMagick display, the bars are not properly clipped below the x-axis:<br>
<a target="_blank" rel="noopener noreferrer nofollow" href="https://cloud.githubusercontent.com/assets/1810515/6434156/807d56e2-c0bd-11e4-9702-436299d59399.png"><img src="https://cloud.githubusercontent.com/assets/1810515/6434156/807d56e2-c0bd-11e4-9702-436299d59399.png" alt="eyeofgnome" style="max-width: 100%;"></a></p>
<p dir="auto">When using hatching patterns the problems multiply. This screenshot shows Firefox and Inkview in the top row, and ImageMagick and Eye of Gnome in the bottom row:<br>
<a target="_blank" rel="noopener noreferrer nofollow" href="https://cloud.githubusercontent.com/assets/1810515/6434163/ba93c0a0-c0bd-11e4-9c02-19327b6eb2e9.png"><img src="https://cloud.githubusercontent.com/assets/1810515/6434163/ba93c0a0-c0bd-11e4-9c02-19327b6eb2e9.png" alt="screenshot" style="max-width: 100%;"></a></p>
<p dir="auto">I examined the SVG source, and found that in both cases there were one or more <code class="notranslate">svg:defs</code> nodes at the end of the document (i.e., after the <code class="notranslate">svg:g</code> node containing the main components of the figure).  If I manually move those <code class="notranslate">svg:defs</code> nodes up so that they occur <em>before</em> the main figure <code class="notranslate">svg:g</code> node, then both files now display normally in all four viewers (only the second example file is shown here):<br>
<a target="_blank" rel="noopener noreferrer nofollow" href="https://cloud.githubusercontent.com/assets/1810515/6434190/5d8958ba-c0be-11e4-883b-3233af7d719f.png"><img src="https://cloud.githubusercontent.com/assets/1810515/6434190/5d8958ba-c0be-11e4-883b-3233af7d719f.png" alt="screenshot_after_reordering_nodes" style="max-width: 100%;"></a></p>
<p dir="auto">I don't know much about the SVG specification, so I don't actually know if this is a case where matplotlib is following the rules and the viewers are to blame, or whether there is genuinely something wrong with the way matplotlib is generating the SVG, and some viewers (but not all) are clever enough to compensate for it.  Regardless, it seems like reordering nodes before writing out the file might (?) be a fairly easy change to make, and would improve compatibility of matplotlib-authored SVGs.</p>
<p dir="auto">I don't know if this last bit of information is relevant, but the problems with the unmodified SVGs persist if they are converted to EPS and then inserted into PDFs via LaTeX (when doing the conversion either with <code class="notranslate">inkscape -f test.svg -E test.eps</code>, or <code class="notranslate">cairosvg test.svg -o test.ps; ps2eps -f -q -B test.ps</code>). Again, some viewers (e.g., Adobe Reader on Windows) will display them correctly, but others (e.g., evince or muPDF) will not.</p>
<p dir="auto">See my stackoverflow post: <a href="http://stackoverflow.com/questions/29616764/matplotlib-savefig-produces-incorrect-svg-image-for-bar-chart-with-log-scaled-y" rel="nofollow">http://stackoverflow.com/questions/29616764/matplotlib-savefig-produces-incorrect-svg-image-for-bar-chart-with-log-scaled-y</a></p>
<p dir="auto">A potential solution to the issue is described here: <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="64073935" data-permission-text="Title is private" data-url="https://github.com/ipython/ipython/issues/8133" data-hovercard-type="issue" data-hovercard-url="/ipython/ipython/issues/8133/hovercard?comment_id=93051239&amp;comment_type=issue_comment" href="https://github.com/ipython/ipython/issues/8133#issuecomment-93051239">ipython/ipython#8133 (comment)</a></p>