matplotlib-devel Mailing List for matplotlib

There has been a recent thread discussing sympy interface to pyglet in 
the context of matplotlib refactoring of the 3D code. See thread named 
'Updating MPlot3D to a more recent matplotlib.'
If you are porting pyglet interface to Ipython, Ondrej might be happy to 
see his sympy 3D plotting routines go there as well :)
cheers,
Johann
Nicolas Rougier wrote:
> Sure, thread about IPython integration to be continued on ipython-dev 
> list...
>
> Nicolas
>
> On 3 Apr, 2009, at 19:07 , Fernando Perez wrote:
>
> 
>> On Fri, Apr 3, 2009 at 10:00 AM, Nicolas Rougier
>> <Nic...@lo...> wrote:
>> 
>>> Sorry for that, I coded it on linux and just tested on mac.
>>> I fixed the error and upload the new version on the same link. Tell 
>>> me if
>>> it's ok.
>>> 
>> Great!
>>
>> Would you have any interest in having this be shipped/developed as
>> part of IPython itself?
>>
>> You are using a fair amount of internals of the ipython machinery, and
>> we're getting ready for a large cleanup. Having your code shipped
>> with ipython itself would give it perhaps more exposure, as well as
>> allow it to evolve in sync with the rest of the API, since we could
>> test it as the internals change.
>>
>> I think it would be great to ship this with ipython itself, and I'm
>> sure you'd get help and contributions from the rest of the ipython
>> team as well...
>>
>> Best,
>>
>> f
>> 
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

> -----Original Message-----
> From: Jouni K. Seppänen [mailto:jk...@ik...]
> Sent: 6 Apr 2009 1:20 PM
> To: mat...@li...
> Subject: Re: [matplotlib-devel] cannot use some fonts on pdf, ps,eps
> backends
> 
> "Andrew Hawryluk" <HA...@no...> writes:
> 
> > When I use Arial Unicode MS within matplotlib, it cannot save to any
> > PostScript-based formats (pdf, eps, ps). Apparently, the font has no
> > glyph names:
> [...]
> > glyph_name = font.get_glyph_name(gind)
> > RuntimeError: Face has no glyph names
 
> What version of Freetype do you have - does updating it help? The check
> for glyph names is just a call to a Freetype macro
I am using the most recent windows binary (0.98.5.2), so I'm guessing that my Freetype library came bundled inside it.
 
> Does it help if you set ps.fonttype and pdf.fonttype to 42 in
> matplotlibrc?
Yes, that works very well, thanks! However, it now embeds the entire font rather than a subset. This results in a PDF of 14.4 MB with this font. I ran it through ghostscript to get a PDF of 24.2 kB with subsetting, but I'm wondering if I can get subsetting of type 42 fonts directly from matplotlib?
Thanks again,
Andrew

"Andrew Hawryluk" <HA...@no...> writes:
> When I use Arial Unicode MS within matplotlib, it cannot save to any
> PostScript-based formats (pdf, eps, ps). Apparently, the font has no
> glyph names:
[...]
> glyph_name = font.get_glyph_name(gind)
> RuntimeError: Face has no glyph names
[...]
> I know that these fonts can be included in PDFs, because I can do it
> in other programs.
What version of Freetype do you have - does updating it help? The check
for glyph names is just a call to a Freetype macro:
 if (!FT_HAS_GLYPH_NAMES(face))
 throw Py::RuntimeError("Face has no glyph names");
Does it help if you set ps.fonttype and pdf.fonttype to 42 in
matplotlibrc? If not, could you send me (off-list) a sample of a PDF
file produced by another program using the font, preferably one that
displays the exact same string that causes this problem with matplotlib?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

When I use Arial Unicode MS within matplotlib, it cannot save to any
PostScript-based formats (pdf, eps, ps). Apparently, the font has no
glyph names:
Traceback (most recent call last):
 File "G:\Chem2009\GK6 Fan Dynamics\plotFanCurve.py", line 31, in
<module>
 p.savefig('memo/figures/normalizedFanCurve.pdf')
 File "C:\Python25\lib\site-packages\matplotlib\pyplot.py", line 345,
in savefig
 return fig.savefig(*args, **kwargs)
 File "C:\Python25\lib\site-packages\matplotlib\figure.py", line 990,
in savefig
 self.canvas.print_figure(*args, **kwargs)
 File "C:\Python25\lib\site-packages\matplotlib\backend_bases.py", line
1419, in print_figure
 **kwargs)
 File "C:\Python25\lib\site-packages\matplotlib\backend_bases.py", line
1313, in print_pdf
 return pdf.print_pdf(*args, **kwargs)
 File
"C:\Python25\lib\site-packages\matplotlib\backends\backend_pdf.py", line
1886, in print_pdf
 self.figure.draw(renderer)
 File "C:\Python25\lib\site-packages\matplotlib\figure.py", line 772,
in draw
 for a in self.axes: a.draw(renderer)
 File "C:\Python25\lib\site-packages\matplotlib\axes.py", line 1601, in
draw
 a.draw(renderer)
 File "C:\Python25\lib\site-packages\matplotlib\axis.py", line 725, in
