matplotlib-devel Mailing List for matplotlib

>>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
 Nicholas> I think it's partly in there in a non-functional form,
 Nicholas> the patch I've attached removes it and adds a new
 Nicholas> function to the Axes class called directshow. This
 Nicholas> accepts the same syntax as imshow (where relevant)
 Nicholas> rather than adding options to imshow; I chose to do this
 Nicholas> as my old syntax for passing through imshow wasn't that
 Nicholas> easy to understand didn't makes the different
 Nicholas> functionality clear. This function calls a class call
 Nicholas> DirectImage which inherits from AxesImage.
I have mixed feelings about making this a separate class / separate
function. The current axes imshow / image.AxesImage is already
overloaded (handling MxN, MxNx3, MxNx3, _image.Image and PIL images.
What is the logic of making a special functions/classes case for MxNx4
with directshow. On the one hand, I appreciate the desire to simplify
the code by pulling it into separate classes and functions. On the
other hand, I wonder if it will confuse users to have one separate
function for UInt8 images and another for everything else. Another
worry I have about the separate DirectImage class is that it copies
much of the image resize functionality from AxesImage, including the
broken handling of aspect='preserve'. This too argues for keeping as
much functionality in AxesImage as possible, testing for A.typecode()
where appropriate. What do you think?
Also, note the matplotlib CVS has added several new image
interpolation methods. Some of these need the parameters
 filternorm=1,
 filterrad=4.0
as described in the imshow docstring. Since directimage exposes the
interpolation method, shouldn't it also expose these new params.
 Nicholas> I've also rewritten my c++ image object creation
 Nicholas> function called frombyte to take an unsigned byte array
 Nicholas> as input rather than a buffer. By using the
 Nicholas> std::memcopy function rather than a loop for copying the
 Nicholas> speed advantage of passing data in as a buffer
 Nicholas> disappears and using arrays is generally more intuitive.
 Nicholas> The function still only takes x*y*4 arrays as input at
 Nicholas> the moment as the processor time decrease from not using
 Nicholas> loops to copy is fairly significant.
Looks good to me. I'll hold off on applying these changes until I
hear from you on the issues above.
Thanks!
JDH

>>>>> "Daishi" == Daishi Harada <da...@eg...> writes:
 Daishi> Hi John, I've uploaded some new files to sourceforge.
 Daishi> On May 26, 2005, at 7:34 PM, John Hunter wrote:
 >> My only suggestions are: 1) move the dash text class to the
 >> text module rather than the axis module (where it seems to
 >> belong since it is a general purpose connector between a text
 >> instance and a point), and
 Daishi> Done. I also slightly modified axes.py to facilitate
 Daishi> providing your suggestion 2).
I've added the changes to CVS text.py revision: 1.27
Thanks again!
JDH

Jeff,
> Eric: Thanks - contour indeed now seems to work perfectly with masked 
> arrays, but I still have problems with contourf (see attached 
> ortho_test.png). Unfortunately, neither of your suggested workarounds 
> help, the first makes no difference and the second makes it much worse.
> -Jeff
It is not working in your basemap/examples/contour_demo.py, either, so 
this does not seem to be exclusively a masked array support problem. I 
hope I can figure it out.
Eric

