matplotlib-devel Mailing List for matplotlib

>>>>> "Stephen" == Stephen Walton <ste...@cs...> writes:
 Stephen> John, this is incredible. For those of you who haven't
 Stephen> tried the demo from CVS yet, it looks to naive me like
 Stephen> John's achieved the Holy Grail of putting arbitrary TeX
 Stephen> into labels in matplotlib. MATLAB doesn't do this,
 Stephen> probably never will. Wow.
Yes, this is the basic idea. While I like the idea of finding the
Holy Grail, in deference to those who came before me, I must admit
that this is not entirely novel. It is basically what psfrag was
written for. xmgrace has had the ability to do this for many years,
and the psfrag manual has an explicit example showing how to do this
with Matlab. The beauty of psfrag is that you can use it with almost
any plotting package -- all you have to do is set up a dictionary
mapping a sentinel string to a TeX string, eg
"replacethistext"->"\TeX", and figure out where to place the sentinel
strings (this is the hard part, see below), and psfrag will do the
rest.
Where the matplotlib implementation is a tiny bit clever is in the
layout. Since we support left/middle/right and bottom/middle/top
alignment as well as rotated strings, we have to have a good estimate
of the text bounding box to do the layout. What the mpl texmamanger
does is tex the string independently, call dvips on the tex output,
and then parse the generated postscript header to extract the bounding
box for layout. With caching using hashes on the TeX string for
efficiency, yada yada...
This is currently broken because it doesn't account properly for
font sizes or rotation, yet, but this is readily fixable...
Also, FYI, I have been working on integrating TeX with Agg via dvipng.
This is also experimental, but if you want to play with it, set the rc
param in .matplotlibrc CVS
 text.usetex : True # experimental, broken
and run the tex demo. Small font sizes don't render well because of
problems in the way I am handling alpha and antialiasing in the dvipng
output, but if you set your font size or dpi high enough these
problems are negligible. Again, rotation is not yet supported. The
Holy Grail, of course, is to support raster (Agg) and vector (PS) TeX
text for all text elements transparently, falling back on an improved
mathtext layout with better fonts when TeX is not available....
JDH

>>>>> "Ted" == Ted Drain <ted...@jp...> writes:
 Ted> Ahhh - Thanks! I was wondering if both axes would scale when
 Ted> doing a zooming operation but I hadn't had time to try it
 Ted> out. Thanks for the example, that's exactly what I was
 Ted> looking for.
 >> On the contrary, you should use twinx for that, as follows:
Baptiste, this is an exceedingly clever solution which wouldn't have
occurred to me, but I suspect it is a clever hack designed to work
around a design flaw. One shouldn't have to be so clever to do
something so simply stated as Ted's original request. Would it not be
better to support (optionally) a different tick labeler and formatter
for bottom/top and left/right?
But this too is the wrong question....
In truth, what we want is to be able to have an arbitrary number of
Axis lines, each with their own tick locator and formatter, which can
be placed at an arbitrary location (arbitrary for an x-axis means a
horizontal line at an arbitrary y-location which spans the x data
range). In this view, the current y=0 for bottom and y=1 for top are
just two special cases for the x-axis; in general we want to be able
to place these suckers anywhere and to control their tick locating and
formatting independently.
This raises the question of how we should specify the location of the
axis line. For concreteness, let's just consider the x axis line and
how we should specify its y location. In the current implementation,
there are only two possible y locations, at 0 and 1 for bottom and
top. Most of the time, this is just what you want, eg, you want the
axis line to remain fixed at the bottom when changing the y pan or
zoom. But it seems that sometimes you also want the y location of the
x axis to be placed in data coords, and sometimes you want it in
places other than the top and bottom. 
Several use cases point to the need to make the axis line (and it's
associated ticks and labels) independent objects that can be
customized. In particular, I have seen Eric Jones demonstrate in
Chaco several times the ability to have multiple y axis objects --
apparently this is something frequently needed in the petroleum
industry. Also, Andrew Straw has posted examples in which he wants to
decouple the axis line from the rectangular box defining the data
clipping box.
When this issue came up previously, I've noted that this is a good use
for traits. But lazy values, properly utilized, could serve as well.
The basic problem to be solved is that we need to have a mechanism so
that when an axis line is moved, eg by a set call at the user level,
the associated ticks and labels move with it. Whether this is done
with traits observer/delegation or shared lazy values is not too
important. 
But a refactoring of axis, tick and labeling is long overdue...
JDH

John Hunter wrote:
>In honor of Darren trying to get his thesis printed using mpl figures,
>and encountering a lot of pain with fonts and mathtext, I added a
>psfrag latex backend today.
>
John, this is incredible. For those of you who haven't tried the demo 
from CVS yet, it looks to naive me like John's achieved the Holy Grail 
of putting arbitrary TeX into labels in matplotlib. MATLAB doesn't do 
this, probably never will. Wow.
OK, enough groveling.