From: John H. <jdh...@ac...> - 2003-11-17 20:40:36
|
In the process of rationalizing the way figure size and dpi is handled between the various backends, I had to make a number of changes to the matplotlib backend. This will pave the way for an rc file in which the user can set the dpi, figsize, font, etc.. properties for each backend. But it required some changes to the Gcf and FigureManager setup. It actually simplifies writing a new backend, but will require some relatively painless changes to wx (GD, GTK, PS, and Template are already updated). In a nutshell, the proliferation of defaultDPI and defaultFigSize throughout several parts of the code and among the various backends is now gone. The only place where the defaults are set is in matlab.py in the figure and savefig command. This now makes it possible to control the figsize and dpi from the matlab interface (which before could only be done with the OO API. An unfortunate side effect is that the default appearance of figures may now be different since I have changed the defaults (different backends used to set their own defaults, so there was no standard). Now I use a default fig size of 8,6 (from matlab) and dpi of 72. Jeremy - what this means for you is some more changes. Sorry to present you with an ever changing target. I've been working pretty hard of late clearing up a lot of lingering issues. Hopefully, we'll stabilize soon.... - Changes to the matlab helpers API * _matlab_helpers.GcfBase is renamed by Gcf. Backends no longer need to derive from this class. Instead, they provide a factory function new_figure_manager(num, figsize, dpi). The destroy method of the GcfDerived from the backends is moved to the derived FigureManager. You'll want to connect the window destroy to the GCf.destroy method, which will forward the call to the FigureManager. * FigureManagerBase moved to backend_bases -- seemed like a better place for it. * Gcf.get_all_figwins renamed to Gcf.get_all_fig_managers * No default dpi or figsize arguments in the backends. * You'll need to change the backends.__init__ for wx to reflect the new API. It was rather easy to port the existing backends and I don't think you'll have much trouble with WX. Note there is a SCREENSIZE parameter in the backend_gtk and backend_gd which is a constant that determines how many pixels there are per inch on the screen. I use this to convert from dpi (in which I assume a dpi of 72 == 1 inch) to screen units. In my tests where I created figures with a dpi of 72, this resulted in accurate measures of figure sizes (holding a ruler up to the screen). Not sure this is perfect yet, but it seems to be a step in the right direction, and the relative sizes of the fonts to the figure appear to be better now -- previously too large in some backends, eg, GD. There is still a discrepancy between relative font sizes between the backends (eg, GTK versus PS) which may have to do with the font dpi issue (75 versus 100 dpi fonts under X11) but am not sure. In any case, I think the CVS changes are step in the right direction Let me know if this is clear .... JDH |
From: Jeremy O'D. <je...@o-...> - 2003-11-18 10:11:03
|
John Hunter said: > [snip] > > Jeremy - what this means for you is some more changes. Sorry to > present you with an ever changing target. I've been working pretty > hard of late clearing up a lot of lingering issues. Hopefully, we'll > stabilize soon.... I'm not concerned by moving targets - the changes to date have been sensible both in improving functionality and rationalising the backend design. Will try to commit appropriate changes today before I go off on a busines= s trip (back Friday, won't have CVS access before then, although I will tak= e a snapshot with me before I leave) > Not sure this is perfect yet, but it seems to be a step in the right > direction, and the relative sizes of the fonts to the figure appear to > be better now -- previously too large in some backends, eg, GD. There > is still a discrepancy between relative font sizes between the > backends (eg, GTK versus PS) which may have to do with the font dpi > issue (75 versus 100 dpi fonts under X11) but am not sure. In any > case, I think the CVS changes are step in the right direction I may need to think about font size scaling separately - currently I just define the font point size, which probably is not what I should be doing. I may not have time to do this today, but will try to think about it in airport lounges ;-) By the way, I noticed on the users list that people are asking for Debian packages. I'm quite happy to do one, but would rather wait until things have calmed down - I'll target the 4.0 release for a .deb on the Sourceforge site. We'll have to think about how the Debian package dependencies are worked out. My inclination is that we should require appropriate support for at least one backend, and suggest the others. Something like: Required packages: python2.3-numeric, python2.3-numeric-ext, fonttools python2.3-gtk | libgd2-dev | libwxpython Recommended packages: python2.3-gtk, libgd2-dev, libwxpython This would allow a Debian user to install matplotlib for only one backend (e.g. gd2 only for a webserver without X), but recommend packages to support other backends. I can probably put simple packages for TTFQuery and gdmodule , which could be 'suggested'. Debian practice would normally provide separate packages matplotlib-doc and matplotlib-examples, so I'll try to arrange that. However, I don't really want to get into doing this until we are ready to make the next release. Debian packaging isn't especially hard, but it is rather tedious... Regards Jeremy |
From: Jochen V. <vo...@se...> - 2003-11-18 11:44:30
|
Hello, On Tue, Nov 18, 2003 at 10:10:33AM -0000, Jeremy O'Donoghue wrote: > By the way, I noticed on the users list that people are asking for Debian > packages. I'm quite happy to do one, but would rather wait until things > have calmed down - I'll target the 4.0 release for a .deb on the > Sourceforge site. > > We'll have to think about how the Debian package dependencies are worked > out. My inclination is that we should require appropriate support for at > least one backend, and suggest the others. Something like: > > Required packages: python2.3-numeric, python2.3-numeric-ext, fonttools > python2.3-gtk | libgd2-dev | libwxpython > Recommended packages: python2.3-gtk, libgd2-dev, libwxpython > > This would allow a Debian user to install matplotlib for only one backend > (e.g. gd2 only for a webserver without X), but recommend packages to > support other backends. I think that Marco Presi <zu...@de...> claims to be working on this. Maybe you can coordinate with him. See http://bugs.debian.org/206691 for details. > I can probably put simple packages for TTFQuery > and gdmodule , which could be 'suggested'. At http://seehuhn.de/debian/ you can find a python-ttfquery package, which I produced for my own personal use. If anything else in the Debian archive would use it, I probably could upload it to the archive. Best regards, Jochen -- http://seehuhn.de/ |
From: John H. <jdh...@ac...> - 2003-11-18 17:29:35
|
>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes: Jeremy> I'm not concerned by moving targets - the changes to date Jeremy> have been sensible both in improving functionality and Jeremy> rationalising the backend design. Good to hear -- I think the code is becoming much cleaner. Even I understand the way _matlab_helpers and Gcf works now! Jeremy> I may need to think about font size scaling separately - Jeremy> currently I just define the font point size, which Jeremy> probably is not what I should be doing. I may not have Jeremy> time to do this today, but will try to think about it in Jeremy> airport lounges ;-) You probably will. Font size needs to scale with DPI, otherwise when you go to a high res output the fonts look really tiny. I use something like scale = self.dpi.get()/72.0 self._font.set_size(scale*self._fontsize) which as I indicated above is not perfect but gets close. Jeremy> By the way, I noticed on the users list that people are Jeremy> asking for Debian packages. I'm quite happy to do one, but Jeremy> would rather wait until things have calmed down - I'll Jeremy> target the 4.0 release for a .deb on the Sourceforge site. I hope you mean 0.4 <wink>. By 4.0 we'll have already acquired The MathWorks. Jeremy> We'll have to think about how the Debian package Jeremy> dependencies are worked out. My inclination is that we Jeremy> should require appropriate support for at least one Jeremy> backend, and suggest the others. Something like: Required packages: python2.3-numeric, python2.3-numeric-ext, fonttools python2.3-gtk | libgd2-dev | libwxpython Recommended packages: python2.3-gtk, libgd2-dev, libwxpython Yes, I've been wondering about this but don't know enough about debian to know how optional packages are handled. Note that neither gtk, gd, or wx are required if all you want is PS (or Template!) output. For the record, I'll list the dependencies by backend below. Since I am not a debian whiz, I'll just list the actual dependencies and leave it to the experts to sort out the debian packages that provide them matplotlib Numeric PS backend (nothing extra) GTK backend GTK2 pygtk-1.99.16 or later GD backend: gd-2.0.15 gdmodule-0.42 fonttools-2.0b1 TTFQuery-0.2.6 WX backend: wxPython-2.4.2.4 Jeremy> Debian practice would normally provide separate packages Jeremy> matplotlib-doc and matplotlib-examples, so I'll try to Jeremy> arrange that. Jeremy> However, I don't really want to get into doing this until Jeremy> we are ready to make the next release. Debian packaging Jeremy> isn't especially hard, but it is rather tedious... OK, but since we're shooting for release date of around 3 weeks from now, it might be good to lay the groundwork, figure out how to handle the optional dependencies, see if we can get gdmodule packed, etc.... Thanks! John Hunter |
From: Charles R. T. <cha...@in...> - 2003-11-18 13:57:36
|
I was unable to contact Marco awhile (months) back. I had been foolish enough to volunteer to package, and he said he'd wait a couple of days and then do it. After a week or so I wrote to say I wasn't going to get the time, but my mails kept bouncing. JV:I think that Marco Presi <zu...@de...> claims to be JV:working on this. Maybe you can coordinate with him. JV:See JV: JV: http://bugs.debian.org/206691 -- Charles R. Twardy www.csse.monash.edu.au/~ctwardy Monash University sarbayes.org Computer Sci. & Software Eng. +61(3) 9905 5823 (w) 5146 (fax) |
From: Charles R. T. <cha...@in...> - 2003-11-19 08:55:09
|
On Tue, 18 Nov 2003, John Hunter wrote: JH: JH:Good to hear -- I think the code is becoming much cleaner. Even I JH:understand the way _matlab_helpers and Gcf works now! I might need a hand there. I had a script that used to use the ShowOn method directly, but that isn't working now, and I'm not quite sure what's the right thing to do. I'm trying to maintain a figure on my own, without having a call to show(). I used to be able to set ShowOn to 1, queue draw events as needed, and update the display every few seconds on my own with calls to gtk_mainiteration(). -C -- Charles R. Twardy www.csse.monash.edu.au/~ctwardy Monash University sarbayes.org Computer Sci. & Software Eng. +61(3) 9905 5823 (w) 5146 (fax) |
From: John H. <jdh...@ac...> - 2003-11-19 13:21:15
|
>>>>> "Charles" == Charles R Twardy <cha...@in...> writes: Charles> On Tue, 18 Nov 2003, John Hunter wrote: JH: JH:Good to Charles> hear -- I think the code is becoming much cleaner. Even Charles> I JH:understand the way _matlab_helpers and Gcf works Charles> now! Charles> I might need a hand there. I had a script that used to Charles> use the ShowOn method directly, but that isn't working Charles> now, and I'm not quite sure what's the right thing to do. Is this with CVS or version 0.32? I just tested the CVS version in interactive mode (interactive2.py) and it worked; I am not sure right now what trouble you are having. I'd like to clear up the bug so let me know anything you can (version info) and if possible an example script. Charles> I'm trying to maintain a figure on my own, without having Charles> a call to show(). I used to be able to set ShowOn to 1, Charles> queue draw events as needed, and update the display every Charles> few seconds on my own with calls to gtk_mainiteration(). As a workaround, is it possible to use the backend_gtk Figure class directly from matplotlib.backends_gtk import FigureGTK fig = Figure(figsize=(5,4), dpi=100) ax = Subplot(fig, 111) # <<<- new API in CVS Then you can do away with 'show' and 'ShowOn' altogether and use the GTK tools directly. See the embedding_in_gtk.py and embedding_in_gtk2.py (new in CVS) if you want to use the toolbar. BTW, excepting the wx backend which Jeremy is still porting to the last frontend change, CVS is now in very good shape with no known bugs, and does a much better job of precise layout (ticklabel positioning, tick sizes, legend placement, etc, by virtue of the new transform system). The untrained eye may not notice a difference. So if you are not using CVS you may want to consider it (cvs mirror may need some time to update). I also would like as much testing as possible before 0.40. For users, there are few significant changes - figure sizes and relative text sizes will appear different (as discussed before) but this is stabilizing. Eg, I don't anticipate significant changes in future releases - If you use the OO API directly, init Axes, Subplot with fig instances. If you create your own Line2D, or Rectangle, or other artists, you need to init them with a dpi instance, bbox, and x and y transformations. See the header in the transforms module. (for a complete list of API changes, see axes.py). I'll spell this out in greater detail in the actual release. JDH |
From: Jeremy O'D. <je...@o-...> - 2003-11-21 17:41:52
|
I've finally gotten around to committing the changes to backend_wx for these API changes. Time has been tight this week, and I haven't been able to thoroughly regression test, but the code worked for the cases I tried. I will be doing a more thorough set of tests over the weekend, but in the meantime, I didn't want backend_wx to stay out of sync for any longer. Regards Jeremy |