matplotlib-devel Mailing List for matplotlib (Page 3)

Hi,
John Hunter <jdh...@ac...> wrote:
> Yes, this is a historical artifact. bar was implemented first (and
[...]
> This would all be fairly trivial except table is based on bar, and the
> table layout is pretty complex. I "fixed" bar but broke table, and
> seeing no easy fix, unrolled the changes to bar. And that is where I
> left this problem last time I looked.
OK, I see.
> Would you mind filing a bug report on the sf site, with example code
> that shows the different behaviors of bar and barv, including a link
> to this discussion.
Done.
-- 
Florent

>>>>> "Abraham" =3D=3D Abraham Schneider <ab...@cn...> writes:
 Abraham> When looking through the backend_cairo.py code, I
 Abraham> realized that it currently renders the mathtext as
 Abraham> images. While this is currently fine, as cairo's export
 Abraham> of PS is really just an image, it would be better in the
 Abraham> future to actually have it draw the fonts as paths.
 Abraham> My first approach was to hack 'draw_mathtext.py', and to
 Abraham> go and draw the strokes for the glyph's paths. The
 Abraham> commands that the glyphs allow are (according to
 Abraham> ft2font.cpp) are: MOVETO=3D0, LINETO=3D1, CURVE3=3D2, CURVE4=
=3D3,
 Abraham> ENDPOLY=3D4. It seemed fairly simple, as cairo has the
 Abraham> commands: 'move_to(x, y)', 'line_to(x, y)', and
 Abraham> 'close_path()'. I wasn't sure if move_to and line_to were
 Abraham> the equivalents of this, or actually 'rel_move_to' and
 Abraham> 'rel_line_to'. Also, I wasn't sure how to map CURVE3 onto
 Abraham> cairo's 'curve_to' (admittedly I know very little about
 Abraham> these types of curves).
 Abraham> If anyone has any suggestions on how to do this, it would
 Abraham> be greatly appreciated. I also realized halfway through
 Abraham> that perhaps it was a better idea to instead use cairo's
 Abraham> truetype font ability, and if there weren't a simpler
 Abraham> method to do this..
I don't know much about cairo, but I can fill in a little detail about
the font paths. From
http://freetype.sourceforge.net/freetype2/docs/glyphs/glyphs-6.html
 An outline is described as a series of closed contours in the 2D
 plane. Each contour is made of a series of line segments and B=E9zier
 arcs. Depending on the file format, these can be second-order or
 third-order polynomials. The former are also called quadratic or
 conic arcs, and they are used in the TrueType format. The latter are
 called cubic arcs and are mostly used in the Type 1 format.
The CURVE3 code is a conic arc and the tuple that represents that
curve in the glyph.path sequence is
 CURVE3, xctl, yctl, xto, yto
and for cubic arcs is=20
 CURVE4, xctl1, yctl1, xctl2, yctl2, xto, yto
The code to extra path from a glyph was lifted from agg, but I put the
data structures in a list rather than an agg path to decouple agg form
the freetype module. I'm still deliberating about whether this is a
good idea or not.
Like you, I am not sure how to best handle conic arcs in cairo, but
Steve may know. Note that if you go the route you are considering,
you will lose hinting information, so figuring out a way to use
cairo's native truetype support may be preferable.
So I can't really answer any of your questions .... but I'll post a
conversion function from the ft2font path to an agg path in case it's
of any use
import os
import matplotlib
from matplotlib.ft2font import FT2Font
import matplotlib.agg as agg
MOVETO, LINETO, CURVE3, CURVE4, ENDPOLY =3D range(5)
def glyph_to_agg_path(glyph):
 path =3D agg.path_storage()
 for tup in glyph.path:
 print tup
 code =3D tup[0]
 if code =3D=3D MOVETO:
 x,y =3D tup[1:]
 path.move_to(x,y)
 elif code =3D=3D LINETO:
 x,y =3D tup[1:]
 path.line_to(x,y)
 elif code =3D=3D CURVE3:
 xctl, yctl, xto, yto=3D tup[1:]
 path.curve3(xctl, yctl, xto, yto)
 elif code =3D=3D CURVE4:
 xctl1, yctl1, xctl2, yctl2, xto, yto=3D tup[1:]
 path.curve4(xctl1, yct1, xctl2, yctl2, xto, yto)
 elif code =3D=3D ENDPOLY:
 path.end_poly()
 return path
fname =3D os.path.join(matplotlib.get_data_path(), 'Vera.ttf')
font =3D FT2Font(fname)
glyph =3D font.load_char(ord('a'))
path =3D glyph_to_agg_path(glyph)

