Jörgen Stenarson <[EMAIL PROTECTED]> writes: > I get a 800x600 pixel png which is expected for a 8x6in figure > at 100 dpi. But for the pdf I get 11.11x8.33in as determined from the > document properties dialog in acrobat reader. Looking at the file > information on a mac it reports the size as 800x600 for the pdf.
I can reproduce this in the trunk, but not in the 0.91 maintenance branch. I have been too busy elsewhere to really follow the development of the transforms branch (which became the trunk), but it seems that the new code is applying a dpi transformation to the coordinates where the old version just used Postscript points (1/72 in), and the default dpi seems to be 100, so all dimensions are enlarged by a factor of 100/72. > Doing some more digging it turns out acrobat reader reports a correct > size for the figure if I set dpi=72 when calling savefig. Perhaps > there is some dpi information that needs to be saved with the pdf > file? In PDF versions >= 1.6 the meaning of the user space coordinates can be modified, so you could change the units from Postscript points to something else. I think otherwise the output is compatible with PDF 1.4, so using this feature would require users to upgrade from Acrobat 5.0 to 7.0, or whatever is equivalent in other software. One important piece of software is pdftex (which can include pdf files) - a quick Googling didn't reveal the relevant version, but I think it parses PDF with xpdf, which only supports PDF 1.6 in version 3.02, released in February 2007. In my experience it takes several years for most people to upgrade their TeX distributions, so it is unlikely that PDF 1.6 is widely supported. Also, changing the units should not be really necessary, since PDF is a vector format. The only place where the dpi setting used to matter in the pdf backend were bitmap images such as you get from imshow. (Changing the units is useful if you need a page size larger than 200 by 200 inches, since the maximum is 144000 units.) So, IMHO, the pdf backend should use Postscript points in the output for compatibility with old software. Since the trunk is supposed to really be the bleeding edge now, I'll try to change it, and let Mike fix it if it breaks. :-) -- Jouni K. Seppänen http://www.iki.fi/jks ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
