[matplotlib-devel] Setting dpi in savefig has unexpected results for PDFs
I recently noticed that setting the dpi for savefig doesn't work as expected
when saving to pdf. Take the following code, for example:
>>> import matplotlib.pyplot as plt
>>>
>>> plt.figure(figsize=(8,6))
>>> plt.plot([1,2])
>>> plt.savefig('test.png', dpi=100)
>>> plt.savefig('test.pdf', dpi=100)
The resulting png file is 800 x 600 (as expected), while the pdf file is 576 x
432 [which is (800 x 600) * 72/100]. I found an old thread suggesting that a
dpi of 72 should be hard coded into the PDF renderer for compatibility with
older versions of the PDF spec. That makes sense; however, it'd be nice if the
docstring for savefig told users about his behavior.
Below, is a patch to the savefig docstring. I'm sure someone else could word
this better, but I thought I'd at least try.
Best,
-Tony
P.S. maybe enough time has passed that most people have adopted PDF
viewers/parsers using PDF >= 1.6, and this hard-coded dpi could be removed?
Just a thought.
Index: lib/matplotlib/figure.py
===
--- lib/matplotlib/figure.py(revision 8561)
+++ lib/matplotlib/figure.py(working copy)
@@ -1018,7 +1018,10 @@
*dpi*: [ None | scalar > 0 ]
The resolution in dots per inch. If *None* it will default to
-the value ``savefig.dpi`` in the matplotlibrc file.
+the value ``savefig.dpi`` in the matplotlibrc file. NOTE: when
+saving to pdf, the dpi will not affect the page dimensions (which
+is always 72 dpi), but it will affect the resolution of rasterized
+elements in the plot.
*facecolor*, *edgecolor*:
the colors of the figure rectangle
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Setting dpi in savefig has unexpected results for PDFs
On 07/16/2010 09:45 AM, Tony S Yu wrote:
> I recently noticed that setting the dpi for savefig doesn't work as
> expected when saving to pdf. Take the following code, for example:
>
> >>> import matplotlib.pyplot as plt
> >>>
> >>> plt.figure(figsize=(8,6))
> >>> plt.plot([1,2])
> >>> plt.savefig('test.png', dpi=100)
> >>> plt.savefig('test.pdf', dpi=100)
>
> The resulting png file is 800 x 600 (as expected), while the pdf file is
> 576 x 432 [which is (800 x 600) * 72/100]. I found an old thread
No, 576 x 432 is the paper size in points, not dots, so it is 8x6 inches
as requested. Since the content is all vector-based, there is no notion
of dots or pixels in test.pdf.
>
> suggesting that a dpi of 72 should be hard coded into the PDF renderer
> for compatibility with older versions of the PDF spec. That makes sense;
> however, it'd be nice if the docstring for savefig told users about his
> behavior.
Yes, the docstring probably should point out that for vector backends
(pdf, ps, svg), the dpi setting affects only the resolution of
rasterized components.
>
> Below, is a patch to the savefig docstring. I'm sure someone else could
> word this better, but I thought I'd at least try.
>
> Best,
> -Tony
>
> P.S. maybe enough time has passed that most people have adopted PDF
> viewers/parsers using PDF >= 1.6, and this hard-coded dpi could be
> removed? Just a thought.
No; I think the present behavior is correct, regardless of the pdf
version. It is not really a hard-coded dpi at all, it is a confusing
aspect of the way mpl uses variables called "dpi". (But someone who
knows more about pdf may correct me if necessary.)
Eric
>
>
> Index: lib/matplotlib/figure.py
> ===
> --- lib/matplotlib/figure.py (revision 8561)
> +++ lib/matplotlib/figure.py (working copy)
> @@ -1018,7 +1018,10 @@
> *dpi*: [ None | scalar > 0 ]
> The resolution in dots per inch. If *None* it will default to
> - the value ``savefig.dpi`` in the matplotlibrc file.
> + the value ``savefig.dpi`` in the matplotlibrc file. NOTE: when
> + saving to pdf, the dpi will not affect the page dimensions (which
> + is always 72 dpi), but it will affect the resolution of rasterized
> + elements in the plot.
> *facecolor*, *edgecolor*:
> the colors of the figure rectangle
>
>
>
> --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>
>
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] refactoring of show
All, John noticed that my changes to show() prior to 1.0 had broken a use case with tkagg and ipython -pylab, so I fixed that yesterday in maintenance branch and trunk. Today, in 8562 and 8563, I did some refactoring to try to make show() behavior more understandable across backends, and easier to modify if necessary. Specifically, we need to work with the ipython people to make sure the ipython 0.11 refactoring of interactive support works as intended. I haven't done any testing with the development version of 0.11 yet. At present, all interactive backends start a blocking mainloop only if ipython has not attached a _needmain flag to show(), and if mpl is not in interactive mode. Under all script and ipython conditions, multiple calls to show in a session or script are permitted. All interactive backends behave the same when run with ipython -pylab, version 0.10: show is non-blocking, regardless of whether it is executed on the command line (completely unnecessary) or is found in a script. Under raw ipython (no -pylab or other threading flags provided), with mpl in non-interactive mode, all backends behave the same: show() is needed and blocks, but may be called multiple times. With mpl in interactive mode, there are two categories: tkagg, fltkagg, gtk*, and qt4agg behave the same as in -pylab mode, so there so no longer any real need for the special threading modes; but wx* and qtagg do not behave in a useful way, so they still need the special threading. All of the above is based on quick tests with my own system, ubuntu 10.04. I expect it will be the same for other supported systems, with the exception that behavior in raw ipython mode, with mpl in interactive mode, may not work with some earlier versions of gui toolkits--but I suspect we will not actually encounter this for supported versions. I have not built or tested anything under Windows or OS X. For the latter, testing of the macosx backend is needed. I expect cocoaagg to behave differently than the others, but no differently than it did before my changes. Eric -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] refactoring of show
Wing IDE recently added support for matplotlib, specifically non blocking show(). It might be worth also to test the 4.0 beta release. http://www.wingware.com/wingide/beta Christoph On 7/16/2010 2:26 PM, Eric Firing wrote: > All, > > John noticed that my changes to show() prior to 1.0 had broken a use > case with tkagg and ipython -pylab, so I fixed that yesterday in > maintenance branch and trunk. Today, in 8562 and 8563, I did some > refactoring to try to make show() behavior more understandable across > backends, and easier to modify if necessary. Specifically, we need to > work with the ipython people to make sure the ipython 0.11 refactoring > of interactive support works as intended. I haven't done any testing > with the development version of 0.11 yet. > > At present, all interactive backends start a blocking mainloop only if > ipython has not attached a _needmain flag to show(), and if mpl is not > in interactive mode. > > Under all script and ipython conditions, multiple calls to show in a > session or script are permitted. > > All interactive backends behave the same when run with ipython -pylab, > version 0.10: show is non-blocking, regardless of whether it is executed > on the command line (completely unnecessary) or is found in a script. > > Under raw ipython (no -pylab or other threading flags provided), with > mpl in non-interactive mode, all backends behave the same: show() is > needed and blocks, but may be called multiple times. With mpl in > interactive mode, there are two categories: tkagg, fltkagg, gtk*, and > qt4agg behave the same as in -pylab mode, so there so no longer any real > need for the special threading modes; but wx* and qtagg do not behave in > a useful way, so they still need the special threading. > > All of the above is based on quick tests with my own system, ubuntu > 10.04. I expect it will be the same for other supported systems, with > the exception that behavior in raw ipython mode, with mpl in interactive > mode, may not work with some earlier versions of gui toolkits--but I > suspect we will not actually encounter this for supported versions. > > I have not built or tested anything under Windows or OS X. For the > latter, testing of the macosx backend is needed. I expect cocoaagg to > behave differently than the others, but no differently than it did > before my changes. > > Eric > -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
