matplotlib-devel Mailing List for matplotlib

Sounds good. I'll take a look at it tomorrow (Thursday).
Ted
At 02:48 PM 5/4/2005, John Hunter wrote:
> >>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
>
> Fernando> With these changes and the corresponding ones to ipython
> Fernando> (not in CVS yet, give me a day or two), it becomes
> Fernando> possible to use ipython to interactively drive Qt
> Fernando> applications, including matplotlib interactive plotting
> Fernando> with the QtAgg backend.
>
>Hey guys thanks for working on this -- Ted and colleagues at JPL, if
>you haven't used ipython for interactive plotting with mpl, it is very
>nice, and I definitely recommend giving it a try when Fernando gets
>his changes in CVS. Could you all look over this patch and make sure
>it doesn't conflict with anything your group is doing with the qt
>backend and if it looks good to you I'll merge it in.
>
>JDH
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: NEC IT Guy Games.
>Get your fingers limbered up and give it your best shot. 4 great events, 4
>opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
>win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Ted Drain Jet Propulsion Laboratory ted...@jp... 

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> With these changes and the corresponding ones to ipython
 Fernando> (not in CVS yet, give me a day or two), it becomes
 Fernando> possible to use ipython to interactively drive Qt
 Fernando> applications, including matplotlib interactive plotting
 Fernando> with the QtAgg backend.
Hey guys thanks for working on this -- Ted and colleagues at JPL, if
you haven't used ipython for interactive plotting with mpl, it is very
nice, and I definitely recommend giving it a try when Fernando gets
his changes in CVS. Could you all look over this patch and make sure
it doesn't conflict with anything your group is doing with the qt
backend and if it looks good to you I'll merge it in.
JDH

Hi all,
Denis Rivi=E8re <nu...@fr...>, Yann Cointepas <ya...@sa...> and B=
enjamin=20
Thyreau <Be...@de...> recently worked on some enhancements to ip=
ython=20
to support Qt threading (like we do for GTK and WX). In the process, the=
y=20
made some fixes to the Qt backend and sent me this, which I hope the powe=
rs=20
that be can take a look at and include before the CVS tree diverges too f=
ar.
With these changes and the corresponding ones to ipython (not in CVS yet,=
 give=20
me a day or two), it becomes possible to use ipython to interactively dri=
ve Qt=20
applications, including matplotlib interactive plotting with the QtAgg ba=
ckend.
Cheers,
f

>>>>> "Marcin" == Marcin Wojdyr <wo...@un...> writes:
 Marcin> Proposition of the patch is attached.
OK, I've added this to my local tree and it will make it into CVS
before too long. Those with an interest in tk, gtk, qt might want to
consider a similar patch to those backends.
 Marcin> BTW could you have a look at
 Marcin> http://sourceforge.net/mailarchive/forum.php?thread_id=7056275&forum_id=36187
 Marcin> Does it makes a sense?
Sorry I didn't respond earlier -- a combination of being out of the
country in combination with a hard-drive failure have left me in
catch-up mode. Thanks for the reminder
I don't like the idea of making the label a string or None, because it
leads to code that is difficult to maintain and may break existing
code that relies on the label to be a string. I would be amenable to
using a sentinel string, such as '_nolegend_' or something like that.
JDH

On Sun, 1 May 2005, John Hunter wrote:
> Marcin> And last thing: what do you think about making toolbar2
> Marcin> more hmm.. interactive(?), i mean disabled back/forward
> Marcin> buttons whan there is no history, pressed pan/zoom buttons
> Marcin> when in pan/zoom mode etc? I don't know if I'll try to do
> Marcin> it, but if someone would do it, would it be included in
> Marcin> MPL?
> 
> Yes, this would be nice. I think fltk already does this. It's mainly
I haven't installed fltk, but had a look at code, and I think it does
toggled pan/zoom buttons, but not enabled/disabled back/forward.
> a matter of getting to this to work on each and every backend. I
> think Steve and I both looked at this for gtk, but couldn't an easy
> way to do this. Part of the problem, I think, is that mpl is using
> custom images for these buttons and it wasn't clear to me how to
> indicate "pressed" status with button relief, etc... Patches gladly
> accepted.
Proposition of the patch is attached. 
BTW could you have a look at 
http://sourceforge.net/mailarchive/forum.php?thread_id=7056275&forum_id=36187
Does it makes a sense?
Marcin
-- 
Marcin Wojdyr | http://www.unipress.waw.pl/~wojdyr/ 

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 >> To fix this one should get the kerning information from the
 >> font, and do the kerning manually. Have a look at dvips output
 >> to get inspiration.
