Might this be a problem with the viewer?

For me, pdf looks like this in Foxit Viewer:

and svg like this in Inkscape:

and like this in Firefox:

I can't reproduce in Preview nor Adobe Acrobat (on Mac).

Interesting, I can reproduce it in Chrome but by default "qpdfview" doesn't show the problem until I zoom in. Chrome looks like the below (smaller gap than in Inkscape, but still a gap) in both PDF and SVG

Whereas "qpdfview" looks like this:

Until I zoom REALLY far in, then it looks like

Also Foxit on my system, still shows the alignment off. But you can only see it if you zoom in a bit.

I can't reproduce in Preview nor Adobe Acrobat (on Mac).

@jklymak My roommate on a mac can reproduce this by zooming into the bottom of the bar in Preview. The gap renders only after a certain zoom level.

Maybe a similar rendering artifact like #5694.

Maybe a similar rendering artifact like #5694.

I suspect not actually, because I can make a better example that also "overflows" the top of the bar instead of just "underflowing" the top. Sorry that it took awhile to get this:

Better Example

import matplotlib.pyplot as plt
from matplotlib.transforms import Bbox

# [ax.get_position() for ax in proprietary_fig.axes]
ax_bbox = Bbox([[0.1974965228858249, 0.203249633462262], [0.8130847727044617, 0.8860326455421427]])
cax_bbox = Bbox([[0.8515590383181265, 0.203249633462262], [0.8753374421595627, 0.8860326455421427]])

# figsize=proprietary_fig.get_size_inches()
fig = plt.figure(figsize=[2.27, 1.58108728])

ax = fig.add_axes([ax_bbox.x0, ax_bbox.y0, ax_bbox.width, ax_bbox.height])
cax = fig.add_axes([cax_bbox.x0, cax_bbox.y0, cax_bbox.width, cax_bbox.height])

cb = plt.colorbar(sm, cax=cax)

plt.savefig('/home/bbeltr1/Downloads/test-no-plot-no-labels.svg')

Output

Screenshot from Foxit Reader on Debian Jessie. Circles obviously made in post (in Gimp) for emphasis.

For the above colorbar, opening the SVG shows that the "box" ends up being called <svg:g id="patch_8"> and is drawn as

M 139.17881,90.700695 V 90.397074 13.277469 12.973848 h 3.88634 v 0.303621 77.119605 0.303621 z

which is functionally equivalent to just

M 139.17881,90.700695 V 12.973848 h 3.88634 v 77.726847 z

whereas the image is a...well....svg:image with x=139, y=-12, width=4, height=78 (and transform=matrix(1, 0, 0, -1, 0, 78)).

This suggests the issue is actually the PNG position is being rounded to the nearest pixel, whereas the SVG path data is being kept as floats.

By zooming in, it is clear that the bar is slightly to the left (139 instead of 139.17...), is slightly to wide (4 instead of 3.886...), etc.

When I run the new example code, I can still not reproduce the issue. I do get

transform="scale(1 -1)translate(0 -77.76)" height="77.76" width="4.32" x="138.96" y="-12.96"

in the svg file.

Here are the two files I obtain (zipped, for github to me upload them):
test.zip

Okay, thanks everyone for your patience here, after games of reinstalling-everything-in-a-fresh-venv , I think I've determined that this is a Jupyter-specific bug.

The following produces a "correct" plot, as reported by @ImportanceOfBeingErnest:

$ python -m venv venv
$ source venv/bin/activate
$ pip install matplotlib jupyter
$ cat make_plot.py
import matplotlib.cm
import matplotlib.pyplot as plt
from matplotlib.transforms import Bbox

# [ax.get_position() for ax in proprietary_fig.axes]
ax_bbox = Bbox([[0.1974965228858249, 0.203249633462262], [0.8130847727044617, 0.8860326455421427]])
cax_bbox = Bbox([[0.8515590383181265, 0.203249633462262], [0.8753374421595627, 0.8860326455421427]])

# figsize=proprietary_fig.get_size_inches()
fig = plt.figure(figsize=[2.27,1.58108728])

ax = fig.add_axes([ax_bbox.x0, ax_bbox.y0, ax_bbox.width, ax_bbox.height])
cax = fig.add_axes([cax_bbox.x0, cax_bbox.y0, cax_bbox.width, cax_bbox.height])

sm = matplotlib.cm.ScalarMappable()
sm.set_array([])

cb = plt.colorbar(sm, cax=cax)

plt.savefig('./test-plot.svg')
$ python make_plot.py

However, opening a new jupyter notebook and executing

%run make_plot.py

produces a PDF with the rounding issue.

Ok, this does not mean that it's a bug with jupyter necessarily. After all, it's still matplotlib producing the output. But most probably there are some settings being made (e.g. if using IPykernel's inline backend) that change the numbers. It might then be possible to construct an example which shows the same problem outside of jupyter as well.

Looks like #6827?

Jupyter does set the DPI itself actually....maybe I'll dig into this, seems like it is probably the same issue.

For the above colorbar, opening the SVG shows that the "box" ends up being called <svg:g id="patch_8"> and is drawn as

M 139.17881,90.700695 V 90.397074 13.277469 12.973848 h 3.88634 v 0.303621 77.119605 0.303621 z

which is functionally equivalent to just

M 139.17881,90.700695 V 12.973848 h 3.88634 v 77.726847 z

whereas the image is a...well....svg:image with x=139, y=-12, width=4, height=78 (and transform=matrix(1, 0, 0, -1, 0, 78)).

This suggests the issue is actually the PNG position is being rounded to the nearest pixel, whereas the SVG path data is being kept as floats.

By zooming in, it is clear that the bar is slightly to the left (139 instead of 139.17...), is slightly to wide (4 instead of 3.886...), etc.

I can reproduce the problem with Chrome + Jupyter notebook. Matplotlib version 3.2.0.

The SVG result:

However, the white space goes away after I use a larger figure size (2*1.5->3*2.25)

Maybe this is an issue due to rounding.

Image positions are rounded to 72/dpi in SVG files. The default dpi in Matplotlib is 100 or so. For Jupyter notebook, dpi=72, so the position is rounded to integers. Increase the DPI would increase the precision of positions. plt.savefig('test.svg') -> plt.savefig('test.svg',dpi=100)

Interesting - do the images need to be snapped like that?

I'm fairly certain this is a duplicate of #6827 then.

Thank you all! Manually setting dpi in the savefig function solved the issue.