Menu
▾
▴
matplotlib-users
|
From: Darren D. <dd...@co...> - 2004-04-27 20:18:09
|
Hi All, interactive2.py, with GTK backend, is continually returning: 'Warning **: Couldnt load font "Tahoma Italic 8" falling back to "Sans Italic 8" I found this line in interactive2.py: self.style_err.set_property( "style", pango.STYLE_ITALIC ) and checked GTK/etc/pango/pango.aliases. There is no mention of Tahoma fonts in this file. Any suggestions? Darren |
|
From: John H. <jdh...@ac...> - 2004-04-28 02:35:00
|
>>>>> "Darren" == Darren Dale <dd...@co...> writes:
Darren> Hi All, interactive2.py, with GTK backend, is continually
Darren> returning: 'Warning **: Couldnt load font "Tahoma Italic
Darren> 8" falling back to "Sans Italic 8"
Basically you are experiencing a win32 GTK font bug.
If GTKAgg is a possibility for you, I encourage you to use it. You
can do an end-run around GTK's font handling with GTKAgg.
Unfortunately, we do not have the resources to manage every backend
across every platform. gtk, tk, wx, gd, ps, agg cross win32, osx,
linux, solaris equals 24 possible environments; multiply this by
different versions of python/gd/tk/gtk/wx and the problem gets worse.
Thus I encourage you and everyone to switch to TkAgg, GTKAgg or WXAgg
where possible. Not only will you get the highest quality and
probably fastest rendering, you'll get the latest features and the
best support. The other platforms are still supported, but not as
aggressively....
Darren> I found this line in interactive2.py:
Darren> self.style_err.set_property( "style", pango.STYLE_ITALIC )
Darren> and checked GTK/etc/pango/pango.aliases. There is no
Darren> mention of Tahoma fonts in this file.
Darren> Any suggestions?
The fact that it is not mentioned in your pango.aliases file is
essentially the problem. When GTK tries to load a font it can't find
it goes to this file to look for an alias. Try mapping it to a known
good font on your system, as described in
http://matplotlib.sf.net/faq.html#WINFONTS.
The fact that you are using interactive2.py means you need an
interactive shell. If you want interactivity from the python shell on
win32, I recommend TkAgg if it is a possibility for you. Noting else
comes close for interactive use from the standard python shell,
particularly if you set
tk.window_focus : True
in your .matplotlibrc. Let me know what you are trying to do, and I
can give more targeted and appropriate advice....
JDH
|
|
From: Darren D. <dd...@co...> - 2004-04-28 03:39:57
|
>Unfortunately, we do not have the resources to manage every backend >across every platform. gtk, tk, wx, gd, ps, agg cross win32, osx, >linux, solaris equals 24 possible environments; multiply this by >different versions of python/gd/tk/gtk/wx and the problem gets worse. I was wondering why matplotlib strives to support so many backends... >Let me know what you are trying to do, and I >can give more targeted and appropriate advice.... I wrote a gui app in matlab that takes the fourier transform of a semi-infinite crystal. The point is to simulate X-ray diffraction (I work at the Cornell Synchrotron). The program is pretty good, from a science standpoint. I am considering publishing the work, but I wanted to make it open source. What's the point of doing work funded by the NSF if the public can't access it? So I am investigating rewriting the code using pygtk. I wanted something free and cross platform, and I need the vectorized matrix operations. Aside from that specific project, I am just trying to get the interactive feel of matlab. I need to take some time to look carefully through all the documentation here, it seems all of my questions have had answers published on the web. Darren |
|
From: John H. <jdh...@ac...> - 2004-04-28 12:18:23
|
>>>>> "Darren" == Darren Dale <dd...@co...> writes:
Darren> I was wondering why matplotlib strives to support so many
Darren> backends...
Accretion. In the beginning there was GTK, but being a LaTeX user, I
needed a postscript output. Also, there was a lot of interest in a
pure image backend that could make JPG/PNG/etc w/o having a window
popup. gdmodule is a python module wrapping the very nice gd library
so I wrote the gd backend to provide pure image generation (could have
just as easily done PIL at this point). Around the same time, David
Moore, also needing a pure image backend (gd hadn't been ported to
win32 yet), stealthily developed paint, a libart backend. Meanwhile,
Jeremy needed wx at work, and developed the wx backend.
At this time the proliferation of backends was beginning to become a
maintenance hassle, and Perry Greenfield had a bright idea: another
backend! But not just any old backend, the mother of all backends,
that could be used not only for pure image generation but used to
render directly into the GUI canvases. GTK and WX use native GUI
drawing code to render the figure, so we not only need to support not
only all the widget-set related stuff, but all the drawing stuff as
well.
The new idea is to focus development on one high quality image backend
and use this in as many areas as possible. We looked hard at libart
and gd, but both had bugs that could not be fixed. Having worked with
the developers of chaco, Perry suggested antigrain which is a very
high quality 2D image library that I've just begun to scratch the
surface of. So Agg was born and the GUI wrappers GTKAgg, TkAgg and
WXAgg quickly followed suit. These 3 are the GUI backends of choice
for performance, feature set, and quality.
I still support the other backends because people still use them but
spend less energy porting all the new features to them. If someone
says "I need alpha blending on WX", I usually say "Can you use
WXAgg?", and so on. postscript is still very actively maintained
because it is in a different category and widely used for publication
and TeX.
Darren> I wrote a gui app in matlab that takes the fourier
Darren> transform of a semi-infinite crystal. The point is to
Darren> simulate X-ray diffraction (I work at the Cornell
Darren> Synchrotron). The program is pretty good, from a science
Darren> standpoint. I am considering publishing the work, but I
Darren> wanted to make it open source. What's the point of doing
Darren> work funded by the NSF if the public can't access it? So I
Darren> am investigating rewriting the code using pygtk. I wanted
Darren> something free and cross platform, and I need the
Darren> vectorized matrix operations.
Darren> Aside from that specific project, I am just trying to get
Darren> the interactive feel of matlab. I need to take some time
Darren> to look carefully through all the documentation here, it
Darren> seems all of my questions have had answers published on
Darren> the web.
Sounds very similar to my situation. I develop a pretty complex
application for EEG and medical image data analysis. I originally
wrote it in matlab but became dissatisfied with the ability of matlab
to easily manipulate complex data structures, work with databases,
fill out CGI forms, and the like. You can do all of this in matlab
using the matlab JVM stuff (and I did), but it's a pain and it's slow.
I started over in python and decided on pygtk. I couldn't find a 2D
plotting library I was satisfied with so wrote matplotlib around
pygtk. If you need any additional encouragement, the quality of the
application and the ease of extending it are dramatically better now.
I develop on linux and most of the users are on win32, and have been
very happy with GTK on win32. The only bug I've seen on OS X is that
progress bars don't seem to work. Now I see why you were looking at
interactive2.py -- you want to embed a python shell in your
application. I think pygtk + matplotlib + GTKAgg
+ a modified interactive2.py is a good combination for you. Some
features of interactive2.py are underdeveloped, such as cutting and
pasting code blocks from an editor into the interpreter.
You may also want to look into VTK if you need 3D plotting, which has
nice integration with pygtk. I use this a lot in my application. I
find it amazing that you can embed an OpenGL window into a GTK widget
set wrapped by pygtk running in a python interpreter on a Microsoft
Windows OS and still get hardware acceleration!
JDH
|
|
From: Darren D. <dd...@co...> - 2004-04-28 18:10:43
|
>John writes: >I still support the other backends because people still use them but >spend less energy porting all the new features to them. If someone >says "I need alpha blending on WX", I usually say "Can you use >WXAgg?", and so on. postscript is still very actively maintained >because it is in a different category and widely used for publication >and TeX. All things to all people...PS support is a big selling point. >Now I see why you were looking at >interactive2.py -- you want to embed a python shell in your >application. No, not really. I was just reading through the documentation, found interactive2, and tried it out. I like the command recall better than Idle. It would be interesting to have a matplotlib user interface, akin to the one from Matlab. If for no other reason than to make converts like myself feel familiar. For example, I still dont know how to change the working directory from inside the shell, or how to access a list of attributes for an object. >You may also want to look into VTK if you need 3D plotting, which has >nice integration with pygtk. I use this a lot in my application. I >find it amazing that you can embed an OpenGL window into a GTK widget >set wrapped by pygtk running in a python interpreter on a Microsoft >Windows OS and still get hardware acceleration! And a partridge in a pear tree. (that IS impressive!) |
|
From: Perry G. <pe...@st...> - 2004-04-29 16:02:10
|
John Hunter wrote: > > At this time the proliferation of backends was beginning to become a > maintenance hassle, and Perry Greenfield had a bright idea: another > backend! But not just any old backend, the mother of all backends, > that could be used not only for pure image generation but used to > render directly into the GUI canvases. GTK and WX use native GUI > drawing code to render the figure, so we not only need to support not > only all the widget-set related stuff, but all the drawing stuff as > well. > Well, it wasn't really my idea. Eric Jones adopted this approach for Chaco and it seemed like a good way of adding lots of functionality and removing gui plotting depenencies. So I basically passed the idea along. > Perry |
|
From: <na...@te...> - 2004-04-28 14:18:58
|
Greetings. I'm new to matplotlib and to this list. I know it is a good thing to wait a little before posting, but I need some work done quickly, so I had to post a message as soon as I could. I also couldn't find in the list archives a solution to my problems, so I had to ask. Bear with me, please. I must say that I'm very impressed with the overall quality of the figures generated with matplotlib, and the possibility to add TeX expression as labels is a fantastic feature that I have never even thought about (but now I can't live without). I had some problems though, which I report below. Some of them I could solve (by hacking a little), others I didn't. * I use TK backend, but also tried wx. They didn't work well: in the TK backend, in interactive mode, the fi- gure take a lot of time to be rendered, and sometimes it does not. The same with wx. I looked into the code of 'show' method in backend_tkagg.py, and did some changes. The Tk.mainloop() was commented, I uncommented it. I also changed the interactive mode to False. By doing this, I lost the interactive environment, but at least the figure shows quickly when I use the 'show' command. I don't know if this has been an issue for everyone, or if it is a problem with compatibility with what I have installed here (it is Python 2.3.2, Windows ME, Tk 8.4, if I'm right), but if there is a better solution to it, I'd like to hear. * Also in the backend_tkagg.py there was two lines with wrong identation. Line 181 (method show of FigureManagerTkAgg class and line 416 (method update of NavigationToolbar class) were not idented correctly. I tried identing them and everything seems to be working fine. I might have changed something that I shouldn't, though. * Well, here is my real problem. I need to generate EPS files of my pictures for use with TeX (MiKTeX). I'm having a lot of trouble with it (this includes problems with the GS conversion tool, but that is beyond the scope of this list). Basically, using TkAgg or the savefig method, I can generate a PS file with the figure. But the problem is that the figure does not show well - it is bigger than the generated page, so a very significant part of the figure is cut out. Is there anyway to resize the picture or tell matplotlib to fit the picture within specified dimensions (like some and some centimeters or inches height and width)? Resizing the drawing window _did_ solve the problem, but then I can't generate the figures by scripting - I would have to manually resize everyone of them. * The EPS problem I might solve with a little hack, and generate an EPS file directly from my scripts. If this turns out to work well, I will contribute the code, of course, if the developers would want it. * Another very important thing to me is to generate the plot of discrete functions (like the Matlab 'mesh' command). Is there anyway to do that with matplotlib? If not, can I suggest it as a feature request? :) That's all for now. Thanks for the great software. --- José Alexandre Nalon na...@te... |
|
From: Todd M. <jm...@st...> - 2004-04-28 19:21:01
|
On Wed, 2004-04-28 at 10:14, José Alexandre Nalon wrote: > Greetings. > > I'm new to matplotlib and to this list. I know it is a > good thing to wait a little before posting, but I need > some work done quickly, so I had to post a message as > soon as I could. I also couldn't find in the list > archives a solution to my problems, so I had to ask. > Bear with me, please. > > I must say that I'm very impressed with the overall > quality of the figures generated with matplotlib, and > the possibility to add TeX expression as labels is a > fantastic feature that I have never even thought about > (but now I can't live without). > > I had some problems though, which I report below. Some > of them I could solve (by hacking a little), others I > didn't. > > * I use TK backend, but also tried wx. They didn't work > well: in the TK backend, in interactive mode, the fi- > gure take a lot of time to be rendered, and sometimes > it does not. The same with wx. I looked into the > code of 'show' method in backend_tkagg.py, and did > some changes. The Tk.mainloop() was commented, I > uncommented it. I also changed the interactive mode > to False. By doing this, I lost the interactive > environment, but at least the figure shows quickly > when I use the 'show' command. I don't know if this > has been an issue for everyone, or if it is a problem > with compatibility with what I have installed here > (it is Python 2.3.2, Windows ME, Tk 8.4, if I'm right), > but if there is a better solution to it, I'd like to > hear. I can't look at this today but I'll try to look tomorrow. > * Also in the backend_tkagg.py there was two lines with > wrong identation. Line 181 (method show of > FigureManagerTkAgg class and line 416 (method update > of NavigationToolbar class) were not idented correctly. > I tried identing them and everything seems to be working > fine. I might have changed something that I shouldn't, > though. I got these. Thanks. > * Well, here is my real problem. I need to generate EPS > files of my pictures for use with TeX (MiKTeX). I'm > having a lot of trouble with it (this includes problems > with the GS conversion tool, but that is beyond the > scope of this list). Basically, using TkAgg or the > savefig method, I can generate a PS file with the > figure. But the problem is that the figure does not > show well - it is bigger than the generated page, so a > very significant part of the figure is cut out. Is > there anyway to resize the picture or tell matplotlib > to fit the picture within specified dimensions (like > some and some centimeters or inches height and width)? > Resizing the drawing window _did_ solve the problem, > but then I can't generate the figures by scripting - > I would have to manually resize everyone of them. I'm not sure it's made clear anywhere, but you can generate EPS by using the extension ".ep" or ".eps". Regards, Todd -- Todd Miller <jm...@st...> |
|
From: John H. <jdh...@ac...> - 2004-04-28 19:41:51
|
>>>>> "Todd" == Todd Miller <jm...@st...> writes:
>> * Well, here is my real problem. I need to generate EPS files
>> of my pictures for use with TeX (MiKTeX). I'm having a lot of
>> trouble with it (this includes problems with the GS conversion
>> tool, but that is beyond the scope of this list). Basically,
>> using TkAgg or the savefig method, I can generate a PS file
>> with the figure. But the problem is that the figure does not
>> show well - it is bigger than the generated page, so a very
>> significant part of the figure is cut out. Is there anyway to
>> resize the picture or tell matplotlib to fit the picture within
>> specified dimensions (like some and some centimeters or inches
>> height and width)? Resizing the drawing window _did_ solve the
>> problem, but then I can't generate the figures by scripting - I
>> would have to manually resize everyone of them.
Todd> I'm not sure it's made clear anywhere, but you can generate
Todd> EPS by using the extension ".ep" or ".eps".
On earlier versions of matplotlib there was a figure sizing issue when
you saved from tkagg -> postscript or eps, but I thought this was
cleared up. Eg when I run examples/simple_plot.py with TkAgg backend
and then save test.eps, I don't see any figure size issues.
Are you using the latest version 0.53.1? If so can you post a test
script that reproduces the eps figure size problem you describe. In
the latter case I can probably fix it pronto.
JDH
|
|
From: <na...@te...> - 2004-04-28 20:06:28
|
Hello, Thanks for all your help! > On earlier versions of matplotlib there was a figure sizing issue when > you saved from tkagg -> postscript or eps, (...) > Are you using the latest version 0.53.1? Yes, it was the version I downloaded and tried. I tried the simple_plot.py running, and I got the exact picture shown in the homepage (the quality of the image still amazes me). The window is shown without any problems, but with the figure saved in a file, it results in a figure bigger than the page, so the result is clipped. I have the EPS generated, I can send them directly to you or to the list, if you want to look at them. --- José Alexandre Nalon na...@te... |
|
From: John H. <jdh...@ac...> - 2004-04-28 20:39:11
|
>>>>> "Jos=E9" =3D=3D Jos=E9 Alexandre Nalon <na...@te...> writes:
Jos=E9> Yes, it was the version I downloaded and tried. I tried the
Jos=E9> simple_plot.py running, and I got the exact picture shown in
Jos=E9> the homepage (the quality of the image still amazes me). The
Jos=E9> window is shown without any problems, but with the figure
Jos=E9> saved in a file, it results in a figure bigger than the
Jos=E9> page, so the result is clipped.
Jos=E9> I have the EPS generated, I can send them directly to you or
Jos=E9> to the list, if you want to look at them.
OK, you're right. I hadn't noticed it before because my postscript
viewer was showing the who figure. When I measure it the postscript
figure extends beyond the 8 inches that it should if you are using the
standard figsize=3D8,6.
This is related to the centering 640 thing Todd noticed earlier. I'll
work on a fix.
JDH
|
|
From: John H. <jdh...@ac...> - 2004-04-28 21:09:24
|
>>>>> "Jos=E9" =3D=3D Jos=E9 Alexandre Nalon <na...@te...> writes:
Jos=E9> Yes, it was the version I downloaded and tried. I tried the
Jos=E9> simple_plot.py running, and I got the exact picture shown in
Jos=E9> the homepage (the quality of the image still amazes me). The
Jos=E9> window is shown without any problems, but with the figure
Jos=E9> saved in a file, it results in a figure bigger than the
Jos=E9> page, so the result is clipped.
OK, the fix is in. For the record there were three problems that
needed fixing.
1) backend_tkagg, gtkagg and wxagg were doing way to much work on a
call to print_figure. All that is needed is to forward the call
onto agg, which now handles ps detection itself.
2) When creating figures with the PS backend (not switching backends
as in tkagg->ps) the matlab interface needed to detect this
situation and override any default DPI that is set since PS is
always 72. When the figures used to be coupled to the backend,
this happened at the backend level. Apparently something was
lost in translation.
3) Any time the figure dpi is set the new Figure.resize method needs
to be called so it can update it's bounding box - not too elegant
but works for now. This call forwards the resize call down to
it's axes, so the axes resize commands no longer need to be made.
Fortunately, all the fixes were a the python level, so you should just
be able to unzip this file in your site-packages dir and be good to go
http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib.zip
CVS is also updated.
Let me know how it goes...
JDH
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X