Agg和开罗之间的Matplotlib后端差异

Question

Hej,

I'd like to produce high quality PDFs from matplotlib plots. Using other code, I have produced a large array of numbers, which I plot in a figure using plt.imshow. If I now produce a PDF using plt.savefig, I notice strong differences depending on which backend I use. Most importantly, the produced files get huge with the Agg or MacOSX backend, while they are reasonably small with Cairo (see examples below). On the other hand, the Cairo backend produces weird text in conjunction with the TeX rendering of labels. This looks awful in the TeX document. My question is therefore twofold:

1. Is it possible to produce small PDF (ie presumably without interpolating the raster image to a higher resolution) using the Agg backend?
2. Can one change some text settings for the Cairo backend such that it looks similar to ordinary TeX (which is the case for the Agg backend)

Here is some example code for test purposes:

import matplotlib as mpl
mpl.use( "cairo" )

import numpy as np
import matplotlib.pyplot as plt
plt.rcParams['text.usetex'] = True

data = np.random.rand( 50, 50 )

plt.imshow( data, interpolation='nearest' )
plt.xlabel( 'X Label' )
plt.savefig( 'cairo.pdf' )

produces a PDF of 15Kb with a bad looking xlabel.

import matplotlib as mpl
mpl.use( "agg" )

import numpy as np
import matplotlib.pyplot as plt
plt.rcParams['text.usetex'] = True

data = np.random.rand( 50, 50 )

plt.imshow( data, interpolation='nearest' )
plt.xlabel( 'X Label' )
plt.savefig( 'agg.pdf' )

produces a PDF of 986Kb which looks good.

I should probably add that I use matplotlib 1.0.1 with python 2.6.7 on OSX 10.6.8. In the comments, someone requested the output of grep -a Font agg.pdf :

/Shading 6 0 R /Font 3 0 R >>
<< /FontFile 16 0 R /Descent -285 /FontBBox [ -174 -285 1001 953 ]
/StemV 50 /Flags 4 /XHeight 500 /Type /FontDescriptor
/FontName /NimbusSanL-Regu /CapHeight 1000 /FontFamily (Nimbus Sans L)
%!PS-AdobeFont-1.0: NimbusSanL-Regu 1.05a
FontDirectory/NimbusSanL-Regu known{/NimbusSanL-Regu findfont dup/UniqueID known{dup
/UniqueID get 5020902 eq exch/FontType get 1 eq and}{pop false}ifelse
/FontType 1 def
/FontMatrix [0.001 0 0 0.001 0 0 ]readonly def
/FontName /NimbusSanL-Regu def
/FontBBox [-174 -285 1001 953 ]readonly def
/FontInfo 9 dict dup begin
/BaseFont /NimbusSanL-Regu /Type /Font /Subtype /Type1
/FontDescriptor 15 0 R /Widths 13 0 R /LastChar 255 /FirstChar 0 >>
<< /FontFile 20 0 R /Descent -251 /FontBBox [ -34 -251 988 750 ] /StemV 50
/Flags 4 /XHeight 500 /Type /FontDescriptor /FontName /CMR12
/CapHeight 1000 /FontFamily (Computer Modern) /ItalicAngle 0 /Ascent 750 >>
%!PS-AdobeFont-1.0: CMR12 003.002
%Copyright:  (<http://www.ams.org>), with Reserved Font Name CMR12.
% This Font Software is licensed under the SIL Open Font License, Version 1.1.
FontDirectory/CMR12 known{/CMR12 findfont dup/UniqueID known{dup
/UniqueID get 5000794 eq exch/FontType get 1 eq and}{pop false}ifelse
/FontType 1 def
/FontMatrix [0.001 0 0 0.001 0 0 ]readonly def
/FontName /CMR12 def
/FontBBox {-34 -251 988 750 }readonly def
/FontInfo 9 dict dup begin
 /Notice (Copyright \050c\051 1997, 2009 American Mathematical Society \050<http://www.ams.org>\051, with Reserved Font Name CMR12.) readonly def
<< /BaseFont /CMR12 /Type /Font /Subtype /Type1 /FontDescriptor 19 0 R

Answer 1

As suggested by steabert in the comments above, a workaround is exporting the graphics in a different format and then convert it to PDF afterwards. Adjusting my example from above, the workflow could look something like this:

import os
import matplotlib as mpl
mpl.use("Agg")

import numpy as np
import matplotlib.pyplot as plt
plt.rcParams['text.usetex'] = True

data = np.random.rand(50, 50)

plt.imshow(data, interpolation='nearest')
plt.xlabel('X Label')
plt.savefig('agg.eps')

os.system('epspdf agg.eps agg.pdf')

producing a file of 16 Kb which looks good. There is still one difference to the examples presented above: Using the (E)PS pipeline seems to ignore the interpolation='nearest' option, ie the image appears blurry in the final PDF. Luckily, I can live with that, but it might be interesting to look into this issue.