matplotlib-devel Mailing List for matplotlib

Darren Dale wrote:
> 
> On Monday 30 June 2008 10:40:27 Darren Dale wrote:
>> On Monday 30 June 2008 09:06:59 am John Hunter wrote:
>>> On Mon, Jun 30, 2008 at 7:10 AM, Michael Droettboom <md...@st...> 
> wrote:
>>>> Hate to say "me too", but I don't really understand text with dash
>>>> either... I'll have a look when I have adequate time to devote to it,
>>>> if no one else volunteers.
>>> Daishi,
>>>
>>> I don't know if this is still the right email address for you, but if
>>> so could you let us know if you could look at the TextWithDash
>>> implementation in matplotlib svn trunk. Our transformations have
>>> undergone a bit of refactoring, and some relatively minor changes were
>>> made in the Text base class positioning code, but these were enough to
>>> break the TextWithDash layout. Let us know if you have a minute to
>>> look at this and perhaps provide a patch to bring TextWithDash
>>> functionality back.
>> Daishi's original contribution of TextWithDash used delegation, which was
>> causing some trouble with object introspection and the dynamically
>> generated list of properties. I refactored his work way back in March 2006,
>> svn 2226:
>> http://sourceforge.net/mailarchive/message.php?msg_id=200603211837.28678.dd
>> 55%40cornell.edu
>>
>> Sorry I'm just now getting to this thread. I recall the behavior of
>> get_position referring to the dash position was strange for a subclass of
>> Text, but this was simply a continuation of the original implimentation. I
>> was only concerned with exposing all of TextWithDash's methods to object
>> introspection when I made my contribution. I also recall seeing strange
>> behavior like what Manuel posted. I'll have a look when I get a chance,
>> hopefully this evening.
> 
> I *think* I found a simple fix: use the Text._x and ._y directly in draw, 
> rather than get_position which refers to the text position in Text and the 
> Dash position in TextWith Dash (thank you for pointing this out, John). Please 
> let me know if something is still amiss, svn 5701.
> 
> I had another working solution which let get/set_position refer to the text 
> position, and added get/set_dashposition. I didn't like it as much, because 
> the text position could be set by the user and would then be overridden by 
> update_coords. But maybe it was a more coherent way to do it. set_position 
> could recalculate the dash length, and set_dashlength/pad/push would 
> recalculate the text position. (The dash position is always the reference.) I 
> think it might be more trouble than its worth, it would take a lot of work and 
> would cause API breakage.
 With that patch everything is working for me: dashpointlabel is 
working, tick labels are also correctly drawn, and the dashtick example 
now also works fine again (both GUI and png output) !
Manuel
> Darren
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Monday 30 June 2008 10:40:27 Darren Dale wrote:
> On Monday 30 June 2008 09:06:59 am John Hunter wrote:
> > On Mon, Jun 30, 2008 at 7:10 AM, Michael Droettboom <md...@st...> 
wrote:
> > > Hate to say "me too", but I don't really understand text with dash
> > > either... I'll have a look when I have adequate time to devote to it,
> > > if no one else volunteers.
> >
> > Daishi,
> >
> > I don't know if this is still the right email address for you, but if
> > so could you let us know if you could look at the TextWithDash
> > implementation in matplotlib svn trunk. Our transformations have
> > undergone a bit of refactoring, and some relatively minor changes were
> > made in the Text base class positioning code, but these were enough to
> > break the TextWithDash layout. Let us know if you have a minute to
> > look at this and perhaps provide a patch to bring TextWithDash
> > functionality back.
>
> Daishi's original contribution of TextWithDash used delegation, which was
> causing some trouble with object introspection and the dynamically
> generated list of properties. I refactored his work way back in March 2006,
> svn 2226:
> http://sourceforge.net/mailarchive/message.php?msg_id=200603211837.28678.dd
>55%40cornell.edu
>
> Sorry I'm just now getting to this thread. I recall the behavior of
> get_position referring to the dash position was strange for a subclass of
> Text, but this was simply a continuation of the original implimentation. I
> was only concerned with exposing all of TextWithDash's methods to object
> introspection when I made my contribution. I also recall seeing strange
> behavior like what Manuel posted. I'll have a look when I get a chance,
> hopefully this evening.
I *think* I found a simple fix: use the Text._x and ._y directly in draw, 
rather than get_position which refers to the text position in Text and the 
Dash position in TextWith Dash (thank you for pointing this out, John). Please 
let me know if something is still amiss, svn 5701.
I had another working solution which let get/set_position refer to the text 
position, and added get/set_dashposition. I didn't like it as much, because 
the text position could be set by the user and would then be overridden by 
update_coords. But maybe it was a more coherent way to do it. set_position 
could recalculate the dash length, and set_dashlength/pad/push would 
recalculate the text position. (The dash position is always the reference.) I 
think it might be more trouble than its worth, it would take a lot of work and 
would cause API breakage.
Darren

Hi all,
this is just a reminder, in case you'll be attending the SIAM 2008
annual meeting next week in San Diego, that there will be a 3-part
minisymposium focusing on the uses of Python and Sage in scientific
computing:
http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7369
http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7370
http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7447
We hope to see many of you there!
Regards,
Fernando and Randy

Sorry, I accidentally sent an incomplete email.
here is a complete one.
I sometimes use a custom Axes class, and want to use it with
add_subplot() command.
As a matter of fact, it IS possible with current version of matplotlib
but it seems a bit inconvenient to me.
Here is what I may do.
 import matplotlib.axes as maxes
 class MyAxes(maxes.Axes):
 name="myaxes"
 # some definitions
 import matplotlib.projections
 matplotlib.projections.register_projection(MyAxes)
 F = figure()
 ax = F.add_subplot(1,2,2, projection="myaxes")
But it would much better if I can simply do something like
 class MyAxes(maxes.Axes):
 # some definitions
 F = figure()
 ax = F.add_subplot(1,2,2, axes_class=MyAxes)
It seems rather straight forward to implement "axes_class" keyword in
add_subplot() and I may make a patch for it.
So, how does others think?
Regards,
-JJ

Hi,
I sometimes use a custom Axes class, and want to use it with
add_subplot() command.
As a matter of fact, it IS possible with current version of matplotlib
but it seems a bit inconvenient to me.
Here is what I do.
class MyAxes(maxes.Axes):
 name="myaxes"

On Monday 30 June 2008 09:06:59 am John Hunter wrote:
> On Mon, Jun 30, 2008 at 7:10 AM, Michael Droettboom <md...@st...> wrote:
> > Hate to say "me too", but I don't really understand text with dash
> > either... I'll have a look when I have adequate time to devote to it,
> > if no one else volunteers.
>
> Daishi,
>
> I don't know if this is still the right email address for you, but if
> so could you let us know if you could look at the TextWithDash
> implementation in matplotlib svn trunk. Our transformations have
> undergone a bit of refactoring, and some relatively minor changes were
> made in the Text base class positioning code, but these were enough to
> break the TextWithDash layout. Let us know if you have a minute to
> look at this and perhaps provide a patch to bring TextWithDash
> functionality back.
Daishi's original contribution of TextWithDash used delegation, which was 
causing some trouble with object introspection and the dynamically generated 
list of properties. I refactored his work way back in March 2006, svn 2226:
http://sourceforge.net/mailarchive/message.php?msg_id=200603211837.28678.dd55%40cornell.edu
Sorry I'm just now getting to this thread. I recall the behavior of 
get_position referring to the dash position was strange for a subclass of 
Text, but this was simply a continuation of the original implimentation. I 
was only concerned with exposing all of TextWithDash's methods to object 
introspection when I made my contribution. I also recall seeing strange 
behavior like what Manuel posted. I'll have a look when I get a chance, 
hopefully this evening.