I sent this message sometime on Friday but as it doesn't seem to have made it to the sourceforge list yet I'm assuming it's not going to and trying again.
On Thu, 2005年05月26日 at 21:15 -0500, John Hunter wrote:
> >>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
> 
> Nicholas> Hi, I made a suggestion for improving imshow performance
> Nicholas> for plotting an image already in byte string form a
> Nicholas> while ago; some of the results are currently in CVS. I
> Nicholas> seems that other changes made to CVS at the same time or
> Nicholas> since mean that the floating point buffer source code is
> Nicholas> now much faster and I'd suggest taking anything sourced
> Nicholas> from my code back out.
> 
> Maybe that explains why I was never able to get the same performance
> benefits you were seeing.... But I was able to get 1.5x - 2.5x faster
> with your patch, which is pretty damned good. And the memory
> benefit of your patch could be substantial as well. Why pull it?
When I first tried the new CVS code (other than my own) I was rather
rushed trying to get a paper finished and tested with too small an image
and thus saw too small a speedup for it to be worth it. I'm also using
non-contiguous arrays which make the relative speed increase smaller. I
also didn't think the interface was particularly user friendly.
I'm now sure why my code was faster (a mixture of data copying using
optimised functions and no need do floating point to integer conversion)
and have written some new code which is slightly faster than the old and
has a nicer interface (patch to CVS attached).
> What are your latest profiling numbers?
Profiling with my latest version and comparing to CVS I get:
Running with 1024x1024:
Starting array:
 Array set up: resident stack size: 37408, size: 12571
 Tests done: resident stack size: 41536, size: 13596
 Elapsed: 7.674
Starting byte:
 Byte set up: resident stack size: 12876, size: 6429
 Tests done: resident stack size: 12880, size: 6428
 Elapsed: 0.521
Fractional improvement: 13.724
Running with 2048x2048:
Starting array:
 Array set up: resident stack size: 143956, size: 39197
 Tests done: resident stack size: 156252, size: 42269
 Elapsed: 29.577
Starting byte:
 Byte set up: resident stack size: 37464, size: 12573
 Tests done: resident stack size: 37464, size: 12572
 Elapsed: 2.098
Fractional improvement: 13.100
Running with 4096x4096:
Starting array:
 Array set up: resident stack size: 561756, size: 143646
 Tests done: resident stack size: 609388, size: 155963
 Elapsed: 127.401
Starting byte:
 Byte set up: resident stack size: 66376, size: 37178
 Tests done: resident stack size: 132280, size: 37177
 Elapsed: 8.526
Fractional improvement: 13.943
> Your patch came in just at the time I was leaving for Paris for a
> meeting, after which I experienced a rather nasty total hard drive
> failure that set me back in my mpl maintenance. I am not sure I am
> ready to give up on the ideas you introduced.... Can you remind me --
> did I manage to incorporate all of the matplotlib.axes and
> matplotlib.image patches I needed to take advantage of your patches to
> the _image extension code?
I think it's partly in there in a non-functional form, the patch I've
attached removes it and adds a new function to the Axes class called
directshow. This accepts the same syntax as imshow (where relevant)
rather than adding options to imshow; I chose to do this as my old
syntax for passing through imshow wasn't that easy to understand didn't
makes the different functionality clear. This function calls a class
call DirectImage which inherits from AxesImage.
I've also rewritten my c++ image object creation function called
frombyte to take an unsigned byte array as input rather than a buffer.
By using the std::memcopy function rather than a loop for copying the
speed advantage of passing data in as a buffer disappears and using
arrays is generally more intuitive. The function still only takes x*y*4
arrays as input at the moment as the processor time decrease from not
using loops to copy is fairly significant.
Nick

