Thanks so much John! That does the trick.
I'm just a new user of mpl, so your question about whether the default
behavior of draw should be changed is probably "above my pay grade." I just
don't know the API well enough to comment intelligently about it. That
said, I would suggest that this behavior be documented (either in the
tutorial page I originally accessed, the documentation for "canvas.draw()",
both locations, or some other appropriate place).
Thanks again from a very satisfied mpl user,
Brian
John Hunter-4 wrote:
>
> On Fri, Feb 26, 2010 at 5:14 PM, brianjpetersen
> <brianjpetersen@...> wrote:
>>
>> Hi All,
>>
>> I'm a new matplotlib user on a Windows XP machine running mpl0.99.0 under
>> Python 2.5. I'm using the default rc file.
>>
>> While reading through the excellent matplotlib "how-to" tutorial
>> (http://matplotlib.sourceforge.net/faq/howto_faq.html), I came across two
>> useful scripts: one to save a figure with a transparent background, and
>> one
>> to resize axes automatically so that labels aren't cut off. I was able
>> to
>> run both these examples given on the "how-to" successfully.
>>
>> However, I ran into trouble when trying to combine them as follows:
>>
>> =====
>>
>> import matplotlib.pyplot as plt
>> import matplotlib.transforms as mtransforms
>>
>> fig = plt.figure()
>> ax = fig.add_subplot(111)
>> ax.plot(range(10))
>> ax.set_yticks((2,5,7))
>> labels = ax.set_yticklabels(('really, really, really', 'long', 'labels'))
>>
>> def on_draw(event):
>> bboxes = []
>> for label in labels:
>> bbox = label.get_window_extent()
>> # the figure transform goes from relative coords->pixels and we
>> # want the inverse of that
>> bboxi = bbox.inverse_transformed(fig.transFigure)
>> bboxes.append(bboxi)
>>
>> # this is the bbox that bounds all the bboxes, again in relative
>> # figure coords
>> bbox = mtransforms.Bbox.union(bboxes)
>> if fig.subplotpars.left < bbox.width:
>> # we need to move it over
>> fig.subplots_adjust(left=1.1*bbox.width) # pad a little
>> fig.canvas.draw()
>>
>> return False
>>
>> fig.canvas.mpl_connect('draw_event', on_draw)
>>
>> plt.savefig('test.png', transparent=True)
>>
>> =====
>>
>> In this case, the saved png file is transparent, but the original set of
>> axes, labels, and plot are visible as well (basically, I have two
>> identical
>> plots shifted over one another on a transparent background).
>>
>> Is there a way to suppress the original output (something akin to
>> "fig.canvas.erase()" or "fig.canvas.clear()", but I can't seem to figure
>> it
>> out) so that the output png only shows the shifted axes and not both
>> sets?
>
> Interesting! That one really surprised me. It turns out mpl is not
> clearing the pixel buffer from the previous draw command. Normally
> you don't see this because the call to draw the figure.patch blanks
> out the pixel buffer with the background color, but since your figure
> patch is transparent you can see the legacy. A call to
> renderer.clear() before drawing again will erase the old image
> (perhaps we should be doing this by default?)
>
> import matplotlib
> matplotlib.use('Agg')
> import matplotlib.pyplot as plt
> import matplotlib.transforms as mtransforms
>
> fig = plt.figure()
> ax = fig.add_subplot(111)
> ax.plot(range(10))
> ax.set_yticks((2,5,7))
> labels = ax.set_yticklabels(('really, really, really', 'long', 'labels'))
>
> def on_draw(event):
> bboxes = []
> for label in labels:
> bbox = label.get_window_extent()
> # the figure transform goes from relative coords->pixels and we
> # want the inverse of that
> bboxi = bbox.inverse_transformed(fig.transFigure)
> bboxes.append(bboxi)
>
> # this is the bbox that bounds all the bboxes, again in relative
> # figure coords
> bbox = mtransforms.Bbox.union(bboxes)
> if fig.subplotpars.left < bbox.width:
> # we need to move it over
> fig.subplots_adjust(left=1.1*bbox.width) # pad a little
> fig.canvas.get_renderer().clear()
> fig.canvas.draw()
>
> return False
>
> fig.canvas.mpl_connect('draw_event', on_draw)
>
> plt.savefig('test.png', transparent=True)
>
>
> JDH
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Matplotlib-users mailing list
> Matplotlib-users@...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
--
View this message in context: http://old.nabble.com/Transparency-with-fig.canvas.mpl_connect-tp27724532p27738002.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Would it be possible to have a different alpha (transparency) value
for the marker face color and edge color for a single line? (Either
currently or as a new feature of mpl). It seems like by default alpha
applies to them both.
I ask because I am experimenting with getting a different look for the
markers by plotting the same points twice, once with a transparent
marker face color and then again with a fully opaque thin marker edge
and it is a nice effect (see attached image). The problem is, I am
doing point picking, and the two-points-at-one-location seems to be
making the popup I create slower and occasionally mis-positioned.
Although I may be able to work that out, I thought it would be
"cleaner" to just have one set of points.
Thanks,
Che

This is a bug report.
I am using matplotlib 0.99.1 on Windows. When using contour with the
keyword
argument locator=ticker.FixedLocator(levels), the plot is always dropping
the first
and last contour level. If there are less than 3 levels, contour.py throws
an
exception.
My workaround is to duplicate the first and last levels when using the fixed
locator:
e.g. my argument becomes
locator=FixedLocator( [levels[0]] + levels + [levels[-1]] )
I have traced the problem to the last line in contour.py, method _autolev()
which
strips the first and last levels if the contours are not filled:
return lev[1:-1]
This line occurs at line 682 in my version of contour.py which came with the
0.991 installation.
I realize that I could specify the levels in the argument V and this does
work. However
this code is embedded in GUI-ness which allows the user to choose how the
contours
are selected. Passing the locator seems to be the best option code-wise.
Thank you,
Dave Smith

2010/2/26 jamgood96 <jamgood96@...>:
>
> Each time I try to run a script, it just keeps printing, "The time is: The
> time is: Fri Feb 26 13:27:08 2010". over and over. I believe I installed all
> the packages correctly, but honesty was a bit overwhelmed. I've tried
> attaching a screen shot of what is happening.
I wonder why in your py2.6 lib/.../calendar.py on line 6 there is a statement:
if prev_time != the_time:
In my calendar.py the file starts:
"""Calendar printing functions
Note when comparing these calendars to the ones printed by cal(1): By
default, these calendars have Monday as the first day of the week, and
Sunday as the last (the European convention). Use setfirstweekday() to
set the first day of the week (0=Monday, 6=Sunday)."""
import sys
import datetime
import locale as _locale
__all__ = ["IllegalMonthError", "IllegalWeekdayError", "setfirstweekday",
"firstweekday", "isleap", "leapdays", "weekday", "monthrange",
"monthcalendar", "prmonth", "month", "prcal", "calendar",
"timegm", "month_name", "month_abbr", "day_name", "day_abbr"]
?
The thing happens when you import matplotlib.pyplot, which imports
matplotlib's cores, which imports calendar from lib/.../site-packages.
I can only guess that this calendar.py has been placed there for some
reason, overwriting Python's original calendar.py?
Friedrich

Things become more and more complicated with time. I come up with
four things to consider:
First the ring I already mentioned is visualised in attachment
Ring.png. A > C > B > A, no z sorting possible, because no linear
order anymore.
Second, the intersecting line may not always separate a tringle in
front as in your example, see "Fourangle".png. Though either the
front or the back part of the intersected tringle is always a
triangle. Furthemore, I suggest to cut both tringles along the
intersection line. This makes things easier to implement, I'm quite
convinced.
Third, z sorting. How does the current algorithm I didn't understand
work? One may consider pict z-sorting.png. For a simple-minded
algorithm comparing the center of mass, the triangle in front seems to
be at higher z.
Fourth, detection of intersection. With the algorithm I proposed, I
assume non-intersecting triangles. The problem is how to detect
intersection at all. One might think that it's sufficient to check in
the corners for inconsistencies with non-intersection. But
unfortunataly, it isn't like that. In pict Tricking.png is an
example. An algorithm checking the corners will find out that [red]
is in front of [green], and nothing more, and hence cannot conclude
towards intersection. I have no straightforward idea?
One idea more: Not leaving B in your example triangles.png intact,
but creating two new planar convex 4-polygons, filling those with
triangles is very easy and straightforward. Thus it works out for A
and B as pointed out in triangles2.png.
Thus 1. detect intersecting triangles and cut them into pieces, second
apply z sorting or equivalents?
I had implemented z sorting for pairs of triangles already, and would
like to compare with the mplot3d algorithmic idea. Using this, one
could simply let a sort algorithm of any kind do the job. Apart from
that results may look strange when there are rings :-)
2010/2/28 Ben Axelrod <BAxelrod@...>:
> Interesting, but I think subdividing triangles like this is unnecessary. For most cases, when one triangle completely covers the other, all that is required it to Z order the triangles. This is what mplot3d does already. The only case we have yet to handle is when one triangle "pierces" the other. As seen in the attached image. Triangle B is mostly behind triangle A, except for a small piece labeled C. All we would have to do is determine the line of intersection, then create a new triangle C. Then we just draw B first, then A, then C.
>
> I think the hardest part is probably doing this for general polygons and handling the edges properly. But that should not be super hard.
Hmm. First I thought: One should create pathes of lines and patches
of surfaces. The lines do not need to be z ordered at all, they just
have to be z ordered against the surfaces. But that's not sufficient,
because lines /on/ surface may be drawn before the surface or not, at
random, spoiling the thing. Maybe have for each triangle outline
attributes? I guess that's what you had in mind from the beginning.
Friedrich

