matplotlib-devel Mailing List for matplotlib (Page 2)

On 8/28/06, Darren Dale <dd...@co...> wrote:
> A while back, I put some effort into rendering an offset ticklabel, which
> allowed the user to do something like
>
> plot(linspace(100000100, 100000200, 100))
>
> and the plot would look like a plot from 0 to 100, with a "+100000100"
> rendered in a new label near the far end of the axis. This doesnt work quite
> as well as it used to, because the axes autoscaling is setting the plot range
> to something like the average plus and minus 6%. I have tried tracing the
> source of this change, but I can't find it. It might be buried in the
> _transforms extension code, and I've never been able to wrap my head around
> mpl's transforms.
> Does anyone know why autoscaling is defaulting to this +-6% range?
I don't know anything about it what happened to the code, but I will
say that +- 6% autoscaling is better than tight bounds for many kinds
of plots. Like a scatter plot. It doesn't look good if some of your
points are right on the axes, with their marker cut in half by the
border. It's always bugged me with Matlab that there was no easy way
to get slightly enlarged bounds on plots, so I'm glad to hear mpl has
added something like that. I'm not sure it should be the default, or
only option though. Some plots are better with tight bounds.
--bb

A while back, I put some effort into rendering an offset ticklabel, which 
allowed the user to do something like
plot(linspace(100000100, 100000200, 100))
and the plot would look like a plot from 0 to 100, with a "+100000100" 
rendered in a new label near the far end of the axis. This doesnt work quite 
as well as it used to, because the axes autoscaling is setting the plot range 
to something like the average plus and minus 6%. I have tried tracing the 
source of this change, but I can't find it. It might be buried in the 
_transforms extension code, and I've never been able to wrap my head around 
mpl's transforms.
Does anyone know why autoscaling is defaulting to this +-6% range? Does it 
have to be this way? I'm trying to improve the scalar formatter (supporting 
engineering notation, cleaning up the code).
Thanks,
Darren

