matplotlib-devel Mailing List for matplotlib

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 2006年8月14日, 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 2006年8月14日, 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 2006年7月18日, 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 2006年7月18日, 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.