matplotlib-users Mailing List for matplotlib

You might want to try setting the rcParam pdf.fonttype to 42 (i.e. 
TrueType mode), which will avoid font subsetting.
You may also want to try using the Ps backend, which does support 
Helvetica directly. matplotlib ships all of the "standard" Ps font 
metrics as part of matplotlib. Be sure to set ps.useafm to True.
Mike
On 06/14/2009 04:54 PM, per freem wrote:
> hello all,
>
> I make my figures in matplotlib and then output them (using savefig) 
> as .pdf. I am using Fedora linux.
>
> When I try to edit the font in the figure to Helvetica using 
> Illustrator, I cannot. i am able to select the fonts, e.g. labels on 
> the axes of the figure, but when i try to change the font it does not 
> work. apparently the font information has been lost.
>
> is there a way to make the .pdf file contain the font? or is the 
> solution to export it as a different file format (if so which)?
>
> p.s. i do not have helvetica on the system that generates the plots so 
> i cannot set it programmatically... this is why i export it using the 
> default matplotlib font and then try to edit it in illustrator.
>
> thanks.
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 

On 06/12/2009 05:27 PM, Zane Selvans wrote:
> If I set path.simplify: False, the shape of the gaps between the
> filled polygons does change. Instead of being irregular, it becomes
> an infinitessimally thin gap of uniform width, allowing the (in this
> case white) background to show through.
> 
Just to clarify, these backs only show with the Mac OS-X gui window, not 
with the PNG or PDF output (which are actually handled by the Agg and 
PDF backends respectively, and don't use the Cocoa/Quartz-specific code 
in the macosx backend).
If that's the case, I'll forward this thread to the attention of Michiel 
de Hoon, the author of the macosx backend.
As for path.simplify = True causing irregular gaps, that's my area, and 
I'll look into that further. path.simplify should not be creating 
visible artifacts (at least in raster images such as PNG), so that's a bug.
Cheers,
Mike
> In both of these cases (path.simplify: True|False), the PNG version of
> the same figures also show representations of these gaps which are
> identical to those which appear in the PDF (though obviously
> pixelated), so I don't think it's something that's wrong in the vector
> graphics code per se.
>
> Zane
>
> On Fri, Jun 12, 2009 at 11:46 AM, Michael Droettboom<md...@st...> wrote:
> 
>> Shot in the dark here, but what if you set the rcParam "path.simplify" to
>> False? There have been recent changes to that code.
>>
>> Also, since the Agg backend doesn't have an associated GUI, you need to use
>> the savefig() command and provide a filename, rather than using show().
>>
>> Cheers,
>> Mike
>>
>> Zane Selvans wrote:
>> 
>>> Um, yeah. So my response got bounced because of the attachment. Take 2:
>>>
>>> For some reason my script bombed when I switched to the Agg backend,
>>> trying to display to the screen (it said Figure has no method show())
>>>
>>> So I output the plot as both a PDF and a PNG (still having backend:
>>> agg in my rcfile) and in both of those cases, irregular gaps are
>>> visible between the polygons making up the filled contours. This
>>> wasn't the case with my previously installed setup. It looks as if
>>> for some reason the vertices of the filled polygons are being
>>> calculated differently from different sides of the same contour,
>>> leading to overlap in some places, and gaps in others. You can download
>>> the PDF version (in which the exact geometry is much clearer).
>>> from:
>>>
>>> http://zaneselvans.org/dropbox/LinDensity_Grid.pdf
>>>
>>> Zane
>>>
>>> On Fri, Jun 12, 2009 at 5:51 AM, Michael Droettboom<md...@st...>
>>> wrote:
>>>
>>> 
>>>> So you see this behavior if you switch to the Agg backend? That's the
>>>> backend used to generate the images in the gallery. If there's a
>>>> difference
>>>> there, that would seem to suggest some tweaking of the macosx backend
>>>> (which
>>>> is still relatively new) is in order.
>>>>
>>>> Mike
>>>>
>>>> Zane Selvans wrote:
>>>>
>>>> 
>>>>> I just installed the latest SciPy Superpack in order to get access to
>>>>> the scipy.spatial.KDTree class, and discovered that for some reason
>>>>> now when I use contourf() lines get drawn at the boundaries between
>>>>> the filled contours. Additionally, there is always a single vertical
>>>>> line crossing from each contour boundary to the next. I'm guessing
>>>>> that these are the edges of the filled polygons which are getting
>>>>> drawn. This behavior doesn't seem to be consistent with the
>>>>> contourf() documentation and when I run code in griddata_demo.py it
>>>>> doesn't come out looking like the picture in the documentation/example
>>>>> gallery...
>>>>>
>>>>> Is anyone else seeing this behavior? Is there a keyword I can use to
>>>>> force the edges of the polygons not to get drawn?
>>>>>
>>>>> This is on Mac OS X 10.5.7, with
>>>>> scipy.__version__ = 0.8.0.dev5635
>>>>> matplotlib.__version__ = 0.98.6svn
>>>>> numpy.__version__=1.4.0.dev6728
>>>>>
>>>>> As installed by superpack_2009年03月28日.sh
>>>>> from http://macinscience.org/?page_id=6
>>>>>
>>>>> using:
>>>>> backend: macosx
>>>>>
>>>>> Cheers,
>>>>> Zane
>>>>>
>>>>>
>>>>>
>>>>> 
>>>> --
>>>> Michael Droettboom
>>>> Science Software Branch
>>>> Operations and Engineering Division
>>>> Space Telescope Science Institute
>>>> Operated by AURA for NASA
>>>>
>>>>
>>>>
>>>> 
>>>
>>>
>>> 
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>> 
>
>
>
> 

