Jae-Joon Lee wrote:
> I cannot reproduce this error.
> I'm using r8330 on Linux.
>
> I guess the error does not occur when you use a normal subplot?
>
> Just in case, replace axes_grid with axes_grid1 and see if it makes
> any difference, i.e.,
>
> from mpl_toolkits.axes_grid1.parasite_axes impo
Hello,
I came across problem of label rotation with autofmt_xdate() in subplothost
too. Is there a new version with the bug fixed or a workaround to doing the
label rotation in subplothost?
Thanks,
Solomon
Jae-Joon Lee wrote:
>
> The workarounds suggested in this thread does not work?
> To me
Yes, it's true that uncommenting path.simplify : False line inside the
matplotlibrc file fixes the artifacts. However, it also produces HUGE
PDF/EPS file sizes. Perhaps, it's better to change path.simplify parameter
as needed inside the code via:
import matplotlib.pyplot as plt
plt.rcParams['pa
On Mon, May 10, 2010 at 12:19 PM, Nico Schlömer
wrote:
> When tick labels are explicitly supplied, that may not actually
> reflect in the return result of get_ticks. Specifically, I set the
> tick labels in a color bar, but get_ticklabels() returns a list of
> empty text objects Text(0,0,'').
> Fo
On Thu, May 20, 2010 at 3:17 PM, Jae-Joon Lee wrote:
> Again, note that not all ticks that are returned by get_xticks()
> methods may be actually drawn.
>
I mean, even if their tick1On (and others) is True.
-JJ
--
Like the gridlines, these are determined during the drawing time.
Each tick instances have
tick1On
tick2On
label1On
label2On
attributes that controls whether to draw tick (or ticklabel) or not.
Again, note that not all ticks that are returned by get_xticks()
methods may be actually drawn.
-JJ
On Thu, May 13, 2010 at 11:25 PM, Uri Laserson wrote:
> I noticed that the example for the radar chart has only a single scale. Is
> there a way to generate a radar plot where each axis has its own scale?
Can you show us some example plots? I'm not clear what you want.
Regards,
-JJ
--
It turns out that when axes_grid toolkit is used and there are some
ticks does not have associated ticklabels (i.e., minor ticks), it
tries to call the "get_texts_widths_heights_descents" method with
empty string.
The following patch prevent this.
--- a/lib/mpl_toolkits/axisartist/axis_artist.py
+
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.plot
use *markevery* keyword.
http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.lines.Line2D.set_markevery
If you want more control, you can always draws the lines (without
markers) first and overplot markers
The error may be dependent on the version of latex being used. Yours
may be handling the empty content just fine. (I'm using TexLive 2009 on
RHEL5).
Mike
On 05/20/2010 02:34 PM, Jae-Joon Lee wrote:
> I cannot reproduce this error.
> I'm using r8330 on Linux.
>
> I guess the error does not occ
The following patch avoids the error with your attached plot. I'm sure
if it the right fix though -- I'm not sure why empty strings are being
sent this far along, and I'm also not seeing any ticks along the top.
Mike
Index: lib/matplotlib/texmanager.py
=
I cannot reproduce this error.
I'm using r8330 on Linux.
I guess the error does not occur when you use a normal subplot?
Just in case, replace axes_grid with axes_grid1 and see if it makes
any difference, i.e.,
from mpl_toolkits.axes_grid1.parasite_axes import SubplotHost
Regards,
-JJ
On Thu
Hi,
I ran into a bug where I get the LaTeX error:
RuntimeError: LaTeX was not able to process the following string:
''
I know it's an uncommon plot, but I need extra (non-uniform) tick labels
at the top so I'm using SubplotHost, on a semilog plot with usetex (so
the fonts look similar to the
On 05/19/2010 11:31 PM, Christer Malmberg wrote:
> Thank you for the help, I never knew what the symlog flag did actually.
>
> However, there is still a slight problem:
>
> =
> x = array([0,1,2,4,6,9,12,24])
> y = array([100, 50, 10, 1
On 05/20/2010 11:32 AM, Ryan May wrote:
> On Thu, May 20, 2010 at 9:34 AM, Michael Droettboom wrote:
>
>> It is a bug, but the broken behavior was kept for backward
>> compatibility. Try setting the vertical alignment to 'baseline'.
>>
>> import matplotlib.pyplot as plt
>> fig=plt.figure()
>>
On Thu, May 20, 2010 at 9:34 AM, Michael Droettboom wrote:
> It is a bug, but the broken behavior was kept for backward
> compatibility. Try setting the vertical alignment to 'baseline'.
>
> import matplotlib.pyplot as plt
> fig=plt.figure()
> plt.text(0.4,0.5,"some text", verticalalignment='base
Ok, good, I just wanted to do a sanity check.
On Thu, May 20, 2010 at 9:21 AM, Michael Droettboom wrote:
> In this case, yes. The assumption of these (private) functions is that
> x will be non-negative. The only case where we need to worry about log
> raising an exception is with exactly 0.
>
It is a bug, but the broken behavior was kept for backward
compatibility. Try setting the vertical alignment to 'baseline'.
import matplotlib.pyplot as plt
fig=plt.figure()
plt.text(0.4,0.5,"some text", verticalalignment='baseline')
plt.text(0.6,0.5,"some text with a g in it", verticalalignment=
That will only work if you have a small-caps variant of the font
installed (which the vast majority of fonts do not). matplotlib does
not do any font synthesis at all -- i.e. it does not create a pseudo
font variation when one does not exist on disk.
Mike
On 05/20/2010 10:19 AM, Nick Schurch
I've also discovered another text problem. If I add two lines of test
to a plot as follows:
import mapplotlib.pyplot as plt
fig=plt.figure()
plt.text(0.4,0.5,"some text")
plt.text(0.6,0.5,"some more text")
then the two sets of text line up nicely with each other, because they
have the same y-axis
In this case, yes. The assumption of these (private) functions is that
x will be non-negative. The only case where we need to worry about log
raising an exception is with exactly 0.
Mike
On 05/20/2010 10:08 AM, Benjamin Root wrote:
> Do we really want to depend on a floating point equality?
>
Hi all,
I'm adding some text to a plt like this:
import mapplotlib.pyplot as plt
fig=plt.figure()
plt.text(0.5,0.5,"some text", variant='small-caps')
but the text that is plotted is not small caps, its just normal. Is
this a bug or am I doing something wrong?
--
Cheers,
Nick Schurch
Data Ana
Do we really want to depend on a floating point equality?
Ben Root
On Thu, May 20, 2010 at 9:02 AM, Michael Droettboom wrote:
> Yep. That's a bug. Here's a patch to fix it:
>
> ndex: lib/matplotlib/ticker.py
> ===
> --- lib/matpl
Yep. That's a bug. Here's a patch to fix it:
ndex: lib/matplotlib/ticker.py
===
--- lib/matplotlib/ticker.py(revision 8323)
+++ lib/matplotlib/ticker.py(working copy)
@@ -1178,16 +1178,21 @@
def decade_down(x, base=10):
Thank you for the help, I never knew what the symlog flag did actually.
However, there is still a slight problem:
=
x = array([0,1,2,4,6,9,12,24])
y = array([100, 50, 10, 100, 5, 1, 1, 1])
subplot(111)
plot(x, y)
yscale('symlog')
xsc
On 5/18/2010 9:53 AM, Nick Schurch wrote:
> Is there anyway of re-ploting the distribution generated by hist at a
> later point?
http://docs.scipy.org/doc/numpy/reference/generated/numpy.histogram.html
hth,
Alan Isaac
-
On 19/05/2010 20:45, David wrote:
> Werner F. Bruhin writes:
>
>
>>
>> On 19/05/2010 19:55, David Grudoski wrote:
>>
>>I'm trying to build an executable using
>> PY2EXE; running Python 2.5.2 and wxPython 2.8.10.1 and MatplotLib 0.99.0
>>I tried using the setup.py from the
>> PY2EXE.org
27 matches
Mail list logo