matplotlib-users Mailing List for matplotlib

The effects are observed from with a single python session.
Out of curiosity - Is there any way of clearing the cache within a 
session ?
Thanks
--Jim
On Mar 29, 2006, at 1:27 PM, John Hunter wrote:
>>>>>> "James" == James Boyle <bo...@ll...> writes:
> James> changed. However, if I just run the rc(font, **fontDict)
> James> command sequence first without ever trying the defaults
> James> fonts all goes well and I get a fine PS file. Evidently,
> James> some aspects of the old font are retained.
>
> Are these effects observed within a single python session (all tests
> in one script or a single interactive session from the shell).
> matplotlib does cache some font information within a single run.
>
> If it is *between* python sessions, you might want to try clearing the
> font cache between runs and see if this makes a difference
>
>> rm -rf ~/.matplotlib/ttffont.cache
>
> JDH
>

In gnuplot, as one plots multiple lines on the same graph, the default
behavior is that gnuplot automatically selects linestyle, colors and
markers. In matplotlib, the default behavior (if I don't specify
format etc) is to draw every line in solid style, no markers, blue
color. I much prefer gnuplot's default behavior -- is there some way
of configuring matplotlib to do the same?
Thanks,
Diwaker
--
Web/Blog/Gallery: http://floatingsun.net/blog

>>>>> "James" == James Boyle <bo...@ll...> writes:
 James> changed. However, if I just run the rc(font, **fontDict)
 James> command sequence first without ever trying the defaults
 James> fonts all goes well and I get a fine PS file. Evidently,
 James> some aspects of the old font are retained.
Are these effects observed within a single python session (all tests
in one script or a single interactive session from the shell).
matplotlib does cache some font information within a single run.
If it is *between* python sessions, you might want to try clearing the
font cache between runs and see if this makes a difference
 > rm -rf ~/.matplotlib/ttffont.cache
JDH

Thanks for your help. Encouraged by your results I tried some more 
experiments.
There appears to be some hysteresis in matplotlib fonts ( at least my 
installation).
Unsaid(!!!) in my message was that I initially ran the PS plot with 
the default fonts and generated a defective PS file, and then I tried 
to change the font properties. After running the rc(font, **fontDict) 
command I still generated a defective file but a different size - so 
something changed.
However, if I just run the rc(font, **fontDict) command sequence first 
without ever trying the defaults fonts all goes well and I get a fine 
PS file.
Evidently, some aspects of the old font are retained.
Thanks again,
--Jim
On Mar 29, 2006, at 8:54 AM, js...@fa... wrote:
>
> On 2006年3月29日 10:34:08 -0500, "Darren Dale" <dd...@co...>
> said:
>> On Tuesday 28 March 2006 19:05, you wrote:
>>> plotlibrc setting:
>>> font.sans-serif : Lucida Grande, Verdana, Geneva, Lucida, 
>>> Bitstream
>>> Vera Sans, Arial, Helvetica, Avant Garde, sans-serif
>>> I get a postscript file that I cannot view.
>>> BUT if I change the matplotlibrc file to:
>>> font.sans-serif : Bitstream Vera Sans
>>> All goes well and the PS file is fine. This has been discussed on the
>>> list previously as an OS X font issue.
>>>
>>> My idea was to use the following code to set the font.sans-serif
>>> dynamically.
>>> However, it does not seem to work in that the ps file is not usable 
>>> as
>>> if Lucida Grande was still the font.sans-serif setting.
>>> There might well be something very obvious - From the font manager
>>> code I surmised that the 'sans-serif' entry was a list but I could be
>>> mistaken:
>>>
>>> import matplotlib
>>> matplotlib.use('PS')
>>> from matplotlib import pylab
>>> import Numeric
>>> N = Numeric
>>> PL = pylab
>>> x = N.arrayrange(100.)
>>> y = N.arrayrange(100.)
>>> fontDict = {'family':'sans-serif',
>>> 'style': 'normal',
>>> 'variant':'normal',
>>> 'weight': 'medium',
>>> 'stretch':'normal',
>>> 'size': 12.0,
>>> 'sans-serif':['Bitstream Vera Sans']}
>>> PL.rc('font',**fontDict)
>>> PL.plot(x,y**2)
>>> PL.savefig('crap')
>>> PL.clf()
>>
>> Your second script works fine for me. I was able to switch the font in
>> the
>> postscript file, between Bitstream Vera Sans and Arial, by modifying 
>> your
>> fontDict. I'm using svn mpl on linux, but I dont think anything has
>> changed
>> since 0.87.2 that would effect the results.
>>
>> Are there any Mac users with a free moment to run his script?
>>
>> Darren
>>
>
> Darren and Jim: Works for me on 10.4. -Jeff
>

