mpl hates my guts today.
I'm developing an application for work and need to plot some spectra on a
logscale. I can recreate my problem with embedding_in_qt4, by replacing
MyDynamicMplCanvas.compute_initial_figure with this:
def compute_initial_figure(self):
self.axes.plot([0, 1, 2,
Rob, Mike,
What this implies to me is that either there is a problem with the code
that is generating afmdict (and I did not change that code, I just
caused it to be invoked when the fontManager instance is created.), or
there is a problem with some .afm files on Rob's machine.
I really don't
On Aug 14, 2007, at 1:55 PM, Eric Firing wrote:
> rcParams['pdf.use14corefonts']
Indeed, reversing this value fixes the problem.
My value had been set to False.
pdf.use14corefonts : True
in the mplrc file works with the latest revision.
-r
Rob Hetland, Associate Professor
Dept.
Mike, Rob,
One of the changes I made was to cause the afmdict to be generated
automatically at the start rather than on demand. The problem you are
having seems related to afm fonts, so I suspect this is it.
What is your rcParams['pdf.use14corefonts'] setting? Please try
reversing it, and se
> What are you setting in matplotlibrc (or in your plot?)
>
> Also, if you delete the font cache (which is now
> ~/.matplotlib/fontManager.cache), does that help? (Might be a useful
> data point -- not suggesting it as a solution.)
Well, I've been trying out the Arev fonts, as you know, so I chan
Hmm... I'm not readily able to reproduce this here.
What are you setting in matplotlibrc (or in your plot?)
Also, if you delete the font cache (which is now
~/.matplotlib/fontManager.cache), does that help? (Might be a useful
data point -- not suggesting it as a solution.)
Cheers,
Mike
Rob
> Done and committed.
It seems a recent commit has severely broken my font loading. When I
start MPL now, I get an infinite stream of messages similar to:
Found an unknown keyword in AFM header (was )
Found an unknown keyword in AFM header (was !"%
#*3*9*:*<[EMAIL PROTECTED]@";;"C#C)*=>A&B879
At 10:36 AM 8/14/2007, Eric Firing wrote:
Ted Drain wrote:
Manuel,
We do plots like this all the time. One thing we've found that's
nice to have is a keyword that controls when the increase in y
happens. We use a step style keyword that can be 'pre' (go up then
right), 'post' (go right then
Ted Drain wrote:
> Manuel,
> We do plots like this all the time. One thing we've found that's nice
> to have is a keyword that controls when the increase in y happens. We
> use a step style keyword that can be 'pre' (go up then right), 'post'
> (go right then up), and 'mid' (right 0.5, up, rig
Manuel,
We do plots like this all the time. One thing we've found that's
nice to have is a keyword that controls when the increase in y
happens. We use a step style keyword that can be 'pre' (go up then
right), 'post' (go right then up), and 'mid' (right 0.5, up, right 0.5).
Regarding your
On Thu, Aug 02, 2007 at 10:31:04AM -0400, Michael Droettboom wrote:
> I don't know if we ever reached consensus on how to specify math text
> vs. regular text. I agree with Eric that it's down to two options:
> using a new kw argument (probably format="math" to be most future-proof)
> or Math('
Hi,
I have created a patch against latest svn that adds a function step to
the axes class to plot step-functions ;-) It's really simple but nice
... Any interest in adding this?
Manuel
<>Index: axes.py
===
--- axes.py (revision
Michael Droettboom wrote:
> My suspicion from looking at the code was that a great deal of time
was spent statting all the font files at start up. FontManager.__init__
goes through all the files in the cache to determine if they still exist
and refreshes the cache if it finds one missing. Your patc
13 matches
Mail list logo