When looking through the backend_cairo.py code, I realized that it 
currently renders the mathtext as images. While this is currently fine, 
as cairo's export of PS is really just an image, it would be better in 
the future to actually have it draw the fonts as paths.
My first approach was to hack 'draw_mathtext.py', and to go and draw the 
strokes for the glyph's paths. The commands that the glyphs allow are 
(according to ft2font.cpp) are: MOVETO=0, LINETO=1, CURVE3=2, CURVE4=3, 
ENDPOLY=4. It seemed fairly simple, as cairo has the commands: 
'move_to(x, y)', 'line_to(x, y)', and 'close_path()'. I wasn't sure if 
move_to and line_to were the equivalents of this, or actually 
'rel_move_to' and 'rel_line_to'. Also, I wasn't sure how to map CURVE3 
onto cairo's 'curve_to' (admittedly I know very little about these types 
of curves).
If anyone has any suggestions on how to do this, it would be greatly 
appreciated. I also realized halfway through that perhaps it was a 
better idea to instead use cairo's truetype font ability, and if there 
weren't a simpler method to do this..
Thanks!
Abe

>>>>> "Marcin" == Marcin Wojdyr <wo...@un...> writes:
 Marcin> And the same about patches? I like SF tracker. It has
 Marcin> "Send email on new submission to" option. Perhaps it
 Marcin> would be a good idea to send e-mail to devel list?
Yes, this is also a good idea.
JDH

>>>>> "Rolf" == Rolf Wester <rol...@il...> writes:
 Rolf> Hi, I have installed matplotlib-0.80 on WinXP and when I run
 Rolf> a Python script that calls pylab.plot several times after a
 Rolf> while the program ends with the error message listed
 Rolf> below. I inserted some print statements into backend_agg.py
 Rolf> and text.py (code snippets see below). As far as I can see
 Rolf> the problem is with the function xy_tup that returns
 Rolf> (70.0555555556, -3509680569.77) when given the input
 Rolf> (-0.030476944389471572, -0.012864052691159839).
It looks like your canvas width and height are really large if I am
reading your traceback properly -- are you sure your figure size and
dpi params are set right? It would help immensely if you can come up
with a stand-alone script that exposes the bug. If you can, report it
to the sourceforge bug tracker, along with the output of
--verbose-helpful and your rc file if it is customized and we can
probably track it down.
Absent a script which produces the bug, it is very hard to fix these
problems, even with the nice tracebacks you've provided. Because many
people use mpl 0.80 on windows XP and haven't reported this problem, I
wonder if there is a bug in the script you are using or in your
configuration file.
Thanks,
JDH

>>>>> "Marcin" == Marcin Wojdyr <wo...@un...> writes:
 Marcin> It is attached. There are two comments-questions in the
 Marcin> patch, please delete them after reading. And at the end
 Marcin> of this patched legend() method there is a line handles =
 Marcin> flatten(handles) If handles are not already flat, I think
 Marcin> something may go wrong earlier in this method (?).
As for the flatten stuff, all I can say is it involves how flatten
works in the presence of generators (the plot code ultimately uses a
generator when building a list of lines) and John Gill and I worked
pretty hard to make this robust and correct at the legend sprint at
pycon. In the absence of a specific use case that breaks legend, I'm
assuming this code is correct.
 Marcin> Thanks for explaination. I guessed it works like this
 Marcin> after finding what 'hold' is in Matlab. I just meant to
 Marcin> say that such explaination could be helpful in mpl
 Marcin> documentation.
Done.
 Marcin> Yes, I've seen all the examples and they are very
 Marcin> useful. However wxPython demo is more useful than just a
 Marcin> set of examples: examples are grouped in categories, every
 Marcin> example has a detailed documentation about introduced
 Marcin> features. From wx demo overview:
Yes, this would be useful. Any documentation you would like to add as
header strings to the examples will be most welcome!
JDH

>>>>> "Florent" == Florent Rougon <f.r...@fr...> writes:
 Florent> So, bar() does what I need. There is still one somewhat
 Florent> weird thing, however: barh() (as the barv() I wrote based
 Florent> on barh()) works with the *centers* of the bars
 Florent> (y-coordinates for barh(), x-coordinates for barv())
 Florent> whereas bar() expects the *left* x-coordinates of the
 Florent> bars in its first argument. This is not a drama, but a
 Florent> bit inconsistent.
Yes, this is a historical artifact. bar was implemented first (and
wrong) and the coords represented left rather than center. barh came
along later and decided rather than follow bar's mistake lead (a
foolish consistency and all that), it would do it right and bar could
be fixed later in a way that hopefully preserves backward
compatibility (eg an rc param and a warning) for a while.
This would all be fairly trivial except table is based on bar, and the
table layout is pretty complex. I "fixed" bar but broke table, and
seeing no easy fix, unrolled the changes to bar. And that is where I
left this problem last time I looked.
Would you mind filing a bug report on the sf site, with example code
that shows the different behaviors of bar and barv, including a link
to this discussion.
Thanks,
JDH

On Thursday 05 May 2005 11:44 pm, John Hunter wrote:
[...]
>
> The next task is to take a set of fonts and build a mapping from
> unicode index to fontname, glyph index. This will require some
> mastery of ft2font. Last time I was working on this I wrote
> examples/font_indexing.py, mainly as a reminder to myself, on how to
> use the module to extract the relevant information from font files,
> character names, glyph indexes and character codes. I now wish I had
> added more comments <wink>. You may want to try this example, read
> over it, and make sure you understand what it is doing (add comments
> as you learn and commit the updates to CVS).
Traceback (most recent call last):
 File "font_indexing.py", line 36, in ?
 print 'AV', font.get_kerning(glyphd['A'], glyphd['V'])/64.0
