On 8/21/07, Michael Droettboom <[EMAIL PROTECTED]> wrote: > Darren Dale wrote: > >> 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). > > > > This seems like a bad idea. If I want to use tex as my text layout engine, > > now > > I have two settings to keep track of. We'll get lots of posts asking why > > latex is not being used when usetex is True. > > I agree with this point. My counter-worry is that people may be > surprised when their dollar signs behave differently when usetex is on > or off. Maybe people don't change that setting all that often in > practice, though... We could (and I'm not necessarily advocate this), > pre-process the string sent to LaTeX when usetex is True and markup == > 'plain', so that the dollar signs are escaped (and will appear as dollar > signs in the output). > > >> 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) > > > > This seems reasonable. Although, if we make it so latex can be used to > > layout > > some text but not others, I worry that we will get no end of posts > > complaining about how the latex fonts dont match the mathtext or normal > > fonts. > > Agreed. > > >> 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? > > > > I think b) fits best. Maybe backward compatibility can be maintained. usetex > > would be deprecated, and would set the text_renderer rcParam to latex when > > True. > > That seems like a good approach, if we go with option b). > > > Or does 0.90.1 already have the markup kwarg? > > The markup kwarg is only a couple weeks old. > > > Again, there must be a > > way. The new validation mechanism in rcParams (not traits, the stuff I did > > right before traits) could probably provide a route for transition without > > actually breaking anything. > > Good point. > > > I am pretty busy this week at work, and will be > > on vacation for 11 days starting August 24, just letting you know. > > Thanks. I don't think there's a huge rush to decide this (the > implementation should be straightforward no matter what we decide). But > it would make sense to sort this out before the next release.
Sorry to jump in late on this discussion again -- I was just trying to use the new mathtext and ran into this use case ax.plot(something, label=r'$\alpha=1'$) ax.legend() Paul mentioned earlier in his objection to the markup kwarg that legend would be a problem, and there will probably be other cases too. I suggested once before that we adopt something like the following rule: if a string has one dollar sign, treat it as plain text. If it has more that one unquoted dollar sign, treat it as TeX, and use mathtext or usetex depending on rc. I know Eric objected that this kind of complexity can make things unpleasant and lead to some difficult to debug oddities, but I think this is a case where convenience trumps complexity. I would like the rescind my earlier vote (now that I am trying to actually use this stuff for real work) and support mathtext w/o kwark markup. To support the use case above with svn, will I need to get the text instances back from the legend and set the markup property on them? JDH ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