Hi Pierre,
On Monday 30 June 2008 06:25:42 am Pierre Raybaut wrote:
> Hi all,
>
> I'm posting to report the following bug in 'backend_qt4.py', class
> 'NavigationToolbar2QT' l. 309 :
>
> When using Qt4 as default backend, if you type 'plot(x,y)' and then
> 'close()', you'll obtain an attribute error because 'NavigationToolbar2QT'
> has no 'toolitem' attribute (see line 310). I think that 'toolitem' was
> used in the previous Qt4 backend implementation.
>
> To make things work, I simply removed this 'destroy' method which is
> probably deprecated.
Thank you for the report. This is fixed in svn.

On Mon, Jun 30, 2008 at 7:10 AM, Michael Droettboom <md...@st...> wrote:
> Hate to say "me too", but I don't really understand text with dash
> either... I'll have a look when I have adequate time to devote to it,
> if no one else volunteers.
Daishi,
I don't know if this is still the right email address for you, but if
so could you let us know if you could look at the TextWithDash
implementation in matplotlib svn trunk. Our transformations have
undergone a bit of refactoring, and some relatively minor changes were
made in the Text base class positioning code, but these were enough to
break the TextWithDash layout. Let us know if you have a minute to
look at this and perhaps provide a patch to bring TextWithDash
functionality back.
Thanks,
JDH

Yes. Thank you for finding this. Fixed in SVN.
Cheers,
Mike
Ryan May wrote:
> Hi,
>
> I think I found a bug while looking over scale.py:
>
> 127 class InvertedNaturalLogTransform(Transform):
> 128 input_dims = 1
> 129 output_dims = 1
> 130 is_separable = True
> 131 base = np.e
> 132
> 133 def transform(self, a):
> 134 return ma.power(np.e, a) / np.e
> 135
> 136 def inverted(self):
> 137 return LogScale.Log2Transform()
>
> Shouldn't line 137 instead read:
> 	return LogScale.NaturalLogTransform()
>
> Ryan
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hate to say "me too", but I don't really understand text with dash 
either... I'll have a look when I have adequate time to devote to it, 
if no one else volunteers.
Cheers,
Mike
Manuel Metz wrote:
> John Hunter wrote:
> 
>> Manuel and Michael worked on fixing a bug with TextWithDash, but this
>> introduced a bug will all tick labels so I reverted the changes. The
>> problem is that the text layout code in Text (eg draw,
>> get_window_extent) is using "get_position" which in TextWithDash is
>> the dash position, according to the doc string and the original impl.
>> On the branch, the draw and layout methods of Text use _get_xy_display
>> which TextWithDash overrides. That is why it works on the branch and
>> not the trunk. The changes of M&M to make set_position and
>> get_position refer to the x and y locs fixed dash with text for
>> reasons that are not completely clear t me, but broke tick labels
>> which are also TextWithDash instances.
>>
>> I did not write TextWithDash so cannot vouch for its conventions, but
>> I don't have time to dig deeply enough right now to fix this, so I
>> wanted to revert the changes so regular plots would work again and
>> give a head's up here so Manuel, Michael and I would not be doing and
>> undoing each other's changes w/o some understanding of where the
>> discerpancy was arising.
>> 
>
> Hm, the patch I applied was exactly because I got also problems with the 
> tick labels -- they were all squashed to one place -- and I thought to 
> have fixed that. Now, it seems this wasn't quite correct ;-)
> As I have also no deeper understanding what's _really_ going on in 
> TextWithDash, I will now better keep my hands off TextWithDash ...
>
> Manuel
>
> 
>> Thanks,
>> JDH
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi all,
I'm posting to report the following bug in 'backend_qt4.py', class
'NavigationToolbar2QT' l. 309 :
When using Qt4 as default backend, if you type 'plot(x,y)' and then
'close()', you'll obtain an attribute error because 'NavigationToolbar2QT'
has no 'toolitem' attribute (see line 310). I think that 'toolitem' was used
in the previous Qt4 backend implementation.
To make things work, I simply removed this 'destroy' method which is
probably deprecated.
Regards,
Pierre Raybaut

Thanks John, I've update the new version with your code.
It is now available at:
 http://www.loria.fr/~rougier/pylab.html
