matplotlib-devel Mailing List for matplotlib (Page 459)

Darren Dale wrote:
> On Sunday 27 August 2006 22:09, Eric Firing wrote:
>> Darren Dale 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? Does
>>> it have to be this way? I'm trying to improve the scalar formatter
>>> (supporting engineering notation, cleaning up the code).
>> Yes.  It is not a +-6% range in general, rather it is an adjustment that
>> is made if the range is very small.  The relevant method in Locator is:
>>
>>      def nonsingular(self, vmin, vmax, expander=0.001, tiny=1e-6):
>>          if vmax < vmin:
>>              vmin, vmax = vmax, vmin
>>          if vmax - vmin <= max(abs(vmin), abs(vmax)) * tiny:
>>              if vmin==0.0:
>>                  vmin -= 1
>>                  vmax += 1
>>              else:
>>                  vmin -= expander*abs(vmin)
>>                  vmax += expander*abs(vmax)
>>          return vmin, vmax
>>
>> I know I did it this way for a reason, but I don't remember exactly what
>> it was--whether it was because of problems with zooming when the zoom
>> range gets too small (this was definitely a big problem), or because of
>> problems with the rest of the locator code, or because it seemed to me
>> to be roughly the desired behavior in most cases.  Maybe it was all of
>> the above.  Certainly, something like this is needed--I think you will
>> find that things go bad rapidly if vmin gets too close to vmax.  I put
>> in the "expander" and "tiny" kwargs in case of future need, but only
>> expander is non-default (e.g., 0.05) in other parts of ticker.py, and
>> neither kwarg is presently exposed to the user.  That could be changed.
> 
> I don't understand, I spent a lot of time making the scalarformatter work with 
> precisely this scenario (zooming in on extremely small ranges), and it was 
> working very well. I don't know of any circumstance where there was a 
> problem, maybe you could be more specific about the big problems you 
> encountered.

Darren,

I'm sorry, but I probably can't be much more specific.  I don't remember 
the details of the whole lengthy process involved in getting MaxNLocator 
and aspect ratio handling working with pan and zoom, but the present 
version of nonsingular was part of it.  It looks like the change you 
don't like was revision 2149 on March 16, when the "tiny" kwarg was 
added.  Now, I think that the point of adding it was that checking for 
vmin == vmax turned out to be not good enough; given floating point 
math, having vmin too close to vmax could still cause trouble, maybe not 
in your formatter, but elsewhere.  At one point "elsewhere" included the 
transforms module, but I am not sure whether the bug I fixed in revision 
2149 involved an error from the transforms module.

For experimental purposes, you can get the old behavior by setting tiny=0.0.

Eric

Ken McIvor wrote:
> I'll put it on the list of things to look into.

Great. I'm glad someone is working on this.

> 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().

darn. I figured as much. wx is really due for an update to support alpha 
properly. But I guess you'll always have problems with different data 
formats.

 > I'm not sure this approach will help speed
 > up the wxAgg accelerator, but

Anyway, this thread started because people were having binary 
compatibility issues. Even if this doesn't speed up the accelerator, it 
may be possible to get the same performance without using 
wx-version-specific compiled code -- i.e. pure python.

I do have one question -- does the agg back-end really need to use an 
alpha channel for it's buffer? Isn't it the whole image anyway? What is 
is it going to get blended with?

-Chris



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

Chr...@no...

On 8/27/06, Eric Firing <ef...@ha...> wrote:
> Bill Baxter wrote:
>
> >
> > 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.
>
> Presently it kicks in only in the unusual case of a very small range,
> but it has also occurred to me that it would be nice to be able to tell
> the autoscaling to add a margin in any case.  I just haven't gotten
> around to doing it.

+1 for that.  I've just recently been fixing my limits by hand in this
way precisely to avoid the half-cut markers problem that Bill
describes.

Cheers,

f

Bill Baxter wrote:

> 
> 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.

Presently it kicks in only in the unusual case of a very small range, 
but it has also occurred to me that it would be nice to be able to tell 
the autoscaling to add a margin in any case.  I just haven't gotten 
around to doing it.

Eric

Darren Dale 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? Does it 
> have to be this way? I'm trying to improve the scalar formatter (supporting 
> engineering notation, cleaning up the code).

Yes.  It is not a +-6% range in general, rather it is an adjustment that 
is made if the range is very small.  The relevant method in Locator is:

     def nonsingular(self, vmin, vmax, expander=0.001, tiny=1e-6):
         if vmax < vmin:
             vmin, vmax = vmax, vmin
         if vmax - vmin <= max(abs(vmin), abs(vmax)) * tiny:
             if vmin==0.0:
                 vmin -= 1
                 vmax += 1
             else:
                 vmin -= expander*abs(vmin)
                 vmax += expander*abs(vmax)
         return vmin, vmax

I know I did it this way for a reason, but I don't remember exactly what 
it was--whether it was because of problems with zooming when the zoom 
range gets too small (this was definitely a big problem), or because of 
problems with the rest of the locator code, or because it seemed to me 
to be roughly the desired behavior in most cases.  Maybe it was all of 
the above.  Certainly, something like this is needed--I think you will 
find that things go bad rapidly if vmin gets too close to vmax.  I put 
in the "expander" and "tiny" kwargs in case of future need, but only 
expander is non-default (e.g., 0.05) in other parts of ticker.py, and 
neither kwarg is presently exposed to the user.  That could be changed.

Eric

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: Fri, 18 Aug 2006 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