matplotlib-devel Mailing List for matplotlib

Yes. The FontProperties objects have a list of options that they try in 
order.
(The fname parameter is sort of an implementation detail rather than a 
public API.)
Cheers,
Mike
Jae-Joon Lee wrote:
> Hello,
>
> When I need to use unicode string in matplotlib, I often set the font
> name directly as below.
>
> import matplotlib.font_manager as fm
> fp1=fm.FontProperties(fname="/users/research/lee/.fonts/malgun.ttf")
>
> This used to work. But not anymore. And I guess this is related with a
> recent change in font_manager.py (r5356 by Michael),
>
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/font_manager.py?r1=5195&r2=5356
>
> Note that "return fname" bacame "return fname[0]".
> So, its seems that now we need to provide a list of filenames for
> fname parameters. And a code like below works.
>
> fp1=fm.FontProperties(fname=["/users/research/lee/.fonts/malgun.ttf"])
>
> Is this change intended? I just want to make sure before I start
> changing my codes.
> Regards,
>
> -JJ
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hello,
When I need to use unicode string in matplotlib, I often set the font
name directly as below.
 import matplotlib.font_manager as fm
 fp1=fm.FontProperties(fname="/users/research/lee/.fonts/malgun.ttf")
This used to work. But not anymore. And I guess this is related with a
recent change in font_manager.py (r5356 by Michael),
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/font_manager.py?r1=5195&r2=5356
Note that "return fname" bacame "return fname[0]".
So, its seems that now we need to provide a list of filenames for
fname parameters. And a code like below works.
 fp1=fm.FontProperties(fname=["/users/research/lee/.fonts/malgun.ttf"])
Is this change intended? I just want to make sure before I start
changing my codes.
Regards,
-JJ