IndexError: Unexpected SeqBase<T> length.
I had to make a change to font_indexing.py, the call to get_kerning() needed a 
kerning mode parameter. This will output information that can be compared 
with values reported by fontforge:
print 'AV', font.get_kerning(glyphd['A'], glyphd['V'], KERNING_UNSCALED)
print 'AA', font.get_kerning(glyphd['A'], glyphd['A'], KERNING_UNSCALED)
The results are:
Vera: (same in fontforge)
AV -131
AA 57
VeraSe: (same in fontforge)
AV -102
AA 0
FreeSerif:
AV 0.0 (-131 according to fontforge)
AA 0.0
FreeSans:
AV 0.0 (-75 according to fontforge)
AA 0.0
PostScript output using the freefont afm's also appears to not be kerned, 
which I dont understand. 
Darren

I am continuing to make progress reproducing Baptiste's results. I am now at 
the final step of his tutorial, I have been able to generate a postscript 
file using afm fonts, by editing the strings as he suggested. On my system, 
~/.fonts is on the gs path, so I stuck the Free*.ps files there and renamed 
them.
One note. The postscript file renders well, but I had trouble converting it to 
a pdf with ghostscript-7.07. Some of the glyphs would render right on top of 
each other, here is an example where I tried to render 
\hbar\hbar\hbar\hbar\omega\omega\omega\omega\hbar\omega\hbar\omega:
http://people.ccmr.cornell.edu/~dd55/matplotlib/unicode/useafm.ps
http://people.ccmr.cornell.edu/~dd55/matplotlib/unicode/useafm.pdf
I ended up uninstalling the GPL'd ghostscript and installed the AFPL verion 
8.51. After that, ps2pdf worked as expected.
Darren

