matplotlib-devel Mailing List for matplotlib (Page 515)

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

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

Ahhh - Thanks!  I was wondering if both axes would scale when doing a=20
zooming operation but I hadn't had time to try it out.  Thanks for the=20
example, that's exactly what I was looking for.

Ted
ps: I too am on the list.

At 03:12 PM 5/20/2005, Baptiste Carvello wrote:
>Ted Drain a =E9crit :
>>I was playing with twinx() a little tonight from the pylab.py file and=20
>>have a small suggestion.  I think twinx() should call (before creating=20
>>the new axes):
>>gca().yaxis.tick_left()
>>Currently, after calling twinx(), then new axis tick marks correctly=20
>>appear on the right side of the plot.  However, the major tick marks from=
=20
>>the left hand side Y axis also appear on the right side of the plot which=
=20
>>is a little confusing.
>indeed, this should be fixed.
>
>>Also, since we have twinx(), it would be nice to have twiny():
>>def twiny(ax=3DNone):
>>     """
>>     Make a second axes overlay ax (or the current axes if ax is None)
>>     sharing the yaxis.  The ticks for ax2 will be placed on the top,
>>     and the ax2 instance is returned.  See examples/two_scales.py
>>     """
>>     if ax is None:
>>         ax=3Dgca()
>>     ax.xaxis.tick_bottom()
>>
>>     ax2 =3D gcf().add_axes(ax.get_position(), sharey=3Dax, frameon=3DFals=
e)
>>     ax2.xaxis.tick_top()
>>     ax2.xaxis.set_label_position('top')
>>     draw_if_interactive()
>>     return ax2
>We could do that. The only reason we didn't yet is because nobody thought=
=20
>of a clear use case. If you have one, it can be done. However, see below.
>
>>The case I'm thinking of where twiny() would would be useful is one that=
=20
>>we hit a lot at work.  Time is represented on the X axis and we want=20
>>multiple label types.  So we'd like to have the bottom axis be time in=20
>>UTC and the upper axis to be PST or some other local time frame.  I'm not=
=20
>>sure whether or not it would be best to replot the data using twiny() or=
=20
>>to try and set up a custom formatter on the second X scale since in my=20
>>scenario there aren't two sets of data.
>I wouldn't do that. The 2 x axes won't stay in sync if you do a zoom or a=
=20
>rescale. What twiny is for would be if you need a different scale.
>
>On the contrary, you should use twinx for that, as follows:
>
> >>> from pylab import *
> >>> from pytz import timezone
> >>> from datetime import datetime
> >>> from matplotlib.dates import DateFormatter, HourLocator, DayLocator,=
=20
> date2num
> >>> from matplotlib.axis import Ticker
>
> >>> tz=3Dtimezone('US/Pacific')
> >>> utc=3Dtimezone('UTC')
> >>> start=3Ddate2num(datetime( 2005, 05, 20, 21, 12 ,tzinfo=3Dtz))
> >>> T=3Darange(0,1.5,0.01)
> >>> V=3Drand(len(T))
>
> >>> plot(start+T,V)
> >>> ax=3Dgca()
> >>> ax2=3Dtwinx()
> >>> gcf().sca(ax)
>
> >>> ax2.yaxis.set_visible(False)
>
> >>> ax.xaxis.set_major_locator(DayLocator(tz=3Dtz))
> >>> ax.xaxis.set_major_formatter(DateFormatter('%d %b',tz=3Dtz))
> >>> ax.xaxis.set_minor_locator(HourLocator(range(0,25,6), tz=3Dtz))
> >>> ax.xaxis.set_minor_formatter(DateFormatter('%H:%M',tz=3Dtz))
> >>> ax.xaxis.tick_bottom()
> >>> ax.set_xlabel('US/Pacific')
>
>
> >>> ax2.xaxis.major=3DTicker()
> >>> ax2.xaxis.minor=3DTicker()
> >>> ax2.xaxis.set_major_locator(DayLocator(tz=3Dutc))
> >>> ax2.xaxis.set_major_formatter(DateFormatter('%d %b',tz=3Dutc))
> >>> ax2.xaxis.set_minor_locator(HourLocator(range(0,25,6), tz=3Dutc))
> >>> ax2.xaxis.set_minor_formatter(DateFormatter('%H:%M',tz=3Dutc))
> >>> ax2.xaxis.tick_top()
> >>> ax2.set_xlabel('UTC')
> >>> ax2.xaxis.set_label_position('top')
>
> >>> draw_if_interactive()
> >>> show()
>
>note that if you do not track cvs, the minor tick labels on the top axis=20
>will not print, due to a known bug, fixed in cvs.
>
>Cheers,
>Baptiste
>
>PS: don't CC me in replies, I'm subscribed to the list. If you also are,=20
>please say so.