You can now choose between python and ipython (option -s python
or -s ipython) and all user events on a figure should be handled
properly (mouse, scroll and key).
Concerning the toolbar, is is quite easy to add but it is not
very pleasant to the eyes. I'm looking for a more asethetic solution.
Nicolas 
On Fri, 2008年06月27日 at 09:58 -0500, John Hunter wrote:
> On Fri, Jun 27, 2008 at 8:03 AM, Nicolas Rougier
> <Nic...@lo...> wrote:
> 
> > I've developed a GTK/Python/Pylab console that is able to display
> > most matplotlib figures directly within the console and handle
> > matplotlib mouse events properly.
> 
> What would be really great is if you could insert the toolbar under
> the figure so panning and zooming would be enabled.
> 
> Also, you mentioned getting lost in the flurry of ipython1 -- you may
> want to check back with them in the near future because I think they
> are making great strides and a gtk frontend would be excellent.
> 
> Finally, I've made a minor additions to support "draw_if_interactive"
> so you don't need to call show. Just type "plot" or "xlim" etc and
> the plot automagically updates. I also needed to replace partial
> since it does not ship with python2.4.
> 
> Thanks,
> JDH

John Hunter wrote:
> Manuel and Michael worked on fixing a bug with TextWithDash, but this
> introduced a bug will all tick labels so I reverted the changes. The
> problem is that the text layout code in Text (eg draw,
> get_window_extent) is using "get_position" which in TextWithDash is
> the dash position, according to the doc string and the original impl.
> On the branch, the draw and layout methods of Text use _get_xy_display
> which TextWithDash overrides. That is why it works on the branch and
> not the trunk. The changes of M&M to make set_position and
> get_position refer to the x and y locs fixed dash with text for
> reasons that are not completely clear t me, but broke tick labels
> which are also TextWithDash instances.
> 
> I did not write TextWithDash so cannot vouch for its conventions, but
> I don't have time to dig deeply enough right now to fix this, so I
> wanted to revert the changes so regular plots would work again and
> give a head's up here so Manuel, Michael and I would not be doing and
> undoing each other's changes w/o some understanding of where the
> discerpancy was arising.
Hm, the patch I applied was exactly because I got also problems with the 
tick labels -- they were all squashed to one place -- and I thought to 
have fixed that. Now, it seems this wasn't quite correct ;-)
 As I have also no deeper understanding what's _really_ going on in 
TextWithDash, I will now better keep my hands off TextWithDash ...
Manuel
> Thanks,
> JDH
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Manuel and Michael worked on fixing a bug with TextWithDash, but this
introduced a bug will all tick labels so I reverted the changes. The
problem is that the text layout code in Text (eg draw,
get_window_extent) is using "get_position" which in TextWithDash is
the dash position, according to the doc string and the original impl.
On the branch, the draw and layout methods of Text use _get_xy_display
which TextWithDash overrides. That is why it works on the branch and
not the trunk. The changes of M&M to make set_position and
get_position refer to the x and y locs fixed dash with text for
reasons that are not completely clear t me, but broke tick labels
which are also TextWithDash instances.
I did not write TextWithDash so cannot vouch for its conventions, but
I don't have time to dig deeply enough right now to fix this, so I
wanted to revert the changes so regular plots would work again and
give a head's up here so Manuel, Michael and I would not be doing and
undoing each other's changes w/o some understanding of where the
discerpancy was arising.
Thanks,
JDH