Eric Firing wrote:
> John,
>
> The attached diff contains a bugfix for the masking problem that Jeff 
> found:
>
> diff -Naur cntr.c_as_sent cntr.c > cntr_bugfix.diff
>
> where cntr.c_as_sent is the old version, cntr.c is the corrected version.
>
> I was simply not transferring the information correctly from the mask 
> to the "reg" array that cntr.c uses; I was setting a value, and then 
> accidentally overwriting it with what should have been an initialization.
>
> With this patch, masked arrays should be handled no better and no 
> worse than before the change from gcntr.c to cntr.c; as far as I know, 
> masking works perfectly for line contours, and it works correctly for 
> filled contours under many but not all circumstances. I tried two 
> workarounds for the latter problem:
>
> 1) in line 1359 of cntr.c, change the nchunk variable from 30 to a 
> much smaller value.
> long nchunk = 30; /* hardwired for now */
> This causes the generation of many small polygons, so it may slow 
> things down quite a bit, and it causes the boundaries to look a little 
> glitchy on the screen (gtkagg); but I haven't done timing tests, and I 
> haven't tried other backends.
>
> 2) change the end of ContourSupport._contour_args(), in contour.py:
>
> self.ax.set_xlim((ma.minimum(x), ma.maximum(x)))
> self.ax.set_ylim((ma.minimum(y), ma.maximum(y)))
> # Workaround for cntr.c bug wrt masked interior regions:
> #if filled:
> # z = ma.masked_array(z.filled(-1e38))
> # It's not clear this is any better than the original bug.
> return (x, y, z, lev)
>
> The workaround is to uncomment the "if filled:" block. This method 
> also works, but can leave some artifacts around the boundary of the 
> bad region.
>
> I am not recommending that either of these workarounds be added to 
> CVS, but if some individual runs into major trouble because of the 
> bug, then either of these methods could be used as a stopgap on an 
> individual basis.
>
> Eric
>
Eric: Thanks - contour indeed now seems to work perfectly with masked 
arrays, but I still have problems with contourf (see attached 
ortho_test.png). Unfortunately, neither of your suggested workarounds 
help, the first makes no difference and the second makes it much worse. 
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/CDC1 FAX : (303)497-6449
325 Broadway Web : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

John,
The attached diff contains a bugfix for the masking problem that Jeff found:
diff -Naur cntr.c_as_sent cntr.c > cntr_bugfix.diff
where cntr.c_as_sent is the old version, cntr.c is the corrected version.
I was simply not transferring the information correctly from the mask to 
the "reg" array that cntr.c uses; I was setting a value, and then 
accidentally overwriting it with what should have been an initialization.
With this patch, masked arrays should be handled no better and no worse 
than before the change from gcntr.c to cntr.c; as far as I know, masking 
works perfectly for line contours, and it works correctly for filled 
contours under many but not all circumstances. I tried two workarounds 
for the latter problem:
1) in line 1359 of cntr.c, change the nchunk variable from 30 to a much 
smaller value.
 long nchunk = 30; /* hardwired for now */
This causes the generation of many small polygons, so it may slow things 
down quite a bit, and it causes the boundaries to look a little glitchy 
on the screen (gtkagg); but I haven't done timing tests, and I haven't 
tried other backends.
2) change the end of ContourSupport._contour_args(), in contour.py:
 self.ax.set_xlim((ma.minimum(x), ma.maximum(x)))
 self.ax.set_ylim((ma.minimum(y), ma.maximum(y)))
 # Workaround for cntr.c bug wrt masked interior regions:
 #if filled:
 # z = ma.masked_array(z.filled(-1e38))
 # It's not clear this is any better than the original bug.
 return (x, y, z, lev)
The workaround is to uncomment the "if filled:" block. This method also 
 works, but can leave some artifacts around the boundary of the bad region.
I am not recommending that either of these workarounds be added to CVS, 
but if some individual runs into major trouble because of the bug, then 
either of these methods could be used as a stopgap on an individual basis.
Eric
John Hunter wrote:
>>>>>>"Jeff" == Jeff Whitaker <js...@fa...> writes:
> 
> 
> Jeff> The basemap toolkit relies on the 'badmask' parameter in
> Jeff> contour/contourf to mask out areas outside the desired map
> Jeff> projection region in matplotlib 0.80. It works quite
> Jeff> well. Unfortunately, the new masked array support in CVS
> Jeff> doesn't (I get all kinds of weird artifacts, especially for
> Jeff> contourf but also for contour). Can the old badmask
> Jeff> functionality be added back in for 0.81, at least
> Jeff> temporarily until the masked array support stabilizes?
> 
> I don't have anything to add to this, I'm just replying so I can CC
> Eric Firing, who added the masked array support to contour, because I
> don't know if he is on the devel list.
> 
> JDH