I was playing with twinx() a little tonight from the pylab.py file and have 
a small suggestion.  I think twinx() should call (before creating the new 
axes):

gca().yaxis.tick_left()

Currently, after calling twinx(), then new axis tick marks correctly appear 
on the right side of the plot.  However, the major tick marks from the left 
hand side Y axis also appear on the right side of the plot which is a 
little confusing.

Also, since we have twinx(), it would be nice to have twiny():

def twiny(ax=None):
     """
     Make a second axes overlay ax (or the current axes if ax is None)
     sharing the yaxis.  The ticks for ax2 will be placed on the top,
     and the ax2 instance is returned.  See examples/two_scales.py
     """
     if ax is None:
         ax=gca()

     ax.xaxis.tick_bottom()
	
     ax2 = gcf().add_axes(ax.get_position(), sharey=ax, frameon=False)
     ax2.xaxis.tick_top()
     ax2.xaxis.set_label_position('top')

     draw_if_interactive()
     return ax2


The case I'm thinking of where twiny() would would be useful is one that we 
hit a lot at work.  Time is represented on the X axis and we want multiple 
label types.  So we'd like to have the bottom axis be time in UTC and the 
upper axis to be PST or some other local time frame.  I'm not sure whether 
or not it would be best to replot the data using twiny() or to try and set 
up a custom formatter on the second X scale since in my scenario there 
aren't two sets of data.

Ted

If you are using python for high performance or scientific computing,
could I ask you to send me a blurb (one or two sentences) on what you
are using it for and if you have any publications or references
related to this work (the refs don't have to be specifically about the
python stuff) please include them (extra points for bibtex).

I am writing some grant text justifying python in scientific computing
and would like to have a range of examples across disciplines to
provide.  

If I could get these today or tomorrow that would be very helpful!
Please send these to me off list.

Thanks!
JDH

John,
Sorry about that - you didn't miss any emails.  I put it on my to-do list 
and then it got swamped w/ other work and I sort of forgot about it.

We've made a few bug fixes w/ regard to keyboard focus so I incorporated 
those into the Fernando's version of the backend.  Attached is the file 
that contains Fernando's mod's for ipython and those bug fixes.  Everything 
seems to be working fine w/ his changes.

Ted

At 09:40 PM 5/17/2005, you wrote:
> >>>>> "Ted" == Ted Drain <ted...@jp...> writes:
>
>     Ted> Sounds good.  I'll take a look at it tomorrow (Thursday).
>
>     Fernando> With these changes and the corresponding ones to ipython
>     Fernando> (not in CVS yet, give me a day or two), it becomes
>     Fernando> possible to use ipython to interactively drive Qt
>     Fernando> applications, including matplotlib interactive plotting
>     Fernando> with the QtAgg backend.
>
>     >>  Hey guys thanks for working on this -- Ted and colleagues at
>     >> JPL, if you haven't used ipython for interactive plotting with
>     >> mpl, it is very nice, and I definitely recommend giving it a
>     >> try when Fernando gets his changes in CVS.  Could you all look
>     >> over this patch and make sure it doesn't conflict with anything
>     >> your group is doing with the qt backend and if it looks good to
>     >> you I'll merge it in.
>     >>
>     >> JDH
>
>Hi Ted,
>
>Any word on this patch?  (did I mess an email?)
>
>JDH

On Tue, 2005-05-17 at 10:55 -0500, John Hunter wrote:
> >>>>> "Patrik" == Patrik Simons <pat...@ne...> writes:
> 
>     Patrik> # Should show orange bars, but shows white, grey, and
>     Patrik> black bars.  from matplotlib.pylab import * figure() t =
>     Patrik> [1,2,3] bar(t, t, color=(1.0, 0.5, 0.0)) show()

>     Patrik> Is this surprising behavior really what you want?
> 
> This is a corner case.  matplotlib is pretty friendly when you set
> colors.  In particular, it allows you to use a float and it interprets
> it as grayscale or an rgb tuple.  What you are bumping into is the
> unusual case when the length of your data is exactly three, and it is
> ambiguous whether you want three grayscale values, different for each
> bar, or a single rgb value for all three bars.  It wouldn't happen
> with 10 bars because a 10 length tuple of grayscale floats is not
> ambiguous.
> 
> You can disambiguate by using hex strings or colorname strings