On Saturday 07 May 2005 10:46 pm, Darren Dale wrote:
>
> At this point, I was not able to save a ps figure with ps.useafm=True. I
> get the following error
[...]
> KeyError: 295
I was able to work through this problem this morning, it was an issue with 
fontforge: inexperienced operator.
> If we try to look at our figure now, ghostscript will complain about
> '/rangecheck yada yada' and fail to display the figure. This is because
> postscript doesn't understand utf-8 encoding.
> Postscript does however understand unicode hexa codes. So we have to replace
> (R(316円251円)) [ octal representation of utf-8 characters ]
> with
> <0052002803a90029> [ each 4 hexa figures are one character ]
> For now, we have to do that manually in our favorite text editor. To compute
> the hexa code in python, we do:
> >>> unistr=u'R(\u03a9)'
> >>> print ('<'+'%04x'*len(unistr)+'>') % tuple([ord(c) for c in unistr])
I tried replacing the characters in my ps file, but was not able to render the 
characters. Would you mind sending me your file, so I can see what you did?
> Producing pretty PDFs is well and nice, but most publishers will ask for
> .eps with all fonts embedded. So we have to embed the fonts into the .eps
> file. I could find no program to do this. DO NOT use gs -sDEVICE=pswrite
> for that. Not only will ghostscript mangle the fonts, but also the plots 
(!).
> 
> Luckily, the FreeSans.ps from above is already a postscript with embedded
> fonts, so we are golden. Just cat the font files together with the .eps
> and merge the headers and footers by hand.
> 
> [ It would be nice to have a ps.embedfonts preference. For Type 0, this is
> easy, as above; I don't know for Type 1. Also, it would be good to embed
> only the needed glyphs, but I haven't looked at how to do it ]
I slept on exactly these considerations last night. I was thinking that we 
should embed only the needed glyphs, and it should not be optional. The 
output has to be portable. Embedding AFM fonts should also take care of the 
PostScript kerning issues we have been talking about.
-- 
Darren S. Dale
Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850
dd...@co...

John Hunter <jdh...@ac...> wrote:
> I think what you are looking for is the "bar" function --
> http://matplotlib.sf.net/matplotlib.pylab.html#-bar. See
> examples/barchart_demo.py.
>
> Or do I misundertand what you are after..
You understood well, thank you. I was confused because at first, when I
looked at hist(), I saw that its argument 'bins' can be a sequence. From
that, I inferred that non-uniform widths were allowed for the bins.
After testing and reading the code, I understood this was wrong. Then, I
quickly looked at Axes.bar's docstring, since it was used in hist(), and
its beginning:
 BAR(left, height, width=0.8, bottom=0,
 color='b', yerr=None, xerr=None, ecolor='k', capsize=3)
 Make a bar plot with rectangles at
 left, left+width, 0, height
 left and height are Numeric arrays.
made me think that 'width' could only be a float, not an array.
So, bar() does what I need. There is still one somewhat weird thing,
however: barh() (as the barv() I wrote based on barh()) works with the
*centers* of the bars (y-coordinates for barh(), x-coordinates for
barv()) whereas bar() expects the *left* x-coordinates of the bars in
its first argument. This is not a drama, but a bit inconsistent.
Thanks.
-- 
Florent

>>>>> "Florent" == Florent Rougon <f.r...@fr...> writes:
 Florent> direction. Therefore, I wrote its twin sister,
 Florent> Axes.barv(), based on Axes.barh(). The patch included in
I think what you are looking for is the "bar" function --
http://matplotlib.sf.net/matplotlib.pylab.html#-bar. See
examples/barchart_demo.py.
Or do I misundertand what you are after..
JDH

On Saturday 07 May 2005 10:46 pm, Darren Dale wrote:
> >
> > Now it's time to produce a PDF. Run ps2pdf on one of the plots above,
> > at look at the ugly Type 3 fonts in your prefered PDF viewer.
> > The only way to get decent PDF is to set ps.useafm to True again.
>
> I copied my ttf fonts to matplotlib/fonts/ttf/, and reinstalled MPL from
> CVS. At this point, with ps.useafm=False, I was able to generate a pdf with
> really nice looking fonts. How were your fonts ugly?
I take that back, the fonts look nice in Adobe Reader 7, but not so good in 
kpdf.

Baptiste,
Thank you so much for this tutorial. It was very easy to follow. I have a 
couple of comments sprinkled through the instructions
On Wednesday 20 April 2005 7:13 pm, Baptiste Carvello wrote:
> Hello,
>
> I've been playing with the unicode rendering code that got added in
> matplotlib 0.74. All tests have been done on Linux with the 0.74-1
> debian package, lazy me... They should work on any platform, but you
> will have to find out the gory details (!).
>
> [ Most of these are examples, but there are a few remarks for the ps
> backend maintainers mostly, enclosed in square brackets in the text. No
> patches yet, but if you find the ideas useful, I can give it a try later. ]
>
> To try this out, you may also need the rather complete FreeFont unicode
> font: 1) download the ttf from
> http://savannah.nongnu.org/download/freefont/freefont-ttf.tar.gz
> 2) put the .ttf files in your prefered Truetype fonts directory
> 3) remove ~/.ttffont.cache
> 4) restart matplotlib
>
> Part I: Guess what I do for a living
>
> Get your favorite interactive backend and display pretty plots
>
> >>> plot([0.3,0.01,-0.01,-0.01,-0.1,-0.1,-0.3,-0.01,0.01,0.01,0.1,0.1,0.3]
> >>>,\
>
> ... [105,100,98,90,92,101,105,100,98,90,92,101,105],'kD-')
>
> >>> ylim(85,110)
> >>> xlabel(u'\u03bc\u2080H(T)', name='FreeSans')
> >>> ylabel(u'R(\u03a9)', name='FreeSans')
> >>> ^D
>
> or weird formulas
>
> >>> figtext(0.5,0.5,u'\u0127\u03c9 \u226a k\u0432T',name='FreeSerif',\
>
> ... size=30, ha='center', va='center', color='r')
>
> >>> ^D
>
> You can also save to svg, and even to postscript (or eps) provided you set
> the ps.useafm preference to False for now.
>
> Part II: All work and no play...
>
> >>> plot([0.3,0.01,-0.01,-0.01,-0.1,-0.1,-0.3,-0.01,0.01,0.01,0.1,0.1,0.3]
> >>>,\
>
> ... [105,100,107,90,92,101,105,100,98,90,92,101,105],'kD-')
>
> >>> ylim(85,110)
> >>> text(-0.01,107,u' \u261c booh! the ugly
> >>> artifact!',name='FreeSerif',\
>
> ... size=20, va='top', ha='left')
>
> >>> ^D
>
> ;-)
>
> Part III: Ugly, dirty and mean
>
> Now it's time to produce a PDF. Run ps2pdf on one of the plots above,
> at look at the ugly Type 3 fonts in your prefered PDF viewer.
> The only way to get decent PDF is to set ps.useafm to True again.
I copied my ttf fonts to matplotlib/fonts/ttf/, and reinstalled MPL from CVS. 
At this point, with ps.useafm=False, I was able to generate a pdf with really 
nice looking fonts. How were your fonts ugly?
>
> For this to work, we have to provide the AFM files for FreeFont:
> 1) download the source of the font from:
> http://savannah.nongnu.org/download/freefont/freefont-sfd.tar.gz
> 2) download fontforge from fontforge.sourceforge.net
> 3) open each .sfd file in freefont, and run File\Generate Fonts;
> choose type 'PS Type 0'; this should produce a corresponding
> .afm and .ps file; save the .ps file for later.
This was a little confusing, I think it should read 'open each .sfd file in 
fontforge, and run ...' I was able to generate afm and ps files, but I think 
something went wrong (see below). Did you have any trouble with this step? 
> 4) move the afm file to a directory which is searched by matplotlib.
> Any subdirectory of /usr/share/fonts/ will do, provided said
> subdirectory is not a symlink
> [ is this a bug ? the implementation is in lib/font_manager.py,
> function x11FontDirectory(); os.path.walk() ignores symlinks ]
> 5) remove ~/.afmfont.cache
> 6) restart matplotlib
> 7) when you save the first .ps figure, the cache is rebuilt
At this point, I was not able to save a ps figure with ps.useafm=True. I get 
the following error, maybe fontforge had trouble generating the afm files? 
At any rate, these fonts look really great. I'm going to start working on the 
unicode mappings so you can do '$\hbar$' instead of u'\u0127'. Again, thanks 
for the tutorial! Can we commit the freefont ttf's to CVS?
Darren
/usr/lib/python2.4/site-packages/matplotlib/pylab.py in savefig(*args, 
**kwargs)
 738 def savefig(*args, **kwargs):
 739 fig = gcf()
