matplotlib-devel Mailing List for matplotlib (Page 3)

Charlie Moad wrote:
> I'll paste the block of interest to save
> you a little digging.
> 
>            bbox = self.replot
>            w, h = int(bbox.width()), int(bbox.height())
>            l, t = bbox.ll().x().get(), bbox.ur().y().get()
>            reg = self.copy_from_bbox(bbox)

So this is one copy.
>            stringBuffer = reg.to_string()

Is this another? or does to_string not copy?

>            qImage = qt.QImage(stringBuffer, w, h, 32, None, 0,
> qt.QImage.IgnoreEndian)

Here we have difference from wx -- AFAICT, a wx.Image doesn't do rgba32, 
it does RGB24, with a separate 8bit alpha channel. if to_string copies 
anyway, then that wouldn't make much difference.

But do we really need alpha here anyway?

>            self.pixmap.convertFromImage(qImage, qt.QPixmap.Color)
>            p.drawPixmap(qt.QPoint(l, self.renderer.height-t), self.pixmap)

And this looks like wx.

I wish I had more time to work on this, but I'm in a crunch that I'll be 
in for while....

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                      		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Darren Dale wrote:
> I think all the high rollers are at SciPy 2006.

Oh right. This is the third year in a row that I have ALMOST gone 
myself. Maybe next year.

But what's the deal? Aren't they all hooked up to wifi and checking 
email constantly?

-Chris





-- 
Christopher Barker, Ph.D.
Oceanographer
                                      		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

On 8/17/06, Christopher Barker <Chr...@no...> wrote:
> Hi all,
>
> I seem to be talking to myself here, but if someone (including myself)
> wants to pick this up in the future, it'll be good to have it in the
> archives.
>
> Christopher Barker wrote:
> >> There is also the
> >> wx.Image.SetDataBuffer method, which will have the wxImage use the
> >> buffer passed in without making a copy, but if the buffer doesn't
> >> live as long as the image does it will likely cause a crash.
> >
> > This would probably be the easiest way to get top performance at the
> > moment. If we can make the Agg data a buffer, and somehow do the
> > reference counting right so it doesn't get deleted while the wxImage is
> > still around (that may not be hard -- the wxImage has to be converted to
> > a wxBitmap to be drawn anyway)
>
> I've been suing this for another use, and Robin just added an improved
> version of new wx.Image factory function I wrote for just this purpose:
>
> def ImageFromBuffer(width, height, dataBuffer, alphaBuffer=None):
>      """
>      Creates a `wx.Image` from the data in dataBuffer.  The dataBuffer
>      parameter must be a Python object that implements the buffer
>      interface, such as a string, array, etc.  The dataBuffer object is
>      expected to contain a series of RGB bytes and be width*height*3
>      bytes long.  A buffer object can optionally be supplied for the
>      image's alpha channel data, and it is expected to be width*height
>      bytes long.
>
>      A reference to the data and alpha buffer objects are kept with the
>      wx.Image, so that they won't get deleted until after the wx.Image
>      is deleted.  However please be aware that it is not guaranteed that
>      an object won't move its memory buffer to a new location when it
>      needs to resize its contents.  If that happens then the wx.Image
>      will end up referring to an invalid memory location and could cause
>      the application to crash.  Therefore care should be taken to not
>      manipulate the objects used for the data and alpha buffers in a
>      way that would cause them to change size.
>      """
>      image = wx.EmptyImage(width, height)
>      image.SetDataBuffer(dataBuffer)
>      if alphaBuffer is not None:
>          image.SetAlphaBuffer(alphaBuffer)
>      image._buffer = dataBuffer
>      image._alpha = alphaBuffer
>      return image
>
> Does the aggDrawer already implement a Python buffer object? If so,
> using this would be easy. If not, then it probably should, unless we go
> straight to the numpy array protocol.