Hi,
Back from vacation. The problem with not being able to end point
selection is easy to fix - allow keyboard clicks to also select points
and enter to also exit (this is the solution matlab uses). This is easy
to add and I will try to work on it sometime over the next couple of
weeks.
I will try your example sometime soon and see what happens. It sounds
like the problem has something to do with what happens when the label
covers the entire contour - currently the contour gets deleted entirely,
but this seems to be doing something strange in your case.
Cheers,
David
On Thu, 2008年08月21日 at 16:02 +0200, Mark Bakker wrote:
> David -
> 
> Enjoy your vacation.
> 
> I tried the contour_label_demo and it works fine, but my problem
> remains.
> 
> I suggest you try the example I provided below, and notice the
> difference between labeling with inline=True and inline=False. When
> inline=True the contours in the middle part (which don't get labeled,
> presumably because there isn't enough room) get erased.
> 
> I figured out the manual input problem. The trick is that you require
> to press the middle button to end (I'll do a post to the user's list).
> Many laptops don't have a middle button. Although suggestions are
> found on the web that pushing both buttons simultaneously works, I
> have never seen it work. What you have to do is configure your
> touchpad such that a corner acts as the middle button. Once I figured
> that out, I could end manually selecting the labels. Very nice. If I
> may, I strongly recommend you change the code such that pushing the
> right button ends the manual input. Is there any reason not to use the
> right button for that?
> 
> I hope you can fix the inline problem. Thanks for all the other new
> cool features,
> 
> Mark
> 
> On Tue, Aug 19, 2008 at 4:06 PM, <ka...@mp...> wrote:
> Hi,
> 
> I am currently on vacation, so I can ́t be of much help - back
> beginning of next month. It would be useful if
> you could try the clabel and ginput demo scripts and send
> images of the resulting figures so that we can determine
> exactly what things work and don ́t work.
> 
> Thanks,
> David
> 
> 
> 
> Mark Bakker <ma...@gm...> ha escrito:
> 
> 
> 
> Hello David and the developers list-
> 
> I have had little luck on the mailing list, so sorry
> for writing you
> directly (David may be on vacation).
> 
> I have two problems labeling contour lines in 0.98.3.
> 
> First, when I call clabel, it removes all contours
> that are not labeled
> (because the label doesn't fit on the section of
> contour, I presume).
> This seems like a bug to me (or a really odd feature).
> It doesn't do this
> when inline = False, but I don't think it should do it
> either when inline =
> True
> Easy example:
> 
> x,y =
> meshgrid( linspace(-10,10,50),
> linspace(-10,10,50) )
> z = log(x**2 + y**2)
> cobj = contour(x,y,z) # Note
> that there are 8 contours
> levels (11
> contour sections in all)
> cobj.clabel()
> <a list of 8 text.Text objects>
> draw() # Now only 5 contours
> are drawn; the ones in the
> middle are
> removed.
> 
> Second, when using the new manual labeling of contour
> labels (which is
> pretty neat!), how do I end this feature?
> The doc string says: right click, or potentially click
> both mouse buttons
> together (which already worries me).
> Neither works for me on win32, mpl 0.98.3, TkAgg
> backend, interactive mode.
> Does anybody have a solution?
> 
> Thanks, Mark
> 
> 
> 
> 
> 
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging
> Program.
> 
> 
> 
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

> Greg,
> 
> Thank you for your very clear and complete explanation.
> 
> I have committed your patch with only a few modifications:
> 
> 0) I fixed a bug with non-agg backends by setting im.is_grayscale.
> 
> 1) I changed the handling of the interpolation kwarg. The default is 
> still 'nearest'.
> 
> 2) I took Mike's suggestion to allocate acols and arows only if needed.
> 
> 3) I renamed pcolor_nonuniform to image_nonuniform, modified it to show 
> both types of interpolation, and added it to the set run by 
> backend_driver.py. This is the most minimal test; one could write a 
> whole test suite to exercise various inputs and options.
Thanks for this!
> 
> Among the questions that occur to me:
> 
> 1) Should the functionality be exposed as an Axes method, and from there 
> as a pyplot function? This could be done by integrating it into imshow, 
> either via the argument signature or via kwargs for X and Y, or it could 
> be a separate method.
it would be nice, at first I tried to find kwargs in imshow to do
exactly that (specify X and Y grid positions), and 
I did find NonUniformImage after quite a lot of documentation digging
and exploring the example directory...
> 
> 2) If X and Y are in fact uniform, should the displayed image be the 
> same as the present imshow? The big difference now is the boundary: 
> NonUniformImage extends boundary values indefinitely while Image uses 
> the background color for anything outside the image. I find the 
> NonUniformImage behavior disconcerting.
You are right, it should be the same. The extrapolation present in
NonUniformImage was disconcerting to me at first too,
but I now enjoy it: it is the same as what we do in our code for
user-provided parameter dependent data: linear interpolation between
points, and flat extrapolation outside the min/max: this avoid nasty
surprises (linear extrapolation) and sidestep
the problem of providing a "default" value outside min/max bounds.
But here it is not a strong argument, as background color/full
transparency is a good default value in the matplotlib case.
I think the best approach would be to give a special kwarg
extrapolation= None/flat (and eventually add other options if needed).
> 
> 3) Should caching be added to NonUniformImage? Every other class in the 
> image.py module uses it.
Hum, there I can not help: I do not know what caching is...Is it an
optimisation to avoid unneeded re-render, when
image size is kept unchanged? If it is, I guess optimisation can never
hurt ;-)
> 
> 4) Can we do anything with the internal function naming, at least, to 
> make the distinction between point data functions and cell data 
> functions? My thought was to use "image" for point data and "pcolor" 
> for cell data, but this may reflect my ignorance and particular usage 
> patterns from matlab days. What I would do is rename the _image.cpp 
> pcolor function to nonuniform_image, or something like that, to 
> distinguish it more clearly from pcolor2, which works with cell data.
Some rationalization would ne nice indeed. I do not have strong
prefences on this, image and pcolor
would work fine for me, as any other names used consistently. It could
be the opportunity to prepare
the addition of other point/cell data function (like delaunay
triangulation of arbitrary point data in matlab, 
or non-uniform cell data with color interpolation on the cell.
For the "phong" mapping (mapping data to color after interpolating the
data for each pixel ), I am affraid the work would be even greater, as I
do not see how to use
the imshow filters in this case....except maybe using a fake "greyscale"
image working on the data directly, and they mapping the
greyscale image to color image using the color mapper pixel per pixel...
Performance would suffer, though...
Regards,
Greg.

Hi,
 I think there is bug in get_xticklabels(). According to the doc it 
should return a list of Text instances, instead it returns a list of 
TextWithDash instances. This also makes the following impossible (which 
should work of course):
xtl = ax.get_xticklabels()
ax.set_xticklabels(xtl)
Manuel