matlab_helpers and screen dpi/figsize refactored

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

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 business
trip (back Friday, won't have CVS access before then, although I will take
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 :wink:

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

Hello,

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 <zufus@...12...> 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

···

On Tue, Nov 18, 2003 at 10:10:33AM -0000, Jeremy O'Donoghue wrote:
--
http://seehuhn.de/

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 <zufus@...12...> 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)

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