>>>>> "Imara" == Imara Jarrett <im...@gm...> writes:
 Imara> Hi there, I am using a 'for loop' to generate multiple
 Imara> scatter plots from my data. So far, so good.
 Imara> I would like to have consistent xticks and yticks for each
 Imara> scatter plot. However, it seems that when I define xticks
 Imara> and yticks (remains the same for each scatter plot), I get
 Imara> different xticks and yticks for each scatterplot depending
 Imara> on the data.
 Imara> How can I make the xticks and yticks consistent over ALL my
 Imara> scatterplots, regardless of the data used to generate them?
some thing like:
xvals = 1,2,3
yvals = 4,5,6
for data in mydata:
 fig = figure(1)
 ax = fig.add_subplot(111)
 ax.scatter(blah, blah, data)
 ax.set_xticks(xvals)
 ax.set_yticks(yvals)
 fig.savefig('myfig')
 close(1)
 

> John Hunter <jdh...@ac...> writes: 
>> why would you ask for ticks midnight and noon, and then hide half of 
>> them. Why not just ask for them at noon 
On 2006年3月29日, Jouni K Seppanen apparently wrote: 
> Because I want the tick lines at midnight and labels at noon. 
> If I add an extra show() to the script, it works... there is something 
> going on that I don't understand: 
I do not think this is so unusual for time series data. 
Example: year end marked with tick marks, but year label set 
at June, between the tick marks.
Cheers,
Alan Isaac

>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:
 Jouni> John Hunter <jdh...@ac...> writes:
 >> why would you ask for ticks midnight and noon, and then hide
 >> half of them. Why not just ask for them at noon
 Jouni> Because I want the tick lines at midnight and labels at
 Jouni> noon.
I see -- one hack would be to use major and minor ticks. Make the
major ticks at midnight and the minor ticks at noon. Make the major
ticklabels invisible and the minor tick labels visible. Should work.
One way of making the major ticks invisible is to use a NullFormatter
for the major formatter.
 Jouni> If I add an extra show() to the script, it works... there
 Jouni> is something going on that I don't understand:
What you may be seeing with the double show is a side effect of
matplotlib not creating all the ticks it needs until it is drawn , and
when it creates extra ticks it uses the first tick, the protoTick from
axis.py, to determine the properties of the new ticks.
JDH