I haven't had time to thoroughly absorb all your post.  From skimming
it looks like we could do a similar approach as the qtagg blitting.
If you look at the else clause in the FigureCanvasQTAgg.paintEvent
method, you'll see we added a to_string method to the BufferRegion
object.  Using this string buffer we create a QImage and blit it.  It
includes the alpha channel.  I'll paste the block of interest to save
you a little digging.

            bbox = self.replot
            w, h = int(bbox.width()), int(bbox.height())
            l, t = bbox.ll().x().get(), bbox.ur().y().get()
            reg = self.copy_from_bbox(bbox)
            stringBuffer = reg.to_string()
            qImage = qt.QImage(stringBuffer, w, h, 32, None, 0,
qt.QImage.IgnoreEndian)
            self.pixmap.convertFromImage(qImage, qt.QPixmap.Color)
            p.drawPixmap(qt.QPoint(l, self.renderer.height-t), self.pixmap)

- Charlie

On Thursday 17 August 2006 7:19 pm, Christopher Barker wrote:
> I seem to be talking to myself here

I think all the high rollers are at SciPy 2006.

Hi all,

I seem to be talking to myself here, but if someone (including myself) 
wants to pick this up in the future, it'll be good to have it in the 
archives.

Christopher Barker wrote:
>> There is also the
>> wx.Image.SetDataBuffer method, which will have the wxImage use the
>> buffer passed in without making a copy, but if the buffer doesn't
>> live as long as the image does it will likely cause a crash.
> 
> This would probably be the easiest way to get top performance at the 
> moment. If we can make the Agg data a buffer, and somehow do the 
> reference counting right so it doesn't get deleted while the wxImage is 
> still around (that may not be hard -- the wxImage has to be converted to 
> a wxBitmap to be drawn anyway)

I've been suing this for another use, and Robin just added an improved 
version of new wx.Image factory function I wrote for just this purpose:

def ImageFromBuffer(width, height, dataBuffer, alphaBuffer=None):
     """
     Creates a `wx.Image` from the data in dataBuffer.  The dataBuffer
     parameter must be a Python object that implements the buffer
     interface, such as a string, array, etc.  The dataBuffer object is
     expected to contain a series of RGB bytes and be width*height*3
     bytes long.  A buffer object can optionally be supplied for the
     image's alpha channel data, and it is expected to be width*height
     bytes long.

     A reference to the data and alpha buffer objects are kept with the
     wx.Image, so that they won't get deleted until after the wx.Image
     is deleted.  However please be aware that it is not guaranteed that
     an object won't move its memory buffer to a new location when it
     needs to resize its contents.  If that happens then the wx.Image
     will end up referring to an invalid memory location and could cause
     the application to crash.  Therefore care should be taken to not
     manipulate the objects used for the data and alpha buffers in a
     way that would cause them to change size.
     """
     image = wx.EmptyImage(width, height)
     image.SetDataBuffer(dataBuffer)
     if alphaBuffer is not None:
         image.SetAlphaBuffer(alphaBuffer)
     image._buffer = dataBuffer
     image._alpha = alphaBuffer
     return image

Does the aggDrawer already implement a Python buffer object? If so, 
using this would be easy. If not, then it probably should, unless we go 
straight to the numpy array protocol.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Hi all,

Please John, take some time before SciPy conf to answer at least some of
this questions, because the SoC deadline (21st August) is *very* near.

1) I'm having some problems regarding FT2Font.
The problem is when I instantiate FT2Font like:
font = FT2Font(filename)
and when I call it's method font.set_text("Some text"), and afterwards,
font.draw_glyphs_to_bitmap(), the latter simply deletes every glyph that
was drawn before it, and just paints in the internal image buffer the
text that was passed on last invocation of set_text (or load_char).

This is a pain, because draw_glyphs_to_bitmap implements the layout
(with kerning etc.), but if one wants to paint several words in different
x,y positions in the same image buffer, he has to do the layout for every
character in every word manually via draw_glyph_to_bitmap(x, y, glyph)
(like you did with the BaKoMa fonts in mathtext).

Why hasn't draw_glyphs_to_bitmap been implemented so that it takes x, y as
arguments (draw_glyphs_to_bitmap(x, y)) and leaves the image
buffer intact (as does draw_glyph_to_bitmap)?