My coworker Sal Uryasev updated his nodebox code for generating the
comparison chart example here:
http://media.juiceanalytics.com/downloads/tufte_nodebox_forcepush.py
post:
http://www.juiceanalytics.com/writing/tufte-style-comparison-chart-generator/
This kind of chart is very similar to energy level diagrams in
physics/chemistry, so people on the list might find it interesting.
On Fri, Jun 27, 2008 at 6:08 PM, Fernando Perez <fpe...@gm...>
wrote:
> Hey folks,
>
> for those of you who hadn't heard of nodebox, it's a very neat
> viz/plotting library that is much more on the 'fancy visuals' end of
> things than the 'scientific plotting'. I'd never mentioned it here
> because it used to be OSX-only, but an MPL fan at a conference just
> pointed me to its recent port to Qt. I figured it might be of
> interest to some here...
>
> Cheers,
>
> f
>
> ---------- Forwarded message ----------
> From: Peter Skomoroch <pet...@gm...>
> Date: Fri, Jun 27, 2008 at 2:34 PM
> Subject: nodebox on ubuntu
> To: fer...@be..., pi...@be...
>
>
> http://dev.nodebox.net/wiki/Qt
>
> Uses Qt instead of Cocoa/OSX
>
> also:
>
> http://www.juiceanalytics.com/writing/topics/nodebox/
>
> --
> Peter N. Skomoroch
> pet...@gm...
> http://www.datawrangling.com
> http://del.icio.us/pskomoroch
>
-- 
Peter N. Skomoroch
pet...@gm...
http://www.datawrangling.com
http://del.icio.us/pskomoroch

Michael Droettboom wrote:
> I believe I have this fixed in SVN. Please kick the tires and let me 
> know if you still have problems.
Hi Mike,
 unfortunately this introduced another problem - with the patch all 
tick labels were miss-placed. I think I've fixed that now...
 But that brings me to another point. I get very strange results when 
running the dashtick example. The two PNGs attached show the result. 
dashticklabel.png is the output-file of the savefig() call, the other 
one is a Screenshot taken.
Manuel

Hey folks,
for those of you who hadn't heard of nodebox, it's a very neat
viz/plotting library that is much more on the 'fancy visuals' end of
things than the 'scientific plotting'. I'd never mentioned it here
because it used to be OSX-only, but an MPL fan at a conference just
pointed me to its recent port to Qt. I figured it might be of
interest to some here...
Cheers,
f
---------- Forwarded message ----------
From: Peter Skomoroch <pet...@gm...>
Date: Fri, Jun 27, 2008 at 2:34 PM
Subject: nodebox on ubuntu
To: fer...@be..., pi...@be...
http://dev.nodebox.net/wiki/Qt
Uses Qt instead of Cocoa/OSX
also:
http://www.juiceanalytics.com/writing/topics/nodebox/
--
Peter N. Skomoroch
pet...@gm...
http://www.datawrangling.com
http://del.icio.us/pskomoroch

Hi,
I think I found a bug while looking over scale.py:
 127 class InvertedNaturalLogTransform(Transform):
 128 input_dims = 1
 129 output_dims = 1
 130 is_separable = True
 131 base = np.e
 132
 133 def transform(self, a):
 134 return ma.power(np.e, a) / np.e
 135
 136 def inverted(self):
 137 return LogScale.Log2Transform()
Shouldn't line 137 instead read:
	return LogScale.NaturalLogTransform()
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

The deadline for submitting abstracts to the Scipy conference was tonight.
In order to give you more time to submit excellent abstracts, the review
committee is extending the deadline to Monday (June 30th), and will work
hastily to get all of them reviewed in time for the program announcement,
on Thursday July 3rd.
----
The SciPy 2008 Conference will be held 21-22 August 2008 at the
California Institute of Technology, Pasadena, California. SciPy is a
scientific computing package, written in the Python language. It is
widely used in research, the industry and academia.
The program features tutorials, contributed papers, lightning talks, and
bird-of-a-feather sessions. We are soliciting talks and accompanying
papers (either formal academic or magazine-style articles) that discuss
topics which center around scientific computing using Python. These
include applications, teaching, future development directions and
research. A collection of peer-reviewed articles will be published as
part of the proceedings.
Proposals for talks are submitted as extended abstracts. There are two
categories of talks:
Lightning talks
These talks are 10 minutes in duration. An abstract of between 300 and
700 words should describe the topic and motivate its relevance to
scientific computing. Lightning talks do not require an accompanying
article (although, if submitted, these will still be published).
Paper presentations
These talks are 35 minutes in duration (including questions). A one page
abstract of no less than 500 words (excluding figures and references)
should give an outline of the final paper. Papers are due two weeks
before the conference, and may be in a formal academic style, or in a
more relaxed magazine-style format.
If you wish to present a talk at the conference, please create an account
on the website http://conference.scipy.org. You may then submit an
abstract by logging in, clicking on your profile and following the "
Submit an abstract " link.
Gaël, on behalf on the SciPy08 organizing committee.