Yes,  and that is what I had to do with the colors I got from a
colormap:

    color = rgb2hex(colormap(x)[:3])

However, what I really would have hoped for is a color class so that I
wouldn't have to worry about rgb versus rgba and the problem above. For
instance, colormap(x) would return a color instance that I can pass to
bar(), and bar() would also understand rgba automatically.

Something like:

import colors

class Color:
    def __init__(self, color):
        self.color = colors.colorConverter.to_rgba(color)

    def __getitem__(self, i):
        return self.color[i]

    def to_hex(self):
        return colors.rgb2hex(self.color[:3])

    def to_rgb(self):
        return self.color[:3]

    def to_rgba(self):
        return self.color

    etc.

-- 
Patrik

On Tuesday 17 May 2005 6:44 pm, 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.  psfrag is a latex package that enables
> you to substitute sentinel strings in an eps figure with latex
> expressions (eg as in xfig).  You create an eps with a bunch of marker
> strings like "psmarker0" or "psmarker1" and then write a latex file
> that does the substitutions
>
> \psfrag{psmarker0}[bl][bl][2.000000][0.000000]{\TeX\ is Number
> $e^{-i\pi}$!} \psfrag{psmarker1}[bl][bl][1.000000][0.000000]{0}
>
> 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.

I don't know what to say, except, Thank you.

> 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
>
>   * 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 text doesn't scale right if you provide a size arg to
>     includegraphics, eg [width=3D4.in]
>
> I'm sure these details can be worked out by someone who has the
> patience to read the psfrag manual closely and knows a bit about tex
> and dvips -- the backend is only 180 lines of code.  I'm kind of busy
> right now with other work, so I was hoping some enterprising soul
> would like to take this and run with it, polish it, fix it and test
> it....  Darren?  If not, I'll get to it as I can.
>
> Changes in CVS

I'll be on a bus 24 of the next 60 hours, to get to my brother's graduation=
=2E=20
I'll print out what is in cvs and the psfrag manual for the trip, and can't=
=20
wait to get my hands on the code when I get back.

Darren

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.  psfrag is a latex package that enables
you to substitute sentinel strings in an eps figure with latex
expressions (eg as in xfig).  You create an eps with a bunch of marker
strings like "psmarker0" or "psmarker1" and then write a latex file
that does the substitutions

\psfrag{psmarker0}[bl][bl][2.000000][0.000000]{\TeX\ is Number $e^{-i\pi}$!}
\psfrag{psmarker1}[bl][bl][1.000000][0.000000]{0}

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

  * 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 text doesn't scale right if you provide a size arg to
    includegraphics, eg [width=4.in]

I'm sure these details can be worked out by someone who has the
patience to read the psfrag manual closely and knows a bit about tex
and dvips -- the backend is only 180 lines of code.  I'm kind of busy
right now with other work, so I was hoping some enterprising soul
would like to take this and run with it, polish it, fix it and test
it....  Darren?  If not, I'll get to it as I can.

Changes in CVS

JDH

>>>>> "Patrik" == Patrik Simons <pat...@ne...> writes:

    Patrik> # Should show orange bars, but shows white, grey, and
    Patrik> black bars.  from matplotlib.pylab import * figure() t =
    Patrik> [1,2,3] bar(t, t, color=(1.0, 0.5, 0.0)) show()

    Patrik> The culprit is len(left)!=3 in bar() and barh():

    Patrik>         if (is_string_like(color) or (iterable(color) and
    Patrik> len(color)==3 and len(left)!=3) or not iterable(color)):
    Patrik> color = [color]*len(left)

    Patrik> Is this surprising behavior really what you want?

This is a corner case.  matplotlib is pretty friendly when you set
colors.  In particular, it allows you to use a float and it interprets
it as grayscale or an rgb tuple.  What you are bumping into is the
unusual case when the length of your data is exactly three, and it is
ambiguous whether you want three grayscale values, different for each
bar, or a single rgb value for all three bars.  It wouldn't happen
with 10 bars because a 10 length tuple of grayscale floats is not
ambiguous.

You can disambiguate by using hex strings or colorname strings

  colors = 'white', 'gray', 'black'
  bar(t,t,color=colors)

Hope this helps,
JDH

The function set_ticklabels() breaks if given unicode labels. Calling
str() on a unicode string doesn't always work.

