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