svg backend truncates output size to integer, which it doesn't need to (and pdf backend doesn't)

[anntzer]

Bug report

Bug summary

For vector backends, it should be acceptable for the output canvas to have a noninteger size. Indeed, the pdf backend will output canvas with noninteger sizes "as is". On the other hand, the svg backend truncates the output to the integer below, which it doesn't need to do.

Code for reproduction

gcf(); savefig("/tmp/foo.pdf"); savefig("/tmp/foo.svg")

and examine foo.pdf and foo.svg with a plain text viewer.

Actual outcome

foo.pdf contains the line

/MediaBox [ 0 0 460.8 345.6 ] /Parent 2 0 R /Resources 8 0 R /Type /Page >>

(460.8 is 6.4 inches at 72dpi, 345.6 is 4.8 inches at 72 dpi).

foo.svg contains the line

<svg height="345pt" version="1.1" viewBox="0 0 460 345" width="460pt" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">

so the SVG was truncated. Note that interestingly, the SVG also contains e.g.

   <path d="M 0 345.6 
L 460.8 345.6 
L 460.8 0 
L 0 0 
z
" style="fill:#ffffff;"/>

i.e. some paths that overflow the SVG canvas.

I believe it is just as valid for the SVG output to use noninteger sizes (at least, manually editing the file doesn't make inkscape complain).

Expected outcome

SVG backend should not crop the output size.

Matplotlib version

• Operating system: N/A
• Matplotlib version: 2.1/master
• Matplotlib backend (print(matplotlib.get_backend())): SVG
• Python version: N/A
• Jupyter version (if applicable): N/A
• Other libraries: N/A

[tacaswell]

It appears have been this way since at least 2005 but see no reason for it to be so.