2) As I have said before, I have started the complete rewrite of mathtext
(the parsing stuff etc.). I have completely removed the dependency on
pyparsing (please don't yell at me :), and I was wondering about how much
of TeX should mathtext support. I'm not talking about support for \frac,
\above, \choose (which I plan to add one by one) etc., but about more
general things - macros (\def etc.). I was thinking of just simulating
them, at least to a tolerable extent, via notion of an enviroment.
Example:
\rm in plain TeX sets the current font to roman (until the end of the
current scope - 'till it hits "}").
Implementation:
At render time, when the parser hits "\rm", it does the folowing:
env["facetype"] = "rm", where env is the environment in the current scope.

Also, I am planing to create a separate class for every new layout item
that gets implemented.
Example: sub/superscripted item (nucleus_sub^sup) gets translated to an
instance of class Scripted that has the attributes nucleus, superscript
and subscript.

3) I was thinking of focusing on just the Agg backend for now (that is
till' the deadline). Is this OK?
4) I think that we should move the job of
math_parse_s_ft2font, math_parse_s_ft2font_svg, and math_parse_s_ps etc.
to the corresponding backends, and that some general function like:
    math_parse_s(x, y, s, prop, angle)
should be implemented directly in mathtext.py (perhaps even without the
"angle" parameter) so that it returns a list of the following type:
[(x1, y1, s1, prop1, angle1), ... , (xn, yn, sn, propn, anglen)]

Then the backend should call draw_text for every item in the list.
Something like
    def draw_mathtext(self, gc, x, y, s, prop, angle):
        items = math_parse_s(x, y, s, prop, angle)
        for item in items:
            draw_text(*items)

instead of current:
    def draw_mathtext(self, gc, x, y, s, prop, angle):
        """
        Draw the math text using matplotlib.mathtext
        """
        if __debug__: verbose.report('RendererAgg.draw_mathtext',
                                     'debug-annoying')
        size = prop.get_size_in_points()
        width, height, fonts = math_parse_s_ft2font(
            s, self.dpi.get(), size, angle)

        if angle == 90:
            width, height = height, width
        for font in fonts:
            if angle == 90:
                font.horiz_image_to_vert_image() # <-- Rotate
                self._renderer.draw_text( font, int(x)-width, int(y)-height, gc)
            else:
                self._renderer.draw_text( font, int(x), int(y)-height, gc)
        if 0:
            self._renderer.draw_rectangle(gc, None,
                                          int(x),
                                          self.height-int(y),
                                          width, height)

Is this possible? I'm aware of overseeing the dpi and fontsize arguments,
but I don't think that this is much of an issue.

5) What would be the consequences of distributing a GPL font (FreeFont)
with matplotlib. I mean, it's not that using a GPL font in some non-GPL
app could be a breach of the GPL. Is there any interest in this?

The new mathtext.py is attached. Please do not try it at home ;)
because nothing visible yet works.

Cheers,
Edin

On Tuesday 15 August 2006 12:32, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> When I run the following: figure(); plot([1,2]) figure();
>     Darren> plot([1,2])
>
>     Darren> and then I use the zoom widget in one figure, and then try
>     Darren> to use the zoom widget in the other figure without turning
>     Darren> off the first zoom widget, I get an error. Is this
>     Darren> desirable?
>
> Hi Darren -- I just modified the code to use per canvas widget
> locking.  Now every FigureCanvas has a widgetlock attr.
> Unfortunately, I cannot adequately test right now because I am working
> over X11 and the interactive widget stuff like examples/lasso_demo.py
> is too slow.  Could you try that demo, as well as multiple figures
> with pan/zoom and make sure you don't see any strangness?

Looks good to me, no problems to report.

I moved this to the devel list -- that seemed more appropriate.

Stefan van der Walt wrote:
> On Mon, Aug 14, 2006 at 11:12:29AM -0700, Christopher Barker wrote:
>> Another (or additional) option is for both MPL and wx to support
>> the new array interface protocol in numpy.

>> Travis posted a patch to PIL for support a while back, I don't know
>> if it's going to get applied or not, but it's worth looking at.
> 
> Looks like it has been added already.

Very cool. Now we just need MPL and wx to support it...