Hi
I am developing on a Desktop install Ubuntu 9.04 machine with matplotlib 0.98.5.2, 
and running the scripts on a Server install Ubuntu 8.10 machine with matplotlib 0.98.3.
I have found that the X axis layout for the same script varies between the two machines.
Both have standard matplotlib installs using apt-get. I haven't made any tweaks.
Rather than go into great detail about the problem, please see the script below and links to the resulting png files.
I hope the png files tell the story.
http://waka.freehostia.com/python/date_axis_scaling_test.py
http://waka.freehostia.com/python/date_axis_scaling_test_0_98_3.png
http://waka.freehostia.com/python/date_axis_scaling_test_0_98_5_2.png
The plot produced by matplotlib 0.98.3 isn't what I want.
Id like the plot to go edge to edge on the x axis grid, as the matplotlib 0.98.3 version does.
Help and advise would be appreciated.
PS : I'm new to python & matplotlib 
######################################################################################
#!/usr/bin/env python
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
from datetime import datetime, timedelta
version = matplotlib.__version__
HOURSBACK = 365 * 24
now = datetime.now()
valueList = []
dateList = []
for i in range(HOURSBACK):
 hoursBack = timedelta( hours = (HOURSBACK - i) )
 then = now - hoursBack
 valueList.append( i )
 dateList.append( then )
fig = plt.figure( figsize=(12, 9), dpi=100 )
ax = fig.add_subplot(111)
ax.plot(dateList, valueList)
plt.title('Date axis scaling test for matplotlib version : %s' % ( version ) )
plt.grid(True)
plt.ylabel('Widgets')
plt.xlabel('Date')
fig.autofmt_xdate()
plt.savefig( "date_axis_scaling_test_%s.png" % version.replace('.','_'), format='png' ) 
quit()
######################################################################################
_________________________________________________________________
Get the best of MSN on your mobile
http://clk.atdmt.com/UKM/go/147991039/direct/01/ 

hello all,
I make my figures in matplotlib and then output them (using savefig) as
.pdf. I am using Fedora linux.
When I try to edit the font in the figure to Helvetica using Illustrator, I
cannot. i am able to select the fonts, e.g. labels on the axes of the
figure, but when i try to change the font it does not work. apparently the
font information has been lost.
is there a way to make the .pdf file contain the font? or is the solution to
export it as a different file format (if so which)?
p.s. i do not have helvetica on the system that generates the plots so i
cannot set it programmatically... this is why i export it using the default
matplotlib font and then try to edit it in illustrator.
thanks.

On Fri, Jun 12, 2009 at 6:44 PM, Christoph Gohlke<cg...@uc...> wrote:
> Here are the Windows installer and egg produced by "setup.py bdist_wininst"
> respectively "setupegg.py bdist_egg":
Thanks Christoph -- I've uploaded these to the sf site. After the
next trunk release, I may ask you again to provide some visual studio
builds if you have the time, since the mingw/python2.6 problems have
not been solved yet.
JDH

The windows binaries for the latest matplotlib release are now
available for download at
 https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
for python2.5 and 2.6 (if you need 2.4 please respond here). Sorry
for the delay, but we hit a nasty python2.6/libpng/mingw that held us
up. Thanks to Christoph Gohlke
for the visual studio builds and Charlie Moad for the MingW framework.
Please let us know if you have any troubles.
JDH

