Thread: [matplotlib-devel] Mathtext improvements (merging into trunk)

The new mathtext with an underlying TeX-like box model is passing all 
unit tests for all backends.  I'm now at a point where I'd like to merge 
this back into the trunk, but I'd like some feedback as to how to best 
deal with the backward-incompatible change wrt font changes.

(This was discussed in an earlier thread, but I don't believe a 
conclusion was reached, so I'm summarizing again here.)  In the existing 
mathtext implementation, font style changes affect the following group.  
For example, in $\cal{R} x$, only the R will be in calligraphic face.  
In TeX, however, font style markers stay in effect until the next font 
style marker or the end of the enclosing group.  Therefore, the same 
example would be rendered with both the R and the x in calligraphic 
face.  The new mathtext adds LaTeX-style font macros (\mathcal, \mathrm 
etc.) that behave as the old mathtext ones.  So the example expression 
could be re-written $\mathcal{R} x$.  It's difficult to trap the old 
case and correct for it, since both are still valid.

Becoming more TeX-like is a good thing, but does breaking existing 
matplotlib plots warrant some additional care here?  Should this be 
merged into trunk, or onto some other branch where we're going to be 
breaking a lot of things.  It is probably feasible to have a 
"compatibility" mode for this, but is that (in this particular case) 
worth the extra maintenance burden?

Cheers,
Mike

On 7/25/07, Michael Droettboom <md...@st...> wrote:
> The new mathtext with an underlying TeX-like box model is passing all
> unit tests for all backends.  I'm now at a point where I'd like to merge
> this back into the trunk, but I'd like some feedback as to how to best
> deal with the backward-incompatible change wrt font changes.

This is really, really cool stuff.  On a mostly unrelated note,  do
you thing the TeX box layout algorithms could be used to solve more
general figure layout problems, eg positioning axes and tick labels,
etc?

> (This was discussed in an earlier thread, but I don't believe a
> conclusion was reached, so I'm summarizing again here.)  In the existing
> mathtext implementation, font style changes affect the following group.
> For example, in $\cal{R} x$, only the R will be in calligraphic face.
> In TeX, however, font style markers stay in effect until the next font
> style marker or the end of the enclosing group.  Therefore, the same
> example would be rendered with both the R and the x in calligraphic
> face.  The new mathtext adds LaTeX-style font macros (\mathcal, \mathrm
> etc.) that behave as the old mathtext ones.  So the example expression
> could be re-written $\mathcal{R} x$.  It's difficult to trap the old
> case and correct for it, since both are still valid.
>
> Becoming more TeX-like is a good thing, but does breaking existing
> matplotlib plots warrant some additional care here?  Should this be
> merged into trunk, or onto some other branch where we're going to be
> breaking a lot of things.  It is probably feasible to have a
> "compatibility" mode for this, but is that (in this particular case)
> worth the extra maintenance burden?

I think we should strive for TeX correctness and should not support
the incorrect usage in a
compatibility  mode.  The improvements you've made are sufficiently
important that mathtext users will gladly accept a little breakage.
We can put up a news flash on the main site, and note the changes in
the CHANGELOG and API_CHANGES file, as well as in the mathtext_demo.

I have a few questions about the mathtext_demo.py.  A number of these
are probably just related to the bakoma fonts, which are just so
horrific it pains me to look at them (like why is the s in sin so much
lighter?)

 * The i in the {i+1} subscript looks too small.  It also looks to
small compared to the j in the \Delta_i^j example.   Are the i and j
coming from the same file, and do you have any idea why it is small?

 * There is a lot of space between the \prod symbol and the rest of
the expression and between the \mathcal{R} and the \prod symbol --
what controls this?  It looks like it is being affected by the wide
\prod subscript {i=\alpha_{i+1}} -- is this correct and is this how
TeX handles it?  Since the subscript is under the prod, it seems like
it's width should not affect the spacing of the R and the sin

 * Have you given any thought to the "cross font" kerning problem.
Eg, if the parens comes from one file, and the 2 from another and the
\pi from a 3rd, how to we kern "( 2 \pi )?

 * have you succeeded in get any non bakoma fonts to work, eg with the
UnicodeFont code?

Anyway, this is really great stuff.  Thanks!
JDH

On Wed, Jul 25, 2007 at 11:36:17AM -0500, John Hunter wrote:
>  * There is a lot of space between the \prod symbol and the rest of
> the expression and between the \mathcal{R} and the \prod symbol --
> what controls this?  It looks like it is being affected by the wide
> \prod subscript {i=\alpha_{i+1}} -- is this correct and is this how
> TeX handles it?

AFAIK yes. I correct this with a lot of "\!\!". This is a hack, but it
gives good results.

Gaël

Michael Droettboom <md...@st...>
writes:

> In the existing mathtext implementation, font style changes affect the
> following group. For example, in $\cal{R} x$, only the R will be in
> calligraphic face. In TeX, however, font style markers stay in effect
> until the next font style marker or the end of the enclosing group.

To clarify a little: in Plain TeX people usually write ${\cal R}x$,
beginning the group before the font-changing macro. The LaTeX macros
such as \mathcal take an argument: for example, both $\mathcal{R}x$ and
$\mathcal Rx$ cause only R to have the calligraphic font. (The latter is
because of TeX's parsing rules: \mathcal takes one argument, and since
there is no {}-group, the argument consists of the single letter R.)
The old mathtext style font-changing commands behave like the LaTeX
macros but have names like the Plain TeX macros, and the change you
are proposing to merge makes mathtext have both Plain TeX and LaTeX
style commands.

> It's difficult to trap the old 
> case and correct for it, since both are still valid.

Is it easy to detect when a Plain TeX style command is followed by an
opening brace, and output a warning? It is typically not useful to
start a new group right after a font-changing command, so such usage is
more likely to be caused by someone relying on the old behavior.

> Becoming more TeX-like is a good thing, but does breaking existing 
> matplotlib plots warrant some additional care here?  Should this be 
> merged into trunk, or onto some other branch where we're going to be 
> breaking a lot of things.  It is probably feasible to have a 
> "compatibility" mode for this, but is that (in this particular case) 
> worth the extra maintenance burden?

IMHO this should be merged into trunk, with a warning in case of "\cal{"
if that is feasible, but no other compatibility mode.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Gael Varoquaux <gae...@no...>
writes:

> On Wed, Jul 25, 2007 at 11:36:17AM -0500, John Hunter wrote:
>>  * There is a lot of space between the \prod symbol and the rest of
>> the expression and between the \mathcal{R} and the \prod symbol --
>> what controls this?  It looks like it is being affected by the wide
>> \prod subscript {i=\alpha_{i+1}} -- is this correct and is this how
>> TeX handles it?
>
> AFAIK yes. I correct this with a lot of "\!\!". This is a hack, but it
> gives good results.

Yes, this is how TeX does it. Another hack is to cause the subscript box
to have zero width, which in principle can be done with \makebox[0pt]
(but Google for "mathclap" to find how to make it actually work).

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

John Hunter wrote:
> On 7/25/07, Michael Droettboom <md...@st...> wrote:
>> The new mathtext with an underlying TeX-like box model is passing all
>> unit tests for all backends.  I'm now at a point where I'd like to merge
>> this back into the trunk, but I'd like some feedback as to how to best
>> deal with the backward-incompatible change wrt font changes.
>
> This is really, really cool stuff.  On a mostly unrelated note,  do
> you thing the TeX box layout algorithms could be used to solve more
> general figure layout problems, eg positioning axes and tick labels,
> etc?
That seems like it would be worth some thought, but nothing springs to mind.
>
> I think we should strive for TeX correctness and should not support
> the incorrect usage in a
> compatibility  mode.  The improvements you've made are sufficiently
> important that mathtext users will gladly accept a little breakage.
> We can put up a news flash on the main site, and note the changes in
> the CHANGELOG and API_CHANGES file, as well as in the mathtext_demo.
Sounds good.
>
> I have a few questions about the mathtext_demo.py.  A number of these
> are probably just related to the bakoma fonts, which are just so
> horrific it pains me to look at them (like why is the s in sin so much
> lighter?)
I think that's due to lack of hinting in the font.  If you generate a 
.ps and zoom in enough, they do look much better.
>
> * The i in the {i+1} subscript looks too small.  It also looks to
> small compared to the j in the \Delta_i^j example.   Are the i and j
> coming from the same file, and do you have any idea why it is small?
Hmmm.  Both i's look identical here.  Perhaps an optical illusion from 
the rotation?  I agree, in general, though that there is some tweaking 
to font sizes and positioning that still needs to be done.  Since 
mathtext always uses the same glyph outlines regardless of font size, 
unlike TeX which changes the actual shapes in response to font size, 
some compromises had to be made in that regard.
>
> * There is a lot of space between the \prod symbol and the rest of
> the expression and between the \mathcal{R} and the \prod symbol --
> what controls this?  It looks like it is being affected by the wide
> \prod subscript {i=\alpha_{i+1}} -- is this correct and is this how
> TeX handles it?  Since the subscript is under the prod, it seems like
> it's width should not affect the spacing of the R and the sin
Yes, as others have pointed out, this is normal TeX behavior.  The 
subscript affects the width of the entire vertical list.  If it didn't, 
it could bump into subscripts before and after.  (Think of  $R_i 
\prod_{i=\alpha_{i+1} $-- the subscripts would run together).  The TeX 
box model only supports a strict hierarchy of boxes within boxes 
(excepting shifting and kerning), and doesn't ever do any checks for 
boxes overlapping boxes with other parents.  (It's really a lot less 
smart than many, myself included, assume.)  The hacks that Gael and 
Jouni suggest may help, but aren't currently supported by the mathtext 
parser (though they could be fairly easily).  Exposing some of the 
low-level commands for TeX gurus might be useful in general, though I 
worry (somewhat abstractly) that since they will probably never behave 
100% like TeX, they will just disappoint.
> * Have you given any thought to the "cross font" kerning problem.
> Eg, if the parens comes from one file, and the 2 from another and the
> \pi from a 3rd, how to we kern "( 2 \pi )?
I haven't looked at how TeX does this yet, though I suspect the job is 
easier there, being that it has its own universe of math fonts that are 
built to work together.  The current implementation does kern 
consecutive characters of the same font and fontsize, but that's all.  I 
have noticed, though, that TeX kerns a lot less in math mode than one 
might expect.  For instance, $AVA$ isn't kerned at all (presumably to 
keep variables looking like separate entities), though $\rm AVA$ is. 
>
> * have you succeeded in get any non bakoma fonts to work, eg with the
> UnicodeFont code?
No, I haven't tried that yet.  I've certainly broken the UnicodeFont 
classes by changing the API a little bit.  Is there a font you would 
suggest that was known to work with the old mathtext that I should test 
with?
>
> Anyway, this is really great stuff.  Thanks!
It's been fun working through this.  You may want to check out 
mathtext_examples.py in my branch for examples that exercise other new 
features.

Cheers,
Mike

On 7/25/07, Michael Droettboom <md...@st...> wrote:

> It's been fun working through this.  You may want to check out
> mathtext_examples.py in my branch for examples that exercise other new
> features.

Maybe you haven't committed it?


johnh@flag:examples> pwd
/home/titan/johnh/python/svn/matplotlib/mathtext_mgd/examples
johnh@flag:examples> svn up
At revision 3613.
johnh@flag:examples> ls mathtext*.py
mathtext2_demo.py  mathtext_demo.py

JDH

John Hunter wrote:
> On 7/25/07, Michael Droettboom <md...@st...> wrote:
>
>> It's been fun working through this.  You may want to check out
>> mathtext_examples.py in my branch for examples that exercise other new
>> features.
>
> Maybe you haven't committed it?
Doh!  Try now.

Cheers,
Mike

It seems that the improvements finally allow users to mix mathtext with
ordinary text, as in 'foo $a=b^c+d$ bar', which I believe has been
requested a lot. This is really cool, but I think it causes another
backward incompatibility: you could use dollar signs in text strings
(except if you wanted a dollar sign both at the beginning and at the end
of a string), but now dollar signs only work if you use an odd number of
them.

My suggestion is to distinguish between mathtext and normal text at a
level outside the string. For example,

  text(['foo ', Math(r'a=b^c+d'), ' bar'])

where Math is a wrapper object that signals to "text" that its contents
are to be passed to the mathtext interpreter.

Or, Math could be a function that parses the string and returns a
lower-level description (presumably a hierarchy of boxes) that "text"
can then intersperse with the simple boxes containing the ordinary
strings. Then we could also have a LaTeX object that passes its argument
to an external LaTeX process, reads the resulting dvi file and returns 
a list of glyphs and rules that "text" knows how to draw on the canvas. 
In other words, formulas could be interpreted by the internal mathtext
parser or the external LaTeX process selectively, not via a single
global usetex switch.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Thursday 26 July 2007 5:54:18 pm Jouni K. Sepp=E4nen wrote:
> It seems that the improvements finally allow users to mix mathtext with
> ordinary text, as in 'foo $a=3Db^c+d$ bar', which I believe has been
> requested a lot. This is really cool, but I think it causes another
> backward incompatibility: you could use dollar signs in text strings
> (except if you wanted a dollar sign both at the beginning and at the end
> of a string), but now dollar signs only work if you use an odd number of
> them.
>
> My suggestion is to distinguish between mathtext and normal text at a
> level outside the string. For example,
>
>   text(['foo ', Math(r'a=3Db^c+d'), ' bar'])
>
> where Math is a wrapper object that signals to "text" that its contents
> are to be passed to the mathtext interpreter.

I would like to voice my opinion against this idea. I think the backward=20
imcompatibility will be rare, and does not justify the additionaly complexi=
ty=20
of the far more common need to interpret mathtext.

Darren

"John Hunter" <jd...@gm...> writes:

> I'm on the fence as to how to handle this case.  The majority of our
> users will think of $ as the US currency symbol, and will have never
> heard of TeX.

Those users are probably also not so likely to want to use mathtext, so
there could be an rc setting for toggling the meaning of $ between the
currency symbol and the math delimiter. Adding rc settings is probably
not good for the API, though.

Is it an option to use something rarer than $ to delimit formulas? Most
of the printable ASCII characters are probably being used by someone,
and the unprintable characters are likely to be difficult to handle. ISO
Latin 1 contains e.g. the little-used currency sign ¤. But perhaps it is
too difficult to type on US keyboards?

(There is a Unicode Technical Note at http://unicode.org/notes/tn28/
which suggests using U+23A8 LEFT CURLY BRACKET MIDDLE PIECE and U+23AC
RIGHT CURLY BRACKET MIDDLE PIECE as math delimiters, but it also has its
own Unicode-based math syntax.)

> Option 1 is to educate them, and require them to \$ quote that symbol.

I guess Option 1' is to move away from $ to something else, and educate
mathtext users. If there are fewer of them (us), this would seem to be
easier globally.

> I'm not too keen on the text(x, y, Math('string')) proposal, which is
> a little outside the normal matplotlib approach.

You're right that it would be quite different than the rest of the API.
Perhaps your Option 2 (a text property) would cause the least surprise
in the long run, although it would break current mathtext-using code.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Fri, Jul 27, 2007 at 08:38:49AM -0400, Michael Droettboom wrote:
> > text(x, y, 'what is the $\sin(x)$', mathtext=True)

> Except for the backward incompatibility, I like this because it is explicit.

Juust a data point for the discussion. I think it would be very nice if a
script gave the same result on a system with or without TeX (as long as
you don't do TeX hacks).

My 2 cents,

Gaël

Gael Varoquaux wrote:
> On Fri, Jul 27, 2007 at 08:38:49AM -0400, Michael Droettboom wrote:
>   
>>> text(x, y, 'what is the $\sin(x)$', mathtext=True)
>>>       
>
>   
>> Except for the backward incompatibility, I like this because it is explicit.
>>     
>
> Juust a data point for the discussion. I think it would be very nice if a
> script gave the same result on a system with or without TeX (as long as
> you don't do TeX hacks).
>   
Using this "mathtext=True" option (as opposed to using a delimiter that 
TeX doesn't understand) or something else entirely, would certainly make 
it easier to make usetex vs. not usetex more consistent.

More broadly, it will probably never be 100% compatible -- I don't think 
reimplementing all of TeX is feasible or desirable, and the fact that it 
is a macro language makes it hard to fully emulate.  Defining what is a 
"hack" vs. normal usage is also subjective, of course...

Cheers,
Mike

On Fri, Jul 27, 2007 at 08:52:27AM -0400, Michael Droettboom wrote:
> Using this "mathtext=True" option (as opposed to using a delimiter that 
> TeX doesn't understand) or something else entirely, would certainly make 
> it easier to make usetex vs. not usetex more consistent.

I think so to.

> More broadly, it will probably never be 100% compatible -- I don't think 
> reimplementing all of TeX is feasible or desirable, and the fact that it 
> is a macro language makes it hard to fully emulate.  Defining what is a 
> "hack" vs. normal usage is also subjective, of course...

No, of course, but you are making some progress in this direction, and I
think that would be a great added value coming from your work.

Cheers,

Gaël

I don't know if we ever reached consensus on how to specify math text 
vs. regular text.  I agree with Eric that it's down to two options: 
using a new kw argument (probably format="math" to be most future-proof) 
or Math('string').  I don't think I have enough "historical perspective" 
to really make the call but I do have a concern about the second option 
that it may be confusing depending on how "Math" is imported.  (It may 
have to be pylab.Math in some instances but not in others.)  But I don't 
have a strong objection.

Any last objections to going with the new keyword argument?

Cheers,
Mike

Eric Firing wrote:
> That leaves some variant of 2 [a keyword argument] and the Math('string') idea.  I find the 
> latter quite pythonic; it is a very concise, readable, and general way 
> of attaching extra information to a string object, and it does not 
> require passing yet another kwarg through a sequence of function and 
> method calls.  But if it is judged to be too out-of-character with the 
> rest of the mpl api, or if in practice it would cause trouble that I 
> don't see yet, then I am happy to let it go.  I have not thought it 
> through carefully, and I am not attached to it.
>
> If a variant of 2 is chosen, one might shorten the kwarg to "math".  Or 
> use "format='math'" or something like that.  This is more flexible than 
> a boolean kwarg, leaving the door open to additional options for 
> interpretation of strings--but not quite as flexible and powerful as the 
> math('string') idea.
>   

On 8/2/07, Michael Droettboom <md...@st...> wrote:
> I don't know if we ever reached consensus on how to specify math text
> vs. regular text.  I agree with Eric that it's down to two options:
> using a new kw argument (probably format="math" to be most future-proof)
> or Math('string').  I don't think I have enough "historical perspective"
> to really make the call but I do have a concern about the second option
> that it may be confusing depending on how "Math" is imported.  (It may
> have to be pylab.Math in some instances but not in others.)  But I don't
> have a strong objection.
>
> Any last objections to going with the new keyword argument?

I'm +1 on the kwarg approach -- it seems most consistent with our other usage.

On Thu, Aug 02, 2007 at 10:31:04AM -0400, Michael Droettboom wrote:
> I don't know if we ever reached consensus on how to specify math text 
> vs. regular text.  I agree with Eric that it's down to two options: 
> using a new kw argument (probably format="math" to be most future-proof) 
> or Math('string').  I don't think I have enough "historical perspective" 
> to really make the call but I do have a concern about the second option 
> that it may be confusing depending on how "Math" is imported.  (It may 
> have to be pylab.Math in some instances but not in others.)  But I don't 
> have a strong objection.
> 
> Any last objections to going with the new keyword argument?

I'm guessing that this discussion is already closed, but I would still
like to propose another option, just like the original: specify the
format in the string itself by requiring a leading '$'.  

For example:

   text(x, y, r'$\sin(x)$')

or for those functions not starting with math:

   text(x, y, r'$$phase $[0,2\pi)$')

This is a variant on Math(r'$\sin(x)$') which is a bit more compact.

As has been pointed out elsewhere, whether or not the string contains
tex markup is a property of the string, not a property of the function
that use the string. Note that the format keyword will be required for 
all functions which have string inputs, and may cause problems if there 
are multiple string inputs to the function.  legend() in particular may 
be a problem.

	- Paul

On 7/26/07, Darren Dale <dd...@co...> wrote:
> > where Math is a wrapper object that signals to "text" that its contents
> > are to be passed to the mathtext interpreter.
>
> I would like to voice my opinion against this idea. I think the backward
> imcompatibility will be rare, and does not justify the additionaly complexity
> of the far more common need to interpret mathtext.

I'm on the fence as to how to handle this case.  The majority of our
users will think of $ as the US currency symbol, and will have never
heard of TeX.   Option 1 is to educate them, and require them to \$
quote that symbol.  Option 2 is to enable a text property eg mathtext,
and do

text(x, y, 'what is the $\sin(x)$', mathtext=True)

Option 3 is to try and be clever, and interpret an even number of
unquoted dollar symbols as mathtext, or any string that has a quoted
dollar sign symbol as mathtext, else assume plain text.  Option 4 is
to treat *all* strings as mathtext, but I think we would pay a pretty
big performance hit to invoke the mathtext machinery for every piece
of text.  But it is an option.  In option 4, of course, users would be
required to quote all dollar signs, so it is related to option 1 but
slightly different in how it treats strings with no dollar signs.

I'm not too keen on the text(x, y, Math('string')) proposal, which is
a little outside the normal matplotlib approach.

Michael, do you have a preference or an alternate proposal?
JDH

[ That was meant for the list, sorry ]

On 7/26/07, John Hunter <jd...@gm...> wrote:

> I'm on the fence as to how to handle this case.  The majority of our
> users will think of $ as the US currency symbol, and will have never
> heard of TeX.   Option 1 is to educate them, and require them to \$
> quote that symbol.  Option 2 is to enable a text property eg mathtext,
> and do
>
> text(x, y, 'what is the $\sin(x)$', mathtext=True)
>
> Option 3 is to try and be clever, and interpret an even number of
> unquoted dollar symbols as mathtext, or any string that has a quoted
> dollar sign symbol as mathtext, else assume plain text.  Option 4 is
> to treat *all* strings as mathtext, but I think we would pay a pretty
> big performance hit to invoke the mathtext machinery for every piece
> of text.  But it is an option.  In option 4, of course, users would be
> required to quote all dollar signs, so it is related to option 1 but
> slightly different in how it treats strings with no dollar signs.
>
> I'm not too keen on the text(x, y, Math('string')) proposal, which is
> a little outside the normal matplotlib approach.
>
> Michael, do you have a preference or an alternate proposal?

I'm not Michael, but I s'pose I can still speak :)

This sounds to me like a good case for Guido's mantra of NOT putting
keywords in functions and instead just making two separate functions.
Why not just

text(x,y,"This year I lost a lot of $$$")
mtext(x,y,r"This year I lost \$$\infty$")

?  Explicit is better than implicit and all that...

cheers,

f

On Thursday 26 July 2007 9:05:41 pm Fernando Perez wrote:
> [ That was meant for the list, sorry ]
>
> On 7/26/07, John Hunter <jd...@gm...> wrote:
> > I'm on the fence as to how to handle this case.  The majority of our
> > users will think of $ as the US currency symbol, and will have never
> > heard of TeX.   Option 1 is to educate them, and require them to \$
> > quote that symbol.  Option 2 is to enable a text property eg mathtext,
> > and do
> >
> > text(x, y, 'what is the $\sin(x)$', mathtext=True)

But would this make sense:
text(x, y, 'what is the $\sin(x)$', mathtext=False)

[...]
> This sounds to me like a good case for Guido's mantra of NOT putting
> keywords in functions and instead just making two separate functions.
> Why not just
>
> text(x,y,"This year I lost a lot of $$$")
> mtext(x,y,r"This year I lost \$$\infty$")
>
> ?  Explicit is better than implicit and all that...

what about x/ylabels, titles, ticks, etc?

I think education is the best way to go. Its not that difficult to grasp, its 
an established standard... and we are designing tools primarily for 
scientists and engineers after all. Most of the other options will probably 
have a larger effect on existing code.

Darren

On 7/26/07, Darren Dale <dd...@co...> wrote:
> On Thursday 26 July 2007 9:05:41 pm Fernando Perez wrote:

> > This sounds to me like a good case for Guido's mantra of NOT putting
> > keywords in functions and instead just making two separate functions.
> > Why not just
> >
> > text(x,y,"This year I lost a lot of $$$")
> > mtext(x,y,r"This year I lost \$$\infty$")
> >
> > ?  Explicit is better than implicit and all that...
>
> what about x/ylabels, titles, ticks, etc?

Oh, I'd forgotten about all of those :)  Yes, this is pervasive across
MPL, I answered in haste.  Duplicating the entire text-related API may
be a tad much, perhaps ;)

> I think education is the best way to go. Its not that difficult to grasp, its
> an established standard... and we are designing tools primarily for
> scientists and engineers after all. Most of the other options will probably
> have a larger effect on existing code.

Well, I was trying to go with John's concern for non-latex users.  I'm
quite happy with a system that treats *every string* via latex.  But I
know for many reasons that's not realistic here (and PyX does
precisely that, if I really want it).



Cheers,

f

John Hunter wrote:
> Option 1 is to educate them, and require them to \$
> quote that symbol.  Option 2 is to enable a text property eg mathtext,
> and do
>
> text(x, y, 'what is the $\sin(x)$', mathtext=True)
>   
Except for the backward incompatibility, I like this because it is explicit.
> Option 3 is to try and be clever, and interpret an even number of
> unquoted dollar symbols as mathtext, or any string that has a quoted
> dollar sign symbol as mathtext, else assume plain text.
That's close to what it does at the moment.
>   Option 4 is
> to treat *all* strings as mathtext, but I think we would pay a pretty
> big performance hit to invoke the mathtext machinery for every piece
> of text.  But it is an option.
I'm not sure the performance hit would be so bad.  The parser is 
completely flat until it goes between the $'s.  But it would require all 
$'s to be escaped, of course.
>   In option 4, of course, users would be
> required to quote all dollar signs, so it is related to option 1 but
> slightly different in how it treats strings with no dollar signs.
>
> I'm not too keen on the text(x, y, Math('string')) proposal, which is
> a little outside the normal matplotlib approach.
>
> Michael, do you have a preference or an alternate proposal?
>   
Well, that certainly is no shortage of options! ;)  I think the decision 
should ultimately lie with someone with a better sense of the existing 
"feel" of matplotlib than I.

If we go with another delimiter, there are others in TeX to choose 
from.  Plain TeX uses $$ for display math, and LaTeX uses \[, \].  Both 
of these are less likely to be legitimate literals.  While display math 
normally implies that the math is placed on a separate line (not inline 
with the text), it's not far from what matplotlib does, since it follows 
the display math layout patterns.

Cheers,
Mike

On Friday 27 July 2007 08:38:49 am Michael Droettboom wrote:
> If we go with another delimiter, there are others in TeX to choose
> from.  Plain TeX uses $$ for display math, and LaTeX uses \[, \].  Both
> of these are less likely to be legitimate literals.  While display math
> normally implies that the math is placed on a separate line (not inline
> with the text), it's not far from what matplotlib does, since it follows
> the display math layout patterns.

I think $$ might be a bad idea, that has a very specific meaning in TeX, which 
is different than $. Like wise, \[ means display math while \( means inline 
math. \( ... \) is considered to be fragile, while $ ... $ is robust, but 
maybe \( \) would be a good solution. Then you could even switch between 
mathtext and usetex, and the usetex code wouldnt have to go through strings 
trying to substitute latex mathmode indicators for mpl indicators.

Darren

John Hunter wrote:
> On 7/26/07, Darren Dale <dd...@co...> wrote:
>>> where Math is a wrapper object that signals to "text" that its contents
>>> are to be passed to the mathtext interpreter.
>> I would like to voice my opinion against this idea. I think the backward
>> imcompatibility will be rare, and does not justify the additionaly complexity
>> of the far more common need to interpret mathtext.
> 
> I'm on the fence as to how to handle this case.  The majority of our
> users will think of $ as the US currency symbol, and will have never
> heard of TeX.   Option 1 is to educate them, and require them to \$
> quote that symbol.  Option 2 is to enable a text property eg mathtext,
> and do
> 
> text(x, y, 'what is the $\sin(x)$', mathtext=True)
> 
> Option 3 is to try and be clever, and interpret an even number of
> unquoted dollar symbols as mathtext, or any string that has a quoted
> dollar sign symbol as mathtext, else assume plain text.  Option 4 is
> to treat *all* strings as mathtext, but I think we would pay a pretty
> big performance hit to invoke the mathtext machinery for every piece
> of text.  But it is an option.  In option 4, of course, users would be
> required to quote all dollar signs, so it is related to option 1 but
> slightly different in how it treats strings with no dollar signs.
> 
> I'm not too keen on the text(x, y, Math('string')) proposal, which is
> a little outside the normal matplotlib approach.
> 
> Michael, do you have a preference or an alternate proposal?
> JDH

Let's rule out option 3 completely; it is an example of the type of 
cleverness that ends up causing more trouble and confusion than it is worth.

I also oppose using something other than the $ to delimit math, if 
delimiters are needed, which I think they are.  At least in *Tex, a 
string of characters (a word) is rendered very differently depending on 
whether it is inside an equation or outside.

I suspect that options 1 and 4 will cause endless questions to 
matplotlib-users, and grumbling among people in the business and 
financial community who use lots of dollar signs and no math.

That leaves some variant of 2 and the Math('string') idea.  I find the 
latter quite pythonic; it is a very concise, readable, and general way 
of attaching extra information to a string object, and it does not 
require passing yet another kwarg through a sequence of function and 
method calls.  But if it is judged to be too out-of-character with the 
rest of the mpl api, or if in practice it would cause trouble that I 
don't see yet, then I am happy to let it go.  I have not thought it 
through carefully, and I am not attached to it.

If a variant of 2 is chosen, one might shorten the kwarg to "math".  Or 
use "format='math'" or something like that.  This is more flexible than 
a boolean kwarg, leaving the door open to additional options for 
interpretation of strings--but not quite as flexible and powerful as the 
math('string') idea.

Eric

On Thursday 02 August 2007 10:42:17 am John Hunter wrote:
> On 8/2/07, Michael Droettboom <md...@st...> wrote:
> > I don't know if we ever reached consensus on how to specify math text
> > vs. regular text.  I agree with Eric that it's down to two options:
> > using a new kw argument (probably format="math" to be most future-proof)
> > or Math('string').  I don't think I have enough "historical perspective"
> > to really make the call but I do have a concern about the second option
> > that it may be confusing depending on how "Math" is imported.  (It may
> > have to be pylab.Math in some instances but not in others.)  But I don't
> > have a strong objection.
> >
> > Any last objections to going with the new keyword argument?
>
> I'm +1 on the kwarg approach -- it seems most consistent with our other
> usage.

Maybe the keyword should be format="TeX"? Or texformatting=True? Maybe it 
would be appropriate to have the kwarg default to None, and if None reference 
an rcoption like text.texformatting? That might be the least disruptive all 
around.

Darren