In the meantime, this note from Robin Dunn on the wxpython-users list:

> wx.Image.SetData makes a copy and gives ownership of the copy to the
> image.  This allows it to work even when the source buffer doesn't
> live as long as the image does.

This is probably how the original wx back-end worked.

> There is also the
> wx.Image.SetDataBuffer method, which will have the wxImage use the
> buffer passed in without making a copy, but if the buffer doesn't
> live as long as the image does it will likely cause a crash.

This would probably be the easiest way to get top performance at the 
moment. If we can make the Agg data a buffer, and somehow do the 
reference counting right so it doesn't get deleted while the wxImage is 
still around (that may not be hard -- the wxImage has to be converted to 
a wxBitmap to be drawn anyway)

Another issue is the data layout of the Agg buffer: is it RGB or RGBA 
(or something else?) wxImage requires 24bit RGB. It can support an alpha 
channel, but as far as I can tell, the alpha data is stored in a 
separate array, rather than as an RGBA array.

I'm poking into the code a bit now, and see:

def _py_convert_agg_to_wx_image(agg, bbox):

     image = wx.EmptyImage(int(agg.width), int(agg.height))
     image.SetData(agg.tostring_rgb())

We might be able to just change that to:
image.SetDataBuffer(agg.tostring_rgb())

Does the agg.tostring_rgb() call make a copy?

If so, then maybe a agg.Getbuffer() method is in order.

Also, if it does, then that string will get garbage collected right 
away, and delete the memory buffer. We'd need to keep that around 
somehow. maybe a subclass of wx.Image that holds a reference to the 
string. Then they'll both get deleted when the wx.Image is deleted..

I also took a look at:

def _clipped_image_as_bitmap(

This is way too ugly!

1) maybe it would be a good idea to have a:

agg.subImageToString_rgb(x,y,w,h)

This must be used in all the back-ends

2) If you do need to do the sub-sampling with wx code, I think you could do:

def _clipped_image_as_bitmap(image, bbox):
     """
     Convert the region of a wx.Image described by bbox to a wx.Bitmap.
     """
     l, b, width, height = bbox.get_bounds()
     r = l + width
     t = b + height

     subImage = image.GetSubImage( wx.Rect( (l,b),(width,height) ) )
     destBmp = wx.BitmapFromImage(subImage)

     return destBmp

Much simpler (and probably faster)

3) Another option would be to use numpy arrays to pass this kind of data 
around. We could then use numpy to sub-sample the image. MPL depends on 
numpy anyway, so it's not an added dependency. That may have to wait 
until the 'grand unification" is complete, and we can drop support for 
Numeric and numarray.

Sorry I don't have time to build and test this code right now.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

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

    Darren> When I run the following: figure(); plot([1,2]) figure();
    Darren> plot([1,2])

    Darren> and then I use the zoom widget in one figure, and then try
    Darren> to use the zoom widget in the other figure without turning
    Darren> off the first zoom widget, I get an error. Is this
    Darren> desirable?

Hi Darren -- I just modified the code to use per canvas widget
locking.  Now every FigureCanvas has a widgetlock attr.
Unfortunately, I cannot adequately test right now because I am working
over X11 and the interactive widget stuff like examples/lasso_demo.py
is too slow.  Could you try that demo, as well as multiple figures
with pan/zoom and make sure you don't see any strangness?

Thanks,
JDH