John, Jeff,
Yes, I am on the matplotlib-devel list.
Coincidentally, while walking in to work yesterday, a possible 
workaround for the long-standing contourf mask bug occurred to me. In 
the process of testing it, I found that masking was not working as 
expected for either contour or contourf. I had done a little testing 
before sending in cntr.c and related changes, but obviously I missed the 
problem then. The cause should be quite simple and localized. I think I 
can track it down and come up with a clean fix, so that at worst only 
the original contourf bug remains (and maybe the workaround for that 
will, indeed, work). Please allow me a little time to work on this.
Eric
John Hunter wrote:
>>>>>>"Jeff" == Jeff Whitaker <js...@fa...> writes:
> 
> 
> Jeff> The basemap toolkit relies on the 'badmask' parameter in
> Jeff> contour/contourf to mask out areas outside the desired map
> Jeff> projection region in matplotlib 0.80. It works quite
> Jeff> well. Unfortunately, the new masked array support in CVS
> Jeff> doesn't (I get all kinds of weird artifacts, especially for
> Jeff> contourf but also for contour). Can the old badmask
> Jeff> functionality be added back in for 0.81, at least
> Jeff> temporarily until the masked array support stabilizes?
> 
> I don't have anything to add to this, I'm just replying so I can CC
> Eric Firing, who added the masked array support to contour, because I
> don't know if he is on the devel list.
> 
> JDH

>>>>> "Jeff" == Jeff Whitaker <js...@fa...> writes:
 Jeff> The basemap toolkit relies on the 'badmask' parameter in
 Jeff> contour/contourf to mask out areas outside the desired map
 Jeff> projection region in matplotlib 0.80. It works quite
 Jeff> well. Unfortunately, the new masked array support in CVS
 Jeff> doesn't (I get all kinds of weird artifacts, especially for
 Jeff> contourf but also for contour). Can the old badmask
 Jeff> functionality be added back in for 0.81, at least
 Jeff> temporarily until the masked array support stabilizes?
I don't have anything to add to this, I'm just replying so I can CC
Eric Firing, who added the masked array support to contour, because I
don't know if he is on the devel list.
JDH

The basemap toolkit relies on the 'badmask' parameter in 
contour/contourf to mask out areas outside the desired map projection 
region in matplotlib 0.80. It works quite well. Unfortunately, the new 
masked array support in CVS doesn't (I get all kinds of weird artifacts, 
especially for contourf but also for contour). Can the old badmask 
functionality be added back in for 0.81, at least temporarily until the 
masked array support stabilizes?
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/CDC1 FAX : (303)497-6449
325 Broadway Web : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

Hi John,
I've uploaded some new files to sourceforge.
On May 26, 2005, at 7:34 PM, John Hunter wrote:
> My only suggestions
> are: 1) move the dash text class to the text module rather than the 
> axis
> module (where it seems to belong since it is a general purpose
> connector between a text instance and a point), and
Done. I also slightly modified axes.py to facilitate providing
your suggestion 2).
> 2) provide an example
> which uses a generic text instance in addition to the one you provided
> using a tick label text instance.
Please see the new example, which I'm attaching below.
As I note in the script which generated the plot, the various
rotations are meant to show the possibilities, rather than
for visual appeal.
> As for the alignment problems (in agg or ps at least), they may be a
> result of sf bugs #1194018 and #1177396.
I also think the current rendering when separate rotations for
the text and the dash are specified is suboptimal (I show
examples of this in the new example plot), but the current code
satisfies my immediate use case, so I'm hoping that if/as this
extension gets incorporated into the matplotlib codebase,
others will find that improving the current rotation/transformation
logic will be an itch that they want to scratch.
Thx,
d
ps. FWIW, the last letter in my name is an 'i', not an 'a'.
(I edited the CHANGELOG to reflect this)

>>>>> "Daishi" == Daishi Harada <da...@eg...> writes:
 Daishi> Please let me know if there are any modifications to the
 Daishi> patch which would make it a better candidate for
 Daishi> incorporation into the mainline source.