Chris,
Thanks for the cross-post. I'm not sure this approach will help 
speed up the wxAgg accelerator, but I'll put it on the list of things 
to look into. The problem I foresee is that the Agg renderer's RGBA 
data has to be converted to RGB before a wxImage can be created by 
convert_agg2image().
Ken
On Aug 18, 2006, at 6:14 PM, Christopher Barker wrote:
> As a probably final installment in the thread about optimizing the wx
> back-end, here is a post from the wxPython list, in which someone 
> posted
> SWIG code for making a PyBuffer from his data set, then using it to
> create a wx.Image without copying. A similar approach could be used 
> for
> the wxAgg back-end.
>
> -Chris
>
> -------- Original Message --------
> Subject: [wxPython-users] Re: using wxImage in C++ python extension
> Date: 2006年8月18日 16:48:08 +0000 (UTC)
> From: Andrew Murray <and...@st...>
> Reply-To: wxP...@li...
> To: wxp...@li...
> References: <200...@uc...>
> <44E...@al...> <200...@uc...>
> <44E...@no...> <44E...@al...>
> <44E...@no...>
>
> Hi all :)
>
> I've followed the combined advice of Robin and Christopher in using 
> a python
> buffer object to instance a wx.Image in the python wrapper layer. It
> all seems
> to be working - and I don't think there are any 'data copies' going 
> on ;)
>
> To keep my underlying C++ python-free, I introduced the buffer (and
> creation of
> the wx.Image) via my .i Swig file. In case anyone who is reading is
> keen trying
> to solve a similar problem, I've included the code that I added to 
> my .i
> file in
> order to implement the change below. (I'd appreciate any comments 
> regarding
> errors or shortcomings that anyone spots in my implementation.)
>
> Sorry I didn't reply to the thread earlier. A combination of being 
> tied
> up with
> more boring work, moving house and background research into using 
> python
> buffers
> with Swig means that I've only just got this far.
>
> One remaining question I have is: Does the call to wx.EmptyImage 
> that I make
> cause any memory to be allocated? I see from Robin's recent post 
> that in my
> case this call is now redundant (as I will soon be using
> ImageFromBuffer) - but
> I'm curious to know the answer anyway ;)
>
> Thanks for all the help. The more I use wxPython the more I like 
> it...
>
> Andrew ;)
>
>
> /* the RawImage C++ class that we are wrapping offers a method that
> returns a pointer to an internal 'unsigned char' buffer of display
> data. To make the python class generated by SWIG a bit more
> friendly to the rest of our wxPython code we instruct SWIG to make
> two modifications during the wrapping process. First we add a
> method to the C++ class that will return a version of the internal
> display buffer wrapped up as a 'python buffer object' (performing
> this in the C++ wrapper class keeps the wrapped C++ python- 
> free)...
> */
> %extend RawImage {
> 	PyObject* RawImage::getDisplayBuffer(void) {
> 		// return a new 'python buffer object' that intialised using
> 		// the memory address and length of our display buffer...
> 		void* pvBufferData = (void*)self->pcGetDisplayData();
> 		int iBufferSize = self->getDisplayBufferSize();
> 		return PyBuffer_FromMemory(pvBufferData, iBufferSize);
> 	}
> }
> /* ... we also add a method to the python wrapper class that will use
> the buffer offered by our new C++ method to create a wx.Image
> (neither of these methods actually copies the image data)...
> */
> %extend RawImage {
> %pythoncode %{
> def getImage(self):
> # create an unintialised wx.Image of the correct size...
> wximage = wx.EmptyImage(self.getWidth(), self.getHeight(), 
> clear=False)
> # then define the data content of the image...
> wximage.SetDataBuffer(self.getDisplayBuffer())
> return wximage
> %}
> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxP...@li...
> For additional commands, e-mail: wxPython-users- 
> he...@li...
>
>
> -- 
> 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...
>
> ---------------------------------------------------------------------- 
> ---
> 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

VGhhbmtzIGZvciB0aGUgZmVlZGJhY2ssIGFuZCBzb3JyeSBmb3IgYW55IHByb2JsZW1zLgoKSSd2
ZSBiZWVuIGEgYml0IGJ1c3kgdGhpcyB3ZWVrLCBhbmQgSSdsbCB0cnkgdG8gaW1wcm92ZS9maXgg
aXQgdGhpcyB3ZWVrZW5kLgoKQ2hlZXJzLApFZGluCgoyMDA2LzgvMjQsIERhcnJlbiBEYWxlIDxk
ZDU1QGNvcm5lbGwuZWR1PjoKPiBPbiBUaHVyc2RheSAyNCBBdWd1c3QgMjAwNiAxNTowMywgaHVt
dWZyQHlhaG9vLmZyIHdyb3RlOgo+ID4gSXTFmyB3b3JraW5nIG5vdywgdGhhbmtzLiBKdXN0IGEg
cmVtYXJrIHdoeSB0aGUgZm9udHMgbXVzdCBiZSBpbiBtcGwtZGF0YQo+ID4gYW5kIHdoeSBtYXRw
bG90bGliIGlzIG5vdCB1c2luZyB0aGUgZm9udHMgd2hvIGFyZSBpbiB0aGUgc3lzdGVtPwo+Cj4g
SXQncyBhIGJ1Zy4gRWRpbiBzYWlkIGhlIHdvdWxkIHdvcmsgb24gaXQuCg==

I get this error when trying to compile _ns_backend_agg.so:
/usr/bin/ld: multiple definitions of symbol __NPY_SIGINT_BUF
build/temp.macosx-10.4-i386-2.4/src/_image.o definition of 
__NPY_SIGINT_BUF in section (__DATA,__common)
build/temp.macosx-10.4-i386-2.4/src/_ns_backend_agg.o definition of 
__NPY_SIGINT_BUF in section (__DATA,__common)
collect2: ld returned 1 exit status
/usr/bin/ld: multiple definitions of symbol __NPY_SIGINT_BUF
build/temp.macosx-10.4-i386-2.4/src/_image.o definition of 
__NPY_SIGINT_BUF in section (__DATA,__common)
build/temp.macosx-10.4-i386-2.4/src/_ns_backend_agg.o definition of 
__NPY_SIGINT_BUF in section (__DATA,__common)
collect2: ld returned 1 exit status
error: Command "c++ -bundle -undefined dynamic_lookup build/ 
temp.macosx-10.4-i386-2.4/agg23/src/agg_trans_affine.o build/ 
temp.macosx-10.4-i386-2.4/agg23/src/agg_path_storage.o build/ 
temp.macosx-10.4-i386-2.4/agg23/src/agg_bezier_arc.o build/ 
temp.macosx-10.4-i386-2.4/agg23/src/agg_curves.o build/ 
temp.macosx-10.4-i386-2.4/agg23/src/agg_vcgen_dash.o build/ 
temp.macosx-10.4-i386-2.4/agg23/src/agg_vcgen_stroke.o build/ 
temp.macosx-10.4-i386-2.4/agg23/src/agg_rasterizer_scanline_aa.o 
build/temp.macosx-10.4-i386-2.4/agg23/src/agg_image_filters.o build/ 
temp.macosx-10.4-i386-2.4/src/_image.o build/temp.macosx-10.4- 
i386-2.4/src/ft2font.o build/temp.macosx-10.4-i386-2.4/src/mplutils.o 
build/temp.macosx-10.4-i386-2.4/CXX/cxx_extensions.o build/ 
temp.macosx-10.4-i386-2.4/CXX/cxxsupport.o build/temp.macosx-10.4- 
i386-2.4/CXX/IndirectPythonInterface.o build/temp.macosx-10.4- 
i386-2.4/CXX/cxxextensions.o build/temp.macosx-10.4-i386-2.4/src/ 
_ns_backend_agg.o -L/usr/local/lib -L/usr/lib -L/usr/local/lib -L/usr/ 
lib -lpng -lz -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o build/ 
lib.macosx-10.4-i386-2.4/matplotlib/backends/_ns_backend_agg.so" 
failed with exit status 1
I tried to use the -multiply_defined suppress flag, but to no avail..
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

I spent a little time this morning looking into these warnings I get when 
building mpl from source, for example:
-----------------------------------------------------
In file included from /usr/include/python2.4/Python.h:13,
 from ./CXX/Objects.hxx:9,
 from ./CXX/Extensions.hxx:19,
 from src/_backend_agg.h:8,
 from src/_wxagg.cpp:48:
/usr/include/python2.4/pyconfig.h:838:1: warning: "_POSIX_C_SOURCE" redefined
In file included from /usr/include/features.h:8,
 from /usr/include/gentoo-multilib/amd64/string.h:26,
 from /usr/include/string.h:8,
 
from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4/cstring:53,
 from src/_wxagg.cpp:38:
/usr/include/gentoo-multilib/amd64/features.h:154:1: warning: this is the 
location of the previous definition
-----------------------------------------------------
These warnings come from the "#include Python.h" statements, although I 
haven't been able to track down the exact reason. (This problem was discussed 
on python-dev, 
http://mail.python.org/pipermail/python-dev/2005-June/054214.html, but I 
wasn't able to improve mpl's code based on that discussion.) The following 
patch allows mpl to build without warnings on my system (it is hackish, I 
don't intend to commit it.) Would anyone please care to comment?
Darren
Index: src/_gtkagg.cpp
===================================================================
--- src/_gtkagg.cpp (revision 2706)
+++ src/_gtkagg.cpp (working copy)
@@ -6,6 +6,9 @@
 #include <utility>
 #include <fstream>
+#ifdef _POSIX_C_SOURCE
+#undef _POSIX_C_SOURCE
+#endif
 #include <pygobject.h>
 #include <pygtk/pygtk.h>
Index: src/_image.cpp
===================================================================
--- src/_image.cpp (revision 2706)
+++ src/_image.cpp (working copy)
@@ -5,6 +5,10 @@
 #include <cstdio>
 #include <png.h>
+#ifdef _POSIX_C_SOURCE
+#undef _POSIX_C_SOURCE
+#endif
+
 #include "Python.h" //after png.h due to setjmp bug
 #include <string>
Index: CXX/Objects.hxx
===================================================================
--- CXX/Objects.hxx (revision 2706)
+++ CXX/Objects.hxx (working copy)
@@ -6,6 +6,10 @@
 #ifndef __CXX_Objects__h
 #define __CXX_Objects__h
+#ifdef _POSIX_C_SOURCE
+#undef _POSIX_C_SOURCE
+#endif
+
 #include "Python.h"
 #include "CXX/Version.hxx"
 #include "CXX/Config.hxx"

Hi Edin,
I am not able to run the example when I have freefont installed=20
in /usr/local/share/fonts (although they are accessible by other programs, =
so=20
they are installed properly as far as X is concerned), but if I copy the=20
ttf's to the fonts directory in matplotlib's source, and then python setup.=
py=20
install, I am able to run your example, and have attached the resulting png=
=2E=20
Note the line is missing in the 3/2 fraction.
Darren
On Monday 21 August 2006 14:25, you wrote:
> Hmm, it looks like mpl is using the old mathtext which doesn't support
> \frac (mathtext.py) not mathtext2.py. Are you sure you put the
> following
>
> mathtext2: True # Needed to enable the new mathtext
>
> line in your rc file. mathtext2 is disabled by default.
>
> Hopefully I'll try tomorrow the SVN version on a Linux box.
>
> Thanks,
> Edin
>
> On 8/21/06, Darren Dale <dd...@co...> wrote:
> > Lets take this offlist for now.
> >
> > I just updated from svn, and tried running mathtext2_demo.py. I get the
> > following error:
> >
> > python mathtext2_demo.py
> > Traceback (most recent call last):
> > File "mathtext2_demo.py", line 40, in ?
> > savefig('mathtext_demo.png')
> > File "/usr/lib64/python2.4/site-packages/matplotlib/pylab.py", line
> > 811, in savefig
> > return fig.savefig(*args, **kwargs)
> > File "/usr/lib64/python2.4/site-packages/matplotlib/figure.py", line
> > 671, in savefig
> > self.canvas.print_figure(*args, **kwargs)
> >
> > File
> > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkagg.=
py
> >", line 113, in print_figure
> > orientation, **kwargs)
> >
> > File
> > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_agg.py",
> > line 454, in print_figure
> > self.draw()
> >
> > File
> > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_agg.py",
> > line 391, in draw
> > self.figure.draw(renderer)
> > File "/usr/lib64/python2.4/site-packages/matplotlib/figure.py", line
> > 534, in draw
> > for a in self.axes: a.draw(renderer)
> > File "/usr/lib64/python2.4/site-packages/matplotlib/axes.py", line
> > 1057, in draw
> > a.draw(renderer)
> > File "/usr/lib64/python2.4/site-packages/matplotlib/text.py", line 33=
9,
> > in draw
> > bbox, info =3D self._get_layout(renderer)
> > File "/usr/lib64/python2.4/site-packages/matplotlib/text.py", line 18=
6,
> > in _get_layout
> > w,h =3D renderer.get_text_width_height(
> >
> > File
> > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_agg.py",
> > line 244, in get_text_width_height
> > width, height, fonts =3D math_parse_s_ft2font(
> > File "/usr/lib64/python2.4/site-packages/matplotlib/mathtext.py", line
> > 1579, in __call__
> > handler.expr.set_size_info(fontsize, dpi)
> > File "/usr/lib64/python2.4/site-packages/matplotlib/mathtext.py", line
> > 1195, in set_size_info
> > self.elements[0].set_size_info(self._scale*fontsize, dpi)
> > File "/usr/lib64/python2.4/site-packages/matplotlib/mathtext.py", line
> > 1107, in set_size_info
> > self.metrics =3D Element.fonts.get_metrics(
> > File "/usr/lib64/python2.4/site-packages/matplotlib/mathtext.py", line
> > 593, in get_metrics
> > cmfont, metrics, glyph, offset =3D \
> > File "/usr/lib64/python2.4/site-packages/matplotlib/mathtext.py", line
> > 613, in _get_info
> > raise ValueError('unrecognized symbol "%s"' % sym)
> > ValueError: unrecognized symbol "\frac3"
> >
> > On Monday 21 August 2006 06:33, you wrote:
> > > On 8/21/06, Edin Salkovi=C4=87 <edi...@gm...> wrote:
> > > > If anyone is having problems with finding unicode fonts, check the
> > > > FreeFonts (FreeSerif is the one that has the most characters in it):
> > > > http://download.savannah.gnu.org/releases/freefont/
> > > > http://download.savannah.gnu.org/releases/freefont/freefont-ttf-200=
60
> > > >126. tar.gz
> > > >
> > > > The only currently supported fonts are True/OpenType.
> > >
> > > Oops. I haven't had updated the _mathtext_data.py file.
> > >
> > > Darren can you check if now everything works properly (even with pfb
> > > fonts)?
> > >
> > > It turns out that mpl now ships with the BaKoMa fonts in the mpl-data
> > > dir, so I though that putting the unicode fonts there would be fine.
> > > I'll see what I can do regarding integrating mathtext2 with the
> > > current font manager.
> > > ---------------------------------------------------------------------=
=2D-
> > >-- Using Tomcat but need to do more? Need to support web services,
> > > security? Get stuff done quickly with pre-integrated technology to ma=
ke
> > > your job easier Download IBM WebSphere Application Server v.1.0.1 bas=
ed
> > > on Apache Geronimo
> > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&d=
at=3D12164
> > >2 _______________________________________________
> > > Matplotlib-devel mailing list
> > > Mat...@li...
> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> > --
> > Darren S. Dale, Ph.D.
> > Cornell High Energy Synchrotron Source
> > Cornell University
> > 200L Wilson Lab
> > Rt. 366 & Pine Tree Road
> > Ithaca, NY 14853
> >
> > dd...@co...
> > office: (607) 255-3819
> > fax: (607) 255-9001
=2D-=20
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dd...@co...
office: (607) 255-3819
fax: (607) 255-9001

"John Hunter" <jd...@gm...> writes:
> Hi all -- John H here under a different email.... I'm on vacation so
> I'll probably be out of touch for a week but just dashed into a
> cyber-cafe and couldn't resist jumping in. 
[It seems that you only sent the email to me, but it looks like it is
meant for the list, so I re-sent it.]
> For those of us on the beach in Michican w/o read access to a TeX
> interpreter, perhaps you could describe what is different or broken.
This works and produces "xyz" in a Roman font:
 In [8]:rcParams['text.usetex'] = True 
 In [9]:text(0,0,r'$\rm xyz$')
 Out[9]:<matplotlib.text.Text instance at 0x1729be90>
This fails with an exception:
 In [10]:rcParams['text.usetex'] = False
 In [11]:text(0,0,r'$\rm xyz$')
 ---------------------------------------------------------------------------
 exceptions.ValueError Traceback (most recent call last)
 /Users/jks/<ipython console> 
[...]
 --> 613 raise ValueError('unrecognized symbol "%s"' % sym)
 614 
 615 #print sym, basename, num
 ValueError: unrecognized symbol "\rm"
In TeX \rm and friends set the font in the current scope. Mathtext
seems to only recognize \rm with an argument in braces, e.g. \rm{xyz}.
> The only "fresh rewrite" I'd be happy to consider is one that
> translated Knuth's algorithm for parsing mathematical expressions
> more or less verbatim.
That's a pretty tall order (as I'm sure you know). Just for fun, go to
http://latex.olympus.het.brown.edu/ and search for the word
"obfuscated".
-- 
Jouni

Hi all -- John H here under a different email.... I'm on vacation so
I'll probably be out of touch for a week but just dashed into a
cyber-cafe and couldn't resist jumping in. If mathtext_demo and TeX
parse or layout that expression differently, it's a bug and should be
fixed. We are trying to follow the TeX conventions to the best of our
ability, and won't consciously choose to do something differently
within our limits.
For those of us on the beach in Michican w/o read access to a TeX
interpreter, perhaps you could describe what is different or broken.
Edin, as for your comment about not understanding the parser, I
understand but consider this. If you don't understand the parser and
why it has the complexity it does, it is pretty unlikely you'll be
able to "roll your own" equivalent functionality. As Darren noted,
it's worth your energy, if only for your own education, to understand
how parsers work, and pyparsing is about the easiest parser I've ever
used. Start with a toy example from the pyparsing web page, and work
your way up. The author is very responsive to questions and helped me
develop and optimize the TeX grammar.
The only "fresh rewrite" I'd be happy to consider is one that
translated Knuth's algorithm for parsing mathematical expressions more
or less verbatim. I believe something like this exist in the
javascript math layout engine, which Robert is looking into. But my
preference at this point in terms of productivity is to fix what's
broken with the current implementation.
net mavens please excuse my top posting -- I'm like a seal out of =20
water here!
Cheers!
JDH
On 8/21/06, Jouni K Seppanen <jk...@ik...> wrote:
> Darren Dale <dd...@co...> writes:
>
> > On Sunday 20 August 2006 10:25 am, Edin Salkovi=C4=87 wrote:
> >> Also, I thought that the author of the current code base did some
> >> design mistakes at the begining. And, being a developer newbie,
> >> it's a lot easier to start things from scratch, than make fixes to
> >> old stuff you don't understand well.
> >
> > Just a general comment. Eric Raymond observed in The Cathedral and
> > the Bazaar that "Good programmers know what to write. Great ones
> > know what to rewrite (and reuse)."
>
> See also: http://www.joelonsoftware.com/articles/fog0000000069.html
>
> >> The point is that, i.e. \cal sets the current fontface to "cal",
> >> and the change is propagated till the end of the current scope (or
> >> untill it hits \rm, for example). Old mathtext applies it only to
> >> the first item after the command.
> >
> > What does this have to do with real TeX? Maybe you could post an
> > example. It is possibly just an mpl bug that needs to be addressed.
>
> Run the attached file through LaTeX to see what he means. Does
> Matplotlib attempt to replicate some subset of (La)TeX syntax exactly,
> or is it just a "TeX-like" syntax?
>
> --
> Jouni
>
>
>
> ----------------------------------------------------------------------=20=
> ---
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?=20
> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>

> This is a bit off topic, but I thought that matplotlib 0.87.4 and
> numpy 1.0b2 didn't work together. At least they don't for me; I have
> these installed on my computer (FC5) but when I set numerix to numpy
> in matplotlibrc, I get the output
> 
Andrew made the backport for Ubuntu systems. Matplotlib stopped working
with numpy due to some functions that were re-arranged in the code. The
fix is simple if you know what changed in the beta versions of numpy.
Best,
Paulo

On 8/21/06, Darren Dale <dd...@co...> wrote:
>
> On Monday 21 August 2006 13:56, Paulo Jose da Silva e Silva wrote:
> > Hello,
> >
> > I am using numpy 1.0b2 + matplotlib 0.87.4 from Andrew Straw repository
> > for Ubuntu (http://debs.astraw.com/).
> I can confirm the strange behavior with the most up-to-date svn versions
> of
> matplotlib and numpy.
This is a bit off topic, but I thought that matplotlib 0.87.4 and numpy
1.0b2 didn't work together. At least they don't for me; I have these
installed on my computer (FC5) but when I set numerix to numpy in
matplotlibrc, I get the output
 File "/usr/lib/python2.4/site-packages/matplotlib/_transforms.py", line 1,
in ?
 import sys, numerix
 File "/usr/lib/python2.4/site-packages/matplotlib/numerix/__init__.py",
line 74, in ?
 Matrix = matrix
NameError: name 'matrix' is not defined

In RendererPS:draw_unicode(), using unicode strings, " ", "-" (and 
others) are converted into /.notdef in ps-output.
Does anyone have suggestions or comments?
Best regards,
Uffe Damgaard Pedersen

On Monday 21 August 2006 13:56, Paulo Jose da Silva e Silva wrote:
> Hello,
>
> I am using numpy 1.0b2 + matplotlib 0.87.4 from Andrew Straw repository
> for Ubuntu (http://debs.astraw.com/).
>
> I am playing with some images to present the Theorem of Best
> Approximation associated to SVD to my students. I have computed a small
> approximated image and I want to plot it using imshow from matplotlib,
> but this command presenting a weird behavior with some weird spots in
> brigh regions.
>
> If I convert the array to a Numeric array and show it with the view
> command from NumTut package (the Numeric tutorial) the picture shows
> correctly.
>
> Did I find a bug?
I can confirm the strange behavior with the most up-to-date svn versions of 
matplotlib and numpy.

Thanks all for the tips,
Darren, that's exactly what I had in mind - mathtext should copy the
syntax of (La)TeX to a tollerable extent (without those dirty macros),
so at least the high level TeX constructs behave the same.
This should allow users to plot everyday plots easily with mathtext,
and when they want a publication ready EPS (perhaps one day mathtext
will be good enough for it), they'll just add the option usetex, with
no other code change.
I think it's easier to stick with plain TeX's syntax because it's very
well documented.
Cheers,
Edin
On 8/21/06, Darren Dale <dd...@co...> wrote:
> I think what he meant to say was that old mathtext didnt behave the way TeX
> does, is that correct Edin? My feeling is that mpl should replicate the
> (La)TeX syntax exactly. Imagine the confusion if mathtext gives one result,
> and usetex gives another.
>

Hello,
I am using numpy 1.0b2 + matplotlib 0.87.4 from Andrew Straw repository
for Ubuntu (http://debs.astraw.com/). 
I am playing with some images to present the Theorem of Best
Approximation associated to SVD to my students. I have computed a small
approximated image and I want to plot it using imshow from matplotlib,
but this command presenting a weird behavior with some weird spots in
brigh regions. 
If I convert the array to a Numeric array and show it with the view
command from NumTut package (the Numeric tutorial) the picture shows
correctly.
Did I find a bug?
To see what I mean, you can download the following small data file
(saved with "tofile" in a i386 systems, it may not work in different
architectures).
http://www.ime.usp.br/~pjssilva/spot
Now run the following script (you need matplotlib, numpy, Numeric and
NumTut packages):
-- script --
import pylab, numpy, Numeric
from NumTut import view
win = numpy.fromfile('spot').reshape((50,50,3))
pylab.imshow(win)
pylab.show()
view(Numeric.array(win))
raw_input('Press enter to finish')
-- end script --
You should see two big green spots when the image is presented using
matplotlib.
Best,
Paulo
Obs: I am not 

On Monday 21 August 2006 02:27, Jouni K Seppanen wrote:
> Darren Dale <dd...@co...> writes:
> > On Sunday 20 August 2006 10:25 am, Edin Salkovi=C4=87 wrote:
> >> Also, I thought that the author of the current code base did some
> >> design mistakes at the begining. And, being a developer newbie,
> >> it's a lot easier to start things from scratch, than make fixes to
> >> old stuff you don't understand well.
> >
> > Just a general comment. Eric Raymond observed in The Cathedral and
> > the Bazaar that "Good programmers know what to write. Great ones
> > know what to rewrite (and reuse)."
>
> See also: http://www.joelonsoftware.com/articles/fog0000000069.html
>
> >> The point is that, i.e. \cal sets the current fontface to "cal",
> >> and the change is propagated till the end of the current scope (or
> >> untill it hits \rm, for example). Old mathtext applies it only to
> >> the first item after the command.
> >
> > What does this have to do with real TeX? Maybe you could post an
> > example. It is possibly just an mpl bug that needs to be addressed.
>
> Run the attached file through LaTeX to see what he means. Does
> Matplotlib attempt to replicate some subset of (La)TeX syntax exactly,
> or is it just a "TeX-like" syntax?
I think what he meant to say was that old mathtext didnt behave the way TeX=
=20
does, is that correct Edin? My feeling is that mpl should replicate the=20
(La)TeX syntax exactly. Imagine the confusion if mathtext gives one result,=
=20
and usetex gives another.=20

T24gOC8yMS8wNiwgRWRpbiBTYWxrb3ZpxIcgPGVkaW4uc2Fsa292aWNAZ21haWwuY29tPiB3cm90
ZToKPiBJZiBhbnlvbmUgaXMgaGF2aW5nIHByb2JsZW1zIHdpdGggZmluZGluZyB1bmljb2RlIGZv
bnRzLCBjaGVjayB0aGUKPiBGcmVlRm9udHMgKEZyZWVTZXJpZiBpcyB0aGUgb25lIHRoYXQgaGFz
IHRoZSBtb3N0IGNoYXJhY3RlcnMgaW4gaXQpOgo+IGh0dHA6Ly9kb3dubG9hZC5zYXZhbm5haC5n
bnUub3JnL3JlbGVhc2VzL2ZyZWVmb250Lwo+IGh0dHA6Ly9kb3dubG9hZC5zYXZhbm5haC5nbnUu
b3JnL3JlbGVhc2VzL2ZyZWVmb250L2ZyZWVmb250LXR0Zi0yMDA2MDEyNi50YXIuZ3oKPgo+IFRo
ZSBvbmx5IGN1cnJlbnRseSBzdXBwb3J0ZWQgZm9udHMgYXJlIFRydWUvT3BlblR5cGUuCgpPb3Bz
LiBJIGhhdmVuJ3QgaGFkIHVwZGF0ZWQgdGhlIF9tYXRodGV4dF9kYXRhLnB5IGZpbGUuCgpEYXJy
ZW4gY2FuIHlvdSBjaGVjayBpZiBub3cgZXZlcnl0aGluZyB3b3JrcyBwcm9wZXJseSAoZXZlbiB3
aXRoIHBmYiBmb250cyk/CgpJdCB0dXJucyBvdXQgdGhhdCBtcGwgbm93IHNoaXBzIHdpdGggdGhl
IEJhS29NYSBmb250cyBpbiB0aGUgbXBsLWRhdGEKZGlyLCBzbyBJIHRob3VnaCB0aGF0IHB1dHRp
bmcgdGhlIHVuaWNvZGUgZm9udHMgdGhlcmUgd291bGQgYmUgZmluZS4KSSdsbCBzZWUgd2hhdCBJ
IGNhbiBkbyByZWdhcmRpbmcgaW50ZWdyYXRpbmcgbWF0aHRleHQyIHdpdGggdGhlCmN1cnJlbnQg
Zm9udCBtYW5hZ2VyLgo=

QmVjYXVzZSBTb0MgaXMgZW5kaW5nLCBhbmQgdGhlIHBlb3BsZSBmcm9tIEdvb2dsZSBzYWlkIHdl
IG5lZWQgdG8KcHJvdmlkZSB0aGUgbGluayB0byB0aGUgY29kZSwgSSBkZWNpZGVkIHRvIGF0YWNo
IHRoZSBtYXRodGV4dDIucHkgY29kZQpoZXJlLiBJIGFsc28gZGVjaWRlZCB0byBhdHRhY2ggX21h
dGh0ZXh0X2RhdGEucHkgKHRoYXQgZG9lcwpcdGV4Y29tbWFuZCAtPiB1bmljb2RlIGNoYXIgdHJh
bnNsYXRpb24pLiBJIGtub3cgdGhpcyBjYW4gYmUgc2VlbiB2aWEKU0YncyBTVk4gdmlld2VyLCBi
dXQsIGp1c3QgaW4gY2FzZSBzb21ldGhpbmcgZ29lcyB3cm9uZy4uLiA7KQoKSWYgYW55b25lIGlz
IGhhdmluZyBwcm9ibGVtcyB3aXRoIGZpbmRpbmcgdW5pY29kZSBmb250cywgY2hlY2sgdGhlCkZy
ZWVGb250cyAoRnJlZVNlcmlmIGlzIHRoZSBvbmUgdGhhdCBoYXMgdGhlIG1vc3QgY2hhcmFjdGVy
cyBpbiBpdCk6Cmh0dHA6Ly9kb3dubG9hZC5zYXZhbm5haC5nbnUub3JnL3JlbGVhc2VzL2ZyZWVm
b250LwpodHRwOi8vZG93bmxvYWQuc2F2YW5uYWguZ251Lm9yZy9yZWxlYXNlcy9mcmVlZm9udC9m
cmVlZm9udC10dGYtMjAwNjAxMjYudGFyLmd6CgpUaGUgb25seSBjdXJyZW50bHkgc3VwcG9ydGVk
IGZvbnRzIGFyZSBUcnVlL09wZW5UeXBlLgoKQWxzbywgSSBiZWd1biBhZGRpbmcgc3VwcG9ydCBm
b3IgZnJhY3Rpb25zOgpcZnJhYzMyLCBcZnJhYzMgMiBub3cgd29yayAobGluZXMgYXJlIGN1cnJl
bnRseSBub3Qgd29ya2luZyBwcm9wZXJseSAtCkkgd2lsbCBuZWVkIHRvIGZpeCBzb21lIEMrKyBj
b2RlIGluIHRoZSBmdDJmb250IG1vZHVsZSkKCkl0J3MgaW4gdGhlIFNWTiAod2l0aCB0aGUgbWF0
aHRleHQyX2RlbW8ucHkgdXBkYXRlZCkuCgpDaGVlcnMsIEVkaW4KCk9uIDgvMjAvMDYsIERhcnJl
biBEYWxlIDxkZDU1QGNvcm5lbGwuZWR1PiB3cm90ZToKPiBIaSBFZGluLAo+Cj4gT24gU3VuZGF5
IDIwIEF1Z3VzdCAyMDA2IDEwOjIxIGFtLCBFZGluIFNhbGtvdmnEhyB3cm90ZToKPiA+IFRoZSBT
b0MgZGVhZGxpbmUgKGZvciBjb2RlKSBpcyB0b21tb3JvdyAoQXVnIDIxc3QuKSwgc28gSSBkZWNp
ZGVkIHRvIGNvbW1pdAo+ID4gd2hhdCBJIGhhdmUgZG9uZSB0aWxsIG5vdyB0byB0aGUgcmVwb3Np
dG9yeS4KPiA+Cj4gPiBKREggaXMgZ29pbmcgb24gYSB2YWNhdGlvbiBhbmQgd2lsbCBub3QgYmUg
YWJsZSB0byByZXZpZXcgaXQgZm9yIGF0Cj4gPiBsZWFzdCBhIHdlZWssCj4gPiBidXQgSSBoYWQg
dG8gY29tbWl0IGl0IGJlZm9yZSAyMXN0LiBBdWcgLSB0aGF0J3MgdGhlIFNvQyBydWxlcy4gSG9w
ZWZ1bGx5LAo+ID4gSSdsbCBiZSBhZGRpbmcgbmV3IHN0dWZmIHRoZSBuZXh0IHdlZWsgKGFuZCBh
ZnRlciksIGJ1dCB0aGF0IGRvZXNuJ3QKPiA+IGNvdW50IGFzIHBhcnQgb2YgU29DIGFueW1vcmUu
Li4KPiA+Cj4gPiBTaW5jZSB0aGlzIGlzIG15IGZpcnN0IGNvbW1pdCwgY2FuIGFueW9uZSBwbGVh
c2UgdGVzdCBpdC4gSSB0ZXN0ZWQgaXQKPiA+IG9ubHkgb24gbXkgd2luZG93cyBib3guCj4gPgo+
ID4gSSBjaGFuZ2VkCj4gPiBfX2luaXRfXy5weSwKPiA+IG1hdGh0ZXh0LnB5Cj4gPiBDSEFOR0VM
T0cKPiA+Cj4gPiBJIGFkZGVkCj4gPiBtYXRodGV4dDIucHkKPiA+IG1hdGh0ZXh0Ml9kZW1vLnB5
Cj4gPgo+ID4gQW55b25lIHdobyB3YW50cyB0byB0ZXN0IHRoZSBuZXcgbWF0aHRleHQyIGhhcyB0
byBhZGQgdGhlIGZvbGxvd2luZyBsaW5lKHMpCj4gPiB0byB0aGUgbWF0cGxvdGxpYnJjIChtYXRo
dGV4dDIgaXMgZGlzYWJsZWQgYnkgZGVmYXVsdCk6Cj4gPgo+ID4gbWF0aHRleHQyOiAgIFRydWUg
ICAgICAgICAgICAjIE5lZWRlZCB0byBlbmFibGUgdGhlIG5ldyBtYXRodGV4dAo+ID4KPiA+ICMg
Rm9udCBsaW5lcywgZmVlbCBmcmVlIHRvIGNoYW5nZSBvciB1bmNvbW1lbnQgKEJhS29NYSBpcyB1
c2VkIGJ5IGRlZmF1bHQpCj4gPiBtYXRodGV4dC5ybSAgICAgOiAgIEZyZWVTZXJpZi50dGYKPiA+
IG1hdGh0ZXh0Lml0ICAgICA6ICAgRnJlZVNlcmlmSXRhbGljLnR0ZiAgICAgIyBUZXh0IGl0YWxp
Ywo+ID4gbWF0aHRleHQudHQgICAgIDogICBGcmVlTW9uby50dGYgICAgIyBUeXBld3JpdGVyICht
b25vc3BhY2VkKQo+ID4gbWF0aHRleHQubWl0ICAgIDogICBGcmVlU2VyaWZJdGFsaWMudHRmICAg
ICAjIE1hdGggaXRhbGljCj4gPiBtYXRodGV4dC5jYWwgICAgOiAgIEZyZWVTYW5zT2JsaXF1ZS50
dGYgIyBDYWxpZ3JhcGhpYwo+ID4gbWF0aHRleHQubm9uYXNjaWk6ICBGcmVlU2VyaWYudHRmICMg
VXNlZCBmb3IgXHN1bSwgXGluZnR5IGV0Yy4KPiA+Cj4gPiBUaGUgRnJlZUZvbnQgZm9udHMgKG9y
IGFueSBvdGhlciBmb3IgdGhhdCBtYXR0ZXIpIGhhdmUgdG8gYmUgZG93bmxvYWRlZCBhbmQKPiA+
IHB1dCBpbnRvIHRoZSBtcGwtZGF0YSBkaXIuIFRoZSBkZWZhdWx0IHNldHRpbmdzdXNlIHRoZSBj
dXJyZW50IGJha29tYQo+ID4gZm9udHMsIGFuZCB0aGV5IHBsYXkgcHJldHR5IHdlbGwgd2l0aCBG
cmVlU2VyaWYudHRmIGFzIHRoZSBub25hc2NpaQo+ID4gKHVuaWNvZGUpIGZvbnQuCj4gPgo+ID4g
c28gSSByZWNvbW1lbmQgeW91IGp1c3QgcHV0IHRoZSBsaW5lCj4gPiBtYXRodGV4dC5ub25hc2Np
aTogIEZyZWVTZXJpZi50dGYKPiA+Cj4gPiBhbmQgY29tbWVudCBvdXQgdGhlIHJlc3QgKGV4cGVy
aW1lbnQgYSBsaXR0bGUgd2l0aCBmb250cykuCj4gPgo+ID4gVG9uaWdodCBJIHBsYW4gdG8gYWRk
IHN1cHBvcnQgZm9yIGZyYWN0aW9ucy4gQmV3YXJlIHRoYXQgdGhlIG9ubHkKPiA+IHN1cHBvcnRl
ZCBiYWNrZW5kIGZvciBub3cgaXMgQWdnLgo+ID4KPiA+IG1hdGh0ZXh0Ml9kZW1vLnB5IGlzIGF0
dGFjaGVkCj4KPiBJIGp1c3QgdXBkYXRlZCBteSBzdm4gcmVwb3NpdG9yeSwgYWRkZWQgdGhlIGxp
bmVzIHlvdSBpbmRpY2F0ZWQgdG8gbXkgcmMgZmlsZSwKPiBidXQgd2hlbiBJIHJ1biB0aGUgZXhh
bXBsZSwgbXBsIGNhbid0IGZpbmQgdGhlIGZyZWVmb250cyB0aGF0IEkgYWxyZWFkeSBoYXZlCj4g
aW5zdGFsbGVkIG9uIG15IHN5c3RlbS4gVGhlIGZyZWVmb250cyBJIGhhdmUgaW5zdGFsbGVkIGFy
ZSBub3QgdHRmLCBidXQgcGZiLgo+IFdoZXJlIHNob3VsZCB3ZSBkb3dubG9hZCBmcm9tPyBmdHA6
Ly9mdHAuY3MudW1uLmVkdS9wdWIvZ2ltcC9wdWIvZ2ltcC9mb250cywKPiBmb3IgZXhhbXBsZT8g
SSBkb250IHRoaW5rIHRob3NlIGFyZSB3aGF0IEkgYW0gbG9va2luZyBmb3IuIERvIHRoZXkgcmVh
bGx5Cj4gbmVlZCB0byBnbyBpbiBtcGwtZGlyPyBJdCB3b3VsZCBiZSBtb3JlIGFwcHJvcHJpYXRl
IGlmIHRoZXkgY291bGQgYmUKPiBpbnN0YWxsZWQgc29tZXdoZXJlIGxpa2UgL3Vzci9zaGFyZS9m
b250cy4KPgo+Cg==

Darren Dale <dd...@co...> writes:
> On Sunday 20 August 2006 10:25 am, Edin Salković wrote:
>> Also, I thought that the author of the current code base did some
>> design mistakes at the begining. And, being a developer newbie,
>> it's a lot easier to start things from scratch, than make fixes to
>> old stuff you don't understand well.
>
> Just a general comment. Eric Raymond observed in The Cathedral and
> the Bazaar that "Good programmers know what to write. Great ones
> know what to rewrite (and reuse)."
See also: http://www.joelonsoftware.com/articles/fog0000000069.html
>> The point is that, i.e. \cal sets the current fontface to "cal",
>> and the change is propagated till the end of the current scope (or
>> untill it hits \rm, for example). Old mathtext applies it only to
>> the first item after the command.
>
> What does this have to do with real TeX? Maybe you could post an
> example. It is possibly just an mpl bug that needs to be addressed.
Run the attached file through LaTeX to see what he means. Does
Matplotlib attempt to replicate some subset of (La)TeX syntax exactly,
or is it just a "TeX-like" syntax?
-- 
Jouni

On Sunday 20 August 2006 10:25 am, Edin Salkovi=C4=87 wrote:
> Here are the reasons for rewriting mathtext2 that I can come up with:
>
> * One of the reasons I started the complete rewrite of the parser is that
> I'm a newbie at parsing, and I wanted to try it out a bit. I didn't
> understand why was it so difficult to parse TeX (or anything a little bit
> complicated for that matter). Well, now I know ;)
>
> * The other reason was that I didn't understand fully the current parsing
> code, or more precisely, the part when what's interpreted get's rendered.
> And I'm not talking about glyphs, but about the complex constructs
> (scripts, frac's etc.)
>
> * The third reason was that I can now try out in pararel the new and the
> old code. Also, because I'm not touching the PS and SVG backends for now =
we
> can have the following code in the current mathtext:
>
> if rcParams[some_parameter]:
> from matplotlib.mathtext2 import math_parse_s_ft2font
> else:
> math_parse_s_ft2font =3D math_parse_s_ft2font_common('BMP')
> math_parse_s_ft2font_svg =3D math_parse_s_ft2font_common('SVG')
> math_parse_s_ps =3D math_parse_s_ft2font_common('PS')
> math_parse_s_pdf =3D math_parse_s_ft2font_common('PDF')
>
> Also, I thought that the author of the current code base did some design
> mistakes at the begining. And, being a developer newbie, it's a lot easier
> to start things from scratch, than make fixes to old stuff you don't
> understand well.
Just a general comment. Eric Raymond observed in The Cathedral and the Baza=
ar=20
that "Good programmers know what to write. Great ones know what to rewrite=
=20
(and reuse)." In the future, I suggest you consider that it may be in your=
=20
own long term interest to try to understand and extend existing code instea=
d=20
of rewriting it from scratch. You'll learn quickly by being exposed to othe=
r=20
people's ideas and techniques, and you will get faster results since you=20
won't be reinventing the wheel.
> As for the mathtext_demo.py part, even real TeX can't handle it :).=20
If TeX isn't yielding the result you expect, then you were expecting the wr=
ong=20
result.
> The point is that, i.e. \cal sets the current fontface to "cal", and the=
=20
> change is propagated till the end of the current scope (or untill it hits=
=20
> \rm, for example). Old mathtext applies it only to the first item after t=
he=20
> command.=20
What does this have to do with real TeX? Maybe you could post an example. I=
t=20
is possibly just an mpl bug that needs to be addressed.
Darren

Hi Edin,
On Sunday 20 August 2006 10:21 am, Edin Salkovi=C4=87 wrote:
> The SoC deadline (for code) is tommorow (Aug 21st.), so I decided to comm=
it
> what I have done till now to the repository.
>
> JDH is going on a vacation and will not be able to review it for at
> least a week,
> but I had to commit it before 21st. Aug - that's the SoC rules. Hopefully,
> I'll be adding new stuff the next week (and after), but that doesn't
> count as part of SoC anymore...
>
> Since this is my first commit, can anyone please test it. I tested it
> only on my windows box.
>
> I changed
> __init__.py,
> mathtext.py
> CHANGELOG
>
> I added
> mathtext2.py
> mathtext2_demo.py
>
> Anyone who wants to test the new mathtext2 has to add the following line(=
s)
> to the matplotlibrc (mathtext2 is disabled by default):
>
> mathtext2: True # Needed to enable the new mathtext
>
> # Font lines, feel free to change or uncomment (BaKoMa is used by default)
> mathtext.rm : FreeSerif.ttf
> mathtext.it : FreeSerifItalic.ttf # Text italic
> mathtext.tt : FreeMono.ttf # Typewriter (monospaced)
> mathtext.mit : FreeSerifItalic.ttf # Math italic
> mathtext.cal : FreeSansOblique.ttf # Caligraphic
> mathtext.nonascii: FreeSerif.ttf # Used for \sum, \infty etc.
>
> The FreeFont fonts (or any other for that matter) have to be downloaded a=
nd
> put into the mpl-data dir. The default settingsuse the current bakoma
> fonts, and they play pretty well with FreeSerif.ttf as the nonascii
> (unicode) font.
>
> so I recommend you just put the line
> mathtext.nonascii: FreeSerif.ttf
>
> and comment out the rest (experiment a little with fonts).
>
> Tonight I plan to add support for fractions. Beware that the only
> supported backend for now is Agg.
>
> mathtext2_demo.py is attached
I just updated my svn repository, added the lines you indicated to my rc fi=
le,=20
but when I run the example, mpl can't find the freefonts that I already hav=
e=20
installed on my system. The freefonts I have installed are not ttf, but pfb=
=2E=20
Where should we download from? ftp://ftp.cs.umn.edu/pub/gimp/pub/gimp/fonts=
,=20
for example? I dont think those are what I am looking for. Do they really=20
need to go in mpl-dir? It would be more appropriate if they could be=20
installed somewhere like /usr/share/fonts.

SGVyZSBhcmUgdGhlIHJlYXNvbnMgZm9yIHJld3JpdGluZyBtYXRodGV4dDIgdGhhdCBJIGNhbiBj
b21lIHVwIHdpdGg6CgogKiBPbmUgb2YgdGhlIHJlYXNvbnMgSSBzdGFydGVkIHRoZSBjb21wbGV0
ZSByZXdyaXRlIG9mIHRoZSBwYXJzZXIgaXMgdGhhdApJJ20gYSBuZXdiaWUgYXQgcGFyc2luZywg
YW5kIEkgd2FudGVkIHRvIHRyeSBpdCBvdXQgYSBiaXQuIEkgZGlkbid0IHVuZGVyc3RhbmQKd2h5
IHdhcyBpdCBzbyBkaWZmaWN1bHQgdG8gcGFyc2UgVGVYIChvciBhbnl0aGluZyBhIGxpdHRsZSBi
aXQgY29tcGxpY2F0ZWQKZm9yIHRoYXQgbWF0dGVyKS4gV2VsbCwgbm93IEkga25vdyA7KQoKICog
VGhlIG90aGVyIHJlYXNvbiB3YXMgdGhhdCBJIGRpZG4ndCB1bmRlcnN0YW5kIGZ1bGx5IHRoZSBj
dXJyZW50IHBhcnNpbmcKY29kZSwgb3IgbW9yZSBwcmVjaXNlbHksIHRoZSBwYXJ0IHdoZW4gd2hh
dCdzIGludGVycHJldGVkIGdldCdzIHJlbmRlcmVkLgpBbmQgSSdtIG5vdCB0YWxraW5nIGFib3V0
IGdseXBocywgYnV0IGFib3V0IHRoZSBjb21wbGV4IGNvbnN0cnVjdHMgKHNjcmlwdHMsCmZyYWMn
cyBldGMuKQoKICogVGhlIHRoaXJkIHJlYXNvbiB3YXMgdGhhdCBJIGNhbiBub3cgdHJ5IG91dCBp
biBwYXJhcmVsIHRoZSBuZXcgYW5kIHRoZSBvbGQKY29kZS4gQWxzbywgYmVjYXVzZSBJJ20gbm90
IHRvdWNoaW5nIHRoZSBQUyBhbmQgU1ZHIGJhY2tlbmRzIGZvciBub3cgd2UgY2FuCmhhdmUgdGhl
IGZvbGxvd2luZyBjb2RlIGluIHRoZSBjdXJyZW50IG1hdGh0ZXh0OgoKaWYgcmNQYXJhbXNbc29t
ZV9wYXJhbWV0ZXJdOgogICBmcm9tIG1hdHBsb3RsaWIubWF0aHRleHQyIGltcG9ydCBtYXRoX3Bh
cnNlX3NfZnQyZm9udAplbHNlOgogICBtYXRoX3BhcnNlX3NfZnQyZm9udCA9IG1hdGhfcGFyc2Vf
c19mdDJmb250X2NvbW1vbignQk1QJykKbWF0aF9wYXJzZV9zX2Z0MmZvbnRfc3ZnID0gbWF0aF9w
YXJzZV9zX2Z0MmZvbnRfY29tbW9uKCdTVkcnKQptYXRoX3BhcnNlX3NfcHMgPSBtYXRoX3BhcnNl
X3NfZnQyZm9udF9jb21tb24oJ1BTJykKbWF0aF9wYXJzZV9zX3BkZiA9IG1hdGhfcGFyc2Vfc19m
dDJmb250X2NvbW1vbignUERGJykKCkFsc28sIEkgdGhvdWdodCB0aGF0IHRoZSBhdXRob3Igb2Yg
dGhlIGN1cnJlbnQgY29kZSBiYXNlIGRpZCBzb21lIGRlc2lnbgptaXN0YWtlcyBhdCB0aGUgYmVn
aW5pbmcuIEFuZCwgYmVpbmcgYSBkZXZlbG9wZXIgbmV3YmllLCBpdCdzIGEgbG90IGVhc2llcgp0
byBzdGFydCB0aGluZ3MgZnJvbSBzY3JhdGNoLCB0aGFuIG1ha2UgZml4ZXMgdG8gb2xkIHN0dWZm
IHlvdSBkb24ndAp1bmRlcnN0YW5kIHdlbGwuCgpBcyBmb3IgdGhlIG1hdGh0ZXh0X2RlbW8ucHkg
cGFydCwgZXZlbiByZWFsIFRlWCBjYW4ndCBoYW5kbGUgaXQgOikuIFRoZSBwb2ludAppcyB0aGF0
LCBpLmUuIFxjYWwgc2V0cyB0aGUgY3VycmVudCBmb250ZmFjZSB0byAiY2FsIiwgYW5kIHRoZSBj
aGFuZ2UgaXMKcHJvcGFnYXRlZCB0aWxsIHRoZSBlbmQgb2YgdGhlIGN1cnJlbnQgc2NvcGUgKG9y
IHVudGlsbCBpdCBoaXRzIFxybSwgZm9yCmV4YW1wbGUpLiBPbGQgbWF0aHRleHQgYXBwbGllcyBp
dCBvbmx5IHRvIHRoZSBmaXJzdCBpdGVtIGFmdGVyIHRoZSBjb21tYW5kLgoKSSBwcm9taXNlIHRo
YXQgSSdsbCBwb3N0IG1vcmUgYWJvdXQgdGhlIGltcGxlbWVudGF0aW9uIGluIGEgZGF5IG9yIHR3
by4KSSdsbCBhbHNvIHBvc3Qgc2NyZWVuc2hvdHMgKFRlWC9tYXRodGV4dC9tYXRodGV4dDIgc2hv
b3RvdXQpLgoKQ2hlZXJzLApFZGluCgpPbiA4LzE4LzA2LCBKb2huIEh1bnRlciA8amRodW50ZXJA
YWNlLmJzZC51Y2hpY2Fnby5lZHU+IHdyb3RlOgo+ID4+Pj4+ICJFZGluIiA9PSBFZGluIFNhbGtv
dmnCpyA8ZWRpbi5zYWxrb3ZpY0BnbWFpbC5jb20+IHdyaXRlczoKPgo+ICAgICBFZGluPiBIaSBh
bGwsIFBsZWFzZSBKb2huLCB0YWtlIHNvbWUgdGltZSBiZWZvcmUgU2NpUHkgY29uZiB0bwo+ICAg
ICBFZGluPiBhbnN3ZXIgYXQgbGVhc3Qgc29tZSBvZiB0aGlzIHF1ZXN0aW9ucywgYmVjYXVzZSB0
aGUgU29DCj4gICAgIEVkaW4+IGRlYWRsaW5lICgyMXN0IEF1Z3VzdCkgaXMgKnZlcnkqIG5lYXIu
Cj4KPiBBbGFzLCBJIGFtIGFscmVhZHkgaGVyZSBhbmQgaGF2ZSBiZWVuIGEgbGl0dGxlIG91dCBv
ZiBlbWFpbCBjb250YWN0Cj4gd2hpbGUgdHJhdmVsaW5nLiAgU29ycnkgZm9yIHRoZSBkZWxheS4K
Pgo+ICAgICBFZGluPiAxKSBJJ20gaGF2aW5nIHNvbWUgcHJvYmxlbXMgcmVnYXJkaW5nIEZUMkZv
bnQuICBUaGUgcHJvYmxlbQo+ICAgICBFZGluPiBpcyB3aGVuIEkgaW5zdGFudGlhdGUgRlQyRm9u
dCBsaWtlOiBmb250ID0gRlQyRm9udChmaWxlbmFtZSkKPiAgICAgRWRpbj4gYW5kIHdoZW4gSSBj
YWxsIGl0J3MgbWV0aG9kIGZvbnQuc2V0X3RleHQoIlNvbWUgdGV4dCIpLCBhbmQKPiAgICAgRWRp
bj4gYWZ0ZXJ3YXJkcywgZm9udC5kcmF3X2dseXBoc190b19iaXRtYXAoKSwgdGhlIGxhdHRlciBz
aW1wbHkKPiAgICAgRWRpbj4gZGVsZXRlcyBldmVyeSBnbHlwaCB0aGF0IHdhcyBkcmF3biBiZWZv
cmUgaXQsIGFuZCBqdXN0Cj4gICAgIEVkaW4+IHBhaW50cyBpbiB0aGUgaW50ZXJuYWwgaW1hZ2Ug
YnVmZmVyIHRoZSB0ZXh0IHRoYXQgd2FzIHBhc3NlZAo+ICAgICBFZGluPiBvbiBsYXN0IGludm9j
YXRpb24gb2Ygc2V0X3RleHQgKG9yIGxvYWRfY2hhcikuCj4KPiBUaGlzIGlzIGEgZmVhdHVyZSwg
bm90IGEgYnVnIDotKSAgWW91IGNhbiBjbGVhciB0aGUgaW1hZ2UgYnVmZmVyIGlmCj4geW91IHdh
bnQgd2l0aCB0aGUgY2xlYXIgbWV0aG9kLCBhcyB3ZSBkbyBpbiB0aGUgbWF0aHRleHkgY29kZQo+
Cj4gICAgICAgICBmb3IgZm9udGZhY2UgaW4gc2VsZi5mb250cy52YWx1ZXMoKToKPiAgICAgICAg
ICAgICBmb250ZmFjZS5jbGVhcigpCj4KPiAgICAgRWRpbj4gVGhpcyBpcyBhIHBhaW4sIGJlY2F1
c2UgZHJhd19nbHlwaHNfdG9fYml0bWFwIGltcGxlbWVudHMgdGhlCj4gICAgIEVkaW4+IGxheW91
dCAod2l0aCBrZXJuaW5nIGV0Yy4pLCBidXQgaWYgb25lIHdhbnRzIHRvIHBhaW50Cj4gICAgIEVk
aW4+IHNldmVyYWwgd29yZHMgaW4gZGlmZmVyZW50IHgseSBwb3NpdGlvbnMgaW4gdGhlIHNhbWUg
aW1hZ2UKPiAgICAgRWRpbj4gYnVmZmVyLCBoZSBoYXMgdG8gZG8gdGhlIGxheW91dCBmb3IgZXZl
cnkgY2hhcmFjdGVyIGluIGV2ZXJ5Cj4gICAgIEVkaW4+IHdvcmQgbWFudWFsbHkgdmlhIGRyYXdf
Z2x5cGhfdG9fYml0bWFwKHgsIHksIGdseXBoKSAobGlrZQo+ICAgICBFZGluPiB5b3UgZGlkIHdp
dGggdGhlIEJhS29NYSBmb250cyBpbiBtYXRodGV4dCkuCj4KPiAgICAgRWRpbj4gV2h5IGhhc24n
dCBkcmF3X2dseXBoc190b19iaXRtYXAgYmVlbiBpbXBsZW1lbnRlZCBzbyB0aGF0IGl0Cj4gICAg
IEVkaW4+IHRha2VzIHgsIHkgYXMgYXJndW1lbnRzIChkcmF3X2dseXBoc190b19iaXRtYXAoeCwg
eSkpIGFuZAo+ICAgICBFZGluPiBsZWF2ZXMgdGhlIGltYWdlIGJ1ZmZlciBpbnRhY3QgKGFzIGRv
ZXMKPiAgICAgRWRpbj4gZHJhd19nbHlwaF90b19iaXRtYXApPwo+Cj4gWW91IGNhbiBhZGQgb3B0
aW9uYWwgeCBhbmQgeSBhcmdzIHRvIGRyYXdfZ2x5cGhzX3RvX2JpdG1hcCBpZiB5b3UgbmVlZAo+
IHRoZW0uICBKdXN0IG1ha2Ugc3VyZSBhbnkgY2hhbmdlcyB5b3UgbWFrZSBwYXNzCj4gZXhhbXBs
ZXMvYmFja2VuZF9kcml2ZXIucHkgYW5kIHVuaXQvbWVtbGVha19oYXdhaWkzLnB5Cj4KPiAgICAg
RWRpbj4gMikgQXMgSSBoYXZlIHNhaWQgYmVmb3JlLCBJIGhhdmUgc3RhcnRlZCB0aGUgY29tcGxl
dGUKPiAgICAgRWRpbj4gcmV3cml0ZSBvZiBtYXRodGV4dCAodGhlIHBhcnNpbmcgc3R1ZmYgZXRj
LikuIEkgaGF2ZQo+ICAgICBFZGluPiBjb21wbGV0ZWx5IHJlbW92ZWQgdGhlIGRlcGVuZGVuY3kg
b24gcHlwYXJzaW5nIChwbGVhc2UgZG9uJ3QKPiAgICAgRWRpbj4geWVsbCBhdCBtZSA6KSwgYW5k
IEkgd2FzIHdvbmRlcmluZyBhYm91dCBob3cgbXVjaCBvZiBUZVgKPgo+IE9LLCBJIHdvbid0IHll
bGwuICBRdWlldGx5IHNjb2xkIG1heWJlIDotKQo+Cj4gSSBhbSBza2VwdGljYWwgb2YgeW91ciAt
LSBvciBhbnlvbmUncyBleGNlcHQgUm9iZXJ0J3MgLS0gYWJpbGl0eSB0bwo+IHBhcnNlIFRlWCBt
YXRoZW1hdGljYWwgZXhwcmVzc2lvbnMgdy9vIGEgdHJ1ZSByZWN1cnNpdmUgZGVzY2VudAo+IHBh
cnNlci4gIEkgdG9vayBhIGxvb2sgYXQgeW91ciBjb2RlIGJ1dCB3L28gYW55IHJ1bm5pbmcgZXhh
bXBsZXMgSQo+IGNvdWxkIG5vdCB0ZXN0IGl0LiAgRnJvbSByZWFkaW5nIGl0LCBJIGRvIG5vdCB0
aGluayBpdCB3aWxsIGJlIGFibGUgdG8KPiBoYW5kbGUgdGhlIGRlZXBseSByZWN1cnNpdmUgc3Ry
dWN0dXJlcyB0aGF0IGFyZSBjdXJyZW50bHkgc3VwcG9ydGVkIGJ5Cj4gdGhlIGV4aXN0aW5nLCB3
b3JraW5nIHBhcnNlci4gIENhbiB5b3UgaGFuZGxlIHJlY3Vyc2l2ZWx5IG5lc3RlZAo+IHN1cGVy
L3N1YiBzY3JpcHRzPyAgQ2FuIGl0IHBhcnNlIHRoaXMKPgo+ICAgdGV4ID0gcickXGNhbHtSfVxw
cm9kX3tpPVxhbHBoYV97aSsxfX1eXGluZnR5IGFfaVxybXtzaW59KDIgXHBpIGYgeF9pKSQnCj4K
Pgo+IElmIHNvLCBJIGFwb2xvZ2l6ZSBmb3IgbXkgc2tlcHRpY2lzbSwgYnV0IG15IHdvcmtpbmcg
YXNzdW1wdGlvbiBpcyB5b3UKPiB3aWxsIG5lZWQgYSBwcm9wZXIgcGFyc2VyIHRvIHBhcnNlIHRl
eCBhbmQgc3RyaW5nIG1ldGhvZHMgYXJlbid0IGdvaW5nCj4gdG8gZ2V0IHlvdSB0aGVyZS4gIFdo
YXQgSSByZWFsbHkgbmVlZCB0byBzZWUgYmVmb3JlIGV2ZW4gY29uc2lkZXJpbmcgYQo+IHN5c3Rl
bSB0aGF0IHJlcGxhY2VzIHRoZSB3b3JraW5nIHN5c3RlbSBpcyBhbiBhcmd1bWVudCBhYm91dCB3
aHkgaXQKPiBuZWVkcyB0byBiZSByZXBsYWNlZCwgYW5kIG1vcmUgaW1wb3J0YW50bHksIGNvZGUg
dGhhdCBjYW4gZG8KPiBldmVyeXRoaW5nIHRoZSBvbGQgY29kZSBjYW4gZG8sIHN1Y2ggYXMgcmVu
ZGVyIHRoZSBtYXRodGV4dF9kZW1vLnB5Cj4gZXhhbXBsZT8KPgo+ICAgICBFZGluPiBzaG91bGQg
bWF0aHRleHQgc3VwcG9ydC4gSSdtIG5vdCB0YWxraW5nIGFib3V0IHN1cHBvcnQgZm9yCj4gICAg
IEVkaW4+IFxmcmFjLCBcYWJvdmUsIFxjaG9vc2UgKHdoaWNoIEkgcGxhbiB0byBhZGQgb25lIGJ5
IG9uZSkKPiAgICAgRWRpbj4gZXRjLiwgYnV0IGFib3V0IG1vcmUgZ2VuZXJhbCB0aGluZ3MgLSBt
YWNyb3MgKFxkZWYgZXRjLikuIEkKPgo+IFxhYm92ZSwgXGZyYWMgYW5kIFxzcXJ0IHllcywgXGRl
ZiBuby4gIE90aGVycyBJJ20gbm90IHN1cmUgYWJvdXQuCj4KPiAgICAgRWRpbj4gd2FzIHRoaW5r
aW5nIG9mIGp1c3Qgc2ltdWxhdGluZyB0aGVtLCBhdCBsZWFzdCB0byBhCj4gICAgIEVkaW4+IHRv
bGVyYWJsZSBleHRlbnQsIHZpYSBub3Rpb24gb2YgYW4gZW52aXJvbWVudC4gIEV4YW1wbGU6IFxy
bQo+ICAgICBFZGluPiBpbiBwbGFpbiBUZVggc2V0cyB0aGUgY3VycmVudCBmb250IHRvIHJvbWFu
ICh1bnRpbCB0aGUgZW5kCj4gICAgIEVkaW4+IG9mIHRoZSBjdXJyZW50IHNjb3BlIC0gJ3RpbGwg
aXQgaGl0cyAifSIpLiAgSW1wbGVtZW50YXRpb246Cj4gICAgIEVkaW4+IEF0IHJlbmRlciB0aW1l
LCB3aGVuIHRoZSBwYXJzZXIgaGl0cyAiXHJtIiwgaXQgZG9lcyB0aGUKPiAgICAgRWRpbj4gZm9s
b3dpbmc6IGVudlsiZmFjZXR5cGUiXSA9ICJybSIsIHdoZXJlIGVudiBpcyB0aGUKPiAgICAgRWRp
bj4gZW52aXJvbm1lbnQgaW4gdGhlIGN1cnJlbnQgc2NvcGUuCj4KPiBDYW4gd2UgdXNlIGNsYXNz
ZXMgaGVyZSByYXRoZXIgdGhhbiBkaWN0aW9uYXJpZXM/ICBTeW50YWN0aWNhbGx5LCBJCj4gcHJl
ZmVyIGVudi5mYWNldHlwZSA9ICJybSIgdG8gdGhlIGRpY3Rpb25hcnkgc3ludGF4Lgo+Cj4gICAg
IEVkaW4+IEFsc28sIEkgYW0gcGxhbmluZyB0byBjcmVhdGUgYSBzZXBhcmF0ZSBjbGFzcyBmb3Ig
ZXZlcnkgbmV3Cj4gICAgIEVkaW4+IGxheW91dCBpdGVtIHRoYXQgZ2V0cyBpbXBsZW1lbnRlZC4g
IEV4YW1wbGU6Cj4gICAgIEVkaW4+IHN1Yi9zdXBlcnNjcmlwdGVkIGl0ZW0gKG51Y2xldXNfc3Vi
XnN1cCkgZ2V0cyB0cmFuc2xhdGVkIHRvCj4gICAgIEVkaW4+IGFuIGluc3RhbmNlIG9mIGNsYXNz
IFNjcmlwdGVkIHRoYXQgaGFzIHRoZSBhdHRyaWJ1dGVzCj4gICAgIEVkaW4+IG51Y2xldXMsIHN1
cGVyc2NyaXB0IGFuZCBzdWJzY3JpcHQuCj4KPiAgICAgRWRpbj4gMykgSSB3YXMgdGhpbmtpbmcg
b2YgZm9jdXNpbmcgb24ganVzdCB0aGUgQWdnIGJhY2tlbmQgZm9yCj4gICAgIEVkaW4+IG5vdyAo
dGhhdCBpcyB0aWxsJyB0aGUgZGVhZGxpbmUpLiBJcyB0aGlzIE9LPyAgNCkgSSB0aGluawo+ICAg
ICBFZGluPiB0aGF0IHdlIHNob3VsZCBtb3ZlIHRoZSBqb2Igb2YgbWF0aF9wYXJzZV9zX2Z0MmZv
bnQsCj4gICAgIEVkaW4+IG1hdGhfcGFyc2Vfc19mdDJmb250X3N2ZywgYW5kIG1hdGhfcGFyc2Vf
c19wcyBldGMuICB0byB0aGUKPiAgICAgRWRpbj4gY29ycmVzcG9uZGluZyBiYWNrZW5kcywgYW5k
IHRoYXQgc29tZSBnZW5lcmFsIGZ1bmN0aW9uIGxpa2U6Cj4gICAgIEVkaW4+IG1hdGhfcGFyc2Vf
cyh4LCB5LCBzLCBwcm9wLCBhbmdsZSkgc2hvdWxkIGJlIGltcGxlbWVudGVkCj4gICAgIEVkaW4+
IGRpcmVjdGx5IGluIG1hdGh0ZXh0LnB5IChwZXJoYXBzIGV2ZW4gd2l0aG91dCB0aGUgImFuZ2xl
Igo+ICAgICBFZGluPiBwYXJhbWV0ZXIpIHNvIHRoYXQgaXQgcmV0dXJucyBhIGxpc3Qgb2YgdGhl
IGZvbGxvd2luZyB0eXBlOgo+ICAgICBFZGluPiBbKHgxLCB5MSwgczEsIHByb3AxLCBhbmdsZTEp
LCAuLi4gLCAoeG4sIHluLCBzbiwgcHJvcG4sCj4gICAgIEVkaW4+IGFuZ2xlbildCj4KPiBJIGNh
bid0IGFkZHJlc3MgdGhlc2UgcXVlc3Rpb25zIHVudGlsIEkgdW5kZXJzdGFuZCB3aHkgeW91IGFy
ZSB0cnlpbmcKPiB0byByZXdyaXRlLCByYXRoZXIgdGhhbiBleHRlbmQgb3IgZml4LCB0aGUgZXhp
c3RpbmcgY29kZS4gIFRoZSBhZ2cgYW5kCj4gdGhlIHBvc3RzY3JpcHQgYmFja2VuZHMgd29yayB3
aXRoIHRoZSBleGlzdGluZyBmcmFtZW93b3JrLiAgQXMgZmFyIGFzCj4gSSBjYW4gc2VlLCB5b3Ug
Y291bGQgZml4IHRoZSBsYXlvdXQgZW5naW5lIGluIHRoZSBleGlzdGluZyBmcmFtZXdvcmsKPiBh
bmQgbm90IGhhdmUgdG8gdGhpbmsgdG9vIG11Y2ggYWJvdXQgYmFja2VuZHMsIHdpdGggdGhlIGV4
Y2VwdGlvbiB0aGF0Cj4geW91IG5lZWQgYSBiYXNpYyBiYWNrZW5kIGxpbmUgZHJhd2luZyBBUEkg
Zm9yIHRoaW5ncyBsaWtlIHRoZQo+IGhvcml6b250YWwgbGluZSBpbiBcZnJhYy4KPgo+ICAgICBF
ZGluPiA1KSBXaGF0IHdvdWxkIGJlIHRoZSBjb25zZXF1ZW5jZXMgb2YgZGlzdHJpYnV0aW5nIGEg
R1BMIGZvbnQKPiAgICAgRWRpbj4gKEZyZWVGb250KSB3aXRoIG1hdHBsb3RsaWIuIEkgbWVhbiwg
aXQncyBub3QgdGhhdCB1c2luZyBhCj4gICAgIEVkaW4+IEdQTCBmb250IGluIHNvbWUgbm9uLUdQ
TCBhcHAgY291bGQgYmUgYSBicmVhY2ggb2YgdGhlCj4gICAgIEVkaW4+IEdQTC4gSXMgdGhlcmUg
YW55IGludGVyZXN0IGluIHRoaXM/Cj4KPiBEb24ndCB1bmRlcmVzdGltYXRlIHRoZSB6ZWFsb3Vz
bmVzcyBvZiBHUEwgYWR2b2NhdGVzLiAgSSBoYXZlIGJlZW4KPiBpbmZvcm1lZCBieSB0aGUgRlNG
IHRoYXQgbWVyZWx5IHByb3ZpZGluZyBhIGJhY2tlbmQgdGhhdCBkb2VzCj4KPiBpbXBvcnQgcXQK
Pgo+IGluIGEgYmFja2VuZCB0aGF0IGlzIG9wdGlvbmFsbHkgaW5jbHVkZWQgYXQgcnVudGltZSBi
eSBhIHVzZXIgd2hvIG1heQo+IGJlIHVzaW5nIGEgR1BMIHZlcnNpb24gb2YgUVQgb3IgbWF5IGJl
IHVzaW5nIGEgY29tbWVyY2lhbGx5IGxpY2Vuc2VkCj4gdmVyc2lvbiBvZiBxdCAod2UgY2FuJ3Qg
a25vdyB3aGljaCkgbWFrZXMgdGhlIGVudGlyZSBjb2RlIGJhc2Ugb2YgbXBsCj4gR1BMJ2QuICBU
aGlzIGNsYWltIHdhcyBwcm92aWRlZCB3L28gYXJndW1lbnQgYW5kIEkgZnJhbmtseSBmaW5kIGl0
Cj4gbHVkaWNyb3VzLiAgUm9iZXJ0IGNhbiBwcm9iYWJseSB0ZWxsIHlvdSB0aGUgSUFOQUwgcmVz
cG9uc2UgdG8KPiBpbmNsdWRpbmcgR1BMJ2QgZm9udHMgYnV0IEknbSBub3QgdG9vIGludGVyZXN0
ZWQgaW4gZGlzdHJpYnV0aW5nIHRoZW0uCj4gV2UgY2FuIGFsd2F5cyBwb2ludCB0aGUgdXNlciB0
byBhIHdlYiBzaXRlIGFuZCB0aGV5IGNhbiBkb3dubG9hZCB0aGVtCj4gZnJvbS4KPgo+ICAgICBF
ZGluPiBUaGUgbmV3IG1hdGh0ZXh0LnB5IGlzIGF0dGFjaGVkLiBQbGVhc2UgZG8gbm90IHRyeSBp
dCBhdAo+ICAgICBFZGluPiBob21lIDspIGJlY2F1c2Ugbm90aGluZyB2aXNpYmxlIHlldCB3b3Jr
cy4KPgo+IE9LLgo+Cj4gSkRICj4K

The SoC deadline (for code) is tommorow (Aug 21st.), so I decided to commit
what I have done till now to the repository.
JDH is going on a vacation and will not be able to review it for at
least a week,
but I had to commit it before 21st. Aug - that's the SoC rules. Hopefully,
I'll be adding new stuff the next week (and after), but that doesn't
count as part of SoC anymore...
Since this is my first commit, can anyone please test it. I tested it
only on my windows box.
I changed
__init__.py,
mathtext.py
CHANGELOG
I added
mathtext2.py
mathtext2_demo.py
Anyone who wants to test the new mathtext2 has to add the following line(s)
to the matplotlibrc (mathtext2 is disabled by default):
mathtext2: True # Needed to enable the new mathtext
# Font lines, feel free to change or uncomment (BaKoMa is used by default)
mathtext.rm : FreeSerif.ttf
mathtext.it : FreeSerifItalic.ttf # Text italic
mathtext.tt : FreeMono.ttf # Typewriter (monospaced)
mathtext.mit : FreeSerifItalic.ttf # Math italic
mathtext.cal : FreeSansOblique.ttf # Caligraphic
mathtext.nonascii: FreeSerif.ttf # Used for \sum, \infty etc.
The FreeFont fonts (or any other for that matter) have to be downloaded and put
into the mpl-data dir. The default settingsuse the current bakoma
fonts, and they play pretty well with FreeSerif.ttf as the nonascii
(unicode) font.
so I recommend you just put the line
mathtext.nonascii: FreeSerif.ttf
and comment out the rest (experiment a little with fonts).
Tonight I plan to add support for fractions. Beware that the only
supported backend for now is Agg.
mathtext2_demo.py is attached

As a probably final installment in the thread about optimizing the wx 
back-end, here is a post from the wxPython list, in which someone posted 
SWIG code for making a PyBuffer from his data set, then using it to 
create a wx.Image without copying. A similar approach could be used for 
the wxAgg back-end.
-Chris
-------- Original Message --------
Subject: [wxPython-users] Re: using wxImage in C++ python extension
Date: 2006年8月18日 16:48:08 +0000 (UTC)
From: Andrew Murray <and...@st...>
Reply-To: wxP...@li...
To: wxp...@li...
References: <200...@uc...> 
<44E...@al...> <200...@uc...> 
<44E...@no...> <44E...@al...> 
<44E...@no...>
Hi all :)
I've followed the combined advice of Robin and Christopher in using a python
buffer object to instance a wx.Image in the python wrapper layer. It 
all seems
to be working - and I don't think there are any 'data copies' going on ;)
To keep my underlying C++ python-free, I introduced the buffer (and 
creation of
the wx.Image) via my .i Swig file. In case anyone who is reading is 
keen trying
to solve a similar problem, I've included the code that I added to my .i 
file in
order to implement the change below. (I'd appreciate any comments regarding
errors or shortcomings that anyone spots in my implementation.)
Sorry I didn't reply to the thread earlier. A combination of being tied 
up with
more boring work, moving house and background research into using python 
buffers
with Swig means that I've only just got this far.
One remaining question I have is: Does the call to wx.EmptyImage that I make
cause any memory to be allocated? I see from Robin's recent post that in my
case this call is now redundant (as I will soon be using 
ImageFromBuffer) - but
I'm curious to know the answer anyway ;)
Thanks for all the help. The more I use wxPython the more I like it...
Andrew ;)
/* the RawImage C++ class that we are wrapping offers a method that
 returns a pointer to an internal 'unsigned char' buffer of display
 data. To make the python class generated by SWIG a bit more
 friendly to the rest of our wxPython code we instruct SWIG to make
 two modifications during the wrapping process. First we add a
 method to the C++ class that will return a version of the internal
 display buffer wrapped up as a 'python buffer object' (performing
 this in the C++ wrapper class keeps the wrapped C++ python-free)...
 */
%extend RawImage {
	PyObject* RawImage::getDisplayBuffer(void) {
		// return a new 'python buffer object' that intialised using
		// the memory address and length of our display buffer...
		void* pvBufferData = (void*)self->pcGetDisplayData();
		int iBufferSize = self->getDisplayBufferSize();
		return PyBuffer_FromMemory(pvBufferData, iBufferSize);
	}
}
/* ... we also add a method to the python wrapper class that will use
 the buffer offered by our new C++ method to create a wx.Image
 (neither of these methods actually copies the image data)...
 */
%extend RawImage {
%pythoncode %{
def getImage(self):
 # create an unintialised wx.Image of the correct size...
 wximage = wx.EmptyImage(self.getWidth(), self.getHeight(), clear=False)
 # then define the data content of the image...
 wximage.SetDataBuffer(self.getDisplayBuffer())
 return wximage
%}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: wxP...@li...
For additional commands, e-mail: wxP...@li...
-- 
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...

>>>>> "Edin" =3D=3D Edin Salkovi=A7 <edi...@gm...> writes:
 Edin> Hi all, Please John, take some time before SciPy conf to
 Edin> answer at least some of this questions, because the SoC
 Edin> deadline (21st August) is *very* near.
Alas, I am already here and have been a little out of email contact
while traveling. Sorry for the delay.
 Edin> 1) I'm having some problems regarding FT2Font. The problem
 Edin> is when I instantiate FT2Font like: font =3D FT2Font(filename)
 Edin> and when I call it's method font.set_text("Some text"), and
 Edin> afterwards, font.draw_glyphs_to_bitmap(), the latter simply
 Edin> deletes every glyph that was drawn before it, and just
 Edin> paints in the internal image buffer the text that was passed
 Edin> on last invocation of set_text (or load_char).
This is a feature, not a bug :-) You can clear the image buffer if
you want with the clear method, as we do in the mathtexy code
 for fontface in self.fonts.values():
 fontface.clear()
 Edin> This is a pain, because draw_glyphs_to_bitmap implements the
 Edin> layout (with kerning etc.), but if one wants to paint
 Edin> several words in different x,y positions in the same image
 Edin> buffer, he has to do the layout for every character in every
 Edin> word manually via draw_glyph_to_bitmap(x, y, glyph) (like
 Edin> you did with the BaKoMa fonts in mathtext).
 Edin> Why hasn't draw_glyphs_to_bitmap been implemented so that it
 Edin> takes x, y as arguments (draw_glyphs_to_bitmap(x, y)) and
 Edin> leaves the image buffer intact (as does
 Edin> draw_glyph_to_bitmap)?
You can add optional x and y args to draw_glyphs_to_bitmap if you need
them. Just make sure any changes you make pass
examples/backend_driver.py and unit/memleak_hawaii3.py
 Edin> 2) As I have said before, I have started the complete
 Edin> rewrite of mathtext (the parsing stuff etc.). I have
 Edin> completely removed the dependency on pyparsing (please don't
 Edin> yell at me :), and I was wondering about how much of TeX
OK, I won't yell. Quietly scold maybe :-)
I am skeptical of your -- or anyone's except Robert's -- ability to
parse TeX mathematical expressions w/o a true recursive descent
parser. I took a look at your code but w/o any running examples I
could not test it. From reading it, I do not think it will be able to
handle the deeply recursive structures that are currently supported by
the existing, working parser. Can you handle recursively nested
super/sub scripts? Can it parse this
 tex =3D r'$\cal{R}\prod_{i=3D\alpha_{i+1}}^\infty a_i\rm{sin}(2 \pi f x=
_i)$'
If so, I apologize for my skepticism, but my working assumption is you
will need a proper parser to parse tex and string methods aren't going
to get you there. What I really need to see before even considering a
system that replaces the working system is an argument about why it
needs to be replaced, and more importantly, code that can do
everything the old code can do, such as render the mathtext_demo.py
example? =20
 Edin> should mathtext support. I'm not talking about support for
 Edin> \frac, \above, \choose (which I plan to add one by one)
 Edin> etc., but about more general things - macros (\def etc.). I