Now that we understand the problem, we have two options.
 * We can manually do the kerning in draw_text for the truetype
 fonts. This won't be hard because we can just follow the example
 of draw_unicode with minor modifications. This will be a little
 slower and make ps files a little bigger, but will look the best.
 * we can add a kwarg to font.get_width_height() to ignore kerning
 information, and backend ps can call
 font.get_width_height(kerning=False). 
 Darren> I also had a look at the dvips output, and get the general
 Darren> idea of how it handles layout. So let me ask, why does
 Darren> mathtext break with afm fonts? Is it inherent, or could
 Darren> mathtext.py (or backend_ps.py) be changed to cooperate
 Darren> with afm? From looking at the dvips output, a naive
 Darren> individual like myself might think it is pretty straight
 Darren> forward to render something like r'My test string
 Darren> $A=A_0e^(i\theta)$'. (I'm not saying it would be easy to
 Darren> implement.)
 Darren> Dvips embeds four fonts to render my example string:
 Darren> CMMI7, CMR7, CMMI10, CMR10. Here is the output, I clipped
 Darren> the start of the file up to the end of the font defs:
I started working with AFM fonts in my initial implementation of
mathtext, but before I got too far Paul took on the task of porting
mathtext to PS and decided to embed the truetype fonts. This has the
advantage of having your postscript figure and screen figure look
nearly identical and also just gives us a single point of maintenance
in the mathtext module. But there are problems as well, as you've
noticed
 * the bakoma fonts suck in my opinion, some glyphs render poorly.
 Paul and I were never able to figure out how the vertical offsets
 in cmex worked, they have licensing problems
 * the use of bakoma fonts for mathtext and other fonts for the rest
 of the figure looks bad, and may be unacceptable for publication.
 One solution is to use cmr as your default font (set the rc param)
 but then see the problem above.
We could go the route of embedding type1 fonts and using afm files for
layout -- this wouldn't be too hard. But our energy might be best
served by converting the mathtext data tables to map text characters
to unicode and then using a set of unicode fonts, using freefont for
now (GPLd I think)
 http://sourceforge.net/mailarchive/forum.php?thread_id=7090823&forum_id=36187
and STIX fonts when they are done http://www.stixfonts.org (which
should be just a few months according to their web site, but then
again their FAQ says "The STIX Fonts will not be completed until some
time in 2003" so we should be cautious....)
See also 
 http://www.mozilla.org/projects/mathml/fonts/
I realize you have a thesis to print, so hopefully we can figure out a
smooth path to success soon! When do you need to turn that thing in?
JDH