Hey Daishi,
That is certainly a nice patch and a funky example -- well done.
I was very pleased to see that you added this as a general text
feature and not a feature of text ticks only. My only suggestions
are: 1) move the dash text class to the text module rather than the axis
module (where it seems to belong since it is a general purpose
connector between a text instance and a point), and 2) provide an example
which uses a generic text instance in addition to the one you provided
using a tick label text instance.
Changes are in CVS -- perhaps you can send me a patch against the
latest revision?
As for the alignment problems (in agg or ps at least), they may be a
result of sf bugs #1194018 and #1177396.
Thanks!
JDH

>>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
 Nicholas> Hi, I made a suggestion for improving imshow performance
 Nicholas> for plotting an image already in byte string form a
 Nicholas> while ago; some of the results are currently in CVS. I
 Nicholas> seems that other changes made to CVS at the same time or
 Nicholas> since mean that the floating point buffer source code is
 Nicholas> now much faster and I'd suggest taking anything sourced
 Nicholas> from my code back out.
Maybe that explains why I was never able to get the same performance
benefits you were seeing.... But I was able to get 1.5x - 2.5x faster
with your patch, which is pretty damned good. And the memory
benefit of your patch could be substantial as well. Why pull it?
What are your latest profiling numbers?
Your patch came in just at the time I was leaving for Paris for a
meeting, after which I experienced a rather nasty total hard drive
failure that set me back in my mpl maintenance. I am not sure I am
ready to give up on the ideas you introduced.... Can you remind me --
did I manage to incorporate all of the matplotlib.axes and
matplotlib.image patches I needed to take advantage of your patches to
the _image extension code?
JDH

Hi,
I've posted a patch on sourceforge that extends tick
labels to allow for a dash of user-specified length
to come between the text label and the actual tick.
I'm attaching an example plot below. (The script
to generate this example is on sourceforge).
The alignment of the dash with the text is less
than ideal in the PNG output, but it appears that
the font-metrics are backend dependent - the
quality of the alignment seems to differ based
on the selected backend.
Please let me know if there are any modifications
to the patch which would make it a better candidate
for incorporation into the mainline source.
Thanks,
d

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> I'm guessing TeX will meet most layout needs. For example,
 Darren> I just discovered the \over command, which will generate
 Darren> fractions in TeX and LaTeX. \frac only works for LaTeX. I
 Darren> will make tex/latex an rc param if you want. Let me know.
frac was the only use case I thought important. If over can do it I
am fine leaving it as TeX. We can generalize later if need be.
JDH

On Tuesday 24 May 2005 5:27 pm, you wrote:
> >>>>> "Darren" =3D=3D Darren Dale <dd...@co...> writes:
>
> Darren> This is expected behavior for PSfrag. You should instead
> Darren> wrap \includegraphics in either a \resizebox or a
> Darren> \scalebox to rescale the text with the figure.
>
> Can you do this?
Yes. backend_latex writes this command to the .tex file, hopefully to guide=
=20
users on how to scale their images:
\scalebox{1}{\includegraphics{<myfile.eps>}}
>
> Darren> It looks like tex_demo.py, without caching, takes about
> Darren> 30% longer with LaTeX than it does for Tex (3 seconds vs
> Darren> 2.3 seconds on my computer). So CVS is back to using
> Darren> TeX. We may want to include a link (or a copy) of this pdf
> Darren> on the MPL website:
> Darren> http://www.csit.fsu.edu/~mimi/tex/tex-refcard.pdf, the
> Darren> source declares it to be freely distributed.
>
> Can tex|latex be an rc param?
I'm guessing TeX will meet most layout needs. For example, I just discovere=
d=20
the \over command, which will generate fractions in TeX and LaTeX. \frac on=
ly=20
works for LaTeX. I will make tex/latex an rc param if you want. Let me know.
Darren

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> This is expected behavior for PSfrag. You should instead
 Darren> wrap \includegraphics in either a \resizebox or a
 Darren> \scalebox to rescale the text with the figure.