Charlie Moad wrote:
> Typically I use OSX's python, but I don't want to start that debate. 
No need for debate, I just wanted to know, so I wouldn't be duplicating 
effort. I'm trying to support the new Universal Build (and the 2.4.1 
Framework Build before that), so I wanted to know if I'm duplicating effort.
> New users should probably be
> pointed to the prebuilt 2.4 framework on pythonmac.
Yup!
> I haven't been keeping up with the intel status though.
There is a new universal build of 2.4.3 We're all hoping it will become 
the "standard" build for OS-X >= 10.3.9, for both PPC and Intel. 
However, it can't really be that until we can get all the critical 
packages built for it. wxPython is a big hang up now, and I consider 
matplotlib critical too.
> Are eggs accepted by pythonmac yet or they still using mpkg's exclusively?
We'd like to put eggs on there too. ideally, we'd make a little launcher 
app that would fire up and run easy_install to install them when double 
clicked. That's been talked about, but not yet done. In the meantime, 
something is better than nothing!
> Cocoa-agg works and has been there for the last few releases.
Will it build by default on OS-X?
> Apple's
> python interface to quartz doesn't have much of the text support
> included.
Darn. And it's proprietary isn't it?
> I think it is much better to focus on the Agg backend and
> use it in gui toolkits.
That is a good plan, unless we go to using All-Cairo Doing both seems 
way too redundant. I'm investigating Cairo vs. Agg for another project.
These are my quick thoughts:
Cairo Pluses:
 In theory: native, hardware accelerated back-ends for various platforms
 PDF and PS support: That's very nice, then we'd really have only one 
back-end! (what about Tex?)
 It's being used for GTK2 and part of Mozilla, so it should see a lot 
of activity and testing.
Cairo Minuses:
 It doesn't look like there's much activity on Windows, but that's 