draw
 self.label.draw(renderer)
 File "C:\Python25\lib\site-packages\matplotlib\text.py", line 502, in
draw
 ismath=ismath)
 File
"C:\Python25\lib\site-packages\matplotlib\backends\backend_pdf.py", line
1573, in draw_text
 return draw_text_woven(chunks)
 File
"C:\Python25\lib\site-packages\matplotlib\backends\backend_pdf.py", line
1543, in draw_text_woven
 glyph_name = font.get_glyph_name(gind)
RuntimeError: Face has no glyph names
I can reproduce this error with several fonts on my system.
(Coincidentally, all the fonts that have a full set of superscript
characters, which I could really use for my plots.) I know that these
fonts can be included in PDFs, because I can do it in other programs. I
also checked the archives and the bug list for clues as to what may be
going on, but came up empty. Any idea what the problem might be? Thanks!
Andrew

João Luís Silva <js...@fc...> writes:
> annotate and usetex='True' can trigger a traceback if the text is 
> invalid. A space or an underscore generate this behavior, I haven't 
> tried others.
Thanks for the report it should be fixed now. You still get a traceback,
but now it should make more sense.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi,
annotate and usetex='True' can trigger a traceback if the text is 
invalid. A space or an underscore generate this behavior, I haven't 
tried others.
Ubuntu 8.10, mpl svn (rev. 7032).
Once again feel free to ignore this, I just feel compelled to report all 
mpl bugs :)
JLS
Example:
#---------------------------------------------------------------------------
from matplotlib import rc
rc('text', usetex=True)
rc('font', family='serif')
import matplotlib.pyplot as plt
import numpy as np
x = np.arange(-10.0,10.0,0.1)
plt.plot(x,np.sin(x))
ax = plt.gca()
ax.annotate(' ',xy=(-5.8,0.5),xytext=(-8.0,0.5),
 arrowprops=dict(facecolor='black',width=1.5, shrink=0.05))
plt.show()
#---------------------------------------------------------------------------
Traceback:
Traceback (most recent call last):
 File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
line 352, in expose_event 
 self._render_figure(self._pixmap, w, h) 
 File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 75, in _render_figure 
 FigureCanvasAgg.draw(self) 
 File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 283, in draw 
 self.figure.draw(self.renderer) 
 File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
773, in draw 
 for a in self.axes: a.draw(renderer) 
 File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 
1672, in draw
 a.draw(renderer) 
 File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line 
1615, in draw
 self.update_positions(renderer) 
 File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line 
1542, in update_positions
 l,b,w,h = self.get_window_extent(renderer).bounds
 File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line 662, 
in get_window_extent
 bbox, info = self._get_layout(self._renderer)
 File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line 253, 
in _get_layout
 clean_line, self._fontproperties, ismath=ismath)
 File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 152, in get_text_width_height_descent
 renderer=self)
 File "/usr/lib/python2.5/site-packages/matplotlib/texmanager.py", 
line 594, in get_text_width_height_descent
 dvi = dviread.Dvi(dvifile, 72*dpi_fraction)
 File "/usr/lib/python2.5/site-packages/matplotlib/dviread.py", line 
45, in __init__
 self.file = open(filename, 'rb')
IOError: [Errno 2] No such file or directory: 
'/home/jls/.matplotlib/tex.cache/557ff391b6beb8d5df7a86de0547f607.dvi'

Hello,
I just thought I'd mention a little more detail about what I've found 
with respect to writing grey/colorscales to vector graphics formats. 
The bottom line is that to plot a grayscale or colorscale in a vector 
graphics format without resampling, it seems at the moment that 
pcolorfast works best, in SVG format (not PS).
Attached is a script to try out different combinations of methods, 
formats, and canvas sizes. In all cases I am plotting a 10x10 numpy 
array. The file sizes I obtain are:
$ du -sh example*
584K	example1.ps (imshow and 4x4 canvas)
2.2M	example2.ps (imshow and 8x8 canvas)
 84K	example3.svg (imshow and 4x4 canvas)
204K	example4.svg (imshow and 8x8 canvas)
600K	example5.ps (pcolorfast and 4x4 canvas)
2.3M	example6.ps (pcolorfast and 8x8 canvas)
 16K	example7.svg (pcolorfast and 4x4 canvas)
 20K	example8.svg (pcolorfast and 8x8 canvas)
As you can see, example7.svg and example8.svg are by far the smallest 
files, and their sizes aren't that different, which is the way things 
should be as changing the canvas size shouldn't be changing much since 
it is a vector graphics format. It's interesting to see that imshow 
and pcolorfast produce different results for SVG (both smaller than 
the PS results)
Interestingly, pcolorfast shows no improvement compared to imshow for 
the PS files, and in addition, the 4x4 images are 4 times smaller than 
the 8x8 images, suggesting that in all cases, the colorscale has been 
rasterized to a finer resolution.
It might be worth seeing how the SVG driver implements this and apply 
the same technique to the PS driver. The fact that the SVG driver can 
do this suggests that the matplotlib API should be able to handle this 
and so all that is needed is to work on the PS driver?
As a temporary solution, it is possible to produce SVG files and 
convert these to PS, but this is not an ideal solution.
Let me know if you have any questions about this,
Thanks,
Thomas