>>>>> "Asheesh" == Asheesh Laroia <as...@as...> writes:

    Asheesh> On Mon, 14 Aug 2006, John Hunter wrote:
    >> Hey Asheesh -- sorry we missed this the first time.  I just
    >> tried to apply it but the patch didn't go through because of
    >> the dir naming conventions you are using on your system. Could
    >> you try to get an svn co, apply your patch, and then submit an
    >> 'svn diff' ?

    Asheesh> That's attached.  Also, try using "patch -p1" next
    Asheesh> time. (-;

OK, it's in -- thanks!

JDH

On Mon, 14 Aug 2006, John Hunter wrote:

> Hey Asheesh -- sorry we missed this the first time.  I just tried to 
> apply it but the patch didn't go through because of the dir naming 
> conventions you are using on your system. Could you try to get an svn 
> co, apply your patch, and then submit an 'svn diff' ?

That's attached.  Also, try using "patch -p1" next time. (-;

I license this under the same terms at matplotlib is currently publicly 
distributed.

-- Asheesh.

-- 
Your boyfriend takes chocolate from strangers.

>>>>> "Asheesh" == Asheesh Laroia <as...@as...> writes:

    Asheesh> This patch does not change default behavior but provides
    Asheesh> a useful feature enhancement that we use at Creative
    Asheesh> Commons.  It would be great if you, our humble upstream,
    Asheesh> would accept it in the new point release.  Would you?

    Asheesh> Thanks!  I'm subscribed to matplotlib-devel and welcome
    Asheesh> comments.  I've re-attached the patch in the case that it
    Asheesh> got lost.

Hey Asheesh -- sorry we missed this the first time.  I just tried to
apply it but the patch didn't go through because of the dir naming
conventions you are using on your system. Could you try to get an svn
co, apply your patch, and then submit an 'svn diff' ?

Thanks!
JDH

Hi Asheesh,

It looks like your first email got overlooked. Sorry about that. Would you 
also post a bug report at the sourceforge webpage? I'll look at your patch 
when I get a chance.

Darren


On Monday 14 August 2006 8:17 pm, Asheesh Laroia wrote:
> On Tue, 18 Jul 2006, Asheesh Laroia wrote:
> > For pie charts, autopct lets a format string with the pie's value be
> > printed on the chart.  The default fraction of the radius that the text
> > is printed at is 0.6; I wanted the text farther out at 0.85.
> >
> > This small patch (against matplotlib 0.87.4) allows one to customize that
> > radius by a new keyword argument, pctradius.  The old behavior is still
> > the default.
>
> This patch does not change default behavior but provides a useful feature
> enhancement that we use at Creative Commons.  It would be great if you,
> our humble upstream, would accept it in the new point release.  Would you?
>
> Thanks!  I'm subscribed to matplotlib-devel and welcome comments.  I've
> re-attached the patch in the case that it got lost.
>
> -- Asheesh.

-- 
Darren S. Dale, Ph.D.
dd...@co...

On Tue, 18 Jul 2006, Asheesh Laroia wrote:

> For pie charts, autopct lets a format string with the pie's value be printed 
> on the chart.  The default fraction of the radius that the text is printed at 
> is 0.6; I wanted the text farther out at 0.85.
>
> This small patch (against matplotlib 0.87.4) allows one to customize that 
> radius by a new keyword argument, pctradius.  The old behavior is still the 
> default.

This patch does not change default behavior but provides a useful feature 
enhancement that we use at Creative Commons.  It would be great if you, 
our humble upstream, would accept it in the new point release.  Would you?

Thanks!  I'm subscribed to matplotlib-devel and welcome comments.  I've 
re-attached the patch in the case that it got lost.

-- Asheesh.

-- 
You are a bundle of energy, always on the go.

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:

    Charlie> Numpy 1.0b2 was released last night and Travis hopes this
    Charlie> will remain binary compatible with numpy 1.0.  Are there
    Charlie> any objections to a minor release bump?  I could do this
    Charlie> an soon as tomorrow.

Let's shoot for Tuesday evening, in advance of scipy.  I'm going to
make one more attempt before then to get the damned widget lock
working right....

JDH

Numpy 1.0b2 was released last night and Travis hopes this will remain
binary compatible with numpy 1.0.  Are there any objections to a minor
release bump?  I could do this an soon as tomorrow.

- Charlie

Hi,

I am using matplotlib 87.4 and I encountered a problem with fill. The outlines
of the filled region look weird when using the TkAgg backend. Same applies when
saved to a png file, so this seems to be a problem of all *Agg backends. The PS
backend is fine. Here is a somewhat longer example, that shows this behaviour.
For comparison, drawing the same outlines with plot gives a perfectly smooth
result.


from pylab import *
clf()
x = linspace(0,1, 100)
y1 = x**2
y2 = 1.03*y1
xx = concatenate((x, x[::-1]))
yy = concatenate((y1, y2[::-1]))
fillh = fill(xx, yy, ec = 'k', lw = 0.4)
fillh = fillh[0]
fillh.set_fill(False)
ph = plot(x, y1+0.1, 'k-',
     x, y2+0.1, 'k-', lw = 0.4)
savefig('jaggyfill.png', dpi = 150)
savefig('jaggyfill.eps')
show()

The more points I use, the worse the result. I create a png file since I need
alpha filling, eps doesn't support this. Creating a high resolution png and
downscaling improves the result, but this is tedious and time consuming. Any
help is appreciated!

Thanks in advance

Gregor Thalhammer

PS. Is this the right place to discuss such problems?

Hi folks,

I recently required a multi-column legend for a matplotlib graph. I
hacked up the Legend class to support this. I figured this might be
useful to others, so I'm attaching a patch in the hopes that someone
who is a regular contributor will review it and check it in.

Disclaimer: I spent an hour learning python for the express purpose of
making these graphs. That's the extent of my python experience so
some things might have been done the long way around.

It adds two parameters to the legend class:

The first 'rowspercolumn' specifies how often to start a new
column. If it is -1 then the current single-column behaviour is
reproduced. I set this to -1 in my matplotlibrc file, and pass a
specific number to the legend command when I want a multi-column
legend. 

The second 'columnsep' specifies the distance between the right side
of one column's label and the left side of the line of the next
column. 

Columns are sized horizontally to fit the largest label in the
column. I've tested it "extensively" on my case, with various
combinations of columns and legend entries. It seems to be stable. But
"extensively" is probably not a huge amount, honestly, and I'm new to
matplotlib so I may not have covered all the cases.

Cheers,
Colin

p.s. the patch is against the MacOS X binary distro which is at
0.87.4.

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

    Darren> When I run the following: figure(); plot([1,2]) figure();
    Darren> plot([1,2])

    Darren> and then I use the zoom widget in one figure, and then try
    Darren> to use the zoom widget in the other figure without turning
    Darren> off the first zoom widget, I get an error. Is this
    Darren> desirable?

No -- I hadn't considered this use case.  The locking should be on a
per figure basis.  I introduced locking to handle the case where
someone wants to use a widget that draws onto the canvas (like the
lasso tool) w/o interfering with the other tools that are handling
events.  Eg, if pan/zoom is enabled and you are also trying to draw a
lasso, all hell breaks loose.

I've commented this out and will re-implement after further
consideration.  Thanks for the heads-up.

JDH

When I run the following:

figure(); plot([1,2])
figure(); plot([1,2])

and then I use the zoom widget in one figure, and then try to use the zoom 
widget in the other figure without turning off the first zoom widget, I get 
an error. Is this desirable?

---------------------------------------------------------------------------
exceptions.ValueError                                Traceback (most recent 
call last)

/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_qt.py in 
zoom(self, *args)
    305     def zoom( self, *args ):
    306         self.buttons[ 'Pan' ].setOn( False )
--> 307         NavigationToolbar2.zoom( self, *args )
    308
    309     def dynamic_update( self ):

/usr/lib64/python2.4/site-packages/matplotlib/backend_bases.py in zoom(self, 
*args)
   1564             self._idRelease = 
self.canvas.mpl_connect('button_release_event', self.release_zoom)
   1565             self.mode = 'Zoom to rect mode'
-> 1566             widgets.lock(self)
   1567         else:
   1568             #pass

/usr/lib64/python2.4/site-packages/matplotlib/widgets.py in __call__(self, o)
     31         'reserve the lock for o'
     32         if not self.available(o):
---> 33             raise ValueError('already locked')
     34         self._owner = o
     35

ValueError: already locked



Darren

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

    Darren> return self.format_data(value)

    Darren> I'm not sure what you had in mind.

Oops:

    def format_data_short(self,value):
        'return a short string version'
        return self.format_data(value)


Fixed in svn

JDH

On Thursday 10 August 2006 11:17, John Hunter wrote:
> I'm a little confused here because the default should be to use the
> axis major formatter (eg in the Axes.format_xdata function).  Why
> would the default formatter return such a long string?
>
> I don't know what the right answer is: using the default formatter is
> usually irritating when plotting dates, since you often want a finer
> resolution than you get with the tick formatting (eg if the ticks are
> formatted to the nearest day, you may want to see H:M:S when
> interacting).  Clearly you can override this by using the fmt_xdata
> and fmt_ydata attrs, but oftentimes I wish the defaults were better.
>
> As a quick solution, I added a default method to the Formatter base
> class
>
>     def format_data_short(self,value):
>         'return a short string version'
>         return format_data(self,value)

I think there is a bug here. Maybe that last line should read

return Formatter.format_data(self,value)

or 

return self.format_data(value)

I'm not sure what you had in mind.

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

    John> I have tested a few backends (TkAgg, WX, QtAgg, GTK and
    John> GTKAgg) and am only seeing it on GTK and GTKAgg.  My guess
    John> is that something ou did in adding the resize functionality
    John> to GTK is triggering this.  You might want to look at a diff
    John> between the current svn and revision 2627 to see if you can
    John> find the source of this.

Scratch that -- I reverted to 2627 and still see it...

JDH

On Thursday 10 August 2006 11:17, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> I fixed that problem in the qt backends by telling the
>     Darren> label to ignore sizing hints. We could make the format
>     Darren> string shorter, but even then, depending on the size of
>     Darren> the window, this problem can occur. What format would you
>     Darren> prefer to be reported on the toolbar?
>
> I'm a little confused here because the default should be to use the
> axis major formatter (eg in the Axes.format_xdata function).  Why
> would the default formatter return such a long string?

I think it is to support for small ranges on top of very large numbers. I 
think the fix you suggest below will work for now (I had to make an 
additional change to format the offset label correctly, svn 2668), and I can 
clean up the default formatter later. I don't want to rush through that. 
People have asked for on more than one occassion for engineering notation: 
tick labels that read 2x10^-5, they would read 20x10^-6, and I think this 
would work with the shorter string formatting.

> I don't know what the right answer is: using the default formatter is
> usually irritating when plotting dates, since you often want a finer
> resolution than you get with the tick formatting (eg if the ticks are
> formatted to the nearest day, you may want to see H:M:S when
> interacting).  Clearly you can override this by using the fmt_xdata
> and fmt_ydata attrs, but oftentimes I wish the defaults were better.
>
> As a quick solution, I added a default method to the Formatter base
> class
>
>     def format_data_short(self,value):
>         'return a short string version'
>         return format_data(self,value)
>
> and overrode it for the scalar formatter
>
>     def format_data_short(self,value):
>         'return a short formatted string representation of a number'
>         return '%1.3g'%value
>
>
> and used this to format the x and y coords.  What do you think about
> that (revision 2666)?
>
> JDH
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:

    Charlie> I periodically am seeing it.  But I can't figure out how
    Charlie> to cause it.

I have tested a few backends (TkAgg, WX, QtAgg, GTK and GTKAgg) and am
only seeing it on GTK and GTKAgg.  My guess is that something ou did
in adding the resize functionality to GTK is triggering this.  You
might want to look at a diff between the current svn and revision
2627 to see if you can find the source of this.

peds-pc311:~/mpl> svn log lib/matplotlib/backends/backend_gtk.py |
head -20
------------------------------------------------------------------------
r2628 | cmoad | 2006-07-28 12:58:58 -0500 (Fri, 28 Jul 2006) | 1 line

fixed qt subplots button. added FigureManager.resize method
------------------------------------------------------------------------
r2502 | jdh2358 | 2006-06-21 08:22:31 -0500 (Wed, 21 Jun 2006) | 1
line

added custom figure class hook
------------------------------------------------------------------------
r2476 | efiring | 2006-06-12 12:36:06 -0500 (Mon, 12 Jun 2006) | 2
lines

GTK backend: don't draw line if linewidth==0.

------------------------------------------------------------------------
r2384 | stevech | 2006-05-08 01:40:08 -0500 (Mon, 08 May 2006) | 2
lines