J�rgen Stenarson <jorgen.stenarson@...173...> 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
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
Jouni K. Sepp�nen