Can you do this?
 Darren> It looks like tex_demo.py, without caching, takes about
 Darren> 30% longer with LaTeX than it does for Tex (3 seconds vs
 Darren> 2.3 seconds on my computer). So CVS is back to using
 Darren> TeX. We may want to include a link (or a copy) of this pdf
 Darren> on the MPL website:
 Darren> http://www.csit.fsu.edu/~mimi/tex/tex-refcard.pdf, the
 Darren> source declares it to be freely distributed.
Can tex|latex be an rc param?
JDH

On Tuesday 17 May 2005 6:44 pm, John Hunter wrote:
> The LaTeX backend generates a *.eps file and a *.tex file. You can
> then latex and dvips the tex file to get a true ps, or just embed the
> generated latex commands directly into your document. This uses latex
> for all text elements, giving a unified font look and feel.
>
> Here is an example
>
> > python examples/tex_demo.py -dLaTeX
> > latex tex_demo.tex
> > dvips -o tex_demo.ps tex_demo.dvi
> > ggv tex_demo.ps
>
> There are a few problems
>
> * the page width and figure placement in the latex document are off
> center
Maybe not. If you use a latex centering environment, I think the figure is=
=20
centered. Even in a centering environment, it may still appear to be off=20
center, since the axes+labels may not have been centered in the figure wind=
ow=20
in the first place. =20
> * the text color is not being respected
=46ixed in cvs.
> * to get the width and height of the string, I tex the individual
> strings separately, run dvips on them, and get the bounding box
> from the generated file. This all happens with caching in
> matplotlib.texmanager. Right now the fontsize is being ignored in
> this process so the layout will be off for nonstandard font sizes
> -- anything other than the default design size of latex which
> defaults to 10pt I think.
This really is fixed now, for both horizontal and vertical alignment.
> * the text doesn't scale right if you provide a size arg to
> includegraphics, eg [width=3D4.in]
This is expected behavior for PSfrag. You should instead wrap \includegraph=
ics=20
in either a \resizebox or a \scalebox to rescale the text with the figure.=
=20
It looks like tex_demo.py, without caching, takes about 30% longer with LaT=
eX=20
than it does for Tex (3 seconds vs 2.3 seconds on my computer). So CVS is=20
back to using TeX. We may want to include a link (or a copy) of this pdf on=
=20
the MPL website: http://www.csit.fsu.edu/~mimi/tex/tex-refcard.pdf, the=20
source declares it to be freely distributed.
Darren

Hi,
I made a suggestion for improving imshow performance for plotting an
image already in byte string form a while ago; some of the results are
currently in CVS. I seems that other changes made to CVS at the same
time or since mean that the floating point buffer source code is now
much faster and I'd suggest taking anything sourced from my code back
out.
Nick

>>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
 Nicholas> Running python -c "import pylab" fails if numarray is
 Nicholas> specified in .matplotlibrc. Failure is due to ticker.py
 Nicholas> attempting to import numerix.average which is only
 Nicholas> present using the Numeric backend.
Fixed in CVS ticker.py revision: 1.26
Thanks!
JDH

Running python -c "import pylab" fails if numarray is specified
in .matplotlibrc. Failure is due to ticker.py attempting to import
numerix.average which is only present using the Numeric backend.
This turned out to be useful for me as it made me realise I'd forgotten
to change back to Numeric after trying out numarray for a task - but for
others it's probably less useful.
-- 
Nicholas Young

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> I just noticed that the following script generates a
 Darren> diagonal line that looks like it was drawn with a really
 Darren> unsteady hand:
 Darren> from pylab import frange, plot, show
 Darren> plot(frange(-1,1,.01)*1e10) show()
 Darren> The problem is not noticable for a small number of points,
 Darren> such as plot(frange(-1,1,.5)*1e10). I tried clearing
 Darren> site-packages, rebuilt MPL-0.80, the problem appears to be
 Darren> in CVS.