Hey everyone,
this is more a how-to / feature request than a question... Normally, my
workflow for embedding images in LaTeX is as follows:
1) produce ps-file
2) use pstoedit (xfig) to separate text/math (LaTeX-typesettable) from
the image
3) save as pdf_t and pdf, respectively
4) \input this in the LaTeX document -- pdflatex will then set the text
at every compilation.
This has the advantage that I can change fonts etc without having to
redo all the figures.
I was trying to do so with matplotlib 0.98.3 and pstoedit 3.45 on a
64bit Ubuntu 8.10. I followed the instructions in the matplotlib
cookbook but kept experiencing problems when calling pstoedit [1], the
xlabels and ylabels were somehow converted to Courier but not put in the
"text" part, "." would become ":" and so on.
Solution brought this thread
http://www.nabble.com/Switching-between-different-font-settings-ts21279388.html
which suggested using OldScalarFormatter (thanks at this point also from
my side, Jouni) -- which works, see attached example.
So much for the "how-to-part" -- obviously, my suggestion is now to not
force users to have math-labels. I have to admit that I am not aware of
the drawbacks of OldScalarFormatter, but alone the name makes me think
that it might be not the best solution...
Thanks and best regards,
Sebastian.
P.S.: why actually does
ax.yaxis.get_ticklabels()[1].get_text()
return an empty string when called before savefig?
P.P.S.: I expect to be offline several days, so please excuse me if I
won't be answering timely.
[1]
pstoedit: version 3.45 / DLL interface 108 (build Jun 17 2008 - release
build - g++ 4.3.1) : Copyright (C) 1993 - 2007 Wolfgang Glunz
Warning: Level 2 version of image and imagemask not supported for this
backend (due to lack of support for bitmaps on intermediate files)
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font MCSZLR+CMMI12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font MCSZLR+CMMI12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font MCSZLR+CMMI12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font MCSZLR+CMMI12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font MCSZLR+CMMI12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.

Thanks John. This doesn't seem to be the cause of my problem, but I appreciate the correction. I wasn't aware that this was such bad practice. I guess it is better to import numpy and matplotlib functions separately then? 
Thanks again
--- On Fri, 6/12/09, John Hunter <jd...@gm...> wrote:
From: John Hunter <jd...@gm...>
Subject: Re: [Matplotlib-users] MPL with PyQt: different behavior on Windows vs. Linux
To: "Steve Nicholes" <ema...@ya...>
Cc: mat...@li...
Date: Friday, June 12, 2009, 7:02 AM
On Wed, Jun 10, 2009 at 12:55 AM, Steve
Nicholes<ema...@ya...> wrote:
> Thanks John. I hope you aren't receiving this reply twice (my email kicked
> me out when I hit send). I actually am importing pylab so it isn't an
> entirely qt app. I didn't post all of the code originally b/c it is long
> (and it would reveal how poor of a programmer I am :) ), but here are the
> relevant sections. The problematic section is in blue. Please let me know
> if you need anything else.
Importing pylab or pyplot into a GUI app is simply not supported.
There is never a reason to do it, and it is fraught with perils. I
don't know if this has anything to do with the problem you are
experiencing, but you need to remove these imports before we can
proceed.
JDH
 

Thanks for the tip Darren. Adding this line seems to have done the trick! Very much appreciated.
--- On Fri, 6/12/09, Darren Dale <dsd...@gm...> wrote:
From: Darren Dale <dsd...@gm...>
Subject: Re: [Matplotlib-users] MPL with PyQt: different behavior on Windows vs. Linux
To: "Steve Nicholes" <ema...@ya...>
Cc: mat...@li...
Date: Friday, June 12, 2009, 6:24 AM
On Tue, Jun 9, 2009 at 6:17 PM, Steve Nicholes <ema...@ya...> wrote:
Hi,
I am writing some code for automated testing via GPIB using MPL and PyQt. To simulate automated data collection while debugging the program, I have added a for loop (see below) after reading in a data file that plots each point one by one. When I run the program in Linux, I see each point appear on the canvas one by one as designed, but when I run the same code in Windows, nothing shows up on the canvas during the for loop. Instead, once the loop has completed, all points appear simulataneously. Is there any reason the why calls to canvas.draw() show nothing when run in Windows? 
I have seen similar discrepancies between PyQt4 behavior on linux and windows in a few situations. In my experience, a call to PyQt4.QtGui.qApp.processEvents() is sufficient to force an update in your view.
Darren