--> 740 return fig.savefig(*args, **kwargs)
 741 if Figure.savefig.__doc__ is not None:
 742 savefig.__doc__ = Figure.savefig.__doc__
/usr/lib/python2.4/site-packages/matplotlib/figure.py in savefig(self, *args, 
**kwargs)
 515 kwargs[key] = rcParams['savefig.%s'%key]
 516
--> 517 self.canvas.print_figure(*args, **kwargs)
 518
 519
/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py in 
print_figure(self, filename, dpi, facecolor, edgecolor, orientation)
 89 else:
 90 agg = self.switch_backends(FigureCanvasAgg)
---> 91 try: agg.print_figure(filename, dpi, facecolor, edgecolor, 
orientation)
 92 except IOError, msg:
 93 error_msg_gtk('Failed to save\nError message: 
%s'%(msg,), self)
/usr/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py in 
print_figure(self, filename, dpi, facecolor, edgecolor, orientation)
 403 from backend_ps import FigureCanvasPS # lazy import
 404 ps = self.switch_backends(FigureCanvasPS)
--> 405 ps.print_figure(filename, dpi, facecolor, edgecolor, 
orientation)
 406 else:
 407 raise IOError('Do not know know to handle extension 
*%s' % ext)
/usr/lib/python2.4/site-packages/matplotlib/backends/backend_ps.py in 
print_figure(self, outfile, dpi, facecolor, edgecolor, orientation)
 909 self._pswriter = StringIO()
 910 renderer = RendererPS(width, height, self._pswriter)
--> 911 self.figure.draw(renderer)
 912
 913 self.figure.set_facecolor(origfacecolor)
/usr/lib/python2.4/site-packages/matplotlib/figure.py in draw(self, renderer)
 393
 394 # render the axes
--> 395 for a in self.axes: a.draw(renderer)
 396
 397 # render the figure text
/usr/lib/python2.4/site-packages/matplotlib/axes.py in draw(self, renderer)
 1358
 1359 for zorder, i, a in dsu:
-> 1360 a.draw(renderer)
 1361
 1362 self.title.draw(renderer)
/usr/lib/python2.4/site-packages/matplotlib/text.py in draw(self, renderer)
 315
 316 return
--> 317 bbox, info = self._get_layout(renderer)
 318
 319 for line, wh, x, y in info:
/usr/lib/python2.4/site-packages/matplotlib/text.py in _get_layout(self, 
renderer)
 162 whs = []
 163 for line in lines:
--> 164 w,h = renderer.get_text_width_height(
 165 line, self._fontproperties, 
ismath=self.is_math_text())
 166 if not len(line) and not self.is_math_text():
/usr/lib/python2.4/site-packages/matplotlib/backends/backend_ps.py in 
get_text_width_height(self, s, prop, ismath)
 191 if ismath: s = s[1:-1]
 192 font = self._get_font_afm(prop)
--> 193 l,b,w,h = font.get_str_bbox(s)
 194
 195 fontsize = prop.get_size_in_points()
/usr/lib/python2.4/site-packages/matplotlib/afm.py in get_str_bbox(self, s)
 315 for c in s:
 316 if c == '\n': continue
--> 317 wx, name, bbox = self._metrics[ord(c)]
 318 l,b,w,h = bbox
 319 if l<left: left = l
KeyError: 295

PS: it seems you cannot specify the color as an RGB tuple, contrary to
 what the comments suggest. At least, I didn't manage to do it, and
 the bug is most probably also in Axes.barh() since the code for this
 part should be unchanged. No time to investigate, sorry.
-- 
Florent

On Thu, 5 May 2005, John Hunter wrote:
> OK, could you resend a patch against CVS?
> 
It is attached. There are two comments-questions in the patch,
please delete them after reading.
And at the end of this patched legend() method there is a line
handles = flatten(handles)
If handles are not already flat, I think something may go wrong
earlier in this method (?).
> Marcin> BTW when I was reading mpl docs I stopped for a while on
> Marcin> description of 'hold'. I'm not used to Matlab and didn't
> Marcin> understand what is "hold state". (I found it out in
> Marcin> Matlab docs).
> 
> When hold is True, subsequent plot commands will be added to the
> current axes. When hold is False, the current axes and figure
> will be cleared on the next plot command
Thanks for explaination. I guessed it works like this after finding
what 'hold' is in Matlab. I just meant to say that such explaination
could be helpful in mpl documentation.
> Marcin> 2. something like wxPython demo,
> Marcin> that contains all the examples
> 
> 2) Have you seen the examples directory in the matplotlib src
> distribution, and is also available here
> http://matplotlib.sourceforge.net/matplotlib_examples_0.80.zip ?
> Or do you mean something else?
Yes, I've seen all the examples and they are very useful. However wxPython
demo is more useful than just a set of examples: examples are grouped
in categories, every example has a detailed documentation about 
introduced features. From wx demo overview:
"""
This demo is not only a collection of test cases for wxPython, but is also 
designed to help you learn about and how to use wxPython. Each sample is 
listed in the tree control on the left. When a sample is selected in the 
tree then a module is loaded and run (usually in a tab of this notebook,) 
and the source code of the module is loaded in another tab for you to 
browse and learn from. 
"""
Marcin
-- 
Marcin Wojdyr | http://www.unipress.waw.pl/~wojdyr/ 

John Hunter wrote:
>As mentioned, selecting charmap 0 is suppose to select a unicode
>character map, and apparently charmap 2 is such a map. So you have
>\alpha in a bunch of different styles (plain, bold, italic, etc -- how
>to deal with all of this choice in the context of TeX/mathtext fonts
>like rm, it, tt etc is where some of the artistry referred to above
>comes in). 
> 
>
I would think the font_manager should be able to help you here, at least 
for the 'rm' and'it' styles. The font_manager tries to provide such 
information with the .style attribute. The 'tt' style is the big 
problem, since this requires a fixed width font. TTF fonts don't provide 
this information. It must be known beforehand or somehow deduced by 
reading the widths of the characters, if one is to do this in the 
general sense. The other option is to hardcode it into MPL. You 
probably know this already, but thought I should mention it anyway.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

John Hunter wrote:
> So some creative ways to handles these cases will have to be devised;
> a good start would be to google search
> 
> tex unicode
Also
 tex mathml
since the MathML people have to deal with the same problem.
> and do a little reading to get the lay of the land. There have been
> previous efforts at mapping characters between TeX and unicode, and
> I've worked on this before (see below). Also, search the archives for
> any posts by Robert Kern on the issue of mathtext --- they are all
> filled with sage advice and wonderful links that you will never find
> even if you google for 1000 years. Unfortunately, the sourceforge
> search engine is as sucky as their stats engine, so finding these
> posts may be difficult.
But Gmane is pretty good.
http://search.gmane.org/search.php?query=tex&email=kern&group=gmane.comp.python.matplotlib.general&sort=date
And couple useful tidbits that I sent privately:
"""There's some information here to go from various TeX font encodings 
to Unicode:
http://cvs.sourceforge.net/viewcvs.py/xdvi/xdvik/texk/xdvik/encodings.c?rev=1.13.2.14&view=markup
They claim some parts of it are GPLed from the catdvi project. I'm not 
sure if one can copyright this kind of information; how much creative 
choice is involved? But it might be worth asking the relevant 
individuals for permission.
"""
"""If you want to use the algorithms from _TeX: The Program_, I would 
suggest that you take a look at the publications of Luca Padovani, the 
implementor of GtkMathView. He describes how he uses, more or less, the 
TeX algorithms without the extra information provided by fonts designed 
for use in TeX.
MathML formatting with TeX rules, TeX fonts, and TeX quality
http://www.tug.org/TUGboat/Articles/tb24-1/padovani.pdf
PhD thesis: MathML Formatting
http://www.cs.unibo.it/~lpadovan/phd/main.pdf
"""
-- 
Robert Kern
rk...@uc...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> Let me make sure I understand this. If we map mathtext
 Darren> characters to unicode, and use freefont for now, will that
 Darren> help prepare MPL for STIX fonts? If there is an option
 Darren> available now that moves MPL in the direction of a
 Darren> permanent solution, then it seems like the decision is
 Darren> already made. 
What follows is a long post of getting unicode fonts to work with
mathtext, which is a very important goal. But there is another goal
which is also important that may serve your thesis needs well: the
ability to farm out text handling to TeX/LaTeX, either for ps or png
using dvitopng. 
Now, on to the unicode question.
In principle we should be able to substitute any set of unicode fonts
with any other, since they will all use the same encoding. Last time
I looked into replacing the bakoma fonts I spent a while looking at
the umbelleek fonts, but I came to the conclusion that they do not use
a unicode encoding, despite their author's later advocacy of unicode
 http://www.tug.org/TUGboat/Articles/tb19-3/tb60kinch.pdf
So I think freefont is a better path to pursue (I wasn't aware of
these until reading Baptiste's post); even though they are GPLd, they
will ease the path to integration with other unicode fontsets later
 Darren> Can we come up with some kind of a plan or
 Darren> design document for what steps we need to take? I will
 Darren> pick at it after work, if I understand what needs to be
 Darren> done.
I am happy to help, offer advice and pointers and so on, but there is
no definite set of steps I can lay out. The person who has their
boots on wading through the mud will have to make many of these
decisions. There is no 1-to-1 mapping between TeX symbols and
unicode. Most unicode symbols (ancient cypriot) have no TeX
equivalent and many TeX symbols have no unicode equivalent (eg there
is no unicode symbol for each of \sqrt, \Sqrt, \SQRT)
So some creative ways to handles these cases will have to be devised;
a good start would be to google search
 tex unicode
and do a little reading to get the lay of the land. There have been
previous efforts at mapping characters between TeX and unicode, and
I've worked on this before (see below). Also, search the archives for
any posts by Robert Kern on the issue of mathtext --- they are all
filled with sage advice and wonderful links that you will never find
even if you google for 1000 years. Unfortunately, the sourceforge
search engine is as sucky as their stats engine, so finding these
posts may be difficult.
 Darren> Now that the new formatter is complete, I have to find new
 Darren> ways to procrastinate. I will defend in August.
Hmm, in my experience, the having nothing to do is only the 2nd best
motivator for working on an open source project. The best one, of
course, is having a dissertation you should be working on. I'll try
and keep up with you :-)
Included below is a hodge-podge of some stuff I drudged out of my
examples and test directories related to fonts, mathtext and unicode
-- collectively they provide the tools required to put all these
pieces together. 
The following is a script to parse a unicode -> text mapping found at
http://www.cl.cam.ac.uk/~mgk25/ucs/examples/ -- grab the file TeX.txt
and run this script on it. The code parses that file builds a
dictionary from TeX->unicode
items = []
for line in file('TeX.txt'):
 line = line.strip()
 if not line.find('\\\\'): continue
 vals = line.split('\t')
 for val in vals:
 tup = val.split(' ')
 if len(tup)!=2: continue
 code, sym = tup
 if not sym.startswith('\\'): continue
 items.append((sym, code))
for k,v in items:
 o = ord(v.decode('utf-8'))
 
 #print k,v,o, hex(o)
 print " r'%s' : %d," % (k, o)
and generates output like
peds-pc311:~/python/mplsupport/test> python parse_tex.py 
 r'\alpha' : 945,
 r'\iota' : 953,
 r'\varrho' : 1009,
 r'\beta' : 946,
 r'\kappa' : 954,
 r'\sigma' : 963,
which you can use to create a dictionary mapping tex syms to unicode
indices. You can save this dictionary as a _mathtext_data dict, for
use by the mathtext module.
The next task is to take a set of fonts and build a mapping from
unicode index to fontname, glyph index. This will require some
mastery of ft2font. Last time I was working on this I wrote
examples/font_indexing.py, mainly as a reminder to myself, on how to
use the module to extract the relevant information from font files,
character names, glyph indexes and character codes. I now wish I had
added more comments <wink>. You may want to try this example, read
over it, and make sure you understand what it is doing (add comments
as you learn and commit the updates to CVS).
Many fonts have multiple character maps. Normally the 0 charmap is
unicode if there is a unicode char map. Let's look at the freefont
files and see how we can use the ft2font to find the font with \alpha
(should be at character code 945 from the results above). Below is
some code I wrote to iterate over a list of ttf files and print the
character codes, glyph indices and character names contained in those
files. I'm running this over all the fonts in the freefont dirs and
grepping for 945 and alpha to eliminate the noise
 test> python find_unicode_texsyms.py /usr/share/fonts/truetype/freefont/*.ttf|grep 945|grep alpha 
produces the following output
 FreeMonoBoldOblique.ttf 0 447 945 alpha
 FreeMonoBoldOblique.ttf 2 447 945 alpha
 FreeMonoBold.ttf 0 612 945 alpha
 FreeMonoBold.ttf 2 612 945 alpha
 FreeMonoOblique.ttf 0 651 945 alpha
 FreeMonoOblique.ttf 2 651 945 alpha
 FreeMono.ttf 0 679 945 alpha
 FreeMono.ttf 2 679 945 alpha
 FreeSansBoldOblique.ttf 0 394 945 alpha
 FreeSansBoldOblique.ttf 2 394 945 alpha
 FreeSansBold.ttf 0 438 945 alpha
 FreeSansBold.ttf 2 438 945 alpha
 FreeSansOblique.ttf 0 457 945 alpha
 FreeSansOblique.ttf 2 457 945 alpha
 FreeSans.ttf 0 570 945 alpha
 FreeSans.ttf 2 570 945 alpha
 FreeSerifBoldItalic.ttf 0 546 945 alpha
 FreeSerifBoldItalic.ttf 2 546 945 alpha
 FreeSerifBold.ttf 0 530 945 alpha
 FreeSerifBold.ttf 2 530 945 alpha
 FreeSerifItalic.ttf 0 527 945 alpha
 FreeSerifItalic.ttf 2 527 945 alpha
 FreeSerif.ttf 0 566 945 alpha
 FreeSerif.ttf 2 566 945 alpha
As mentioned, selecting charmap 0 is suppose to select a unicode
character map, and apparently charmap 2 is such a map. So you have
\alpha in a bunch of different styles (plain, bold, italic, etc -- how
to deal with all of this choice in the context of TeX/mathtext fonts
like rm, it, tt etc is where some of the artistry referred to above
comes in). 
Below is the code that generated this output -- hopefully it will give
you some more insight into how to use ft2font [BTW, if you take this
on, it would be really helpful if right now you open a notes file and
start a tutorial to self about what you are learning. I have to
relearn this stuff myself every time I work on it (and I wrote most of
the font code and the examples). There is no better time to write
helpful documentation than when learning. Someone may have to do this
again one day, and that someone may be you!]
import sys, os
from glob import glob
from matplotlib.font_manager import fontManager
from matplotlib.ft2font import FT2Font
from matplotlib.cbook import reverse_dict
for fname in sys.argv[1:]:
 #for fname in fontManager.ttffiles:
 font = FT2Font(fname)
 print 'loaded', fname, font.num_charmaps
 for i in range(font.num_charmaps):
 font.set_charmap(i)
 cmap = font.get_charmap()
 items = cmap.items()
 items.sort()
 fname = os.path.split(fname)[-1]
 for gind, code in items:
 name = font.get_glyph_name(gind)
 print fname, i, gind, code, name
 
OK, so now we have some mappings from TeX -> unicode and some idea of
how to map unicode symbols tofont names and glyph indices. Another
tool which you can look at to understand font handling and glyph
rendering is in the mpl examples dir. The following builds a standard
font table in a plot window
 examples> ./font_table_ttf.py /usr/share/fonts/truetype/freefont/FreeSans.ttf
This should be enough for tonight :-). We can talk by phone tomorrow
if you think it would help, or you can post questions here. It's good
to get some of this on record. I've spent many hours working on this
problem, but have never had the time and stamina to see it through.
mathtext in matplotlib has a lot of promise but the current
implementation is not satisfactory. Getting a good set of unicode
fonts working would be a significant step forward.
Thanks!
JDH

On Wednesday 04 May 2005 3:45 pm, John Hunter wrote:
> >> 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.
>
> 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=361
>87
>
> and STIX fonts when they are done 
Let me make sure I understand this. If we map mathtext characters to unicode, 
and use freefont for now, will that help prepare MPL for STIX fonts? If there 
is an option available now that moves MPL in the direction of a permanent 
solution, then it seems like the decision is already made. Can we come up 
with some kind of a plan or design document for what steps we need to take? I 
will pick at it after work, if I understand what needs to be done.
> 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?
Now that the new formatter is complete, I have to find new ways to 
procrastinate. I will defend in August.

>>>>> "Marcin" == Marcin Wojdyr <wo...@un...> writes:
 Marcin> On Wed, 4 May 2005, John Hunter wrote:
 >> 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.
 Marcin> Ok, it would also work well for me.
OK, could you resend a patch against CVS?
 Marcin> BTW when I was reading mpl docs I stopped for a while on
 Marcin> description of 'hold'. I'm not used to Matlab and didn't
 Marcin> understand what is "hold state". (I found it out in
 Marcin> Matlab docs).
When hold is True, subsequent plot commands will be added to the
current axes. When hold is False, the current axes and figure
will be cleared on the next plot command
There are many ways to manipulate the hold state. You can call the
pylab (or Axes) "hold" function with a boolean. You can pass hold as
a kwarg to a plot command to temporarily override the default. And
you can set the default value in your rc file.
For example, suppose you have hold=False in rc. Then every plot
command will clear the previous one. But you may want to add a new
overplot
 plot([1,2,3])
 plot([2,4,6], hold=True) # overplot
The default rc file that ships with matplotlib already has hold : True
be default (matlab is hold False by default).
You can query the hold state with ishold.
 Marcin> And if I could say what features I'm lacking most in MPL,
 Marcin> it would be: 1. plotting a function like in, say, gnuplot,
 Marcin> without using arange() 2. something like wxPython demo,
 Marcin> that contains all the examples
 1) Would definitely be nice -- we've talked about it.
 2) Have you seen the examples directory in the matplotlib src
 distribution, and is also available here
 http://matplotlib.sourceforge.net/matplotlib_examples_0.80.zip ?
 Or do you mean something else?
JDH

On Wed, 4 May 2005, John Hunter wrote:
> 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.
Ok, it would also work well for me. 
BTW when I was reading mpl docs I stopped for a while on description of 
'hold'. I'm not used to Matlab and didn't understand what is "hold state".
(I found it out in Matlab docs).
And if I could say what features I'm lacking most in MPL, it would be: 
1. plotting a function like in, say, gnuplot, without using arange()
2. something like wxPython demo, that contains all the examples
Thanks for your work,
Marcin
-- 
Marcin Wojdyr | http://www.unipress.waw.pl/~wojdyr/

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