Sorry for taking so long to respond -- I was at SciPy and wanted to make sure I had the time to sit down and look at this before responding.
Paul Kienzle 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\)')
Unfortunately, this will break if text.usetex is True. Double-dollar signs in LaTeX delimits "display math" mode.
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.
I agree with you in a semantic sense. However, does that distinction really matter at the end of the day? Couldn't the same argument be made for the color or font of the text? All of them have to do with how the string is rendered. I think the oddball (for matplotlib) nature of this syntax and the import namespace details make this at least equally as cumbersome as the "markup" keyword. But it's subjective, and I'm willing to change the code if there's consensus on this.
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.
legend() doesn't currently accept a "markup" keyword, but obviously it should (if we decide to stick with the "markup" keyword). (And there are undoubtedly more holes like this to plug up). However, I don't know if it is necessary to specify the markup of each individual legend string, now that math can be easily interleaved with non-math. Isn't that just adding options where none is needed?
As I see it, the only reason to have this stuff optional at all is because it's surprising for '$'s to be delimiters. Performance is a very minor issue. I "benchmarked" global mathtext vs. optional mathtext on the "backend_driver.py" script (which admittedly is not a great benchmark, but it's something), and the timing differences seem to be below the noise threshold:
all math: 0.78s 0.67s 0.72s
optional math: 0.72s 0.75s 0.68s
So I don't see why in a legend you would want some labels to be interpreted as having math and some without. If you need a real dollar sign, with math on, you can always use "\$".
On a related note, there was a recent thread on matplotlib-users about usetex being a global setting:
http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg04101.html
I'm concerned about consistency and/or redundancy between this and the new markup kwarg. I don't know whether or not "usetex" being "all-or-nothing" is desirable. But we could meet in the middle by doing one of the following:
a) only send text to LaTeX for rendering when text.usetex=True and markup="tex". (Which makes usetex=True behave a little more like usetex=False).
b) add another value to markup, to render text with LaTeX. (If we do, I would suggest changing the kwarg to "text_renderer" and having the values be "normal", "mathtext" and "latex" or something)
c) make markup="tex" be all-or-nothing as well (that is, keep the rcParam, but drop the kwarg.) With this flag, you're basically saying "I know how to deal with $'s".
b) is probably the most flexible (maybe too flexible, as I can't see why one would want to use all three types of rendering in the same plot). a) and b) would break backward compatibility with 0.90.1, while c) would not.
Any thoughts?
Cheers,
Mike
···
On Thu, Aug 02, 2007 at 10:31:04AM -0400, Michael Droettboom wrote: