Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
Description
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"/>
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