On Tuesday 03 May 2005 9:51 am, Jochen Voss wrote:
> Hi Darren,
>
> On Mon, May 02, 2005 at 04:03:17PM -0400, Darren Dale wrote:
> > I assigned the PS bug to myself. If anyone has some insight, I could
> > definitely use it.
>
> Sorry, I do not have much time at the moment, but I remember
> something: the PostScript driver always got the horizontal text
> extents slightly wrong, because PostScript seems to not do kerning by
> itself. It is a small effect, but visible. This is especially
> visible when comparing strings like "AAAAA" and "AVAVAV". Is this
> what you are seeing?
>
> To fix this one should get the kerning information from the font,
> and do the kerning manually. Have a look at dvips output to get
> inspiration.
I just finished reading Adobe's Technical Note #5012: The Type 42 Font Format 
Specification. The only mention of kerning is on page 12, indicating that 
performance can be improved by including only those type 42 tables that are 
actually used by the TrueType rasterizer. It implies that kerning tables are 
not used.
I also had a look at the dvips output, and get the general idea of how it 
handles layout. So let me ask, why does mathtext break with afm fonts? Is it 
inherent, or could mathtext.py (or backend_ps.py) be changed to cooperate 
with afm? From looking at the dvips output, a naive individual like myself 
might think it is pretty straight forward to render something like 
r'My test string $A=A_0e^(i\theta)$'. 
(I'm not saying it would be easy to implement.)
Dvips embeds four fonts to render my example string: CMMI7, CMR7, CMMI10, 
CMR10. Here is the output, I clipped the start of the file up to the end of 
the font defs:
>%%EndFont 
>TeXDict begin 40258431 52099146 1000 600 600 (temp.dvi)
>@start /Fa 150[23 86[32 18[{}2 58.1154 /CMMI7 rf /Fb
>207[33 48[{}1 58.1154 /CMR7 rf /Fc 154[39 35[62 65[{}2
>83.022 /CMMI10 rf /Fd 134[44 4[32 33 33 3[46 4[23 1[42
>1[37 23[76 15[65 11[42 49[{}11 83.022 /CMR10 rf end
>%%EndProlog
>%%BeginSetup
>%%Feature: *Resolution 600dpi
>TeXDict begin
> end
>%%EndSetup
>%%Page: 1 1
I'm not sure what that first block is doing (yet), but here is the important 
part:
>TeXDict begin 1 0 bop 639 523 a Fd(My)28 b(test)g(string)f
>Fc(A)c Fd(=)g Fc(A)1420 535 y Fb(0)1457 523 y Fc(e)1496
>493 y Fa(i022円)1926 5255 y Fd(1)p eop end
Its essentially a group of moveto statements and font changes. It looks like 
the kerning support is sort of a hybrid, where you dont have to layout each 
glyph independently, but layout is done manually between groups of glyphs.
I guess I havent considered rendering in AGG.
Darren

Hi,
I have installed matplotlib-0.80 on WinXP and when I run a Python script 
that calls pylab.plot
several times after a while the program ends with the error message 
listed below. I inserted some print statements into backend_agg.py and 
text.py (code snippets see below). As far as I can see the problem is 
with the function xy_tup that returns (70.0555555556, -3509680569.77) 
when given the input (-0.030476944389471572, -0.012864052691159839).
My workaround is to set:
try:
 self._renderer.draw_text(font, int(x), int(y), gc)
except:
 pass
in backend_agg.py
Is there anything I can do instead to avoid this error message?
With kind regards
Rolf Wester
-------------------------------------------------------------------------------------------------
text.py
 def draw(self, renderer):
 ...
 
 bbox, info = self._get_layout(renderer)
-> print "draw ", info,
 for line, wh, x, y in info:
 x, y = self._transform.xy_tup((x, y))
-> print x,y," / ",
 #renderer.draw_arc(gc, (1,0,0),
 # x, y, 2, 2, 0.0, 360.0)
 if renderer.flipy():
 canvasw, canvash = renderer.get_canvas_width_height()
 y = canvash-y
-> print y, canvash
 
 renderer.draw_text(gc, x, y, line,
 self._fontproperties, angle,
 ismath=self.is_math_text())
------------------------------------------------
backend_agg.py:
 def draw_text(self, gc, x, y, s, prop, angle, ismath):
 """
 Render the text
 """
 if __debug__: verbose.report('RendererAgg.draw_text', 
'debug-annoying')
 if ismath:
 return self.draw_mathtext(gc, x, y, s, prop, angle)
 font = self._get_agg_font(prop)
 if font is None: return None
 if len(s)==1 and ord(s)>127:
 font.load_char(ord(s))
 else:
 font.set_text(s, angle)
 font.draw_glyphs_to_bitmap()
-> print font, int(x), int(y), gc
 self._renderer.draw_text(font, int(x), int(y), gc)
--------------------------------------------------------------
Shell
...
draw [('0', (7.0, 10.0), -0.030476944389471572, -0.012864052691159839)] 
70.0555555556 -3509680569.77 / 3509681061.77 492.0
<FT2Font object at 0x0132DEAC> 70 3509681061 
<matplotlib.backend_bases.GraphicsContextBase instance at 0x1B340F80>
Traceback (most recent call last):
 File "E:\work\trumpf\kaustikopti6659mmAK2ma.py", line 238, in -toplevel-
 intensity_nf, intensity_ff = opt_resonator_online(GRIDLIST, OELIST, 
outcoupler, SEQUENCELIST1, SEQUENCELIST2, no_fc, init_kind, nit, nav, 
verbose=verbose, plot = plot, genplot = gen_plot)
 File "D:\PROGLA~1\Python23\lib\site-packages\OPT\opt_resonator.py", 
line 473, in opt_resonator_online
 if plot: genplot.plot_slice(fc_outcouple, ifigure = 2, clear = 
'yes', nr = 1, nc = 2, nf = 1, slice = 1, xlabel = '$r$', i=0, 
ylabel = '$Intensity$', title = '$nearfield$')
 File "D:\PROGLA~1\Python23\lib\site-packages\OPT\opt_graphics.py", 
line 507, in plot_slice
 xlabel = xlabel, ylabel = ylabel, title = title)
 File "D:\PROGLA~1\Python23\lib\site-packages\OPT\opt_graphics.py", 
line 560, in plot_slice_matplotlib
 pylab.plot(x,xslice)
 File "D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\pylab.py", 
line 1900, in plot
 draw_if_interactive()
 File 
"D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\backends\backend_tkagg.py", 
line 58, in draw_if_interactive
 figManager.show()
 File 
"D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\backends\backend_tkagg.py", 
line 292, in show
 self.canvas.draw()
 File 
"D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\backends\backend_tkagg.py", 
line 146, in draw
 FigureCanvasAgg.draw(self)
 File 
"D:\PROGLA~1\Python23\lib\site-packages\matplotlib\backends\backend_agg.py", 
line 312, in draw
 self.figure.draw(renderer)
 File "D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\figure.py", 
line 395, in draw
 for a in self.axes: a.draw(renderer)
 File "D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\axes.py", line 
1362, in draw
 self.yaxis.draw(renderer)
 File "D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\axis.py", line 
524, in draw
 tick.draw(renderer)
 File "D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\axis.py", line 
141, in draw
 if self.label1On: self.label1.draw(renderer)
 File "D:\PROGLA~1\Python23\lib\site-packages\matplotlib\text.py", line 
332, in draw
 ismath=self.is_math_text())
 File 
"D:\PROGLA~1\Python23\lib\site-packages\matplotlib\backends\backend_agg.py", 
line 211, in draw_text
 self._renderer.draw_text(font, int(x), int(y), gc)
TypeError: CXX: type error.
 >>>
-- 
-------------------------------------
Rolf Wester
rol...@il...

On Tuesday 03 May 2005 9:51 am, Jochen Voss wrote:
> Hi Darren,
>
> On Mon, May 02, 2005 at 04:03:17PM -0400, Darren Dale wrote:
> > I assigned the PS bug to myself. If anyone has some insight, I could
> > definitely use it.
>
> Sorry, I do not have much time at the moment, but I remember
> something: the PostScript driver always got the horizontal text
> extents slightly wrong, because PostScript seems to not do kerning by
> itself. It is a small effect, but visible. This is especially
> visible when comparing strings like "AAAAA" and "AVAVAV". Is this
> what you are seeing?
>
> To fix this one should get the kerning information from the font,
> and do the kerning manually. Have a look at dvips output to get
> inspiration.
Hi Jochen,
Thanks for responding. I'll continue looking into this tomorrow. For now, I 
posted a new eps file in the sourceforge bugreport, which renders the 
suggested strings. You are right, the effect is especially visible when 
rendering 'AVAVAV'.
By the way, did you know MoonBuggy is in the gentoo package management tree?
-- 
Darren S. Dale
Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850
dd...@co...