\above, \frac and \sqrt yes, \def no. Others I'm not sure about. =20
 Edin> was thinking of just simulating them, at least to a
 Edin> tolerable extent, via notion of an enviroment. Example: \rm
 Edin> in plain TeX sets the current font to roman (until the end
 Edin> of the current scope - 'till it hits "}"). Implementation:
 Edin> At render time, when the parser hits "\rm", it does the
 Edin> folowing: env["facetype"] =3D "rm", where env is the
 Edin> environment in the current scope.
Can we use classes here rather than dictionaries? Syntactically, I
prefer env.facetype =3D "rm" to the dictionary syntax.
 Edin> Also, I am planing to create a separate class for every new
 Edin> layout item that gets implemented. Example:
 Edin> sub/superscripted item (nucleus_sub^sup) gets translated to
 Edin> an instance of class Scripted that has the attributes
 Edin> nucleus, superscript and subscript.
 Edin> 3) I was thinking of focusing on just the Agg backend for
 Edin> now (that is till' the deadline). Is this OK? 4) I think
 Edin> that we should move the job of math_parse_s_ft2font,
 Edin> math_parse_s_ft2font_svg, and math_parse_s_ps etc. to the
 Edin> corresponding backends, and that some general function like:
 Edin> math_parse_s(x, y, s, prop, angle) should be implemented
 Edin> directly in mathtext.py (perhaps even without the "angle"
 Edin> parameter) so that it returns a list of the following type:
 Edin> [(x1, y1, s1, prop1, angle1), ... , (xn, yn, sn, propn,
 Edin> anglen)]
I can't address these questions until I understand why you are trying
to rewrite, rather than extend or fix, the existing code. The agg and
the postscript backends work with the existing frameowork. As far as
I can see, you could fix the layout engine in the existing framework
and not have to think too much about backends, with the exception that
you need a basic backend line drawing API for things like the
horizontal line in \frac.
 Edin> 5) What would be the consequences of distributing a GPL font
 Edin> (FreeFont) with matplotlib. I mean, it's not that using a
 Edin> GPL font in some non-GPL app could be a breach of the
 Edin> GPL. Is there any interest in this?
Don't underestimate the zealousness of GPL advocates. I have been
informed by the FSF that merely providing a backend that does=20
import qt
in a backend that is optionally included at runtime by a user who may
be using a GPL version of QT or may be using a commercially licensed
version of qt (we can't know which) makes the entire code base of mpl
GPL'd. This claim was provided w/o argument and I frankly find it
ludicrous. Robert can probably tell you the IANAL response to
including GPL'd fonts but I'm not too interested in distributing them.
We can always point the user to a web site and they can download them
from.
 Edin> The new mathtext.py is attached. Please do not try it at
 Edin> home ;) because nothing visible yet works.
OK.
JDH