On Fri, Jun 27, 2008 at 8:03 AM, Nicolas Rougier
<Nic...@lo...> wrote:
> I've developed a GTK/Python/Pylab console that is able to display
> most matplotlib figures directly within the console and handle
> matplotlib mouse events properly.
What would be really great is if you could insert the toolbar under
the figure so panning and zooming would be enabled.
Also, you mentioned getting lost in the flurry of ipython1 -- you may
want to check back with them in the near future because I think they
are making great strides and a gtk frontend would be excellent.
Finally, I've made a minor additions to support "draw_if_interactive"
so you don't need to call show. Just type "plot" or "xlim" etc and
the plot automagically updates. I also needed to replace partial
since it does not ship with python2.4.
Thanks,
JDH

Thanks, Chris. Fixed.
Mike
Chris Walker wrote:
> The patch below fixes a minor typo in the documentation. 
>
> Chris
>
> cjtest@Daedalus:~/mydeb/mpl-svn/matplotlib/trunk/matplotlib/lib/matplotlib$ svn diff afm.py 
> Index: afm.py
> ===================================================================
> --- afm.py	(revision 5683)
> +++ afm.py	(working copy)
> @@ -4,7 +4,7 @@
> than mine) I decided not to go with them because either they were
> either
> 
> - 1) copyighted or used a non-BSD compatible license
> + 1) copyrighted or used a non-BSD compatible license
> 
> 2) had too many dependencies and I wanted a free standing lib
> 
>
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

The patch below fixes a minor typo in the documentation. 
Chris
cjtest@Daedalus:~/mydeb/mpl-svn/matplotlib/trunk/matplotlib/lib/matplotlib$ svn diff afm.py 
Index: afm.py
===================================================================
--- afm.py	(revision 5683)
+++ afm.py	(working copy)
@@ -4,7 +4,7 @@
 than mine) I decided not to go with them because either they were
 either
 
- 1) copyighted or used a non-BSD compatible license
+ 1) copyrighted or used a non-BSD compatible license
 
 2) had too many dependencies and I wanted a free standing lib
 

Hi all, 
I've developed a GTK/Python/Pylab console that is able to display
most matplotlib figures directly within the console and handle
matplotlib mouse events properly.
Screenshots and sources are available at:
http://www.loria.fr/~rougier/pylab.html
I've tested several examples from matplotlib examples and they
seem to be displayed properly. Any comments/requests are welcome.
Nicolas Rougier.

Thanks. It's supposed to try an autodelimiter (something like "\left(" 
) first, and then fallback to regular symbols. Unfortunately, inside a 
group, the fallback wasn't happening correctly. It's a one character 
fix. ;)
Cheers,
Mike
Manuel Metz wrote:
> Hi,
> just want to point to a bug (2002836) reported on sourceforge.
>
> I could track this a little bit more down and found that a subscript 
> like r'x_{\leftarrow}' fails, whereas r'x_\leftarrow' works (!); also 
> fails e.g. for r'x_{\leftrightarrow}'. Anything that starts with 
> \right or \Left works, too.
> Seems to be related to Parser.autoDelim ?!
>
> Manuel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
 just want to point to a bug (2002836) reported on sourceforge.
 I could track this a little bit more down and found that a subscript 
like r'x_{\leftarrow}' fails, whereas r'x_\leftarrow' works (!); also 
fails e.g. for r'x_{\leftrightarrow}'. Anything that starts with \right 
or \Left works, too.
 Seems to be related to Parser.autoDelim ?!
Manuel