--- axis.py.orig	2005-03-28 06:29:11.000000000 +0300
+++ axis.py	2005-05-17 15:01:48.000000000 +0300
@@ -734,7 +734,13 @@
 instances.
 
 ACCEPTS: sequence of strings"""
-        ticklabels = [str(l) for l in ticklabels]
+        tl = []
+        for l in ticklabels:
+            if isinstance(l, basestring):
+                tl.append(l)
+            else:
+                tl.append(str(l))
+        ticklables = tl
 
         self.set_major_formatter( FixedFormatter(ticklabels) )

-- 
Patrik

# Should show orange bars, but shows white, grey, and black bars.
from matplotlib.pylab import *
figure()
t = [1,2,3]
bar(t, t, color=(1.0, 0.5, 0.0))
show()

The culprit is len(left)!=3 in bar() and barh():

        if (is_string_like(color) or
            (iterable(color) and len(color)==3 and len(left)!=3) or
            not iterable(color)):
            color = [color]*len(left)

Is this surprising behavior really what you want?

-- 
Patrik

Hi Ken,

Thanks for the report.  It seems sort of odd that this
doesn't show up on Windows or Mac, but it does seem like 
a fine idea to force the args of SetWidth, etc to be 
integers.

I'll change this in cvs.  Thanks!!

--Matt

On Mon, 16 May 2005, Ken McIvor wrote:

> While trying out the new printing support in matplotlib 0.80's WxAgg backend, 
> I encountered the following DeprecationWarning when calling 
> FigureCanvasWxAgg.Printer_Preview().
> 
>    /usr/lib/python2.3/site-packages/wxPython/gdi.py:77: DeprecationWarning:
>    integer argument expected, got float
>      val = gdic.wxBitmap_SetWidth(self, *_args, **_kwargs)
>    /usr/lib/python2.3/site-packages/wxPython/gdi.py:80: DeprecationWarning:
>    integer argument expected, got float
>      val = gdic.wxBitmap_SetHeight(self, *_args, **_kwargs)
> 
> A little digging located the problem in backend_wx.PrintoutWx.OnPrintPage() on 
> lines 1906 and 1907.  Wrapping a call to int() around the arguments of 
> SetWidth() and SetHeight() there solves this problem.
> 
> I'm not sure that a two line change warrents a patch, but I'll happily submit 
> one if asked.
> 
> Ken
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

While trying out the new printing support in matplotlib 0.80's WxAgg backend, 
I encountered the following DeprecationWarning when calling 
FigureCanvasWxAgg.Printer_Preview().

   /usr/lib/python2.3/site-packages/wxPython/gdi.py:77: DeprecationWarning:
   integer argument expected, got float
     val = gdic.wxBitmap_SetWidth(self, *_args, **_kwargs)
   /usr/lib/python2.3/site-packages/wxPython/gdi.py:80: DeprecationWarning:
   integer argument expected, got float
     val = gdic.wxBitmap_SetHeight(self, *_args, **_kwargs)

A little digging located the problem in backend_wx.PrintoutWx.OnPrintPage() on 
lines 1906 and 1907.  Wrapping a call to int() around the arguments of 
SetWidth() and SetHeight() there solves this problem.

I'm not sure that a two line change warrents a patch, but I'll happily submit 
one if asked.

Ken

On Sat, 2005-05-14 at 15:42 -0500, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
>     Steve> - consistency with other applications - if you are using
>     Steve> gtk+/GNOME, Qt/KDE, Mozilla or other applications that use
>     Steve> fontconfig then using fontconfig from matplotlib means you
>     Steve> are using the same font-matching library and have access to
>     Steve> exactly the same font files as your other applications.
> 
> This looked to me to be a heavily UNIX oriented system.  Eg, one thing
> the font_manager does is query the win32 registry for font location
> information.  All of the examples I saw on the fontconfig page seemed
> to assume /etc and a unix like file system.  I didn't look too deep,
> though.
> 
> Is this portable?
Fontconfig was developed to work with FreeType, Xft and Unix X-Windows.
However its an independent utility/library, does not require an X
server, and (like GTK+ and GIMP) has since been ported to other systems.

I found this page
http://www.gimp.org/~tml/gimp/win32/downloads.html
which lists fontconfig for Windows.

Steve

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> - consistency with other applications - if you are using
    Steve> gtk+/GNOME, Qt/KDE, Mozilla or other applications that use
    Steve> fontconfig then using fontconfig from matplotlib means you
    Steve> are using the same font-matching library and have access to
    Steve> exactly the same font files as your other applications.

This looked to me to be a heavily UNIX oriented system.  Eg, one thing
the font_manager does is query the win32 registry for font location
information.  All of the examples I saw on the fontconfig page seemed
to assume /etc and a unix like file system.  I didn't look too deep,
though.

Is this portable?

JDH