On Fri, Feb 26, 2010 at 5:14 PM, brianjpetersen
<brianjpetersen@...> wrote:
>
> Hi All,
>
> I'm a new matplotlib user on a Windows XP machine running mpl0.99.0 under
> Python 2.5. I'm using the default rc file.
>
> While reading through the excellent matplotlib "how-to" tutorial
> (http://matplotlib.sourceforge.net/faq/howto_faq.html), I came across two
> useful scripts: one to save a figure with a transparent background, and one
> to resize axes automatically so that labels aren't cut off. I was able to
> run both these examples given on the "how-to" successfully.
>
> However, I ran into trouble when trying to combine them as follows:
>
> =====
>
> import matplotlib.pyplot as plt
> import matplotlib.transforms as mtransforms
>
> fig = plt.figure()
> ax = fig.add_subplot(111)
> ax.plot(range(10))
> ax.set_yticks((2,5,7))
> labels = ax.set_yticklabels(('really, really, really', 'long', 'labels'))
>
> def on_draw(event):
> bboxes = []
> for label in labels:
> bbox = label.get_window_extent()
> # the figure transform goes from relative coords->pixels and we
> # want the inverse of that
> bboxi = bbox.inverse_transformed(fig.transFigure)
> bboxes.append(bboxi)
>
> # this is the bbox that bounds all the bboxes, again in relative
> # figure coords
> bbox = mtransforms.Bbox.union(bboxes)
> if fig.subplotpars.left < bbox.width:
> # we need to move it over
> fig.subplots_adjust(left=1.1*bbox.width) # pad a little
> fig.canvas.draw()
>
> return False
>
> fig.canvas.mpl_connect('draw_event', on_draw)
>
> plt.savefig('test.png', transparent=True)
>
> =====
>
> In this case, the saved png file is transparent, but the original set of
> axes, labels, and plot are visible as well (basically, I have two identical
> plots shifted over one another on a transparent background).
>
> Is there a way to suppress the original output (something akin to
> "fig.canvas.erase()" or "fig.canvas.clear()", but I can't seem to figure it
> out) so that the output png only shows the shifted axes and not both sets?
Interesting! That one really surprised me. It turns out mpl is not
clearing the pixel buffer from the previous draw command. Normally
you don't see this because the call to draw the figure.patch blanks
out the pixel buffer with the background color, but since your figure
patch is transparent you can see the legacy. A call to
renderer.clear() before drawing again will erase the old image
(perhaps we should be doing this by default?)
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
import matplotlib.transforms as mtransforms
fig = plt.figure()
ax = fig.add_subplot(111)
ax.plot(range(10))
ax.set_yticks((2,5,7))
labels = ax.set_yticklabels(('really, really, really', 'long', 'labels'))
def on_draw(event):
bboxes = []
for label in labels:
bbox = label.get_window_extent()
# the figure transform goes from relative coords->pixels and we
# want the inverse of that
bboxi = bbox.inverse_transformed(fig.transFigure)
bboxes.append(bboxi)
# this is the bbox that bounds all the bboxes, again in relative
# figure coords
bbox = mtransforms.Bbox.union(bboxes)
if fig.subplotpars.left < bbox.width:
# we need to move it over
fig.subplots_adjust(left=1.1*bbox.width) # pad a little
fig.canvas.get_renderer().clear()
fig.canvas.draw()
return False
fig.canvas.mpl_connect('draw_event', on_draw)
plt.savefig('test.png', transparent=True)
JDH

Interesting, but I think subdividing triangles like this is unnecessary. For most cases, when one triangle completely covers the other, all that is required it to Z order the triangles. This is what mplot3d does already. The only case we have yet to handle is when one triangle "pierces" the other. As seen in the attached image. Triangle B is mostly behind triangle A, except for a small piece labeled C. All we would have to do is determine the line of intersection, then create a new triangle C. Then we just draw B first, then A, then C.
I think the hardest part is probably doing this for general polygons and handling the edges properly. But that should not be super hard.
-Ben
________________________________________
From: Friedrich Romstedt [friedrichromstedt@...]
Sent: Saturday, February 27, 2010 11:28 AM
To: matplotlib-users
Subject: Re: [Matplotlib-users] mplot3d stays?
http://www.friedrichromstedt.org/python/pyclip/a01.Zerteilung.pdf
(It's unfortunately in german, but the graphics are self-explaining)
A school mate working together with me on the project has worked that out.
H = number of corners of the front triangle lying inside of the back triangle
V = number of corners of the back triangle lying inside of the front triangle
S = number of the collinear edges of the two triangles
Z = number of intersection points of the two tringles' edges, minus
the number of those occuring because of collinear edges.
Red: front triangle
Black: back triangle
Green: subdivision lines in the back triangle.
I will check my implementation in C++ today. I will maybe need some
advice in making a Python module out of it.
Friedrich
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Sat, Feb 27, 2010 at 2:23 PM, David Goldsmith
<d_l_goldsmith@...> wrote:
> Question 2) is there some way I can add pieces of the array incrementally to
> the image into their proper place, i.e., modify the following code:
>
> ax.imshow(image[0:ny/2+1, 0:nx/2+1]) # upper left corner of image
> ax.hold(True)
> ax.imshow(argW[ny/2+1:-1, 0:nx/2+1]) # lower left corner of image
> ax.imshow(argW[0:ny/2+1, nx/2+1:-1]) # upper right corner of image
> ax.imshow(argW[ny/2+1:-1, nx/2+1:-1]) # lower right corner of image
Try the extents keyword argument. It let's you specify the corners of
the image in data coordinates.
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

If I read your correctly,
for l, b in zip(x, y):
# And here I work with data coordinates (!)
dashBox = Bbox.from_bounds(l, b, width+5, height+5)
badness = 0
for line in lines:
if line.intersects_bbox(dashBox):
badness += 1
x, y (therefore l, b) in data coordinate.
width, height?? this seems to be some wx specific coordinate, i have no idea.
lines (therefore line) in display coordinate.
converting x,y to display coordinate should straight forward. But I'm
not sure what kind of coordinate width and height has. Is it a method
of some class derived from matplotlib's Text?? If then, the extent of
the text can be measured using the get_window_extent method. This
requires a renderer instance, which should be known if the method is
called during the drawing time.
Again, post a complete but simple(!) code.
-JJ
On Sat, Feb 27, 2010 at 8:59 PM, Andrea Gavana <andrea.gavana@...> wrote:
> On 28 February 2010 01:18, Jae-Joon Lee wrote:
>> On Sat, Feb 27, 2010 at 12:29 PM, Andrea Gavana <andrea.gavana@...> wrote:
>>> This code is not doing anything useful as I always get a badness of 0,
>>> although I can see that the new text overlaps quite a lot of other
>>> artists.
>>>
>>> Does anyone have some suggestion on how to improve the code?
>>>
>>
>> A snippet of code seldom helps.
>> Is your x,y input in display coordinates?
>
> No, data values.
>
>> Ideally, this must be checked in the drawing time (as in the legend).
>
> This is what I am trying to do, but I messed up screen/data/canvas
> coordinates and I can't get my head around it :-(
>
> Andrea.
>
> "Imagination Is The Only Weapon In The War Against Reality."
> http://xoomer.alice.it/infinity77/
> http://thedoomedcity.blogspot.com/
>

On 28 February 2010 01:18, Jae-Joon Lee wrote:
> On Sat, Feb 27, 2010 at 12:29 PM, Andrea Gavana <andrea.gavana@...> wrote:
>> This code is not doing anything useful as I always get a badness of 0,
>> although I can see that the new text overlaps quite a lot of other
>> artists.
>>
>> Does anyone have some suggestion on how to improve the code?
>>
>
> A snippet of code seldom helps.
> Is your x,y input in display coordinates?
No, data values.
> Ideally, this must be checked in the drawing time (as in the legend).
This is what I am trying to do, but I messed up screen/data/canvas
coordinates and I can't get my head around it :-(
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/http://thedoomedcity.blogspot.com/

On Sat, Feb 27, 2010 at 12:29 PM, Andrea Gavana <andrea.gavana@...> wrote:
> This code is not doing anything useful as I always get a badness of 0,
> although I can see that the new text overlaps quite a lot of other
> artists.
>
> Does anyone have some suggestion on how to improve the code?
>
A snippet of code seldom helps.
Is your x,y input in display coordinates?
Ideally, this must be checked in the drawing time (as in the legend).
With your current approach, there could be lots of possible reason
that this does not work.
Regards,
-JJ

I believe it is not just the size of font but the font itself should match.
Depending on your setting, the tex file generated by matplotlib
include preambles related with font setting. For example, below is
mine.
\documentclass{article}
\usepackage{type1cm}
\renewcommand{\rmdefault}{pnc}
\usepackage{helvet}
\usepackage{courier}
\usepackage{textcomp}
\usepackage{ucs}
\usepackage[utf8x]{inputenc}
And of course, the output is different from the output without these preambles.
So when you say,
On Fri, Feb 26, 2010 at 5:09 AM, Freddie Witherden
<freddie@...> wrote:
> Does anyone know what might be causing this? The document font sizes are the
> same and I tried to match the LaTeX file as closely as possible to the one used
> internally by matplotlib.
>
Did you match those font preambles also?
Also, is it just the pdf backend? What about other backend?
Regards,
-JJ

Hi, folks! I'm again encountering the problem - imshow generating a
MemoryError exception trying to image a very large array - discussed in this
thread I started almost a year and a half ago.
Question 1) has anything changed in MPL in that time interval which would
provide an "easy" solution?
Question 2) is there some way I can add pieces of the array incrementally to
the image into their proper place, i.e., modify the following code:
ax.imshow(image[0:ny/2+1, 0:nx/2+1]) # upper left corner of image
ax.hold(True)
ax.imshow(argW[ny/2+1:-1, 0:nx/2+1]) # lower left corner of image
ax.imshow(argW[0:ny/2+1, nx/2+1:-1]) # upper right corner of image
ax.imshow(argW[ny/2+1:-1, nx/2+1:-1]) # lower right corner of image
so that each subsequent imshow doesn't cover up the previous imshow and is
placed in the right place relative to each of the other pieces?
Question 3) Would such incremental addition work to get around the memory
limit, or does the fact (if the following statement is in fact correct) that
eventually the entire too-large image needs to be handled doom this strategy
to failure?
Question 4) would I have this problem if I was running 64 bit (i.e., OS, as
well as 64 bit builds of Python, numpy, MPL, etc.), i.e., is it most likely
a memory addressing problem?
Question 5) can anyone suggest any other work-around(s)?
Thanks!
DG
On Sat, Sep 6, 2008 at 4:00 PM, David Goldsmith <d_l_goldsmith@...>wrote:
> Ah, Ich verstehe now. I'll try RGBA-ing it; in the meantime, let me know
> if the colormapping conversion gets changed to 32 bit. Thanks again!
>
> DG
>
> --- On Sat, 9/6/08, Eric Firing <efiring@...> wrote:
>
> > From: Eric Firing <efiring@...>
> > Subject: Re: [Matplotlib-users] imshow size limitations?
> > To: d_l_goldsmith@...
> > Cc: matplotlib-users@...
> > Date: Saturday, September 6, 2008, 3:13 PM
> > David Goldsmith wrote:
> > > Thanks, Eric!
> > >
> > > --- On Sat, 9/6/08, Eric Firing
> > <efiring@...> wrote:
> > >
> > > -- snip OP --
> > >
> > >> It looks to me like you simply ran out of
> > memory--this is
> > >> not an imshow
> > >> problem as such. Your array is about 1e8
> > elements, and as
> > >> floats that
> > >> would be close to a GB--just for that array alone.
> > Do you
> > >
> > > Well, I anticipated that, so I do initialize the
> > storage for the numpy array as numpy.uint8 and have
> > confirmed that the data in the array returned by the
> > function which creates it remains numpy.uint8, so it should
> > "only" be ~100MB (indeed, the .na file into which
> > I tofile it is 85,430 KB, just as it should be for a 10800 x
> > 8100 array of uint8 elements). And the ax.imshow statement
> > doesn't (directly) cause the crash (but I don't know
> > that it isn't making either a float copy or an in-place
> > conversion of the array). So, AFAIK, right up until the
> > statement:
> > >
> > > canvas.print_figure('HiResHex')
> > >
> > > the data being imaged are all numpy.uint8 type.
> >
> > Yes, but it looks to me like they are still getting
> > color-mapped, and
> > this requires conversion to numpy.float. This may be a bad
> > aspect of
> > the mpl design, but it is quite deeply embedded. I suspect
> > the best we
> > could do would be to use float32 instead of float64;
> > certainly for color
> > mapping one does not need 64 bits.
> >
> > Using numpy.uint8 helps only if you are specifying RGBA
> > directly,
> > bypassing the colormapping.
> >
> > >
> > >> really need
> > >> all that resolution?
> > >
> > > Well, there's the rub: I fancy myself a fractal
> > "artist" and I have
> > > access to an HP DesignJet 500ps plotter with a maximum
> > resolution of
> > > 1200 x 600 dpi. For the size images I'm trying to
> > make (I'm hoping to go
> > > even bigger than 36" x 27", but I figured
> > that as a good starting point)
> > > even I regard _that_ resolution as too much - I was
> > thinking of 300 x
> > > 300 dpi (which is its "normal" resolution)
> > as certainly worthy of giving
> > > a try. :-)
> >
> > >> If you do, you will probably have to
> > >> get a much
> > >> more capable machine.
> > >
> > > Possible, but I was hoping to generate at least one
> > "proof" first to determine how hard I'd need
> > to try.
> > >
> > >> Otherwise, you need to knock down
> > >> the size of
> > >> that array before trying to plot or otherwise
> > manipulate
> > >> it.
> > >
> > > Forgive me, but I'd like a more detailed
> > explanation as to why: I
> > > have
> > > ample (~35 GB, just on my built-in disc, much more
> > than that on external
> > > discs) harddisc space - isn't there some way to
> > leverage that?
> >
> > I don't know enough about virtual memory
> > implementations--especially on
> > Win or Mac--to say. In practice, I suspect you would find
> > that as soon
> > as you are doing major swapping during a calculation, you
> > will thrash
> > the disk until you run out of patience.
> >
> >
> > >> With respect to imshow, probably you can get it to
> > handle
> > >> larger images
> > >
> > > Again, imshow doesn't appear to be the culprit
> > (contrary to my
> > > original subject line), rather it would appear to be
> > > canvas.print_figure. (While I'm on the subject of
> > canvas.print_figure,
> > > isn't there some way for MPL to "splash"
> > the image directly to the
> > > screen, without first having to write to a file? I
> > didn't ask this
> > > before because I did eventually want to write the
> > image to a file, but I
> > > would prefer to do so only after I've had a look
> > at it.)
> >
> > It is imshow in the sense that most of the action in mpl
> > doesn't happen
> > when you call imshow or plot or whatever--they just set
> > things up. The
> > real work is done in the backend when you display with
> > show() or write
> > to a file.
> >
> >
> > >> if you feed them in as NxMx4 numpy.uint8 RGBA
> > arrays--but I
> > >> doubt this
> > >> is going to be enough, or the right approach, for
> > your
> > >> present situation.
> > >
> > > Right: I don't see how that would be better than
> > having a single 8
> > > bit
> > > datum at each point w/ color being determined from a
> > color map (which is
> > > how I'd prefer to do it anyway).
> >
> > The way it is better is that it avoids a major operation,
> > including the
> > generation of the double-precision array. The rgba array
> > can go
> > straight to agg.
> >
> > Eric
> >
> >
> > > Thanks again,
> > >
> > > DG
> > >> Eric
> > >>
> > >>> Platform Details: MPL 0.91.2 (sorry, I
> > didn't
> > >> realize I was running such an old version, maybe I
> > just need
> > >> to upgrade?), Python 2.5.2, Windows XP 2002 SP3,
> > 504MB
> > >> physical RAM, 1294MB VM Page size (1000MB init.,
> > 5000MB max)
> > >>> Thanks!
> > >>>
> > >>> DG
>
>
>
>

Hi All,
I am trying to visualize some more text in an already rather
crowded 2D plot. As this new information I want to display is optional
(it depends on a use choice) but possibly very useful as information,
I would like to add it as text inside my plot, and possibly to add it
in a "smart" way (i.e., with minimum or no overlapping between this
new text and the rest of the plot, like legend does with loc=0).
Now, I have tried to steal the code from legend.py but I am not
getting anywhere, also because I am mixing display coordinates, data
coordinates and wx.DC text extents and I am getting crazy :-(
This is the code I have so far:
def PositionAnnotation(self, dc, label, dash, x, y):
"""
Position a matplotlib text instance without overlapping with
the rest of the data.
:param `dc`: an instance of wx.ClientDC;
:param `label`: the label to display (2 lines of text);
:param `dash`: the actual TextWithDash matplotlib class to position
:param `x`: a list of possible x location (this is fixed)
:param `y`: a list of possible y location (this is fixed)
"""
# Stolen from legend.py
lines = []
# Here I work with display coordinates (!)
for handle in self.leftaxis.lines:
path = handle.get_path()
trans = handle.get_transform()
tpath = trans.transform_path(path)
lines.append(tpath)
# End of stolen from legend.py
# Here I work with screen/character coordinates (!)
width, height, dummy = dc.GetMultiLineTextExtent(label)
candidates = []
for l, b in zip(x, y):
# And here I work with data coordinates (!)
dashBox = Bbox.from_bounds(l, b, width+5, height+5)
badness = 0
for line in lines:
if line.intersects_bbox(dashBox):
badness += 1
ox, oy = l, b
if badness == 0:
return ox, oy
candidates.append((badness, (l, b)))
# Stolen from legend.py
# rather than use min() or list.sort(), do this so that we are assured
# that in the case of two equal badnesses, the one first considered is
# returned.
# NOTE: list.sort() is stable.But leave as it is for now. -JJL
minCandidate = candidates[0]
for candidate in candidates:
if candidate[0] < minCandidate[0]:
minCandidate = candidate
ox, oy = minCandidate[1]
return ox, oy
This code is not doing anything useful as I always get a badness of 0,
although I can see that the new text overlaps quite a lot of other
artists.
Does anyone have some suggestion on how to improve the code?
Thank you in advance.
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/http://thedoomedcity.blogspot.com/

http://www.friedrichromstedt.org/python/pyclip/a01.Zerteilung.pdf
(It's unfortunately in german, but the graphics are self-explaining)
A school mate working together with me on the project has worked that out.
H = number of corners of the front triangle lying inside of the back triangle
V = number of corners of the back triangle lying inside of the front triangle
S = number of the collinear edges of the two triangles
Z = number of intersection points of the two tringles' edges, minus
the number of those occuring because of collinear edges.
Red: front triangle
Black: back triangle
Green: subdivision lines in the back triangle.
I will check my implementation in C++ today. I will maybe need some
advice in making a Python module out of it.
Friedrich

Hi,
I am a fan of the STIX sans serif typeface for mathtext, but I was
wondering if it was possible to use this typeface for non-mathtext
text as well. My main use for this is ticklabels, which seem to render
in the non-mathtext font no matter what I do. I have tried using
ax.xaxis.set_major_formatter(P.ScalarFormatter(useMathText=True))
to force the (scalar) major ticks to use mathtext and thus stixsans,
but this does not work. Am I doing something wrong here?
A better solution (for me) would be to use STIX sans serif faces as
the regular font, ie something like
rcParams["font.sans-serif"] = 'stixsans'
I know this is possible for serif fonts, and I know that a post to the
list back in 2008 noted that it was not (at that time) possible for
sans-serifs. I am curious to know if there has been any progress on
allowing STIX sans-serifs in non-mathtext text.
thanks,
Jeff Oishi