matplotlib-devel Mailing List for matplotlib

There is some news about the STIX fonts. It looks like they will be releasing 
a beta sometime in October (translation: November-December). At this time, 
they have a draft copy of the license up on their website and are welcoming 
comments.

http://www.stixfonts.org/user_license.html

What I saw was encouraging, but maybe somebody else might see something that 
concerns bundling and distributing with MPL.

Darren

>>>>> "John" == John Hunter <jdh...@ac...> writes:

    John>   self.canvas.set_size_request(w,h)

I've thought about this a little more and realize we have to proceed
with some caution.  A minor nit is that set_size_request is the wrong
name, since this sets the minimum size in the GTK API, which is not
what we mean.  We want something like "resize".  Here is an
implementation for gtk which can be called on the canvas and resizes
the window to account for the other objects in the window

    def resize(self, w, h):
        """
        set the canvas size in pixels
        """

        # the window size
        winw, winh = self.parent.parent.get_size()
        tmp, tmp, myw, myh = self.get_allocation()

        padw = winw-myw
        padh = winh-myh

        neww = w+padw
        newh = h+padh
        self.parent.parent.resize(neww, newh)


The question is: how do we want to expose this?  If the user calls
fig.set_figsize_inches, should the Figure forward the call to
canvas.resize?  We have to be careful of a potential infinite
recursion, because the resize method will trigger a GUI resize event
which calls fig.set_figsize_inches in the various backends.

We could define an optional kwarg to fig.set_figsize_inches, eg

  def set_figsize_inches(self, w, h, forward=False):

where when forward is False the call is not forwarded on to the
canvas.  This would enable the canvas to set the figure size on mouse
resizes, the typical case, w/o triggering the infinite recursion.

My inclination is to support the user being able to use either the
fig.set_figsize_inches method or the canvas.resize method because
sometimes it's more natural to think in terms of inches and sometimes
pixels.

class Canvas:

  def resize(self, w, h):
     # resize the window/canvas this will automatically trigger a
     # GUI resize event that will cause the figure size to be updated
     # because the various backends already call set_figsize_inches on
     # resize events


class Figure:
   def set_figsize_inches(self, w, h, forward=False):
     # by default this will not forward events to canvas.resize
     # but when forward is True call self.canvas.resize

This prevents the infinite recursion on mouse resizes (the resize
event calls set_figsize_inches and the event is not propagated back to
canvas.resize).

The user who *wants* to resize the canvas, eg from the shell, calls

  fig.set_figsize_inches(w, h, forward=True)

which triggers canvas.resize(w,h) which triggers the GUI resize event
which in turn calls fig.set_figsize_inches(w, h, forward=False) and
the recursion is blocked.  It seems a bit strange that
fig.set_figsize_inches triggers a call to itself, but this is where my
screwy Friday afternoon logic has led me in thinking about how to
support resizes in the three ways people want to do it

  * with the mouse

  * with fig.set_figsize_inches(winch, hinch)

  * with canvas.resize(wpixe, hpixel)

On light testing, this appears to be working in GTK:

    Checking in lib/matplotlib/figure.py;
    /cvsroot/matplotlib/matplotlib/lib/matplotlib/figure.py,v  <--  figure.py
    new revision: 1.37; previous revision: 1.36
    done

    Checking in lib/matplotlib/backends/backend_gtk.py;
    /cvsroot/matplotlib/matplotlib/lib/matplotlib/backends/backend_gtk.py,v  <--  backend_gtk.py
    new revision: 1.112; previous revision: 1.111


Or is there a simpler solution that is escaping me?
JDH

Hello all,

I've fixed the quiver function so it works on non-square arrays. I
believe I've generated a patch against the 0.83.2 sources properly, but
this is the first time I've done this.

Regards,
John

--
John Byrnes (by...@bu...)
Graduate Student
Electrical Engineering
Boston University

The law will never make men free; it is men who have got to make the law free.
		-- Henry David Thoreau

On Thu, 2005-09-08 at 23:18 -0500, John Hunter wrote:
> Yes.  We need to abstract the set size request call across backends to
> make it work properly, eg GTK's win.set_size_request.  This should be
> a FigureCanvas method.  The base class should "pass" (ignore) and the
> derived GUI classes should implement the proper GUI code.  My
> intuition is that the args to this function should be width, height in
> pixels.  The fig.set_figsize_inches will compute w,h in pixels and
> call something like

If this API is being corrected I'd suggest adding a setting somewhere in
the api of the gui backends to allow setting an additional size and dpi
to be used when a user presses the save button on the toolbar (and give
this setting a default that fits onto both letter and A4 paper).  This
behaviour is probably preferable for the majority of users (who want to
save things at a size they can print) and could be easily overridden
where it is not.  Personally I would also find it useful to be able to
easily use gui tools to zoom and pan multiple plots and then to produce
outputs which are of a consistent size (although I'll probably produce
my own subclass of a backend to do this if others don't). 

Whilst I'd be willing to produce a patch to do this myself it seems
better in this case for someone more familiar with the each of the
backends to do so.

Nick

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> set_figsize_inches will change the printed output,
    Darren> although it does not seem to effect the screen size (is
    Darren> this a bug?).

Yes.  We need to abstract the set size request call across backends to
make it work properly, eg GTK's win.set_size_request.  This should be
a FigureCanvas method.  The base class should "pass" (ignore) and the
derived GUI classes should implement the proper GUI code.  My
intuition is that the args to this function should be width, height in
pixels.  The fig.set_figsize_inches will compute w,h in pixels and
call something like

  self.canvas.set_size_request(w,h)

where self is a Figure instance.

This has come up before in other contexts.  If you could file this on
the sf site, it'll help keep it from falling through the cracks.  If
you also can define the base class method in CVS and write the
docstring, that will help.  Once/if you have done this, reply to the
list to ask other GUI backend maintainers to implement the behavior
for their respective GUIs.

Thanks,
JDH

Thanks Darren!

I managed to wite a bit of wrapper code to handle this now.
The only bad thing to data is that I hardcode "A4".
Maybe this can be moved into backend_ps.

<snip>
def my_print(self, fname,orientation=None):
    w = self.figure.figwidth.get()
    h = self.figure.figheight.get()                        
    a4w = 8.25
    a4h = 11.25
    
    if orientation is None:
        # auto-oriented
        if w > h:
            orientation = 'landscape'
        else:
            orientation = 'portrait'
    ds = None
    if orientation == 'landscape':
        ds = min(a4h/w,a4w/h)
    else:
        ds = min(a4w/w,a4h/h)
    ow = ds * w
    oh = ds * h
    self.figure.set_figsize_inches((ow,oh))                   
    self.canvas.print_figure(fname,orientation=orientation)
 

On Thursday 08 September 2005 6:30 pm, Mal...@cs... wrote:
> "My users" want to see the ps output scaled to A4, which I also think is
> the correct behaviour. Usually you increase the size of the window on the
> screen to get a better view of things, but when you want to print the
> figure it should adjust to the papersize. Also, how do you know the figure
> is larger than the papersize?!

f = figure(figsize=(5,4))
# resize with mouse, and when you are ready to save:
f.set_figsize_inches(5,4)
savefig('t.ps')

set_figsize_inches will change the printed output, although it does not seem 
to effect the screen size (is this a bug?).

Darren