w/o testing, I'll hazard a guess that this is due to a workaround I
have never been able to figure out with how agg does subpixel
rendering
Try commenting out these lines in _backend_agg.cpp in the draw_lines
function
 thisx = (int)thisx + 0.5;
 thisy = (int)thisy + 0.5;
These lines snap all the x and y points to pixel centers. If you
don't use pixel centers, agg will draw lines of different widths and
heights depending on the subpixel fraction. This is only apparent for
vertical and horizontal lines, generally, but is glaring for ticks and
grid lines. In the past, I've added a hack to only do snap to pixel
for horizontal and vertical lines with 2 points, which fixes the
special case problems of ticks and grids
I raised this issue with Maxim on the agg mailing list
http://sourceforge.net/mailarchive/message.php?msg_id=8575544
and he responded by writing this page
http://antigrain.com/tips/line_alignment/line_alignment.agdoc.html
which I still haven't been able to digest sufficiently in a way that
fixes this problem generally.
I reinstated in CVS a temporary hack which only does the snapto pixel
trick for len(2) lines. Should work well for most use cases. Give it
a try.
JDH

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> On a related subject, tex layout via text.usetex does not
 Darren> appear to be working at the moment. I tried undoing my
 Darren> changes but was not able to get the old results back. Did
 Darren> I break this or did I catch it in transition?
This is totally experimental and will break all backends except agg --
I will handle this more elegantly once I figure out how I want to do
it, but right now am trying to fix low level problems like getting the
alpha channel right (am working with dvipng author for the next dvipng
release to get proper access to alpha channel) and then to handle
rotation. Once all of that is working I can work out the interface so
that it plays nicely with other backend.
With the revision I just checked into CVS, you should get TeX rasters
in agg if you set usetex (they will look crappy because of the alpha
problem). But I'm optimistic that I can clear up all these problems
in a couple of weeks time. If you get psfrag in decent shape, we'll
be in good shape for a TeX enabled 0.81 release...
 Darren> The horizontal placement appears to be fixed in CVS. I
 Darren> haven't gone searching for trouble in the vertical layout
 Darren> yet.
Unless you fixed it, I would be surprised...
JDH

I just noticed that the following script generates a diagonal line that loo=
ks=20
like it was drawn with a really unsteady hand:
from pylab import frange, plot, show
plot(frange(-1,1,.01)*1e10)
show()
The problem is not noticable for a small number of points, such as=20
plot(frange(-1,1,.5)*1e10). I tried clearing site-packages, rebuilt MPL-0.8=
0,=20
the problem appears to be in CVS.
Darren

I played with the new latex backend tonight, and made some incremental=20
improvements. texmanager now calls latex instead of tex, so we can make use=
=20
of some of the more complex layout commands, \frac{}{} for instance. A new=
=20
version of tex_demo.py is in cvs, try running:
> > python examples/tex_demo.py -dLaTeX
> > latex tex_demo.tex
> > dvips -o tex_demo.ps tex_demo.dvi
> > ggv tex_demo.ps
On a related subject, tex layout via text.usetex does not appear to be work=
ing=20
at the moment. I tried undoing my changes but was not able to get the old=20
results back. Did I break this or did I catch it in transition?
>
> There are a few problems
>
> * the page width and figure placement in the latex document are off
> center
>
> * the text color is not being respected
>
> * to get the width and height of the string, I tex the individual
> strings separately, run dvips on them, and get the bounding box
> from the generated file. This all happens with caching in
> matplotlib.texmanager. Right now the fontsize is being ignored in
> this process so the layout will be off for nonstandard font sizes
> -- anything other than the default design size of latex which
> defaults to 10pt I think.
The horizontal placement appears to be fixed in CVS. I haven't gone searchi=
ng=20
for trouble in the vertical layout yet.
>
> * the text doesn't scale right if you provide a size arg to
> includegraphics, eg [width=3D4.in]
Darren

>>>>> "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