gotten better with the Mozilla folks getting involved. I don't know 
about OS-X
Agg pluses:
 It works now!
 It has fabulous anti-aliasing (I haven't compared to Cairo yet)
 It's smaller and simpler.
Anyone else have some thoughts?
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Hi there,
I am using a 'for loop' to generate multiple scatter plots from my data. S=
o
far, so good.
I would like to have consistent xticks and yticks for each scatter plot.
However, it seems that when I define xticks and yticks (remains the same fo=
r
each scatter plot), I get different xticks and yticks for each scatterplot
depending on the data.
How can I make the xticks and yticks consistent over ALL my scatterplots,
regardless of the data used to generate them?
Thanks in advance!

I can get it to work with numarray. I tried briefly with numpy but I
keep getting an error about no numpy.Int8 amongst other things.
On 3/29/06, Jeff Peery <jef...@ya...> wrote:
> Hello, I am having some trouble with matplotlib and numpy when I use py2e=
xe.
> Has anyone had success with matplotlib and numpy when bundling it with
> py2exe?
>
> Thanks.
>
> Jeff
>
>
>
>
> ________________________________
> Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rate=
s
> starting at 1=A2/min.
>
>

Another thought, if you want to sneak some padding in to the
ticklabels, adding some whitespace might work. Off the top of my
head, I don't know how the text layout mechanism will handle leading
and trailing whitespace. 
 xax.set_major_formatter(DateFormatter(' %a '))

I'm confused by this
 setp(xax, 'major_locator', HourLocator(byhour=(0,12)))
 # Hide every other tick; for some reason this means every _fourth_ tickline
why would you ask for ticks midnight and noon, and then hide half of
them. Why not just ask for them at noon
 xax.set_major_locator(HourLocator(byhour=(12,)))
JDH

This script _almost_ works for me:
 import datetime
 import matplotlib.numerix as nx 
 from matplotlib.dates import date2num, DateFormatter, HourLocator
 from pylab import *
 # Plot some example data
 figure()
 dmin = date2num(datetime.datetime(2006,03,29))
 plot(nx.arange(dmin, dmin+7, 0.1), cumsum(rand(70)), 'r-')
 # Label midnights and noons with the weekday
 xax = gca().xaxis
 setp(xax, 'major_formatter', DateFormatter('%a')) 
 setp(xax, 'major_locator', HourLocator(byhour=(0,12)))
 # Hide every other tick; for some reason this means every _fourth_ tickline
 setp(getp(gca(), 'xticklines')[::4], 'visible', False)
 # Hide every other label; this is really every second object in the sequence
 setp(getp(gca(), 'xticklabels')[1::2], 'visible', False)
 show()
By "almost" I mean that the script doesn't work if I run it (using
e.g. %run foo.py in ipython) but, weirdly, it does work if I paste it
into ipython. The problematic line is the one that sets some
xticklines' visibility to False: within a script it hides all tick
lines, entered in ipython it hides every other line. (This is with
Matplotlib svn 2239, IPython 0.6.15, Python 2.4.1 "official unofficial
framework build", OS X 10.4.5, WXAgg.)
-- 
Jouni

Jouni K Seppanen wrote:
> John Hunter <jdh...@ac...> writes:
>=20
> >>>>>> "Jouni" =3D=3D Jouni K Seppanen <jk...@ik...> writes:
> > Jouni> Halldor Bj=EF=BF=BDrnsson <ha...@ve...> writes:
> > >> Currently the weekday label is aligned underneath the tickmar=
k,
> > >> but I would like to align the label to rhe right of the
> > >> tickmark (halfway to next tick)
> >
> > Have you tried experimenting with the horizontalalignment property,
> > which accepts left|right|center ? The default is center, which ofte=
n
> > looks wrong with rotated ticklabels
>=20
> I think what Halldor means that it is counterintuitive to have the
> weekday labels positioned at midnight. The attached example figure
> shows a week's worth of data, and from a quick glance you'd imagine
> that the peaks occur at night, while they really are in the afternoon.
> Aligning the labels' left-hand side with the ticks would help a
> little, but not nearly as much as having the labels centered between
> the ticks.
Jouni is correct. Below is a small script that I have written and gets=20
the flavor of what I am aiming for, although positions are slightly off.
It would be best to be able to keep the labels centered at given=20
positions, and simply be able to move the label with something like
labs=3Dget(ax,'xticklabels')
#change position of first label
pos=3Dget(labs[0],'position')
posnew=3D(pos[1]+0.5, 0)
setp(labs[0],position=3Dposnew)
This is very similar to how ticklabels can be moved around in Matlab
but it does not do anything in pylab. Is the "non-mobility" of=20
ticklabels something that is here on purpose and cannot be changed, or=20
is it easy to modify matplotlib to allow for this?
Sincerely,
Halldor
----------------------------------------------------------------------
 Halldor Bjornsson
 halldor()vedur.is tel:+354-522600
----------------------------------------------------------------------
Example where daynames are between the tickmarks but poorly aligned....
----------------------
from pylab import *
import datetime
x=3Darange(date2num(datetime.date.today()),date2num(datetime.date.today()=
)+7,0.5)
y=3Drand(size(x))
ax=3Dsubplot(312)
p1=3Dplot_date(x,y)
xlim(min(x),max(x))
locs=3Darange(min(x),max(x),1)
xticks(locs)
setp(ax,xticklabels=3D[])
for item in locs[0:len(locs)-1]:
 text(item+0.1,-0.1,num2date(item).strftime('%A'),fontsize=3D7)
show()
--=20

Hello, I am having some trouble with matplotlib and numpy when I use py2exe. Has anyone had success with matplotlib and numpy when bundling it with py2exe?
Thanks.
Jeff
		
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min.

>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:
 Jouni> I think what Halldor means that it is counterintuitive to
 Jouni> have the weekday labels positioned at midnight. The
 Jouni> attached example figure shows a week's worth of data, and
 Jouni> from a quick glance you'd imagine that the peaks occur at
 Jouni> night, while they really are in the afternoon. Aligning
 Jouni> the labels' left-hand side with the ticks would help a
 Jouni> little, but not nearly as much as having the labels
 Jouni> centered between the ticks.
If so, this seems less a problem of tick alignment than tick placing.
One can easily construct ticks for noon. 
 #untested
 import matplotlib.numerix as nx
 from matplotlib.dates import date2num
 dmin = date2num(datetime.datetime(2003,05,10)) # in days
 dateticks = nx.arange(dmin, dmin+7)+0.5 # 7 ticks, at noon
 xticks(dateticks, rotation=-45, ha='left')
It seems to me that you want the tick labels clearly associated with
the ticks, and you should place txhe ticks accordingly, but I can see
how there is room for argument...

>>>>> "Tom" == Tom Loredo <lo...@as...> writes:
 Tom> Hi John,
 Tom> I hate to nag you about this, but I'm being nagged myself!
 Tom> After boasting about Python to my colleagues, I'm glad to
 Tom> have them interested in it, but it's proving embarassing that
 Tom> it's so troublesome just to install it. I haven't had such
 Tom> problems on several other Mac and Linux machines, so there is
 Tom> probably something fishy about his OS X install, but I can't
 Tom> figure out what it is. Do you have any thoughts on this? Is
 Tom> X11 necessary, for example? I'm really at a dead end
 Tom> regarding how to pursue this.
I can help you walk through the diagnosis a bit
Stage 1:
Fire up a python shell
 * does import pylab cause a segfault?
If so, try importing these 1 by 1 and see where the problem is
 import matplotlib._image
 import matplotlib._transforms
 import matplotlib.ft2font
 import matplotlib.numerix
 ..maybe others but that is a good start
If not, eg you need to try and make a figure to trigger the import, we
want to enable extra verbose debugging.
Flush your build subdir, and edit setup.py to set VERBOSE = True and
recompile (capture the build to a file and post it). This will cause
the extension code to generate verbose output which may isolate the
problem. Run your test code with --verbose-debug-annoying and be
prepared for a deluge of messages.
You might want to flush ~/.matplotlib occassionaly to make sure there
is not something messing with you in the cache.
One possibility is that you are picking up multiple zlibs or libpngs
or libfreetypes, which can lead to segfaults. Try inspecting your
system to make sure you know which of these libsa are installed, which
versions, and where.
I'm putting this back on list in case your response triggers a
lightbulb in some resident OSX expert's head.
Happy hunting!
JDH
> LocalWords: occassionaly

On 3/29/06, Christopher Barker <Chr...@no...> wrote:
> Charlie Moad wrote:
> > I absolutely agree with statically linking in libpng and
> > freetype. This just makes sense, since it leaves no dependencies.
> > Anyone who is using GTK most likely does not care for a native mac
> > solution and would be using fink or darwin port's python. As of late
> > I usually build an egg with tk, wx, and the 3 pyarrays with the static
> > libs as mentioned above.
>
> Which Python build are you using?
Typically I use OSX's python, but I don't want to start that debate.=20
I also build everything from source. New users should probably be
pointed to the prebuilt 2.4 framework on pythonmac. I haven't been
keeping up with the intel status though.
>
> At the moment, there is not a Universal wxPython, and Py2App/bdist_mpkg
> is not yet working with the Universal build, so I may wait for those two
> before I do a Universal build of MPL.
>
> As packages built for the 2.4.1 Framework build work fine with the
> Universal build (on PPC machines) then I can probably just use what
> you've built for the moment.
Are eggs accepted by pythonmac yet or they still using mpkg's exclusively?
> By the way, what's the status of the cocoa back-end? And the Cairo
> Back-end on OS-X (and other platforms, while I'm asking)
Cocoa-agg works and has been there for the last few releases. There
are some quirks with multiple figures/windows. A toolbar has not been
implemented yet though. I still see the cocoa-agg as being sample
code on embedding matplotlib into a cocoa app. It doesn't have much
benefit in my eyes over tkagg.
When I first started the cocoa backend, I attempted it using quartz.=20
The graphics were actually really easy to get working. As I think
will be the case with Cairo, the text was the big hangup. Apple's
python interface to quartz doesn't have much of the text support
included. I think it is much better to focus on the Agg backend and
use it in gui toolkits. Otherwise, we will play this never-ending
game of trying to make the rendered results match between the
different rendering engines. Also by using the Agg backend, the
Cocoa-agg gets all the features of Agg for free. These don't have to
be re-implemented.
>
> > This seems to be very portable. I would be
> > happy to test anything you create
>
> I don't suppose you have an Intel Mac do you? That's what would really
> need testing. Or OS-X 10.3.9 -- I'm only running 10.4 on PPC.
10.4 PPC : (

Sergey,
Your example works for me with svn.
Eric
Sergey Dolgov wrote:
> A simple plot command, which worked in 0.86, fails in 087.2:
> 
> import pylab
> pylab.plot([0.0, 1.0], [0.0, 0.0])
> 
> A traceback indicates that it apparently has to do with MaxNLocator
> introduced in 0.87.
> 
> There was a thread on this list 2 weeks ago started by
> da...@in... concerning similar issue, but in that case y-values
> were slightly diffrent. Setting pylab.ylim to something like (-1,1)
> prior to calling plot(), as John Hunter suggested in that thread, does
> not quite work for me in this case.
> 
> Also, the changelog to 0.87.2 mentiones that same thread and claims a
> fix that "adjusts vmin and vmax if they are nearly the same, not just
> if they are equal". In my simple case, they are equal, but still i
> figure that it is not being treated gracefully enough.
> 
> Thanks,
> Sergey
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid1720ドル&dat1642
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

John Hunter <jdh...@ac...> writes:
>>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:
> Jouni> Halldor Björnsson <ha...@ve...> writes:
> >> Currently the weekday label is aligned underneath the tickmark,
> >> but I would like to align the label to rhe right of the
> >> tickmark (halfway to next tick)
>
> Have you tried experimenting with the horizontalalignment property,
> which accepts left|right|center ? The default is center, which often
> looks wrong with rotated ticklabels
I think what Halldor means that it is counterintuitive to have the
weekday labels positioned at midnight. The attached example figure
shows a week's worth of data, and from a quick glance you'd imagine
that the peaks occur at night, while they really are in the afternoon. 
Aligning the labels' left-hand side with the ticks would help a
little, but not nearly as much as having the labels centered between
the ticks.

On 2006年3月29日 10:34:08 -0500, "Darren Dale" <dd...@co...>
said:
> On Tuesday 28 March 2006 19:05, you wrote:
> > plotlibrc setting:
> > font.sans-serif : Lucida Grande, Verdana, Geneva, Lucida, Bitstream 
> > Vera Sans, Arial, Helvetica, Avant Garde, sans-serif
> > I get a postscript file that I cannot view.
> > BUT if I change the matplotlibrc file to:
> > font.sans-serif : Bitstream Vera Sans
> > All goes well and the PS file is fine. This has been discussed on the 
> > list previously as an OS X font issue.
> >
> > My idea was to use the following code to set the font.sans-serif 
> > dynamically.
> > However, it does not seem to work in that the ps file is not usable as 
> > if Lucida Grande was still the font.sans-serif setting.
> > There might well be something very obvious - From the font manager 
> > code I surmised that the 'sans-serif' entry was a list but I could be 
> > mistaken:
> >
> > import matplotlib
> > matplotlib.use('PS')
> > from matplotlib import pylab
> > import Numeric
> > N = Numeric
> > PL = pylab
> > x = N.arrayrange(100.)
> > y = N.arrayrange(100.)
> > fontDict = {'family':'sans-serif',
> > 'style': 'normal',
> > 'variant':'normal',
> > 'weight': 'medium',
> > 'stretch':'normal',
> > 'size': 12.0,
> > 'sans-serif':['Bitstream Vera Sans']}
> > PL.rc('font',**fontDict)
> > PL.plot(x,y**2)
> > PL.savefig('crap')
> > PL.clf()
> 
> Your second script works fine for me. I was able to switch the font in
> the 
> postscript file, between Bitstream Vera Sans and Arial, by modifying your 
> fontDict. I'm using svn mpl on linux, but I dont think anything has
> changed 
> since 0.87.2 that would effect the results.
> 
> Are there any Mac users with a free moment to run his script?
> 
> Darren
> 
Darren and Jim: Works for me on 10.4. -Jeff

Charlie Moad wrote:
> I absolutely agree with statically linking in libpng and
> freetype. This just makes sense, since it leaves no dependencies. 
> Anyone who is using GTK most likely does not care for a native mac
> solution and would be using fink or darwin port's python. As of late
> I usually build an egg with tk, wx, and the 3 pyarrays with the static
> libs as mentioned above.
Which Python build are you using?
At the moment, there is not a Universal wxPython, and Py2App/bdist_mpkg 
is not yet working with the Universal build, so I may wait for those two 
 before I do a Universal build of MPL.
As packages built for the 2.4.1 Framework build work fine with the 
Universal build (on PPC machines) then I can probably just use what 
you've built for the moment.
By the way, what's the status of the cocoa back-end? And the Cairo 
Back-end on OS-X (and other platforms, while I'm asking)
 > This seems to be very portable. I would be
> happy to test anything you create
I don't suppose you have an Intel Mac do you? That's what would really 
need testing. Or OS-X 10.3.9 -- I'm only running 10.4 on PPC.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Tuesday 28 March 2006 19:05, you wrote:
> plotlibrc setting:
> font.sans-serif : Lucida Grande, Verdana, Geneva, Lucida, Bitstream 
> Vera Sans, Arial, Helvetica, Avant Garde, sans-serif
> I get a postscript file that I cannot view.
> BUT if I change the matplotlibrc file to:
> font.sans-serif : Bitstream Vera Sans
> All goes well and the PS file is fine. This has been discussed on the 
> list previously as an OS X font issue.
>
> My idea was to use the following code to set the font.sans-serif 
> dynamically.
> However, it does not seem to work in that the ps file is not usable as 
> if Lucida Grande was still the font.sans-serif setting.
> There might well be something very obvious - From the font manager 
> code I surmised that the 'sans-serif' entry was a list but I could be 
> mistaken:
>
> import matplotlib
> matplotlib.use('PS')
> from matplotlib import pylab
> import Numeric
> N = Numeric
> PL = pylab
> x = N.arrayrange(100.)
> y = N.arrayrange(100.)
> fontDict = {'family':'sans-serif',
> 'style': 'normal',
> 'variant':'normal',
> 'weight': 'medium',
> 'stretch':'normal',
> 'size': 12.0,
> 'sans-serif':['Bitstream Vera Sans']}
> PL.rc('font',**fontDict)
> PL.plot(x,y**2)
> PL.savefig('crap')
> PL.clf()
Your second script works fine for me. I was able to switch the font in the 
postscript file, between Bitstream Vera Sans and Arial, by modifying your 
fontDict. I'm using svn mpl on linux, but I dont think anything has changed 
since 0.87.2 that would effect the results.
Are there any Mac users with a free moment to run his script?
Darren

>>>>> "Jouni" =3D=3D Jouni K Seppanen <jk...@ik...> writes:
 Jouni> Halldor Bj=F6rnsson <ha...@ve...> writes:
 >> Currently the weekday label is aligned underneath the tickmark,
 >> but I would like to align the label to rhe right of the
 >> tickmark (halfway to next tick)
Have you tried experimenting with the horizontalalignment property,
which accepts left|right|center ? The default is center, which often
looks wrong with rotated ticklabels
JDH

A simple plot command, which worked in 0.86, fails in 087.2:
import pylab
pylab.plot([0.0, 1.0], [0.0, 0.0])
A traceback indicates that it apparently has to do with MaxNLocator
introduced in 0.87.
There was a thread on this list 2 weeks ago started by
da...@in... concerning similar issue, but in that case y-values
were slightly diffrent. Setting pylab.ylim to something like (-1,1)
prior to calling plot(), as John Hunter suggested in that thread, does
not quite work for me in this case.
Also, the changelog to 0.87.2 mentiones that same thread and claims a
fix that "adjusts vmin and vmax if they are nearly the same, not just
if they are equal". In my simple case, they are equal, but still i
figure that it is not being treated gracefully enough.
Thanks,
Sergey